Profile for q66
- Display name
- nina
- Username
- @q66@gts.q66.moe
- Role
- admin
About q66
Fields
- website
- https://q66.moe
- irc, matrix
- q66, @q66:matrix.org
- xmpp
- me@q66.moe
- signal
- @q66.66
- age
- 31
- pronouns
- she/her
Bio
nyaa~
awkward czech anxiety bundle from a corunya, galicia, spain
cringy leftist, scared of people but still too idealistic for my own good, recovering meanie
computer toucher, serial infodumper, distro person, made @chimera_linux, powerpc enjoyer, into baking bread (sourdough) and sweets, trains, old cars and motorcycles, vintage audio and music, diy, anime, cute things, etc
webkitten at @igalia
formerly @q66
Stats
- Joined
- Posts
- 227
- Followed by
- 437
- Following
- 156
made a big pile of crepes for dinner... guess that solves tomorrow's breakfast as well
it's just 0.5l milk but it makes *a lot*
cooking small amounts of stuff is such a pain
well
i got remote access to a milk-v pioneer box that i'm currently rebuilding the system from scratch on
if it survives the ordeal the architecture support might as well be kept but it all depends on the next few days
if i do keep it, it'll be with fresh repos built with tests newly enforced
it's called electron because using it is always a negative thing
bureaucracy is a fascinating thing
it's fun how some things can be supposedly important but in reality completely meaningless because they change literally nothing in practice
and how whether it has a real impact on your life depends solely on the goodwill of the person handling your case
would anyone be mad if i actually dropped riscv64 support
this emulator situation is unsustainable (especially with go world rebuilds that happen on every go update the qemu-user randomly hangs about 1/3 of the time, requiring me to manually stop and restart the builds) on top of being by far the slowest builder
and reasonable hardware just isn't appearing and as far as i can tell there isn't going to be anything anytime soon
i really tried but this sucks...
if someone does have any alternative ideas, please do tell, i'm all ears...
the deficiencies of the c++ iostream interface are known for 20+ years and considering foo << bar << baz is just two function calls in a trenchcoat it behaves exactly as any two function calls that alter global state would tbh, not sure why everyone is so surprised
i always have this feeling of impending doom when update check shows the chromium major version number went up
at least unlike all my other anxiety episodes and other negative moments this one makes sense because it 99% means they broke, erm, refactored, some shit i have to fix
longpost about flatpak and why it's not so good as well as perhaps good in some ways
well since i got reminded of it might as well write down my thoughts a bit
soooo, about flatpak
there is a lot of people these days pushing for some form of flatpak maximalism so that fewer things go in distros and you have One True Source for distribution of user level apps
it works everwhere, distribution maintainers get less pain, everything is good, right?
well, i wish, but not quite...
in practice, as someone who really cares about software portability in many forms (between cpu architectures, between toolchains, etc.) because as i see it it's fundamental for having actual control of your computing platform as a user, flatpak is in some aspects a step back - for one it targets a largely unified toolchain (and configuration) and support for non-x86/arm platforms is poor, which means that we are losing the heterogeneity that has the benefit of increasing the chances of finding actual code problems, and we are also losing the potential extra hardening that some distros go for at compiler level
and there are some future consequences looming over those who currently appreciate the practical portability within the x86 ecosystem as in being able to install their apps on any distro - since flatpak runs a separate namespace with no service management (at the moment), that makes it great for simple apps that are just foreground processes, but anything that needs some auxiliary services to go with it is currently left with nothing but just ad-hoc running them unsupervised (that's why any flatpak thing that comes with dbus services at the moment relies on unsupervised traditional activation); this is a step back for robustness, so i'm sure someone will try to come up with a solution for it eventually, and i don't see that happening without being heavily tied into systemd, and everyone else at best being left with the halfbaked current situation with no way out
so while flatpak is excellent for running stuff you don't have packaged in your distro, and perhaps the sandboxing stuff does have some merit (though i think it's largely overstated in practice), it's something we should be very careful about, especially if we are running something that is significantly different from the red hat style ecosystem that the flatpak people are driving
broke: "our distro is specifically compiled to utilize x86_64-v99, so it requires cpus no older than 3 years, we do that for a 1% performance gain"
woke: "our distro targets 7 architectures, two of them dead, and i run the same one on my laptop, phone, router, 4 servers, and a 2001 mac"
if you thought build infrastructures had to be complex, chimera's build infra works roughly like this:
* buildmaster receives a git event "hey, something changed"
* buildmaster tells every worker machine "hey, something changed"
* every worker pulls its copy of cports and tells cbuild "hey, something changed, build whatever changed"
* on success, rsync uploads the changes (first all new packages in one run, then indexes + delete old ones to ensure consistency)
there is no state or cache because cbuild parses and sorts everything it needs on every run