@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)
@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
@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
@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)
@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
@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)
@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)
@lanodan i promise it will actually report desktop properly if you launch it properly as the sole thing (modern applications should launch properly too)
i will probably package the rest of it and push it to user/ repo so people can have some fun (but of course, this is an ancient and very insecure codebase and i had to disable all toolchain hardening and more to get it to work... old C/C++ is "fun" and i don't entirely recommend running this as a regular thing)
@lanodan i couldn't be bothered to actually log out of my primary desktop, so i just startx'ed on another tty (and of course, elogind and dbus don't entirely like it :))
the switch has introduced another problem and that's a build-time depcycle (xz->gettext->libxml2->xz) - which is the primary reason we have not switched (pregenerated autotools files solve that)
that said, there is no difference otherwise, since the malicious condition does *not* trigger even with the upstream release tarball
the positive part is that we are not affected (several compile-time preconditions are not met for the backdoor to even get compiled in, such as gcc compiler, gnu linker, ifunc support, linux-gnu triple) and neither is our infrastructure (there are a couple debian servers, still on xz 5.4)
that said, everyone check their systems (whatever they are) and stay safe :)
@lanodan@Gottox@ariadne what something else? there *wasn't* anything else they could have realistically used at the time (to a degree there still isn't)
@lanodan@Gottox@ariadne the latter is the "traditional" way and it was bound to happen that as soon as there was something better somebody would jump on it
unfortunately we still have to live with the latter (gnome is nice enough that they still maintain vast majority of the old paths even though they have no obligation to) though in a few months we'll be ready to switch to a better architecture