Dave Anderson
@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 :)
Chimera Linux
@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)
Chimera Linux
@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)
Dave Anderson
@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.
Chimera Linux
@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
Dave Anderson
@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)
Dave Anderson
@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 ❤️
Chimera Linux
@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)
Dave Anderson
@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.
Chimera Linux
@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
Dave Anderson
@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.
Chimera Linux
@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
Chimera Linux
@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)
Dave Anderson
@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.
GNU social JP is a social network, courtesy of GNU social JP管理人. It runs on GNU social, version 2.0.2-dev, available under the GNU Affero General Public License.
All GNU social JP content and data are available under the Creative Commons Attribution 3.0 license.