Post AhKAYDyTeUIaix6PyK by danderson@hachyderm.io
(DIR) More posts by danderson@hachyderm.io
(DIR) Post #AhKAEpCNXlcKNhM27c by bitprophet@social.coop
2024-04-26T22:02:28Z
1 likes, 0 repeats
Getting really sick of painstakingly migrating to some Cool New Technical Thing With Superpowers and then whoops, It's All Ethics Violations after a while.First #Kagi - CEO is a white dude who can't read the room when a bunch of users raise serious concerns re: suicide warnings, .ru indexes, Brave collab, etc.Now #Nix / #NixOS - BDFL is a white dude who can't read the room when a bunch of users raise serious concerns re: toxic members, shitty governance, MIC sponsorship, etc.
(DIR) Post #AhKAEr7UOutWL759mK by bitprophet@social.coop
2024-04-26T22:03:18Z
0 likes, 0 repeats
I feel like there's a pattern here but I just can't put my cishetwhyteguy finger on it.
(DIR) Post #AhKAEt6V1ZI6UcdOVs by bitprophet@social.coop
2024-04-26T22:24:28Z
0 likes, 0 repeats
“Wow why can’t we just keep our focus on technical things instead of all this PoLiTiCs 🥴”
(DIR) Post #AhKAJNfXKGV4RnAIim by danderson@hachyderm.io
2024-04-27T07:07:50Z
1 likes, 0 repeats
@bitprophet Genuinely exhausting. I'm picking my next OS in part based on whether I've ever heard _anything_ about it, on the theory that it means it has its house in order and isn't trying to sell me religion. That sounds like a nice place to be, for a while.
(DIR) Post #AhKAYAPctbdffzm2jY by danderson@hachyderm.io
2024-04-27T17:27:21Z
0 likes, 0 repeats
@valpackett @nogweii @bitprophet @chimera_linux Yeah I wasn't sure about the atomic fedoras, but I think toolbox/distrobox is what's going to make me give them a try for at least some time. It captures some of the ways I like to run my computers reasonably well, and combined with Flatpak for apps I think I can run a computer like that.Chimera is super interesting, but a lot of its design decisions make it very alien for non-free linux software, and I need a break from that for a while :)
(DIR) Post #AhKAYBTYwSNiyUchVY by danderson@hachyderm.io
2024-04-27T17:29:26Z
0 likes, 0 repeats
@valpackett @nogweii @bitprophet @chimera_linux I don't love it, but realistically the linux target companies build for is ubuntu, so any system that doesn't look like ubuntu at the most basic layers (gcc, glibc, FHS layout etc.) is swimming upstream to get that stuff working. I've lived with that swimming upstream for several years, and my arms are tired 😂 Atomic Fedora with flatpak/toolbox feels like a better balance for me, because I can drop into near vanilla ubuntu when needed.
(DIR) Post #AhKAYCIbsfDNWoVT4i by chimera_linux@floss.social
2024-04-27T17:36:11Z
0 likes, 0 repeats
@danderson @valpackett @nogweii @bitprophet btw, we have flatpak working just fine ;) (as well as podman/containerd and various other stuff you can use to spin third party containers)
(DIR) Post #AhKAYDBCbgsqG834AS by danderson@hachyderm.io
2024-04-27T18:24:49Z
0 likes, 0 repeats
@chimera_linux @valpackett @nogweii @bitprophet Huh, I'm honestly surprised! I expected LLVM+musl to be a too different ABI to make app distribution stuff work right. Either there's less implicit dependency on gcc+glibc in the world than I thought, or y'all have done a lot of work make the worlds meet. Either way, it's very nice to hear :)Chimera makes other choices that are very reasonable, but that I disagree with. So I think it's still not for me, but I'm glad it exists ❤️
(DIR) Post #AhKAYDyTeUIaix6PyK by danderson@hachyderm.io
2024-04-27T18:41:01Z
0 likes, 0 repeats
@chimera_linux @valpackett @nogweii @bitprophet (in particular, I'm a huge fan of systemd, and so distros that don't use it are off the table. Chimera has a whole FAQ about it, so I won't relitigate in detail. I think it still perpetuates some unhelpful myths about systemd, but ignoring those small parts, I think Chimera's analysis is very reasonable, and what you ended up doing is a very valid point in the design space. I will definitely watch how it develops, but for now it's not for me)
(DIR) Post #AhKAYEkKmYa17NUdZA by chimera_linux@floss.social
2024-04-27T18:57:29Z
0 likes, 0 repeats
@danderson @valpackett @nogweii @bitprophet i'm a little curious about what myths there supposedly are in the FAQ, as it was written to provide an entirely neutral stance
(DIR) Post #AhKAYFNgQG3V5Pu3to by danderson@hachyderm.io
2024-04-27T19:17:58Z
0 likes, 0 repeats
@chimera_linux @valpackett @nogweii @bitprophet I think it does a good job!The section about unrelated components (IMO) implies that you are forced to use all or nothing, which is one of the most commonly repeated myths about systemd (see also 1, 6, 12 in http://0pointer.de/blog/projects/the-biggest-myths.html). Maybe I'm reading too much between the lines, but I read that and think "oh the conflation of monorepo source organization and monolithic output again".I do agree about various components being hit and miss though.
(DIR) Post #AhKAYGQYX3woKcFs12 by chimera_linux@floss.social
2024-04-27T20:00:27Z
0 likes, 0 repeats
@danderson @valpackett @nogweii @bitprophet it's not really the same point though; that part of the FAQ talks specifically about how the individual components are all tied into libbasic/libshared, which is a kitchen sink of all sorts of functionality and entirely interwoven (every part of it directly or indirectly includes half of the rest), which makes isolating individual programs super difficult (i spent roughly a month isolating https://github.com/chimera-linux/sd-tools and it was not a fun time)
(DIR) Post #AhKAYHML4EAVDpI156 by chimera_linux@floss.social
2024-04-27T20:01:20Z
1 likes, 0 repeats
@danderson @valpackett @nogweii @bitprophet additionally some of the components would really benefit from being properly buildable standalone; for instance we have to carry like half the musl patches for systemd just to build udev, alongside a large bunch of build system hacks, because it forces you to build systemd core no matter what (which we discard)
(DIR) Post #AhKAYISkxqtce1Ieiu by danderson@hachyderm.io
2024-04-27T19:24:47Z
0 likes, 0 repeats
@chimera_linux @valpackett @nogweii @bitprophet The section on non-portability is an accurate description of current reality, but maybe also misrepresents why. systemd+musl comes up on systemd-devel@ periodically, and the position is consistently that systemd uses posix APIs where possible. But if glibc provides something useful and generic (an old example from my email is parse_printf_format()), they're not going to implement their own, that should be on musl or some 3p shim.
(DIR) Post #AhKAYLbNIGZYNcM54a by danderson@hachyderm.io
2024-04-27T19:27:11Z
0 likes, 0 repeats
@chimera_linux @valpackett @nogweii @bitprophet tbh that section is fair enough, I think it's presenting facts with the bias of "systemd should do extra work to work with only union(glibc, musl) APIs", whereas systemd has the bias that musl/musl users should do the extra work if musl chooses to diverge.Regardless, I think the position that "okay, systemd doesn't want to do the work and neither do we, so bye bye systemd" is perfectly reasonable.
(DIR) Post #AhKAYOSydwdbGRRuts by danderson@hachyderm.io
2024-04-27T19:29:42Z
0 likes, 0 repeats
@chimera_linux @valpackett @nogweii @bitprophet Finally, "one of the goals in Chimera is to implement the actual useful systemd functionality, but ..." is not very neutral. "actual useful systemd functionality" declares Chimera's bias that systemd likes to implement things that aren't useful. That's fine obviously, just an opinion, but it's not neutral compared to e.g. "one of the goals in Chimera is to implement a subset of systemd functionality, in a way that fits our preferences better".
(DIR) Post #AhKAYREYM1slqZiwKm by danderson@hachyderm.io
2024-04-27T19:32:56Z
0 likes, 0 repeats
@chimera_linux @valpackett @nogweii @bitprophet Like I said right at the top, this is all nitpicking. I've been exposed to a lot of systemd bashing over the years, and your FAQ is not that. I would say it clearly shows you're annoyed at systemd for not supporting musl, and that you think the project's design is flawed. I partially disagree, but reading the FAQ I definitely understand why, and IMO you're taking a very reasonable alternative path. I'll keep an eye on Dinit and see how it evolves!
(DIR) Post #AhKAc7LWEovbKCjiqW by chimera_linux@floss.social
2024-04-27T20:05:22Z
1 likes, 0 repeats
@danderson @valpackett @nogweii @bitprophet there is some entirely non-portable and sketchy functionality used by systemd that imo has no justification whatsoever; for instance the way it assumes object sizes via malloc_usable_size rather than tracking its own memory properly is really bad and has bitten them even on glibc before (https://github.com/systemd/systemd/issues/22801) and the basis for using it is entirely misguided
(DIR) Post #AhKAc8vMN3BwDeVrLk by chimera_linux@floss.social
2024-04-27T20:09:28Z
1 likes, 0 repeats
@danderson @valpackett @nogweii @bitprophet additionally i'm also not a fan of their blatant disregard of cost vs usefulness; for instance it has some iirc 1500 lines of code whose sole purpose is printing ellipsis in unicode in the logs; the code for doing so is non-trivial and possibly a source of annoying bugs and corner cases, while the actual usefulness of it seems dubious at best
(DIR) Post #AhKBhUqoNKrLcqVC2C by danderson@hachyderm.io
2024-04-27T20:16:27Z
0 likes, 0 repeats
@chimera_linux Yup, that is all very fair. A lot of the glibc dependence is self-reinforcing, the longer it's the only implementation the more it makes sense to depend on it deeper. Maybe this was fixable 10y ago, but I agree that it's not likely to change now.
(DIR) Post #AhKBhVUryOtzd5FBTM by chimera_linux@floss.social
2024-04-27T20:23:35Z
1 likes, 0 repeats
@danderson in any case, i see this as an opportunity; whenever we are creating new APIs, they are vendor-neutral abstractions so that software utilizing them can work on top of anything (whether it's our own stuff, or systemd, or something completely different like a BSD)it's fine for systemd to have its own APIs, but it's not a correct abstraction level for higher level applications to rely on (the low level systemd api is not even that pleasant to work with in the first place)