 not surprised that @postmarketOS folks pulled the trigger on systemd in alpine we have promised to build something better than openrc for years, but it still isn’t here. meanwhile, the polyfills for various systemd apis to work on openrc do not actually work correctly in many cases, leading to unnecessary bugs on the desktop. i think @alpinelinux should join pmOS in getting off openrc, the project is basically on life support anyway and the maintainers primarily focus on Gentoo usecases also. 150 comments
@sertonix what is the alternative? alpine has been waiting over half a decade for s6-rc to be ready. it still isn’t even at usability parity with openrc. show me a project with working polyfills and a usable and concise service management model that exists today that isn’t systemd, and there is something to talk about. but all there is are toy projects designed by random techies who haven’t thought about what a servicing lifecycle actually looks like, and systemd.  @ariadne I also had good experience with artix. It might be that I don't notice issues that other people have without systemd since I try to pick lean software but if you look at the alpine linux about page that is the target of alpine linux: simple  @ariadne @sertonix The reason why s6-rc isn't at usability parity with openrc is because openrc cheats by embedding itself with a shell, which means it's dynamic everywhere, which makes it powerful but very hacky. Using similar shortcuts would lead to similar results, and getting the same amount of power with a clean infrastructure is *difficult*. (Edit: typo) @mary alpine has been waiting for s6-rc for almost half a decade at this point. meanwhile the world is moving on, and openrc is increasingly not suitable for the things people want to do with alpine. @mary there is no service management framework built around runit that is suitable for a mainline distro like alpine (this is not an invitation to tell me about your friend’s pet init system. designing a service management framework for an operating system is harder than it looks. i’ve looked at all of the options outside systemd, and frankly openrc is the one with the most maturity. the landscape is bleak.) and, frankly, whatever you want to say about @pid_eins, he is one of the rare software engineers who understands both the technical aspects of creating software and also the usability aspects. this is something that every other proposed service management framework lacks. it’s not necessarily a bad thing, but it is good to have a maintainer at the top that has good taste in both departments.  @dysfun i’m not wrong though. i am not saying systemd is *good*, but the tooling around it feels solid. much more so than openrc, or any of the other hobbyist projects. @dysfun in general i think it is his strongest quality. he knows enough to get things going on the development side of things, but where he does his best work is in designing tools. @dysfun pulseaudio failing to route audio doesn’t mean that pavucontrol wasn’t a well designed mixer 😂  @dysfun avahi doesn’t have any UI of its own, it hooks into gtk and qt file choosers. distributions also misconfigured avahi in many cases. i can’t actually put that one on him because i’ve seen how the sausage was implemented. @ariadne it has a dbus interface. i'm not very fond of dbus either. @dysfun i mean, same? but that ship sailed well before lennart entered the picture @ariadne @dysfun hm. Somehow my perception is very different here. The time I've sunk into trying to figure out why systemd is (or is not) doing something while wrangling service files is… significant. And pretty much all of my bubble shares this view: it's great while it works, but as soon as something goes wrong you're left digging for scraps of rare helpful output and trying to divine from manpages what is going on. The tools are /horrible/ at telling you /why/ things are as they are. @dysfun @equinox we have had conversations with him over the years and he has largely come around to seeing our thinking on a number of issues, which led to pmOS feeling like they could pull the trigger. i worry more about openrc having basically no maintenance and the code being a minefield of potential CVEs than dealing with lennart on a bad day. i can’t stress this enough. one of the guiding design principles in alpine is that if you have to read a manpage to perform a basic operation as a user, we have already failed. the competition to systemd in service lifecycle management is largely a minefield of tools with cryptic command line switches and other potholes. the tools do not feel good to use. we want a service management system that feels as good to use as apk. there are of course, valid criticisms of systemd. the fact that so much userspace surface is contained in a single project is unpleasant from a technical and governance POV. however, systemd itself is highly modular. the core service management framework is only a few megabytes on disk, which is comparable to openrc. so the people who complain about bloat are likely just not using a properly packaged form of systemd…  @ariadne modularity of some chunks of code is kind of moot when such fundamental parts of the kernel interface (eg. udev) no longer work standalone.  @ariadne @spacehobo but systemd doesn’t actually do that. its a monorepo, but it generates tons of binaries. @ariadne Yeah, I was hoping to wave hands a little wider than I did with the word "runtime", really. @ariadne as a long-time systemd hater I tried out Void, which is on runit, and discovered to my displeasure that the Old Ways are actually super annoying and systemctl is actually a very wieldy way to manage services… but there’s also part of me that appreciated having a system where you could quickly figure out how to enable or disable a service by inspecting its peers in the filesystem. I think systemd is equally guilty of needing a manpage check – I’ve had to google how to read logs so much  @ariadne Lennart is one of the kindest people I've ever met. And this is when he'd have all the rights in the world to be the exact opposite, yet he does not.  @ariadne I'm half sad about it. systemd kinda works and isn't bad but its lock in tactics are bad and now that succeeds yet more. @ariadne honestly the most realistic thing (IMHO) to do is probably to write (or derive from existing systemd code) a bunch of (dependent) libraries that reimplement parts of systemd. Unit file parser. Constraints manager. Service starter. Hotplug handler. Some of the design decisions make things difficult to untangle, but a lot of the underlying building blocks are OK. They're just tied together into an undebuggable opinionated monolith…   @ariadne I've worked with I think 8 different init systems in constrained use cases for work over the years, and the concept of using *any* of them other than systemd for a whole distro is nightmarish (that includes SystemV). @ariadne @postmarketOS @alpinelinux meanwhile systemd wasn’t even accepted in @ariadne @postmarketOS @alpinelinux i just installed alpine today, and yeah, getting pipewire working was *not* fun.  @ariadne @postmarketOS @alpinelinux You are such a sellout! ;-) A very welcome sellout though. ;-) @ariadne I feel like "required reading" for anyone wanting to chime in on this situation is the combination of @aurynn 's "Contempt Culture" and @benno 's Tragedy of Systemd https://blog.aurynn.com/2015/12/16-contempt-culture/ @ariadne @postmarketOS @alpinelinux Is there a blog post or something about this new init system plan? @ariadne @postmarketOS @alpinelinux If everyone is going to get on the systemd bandwagon, then it is important to focus many thousands of eyes on the source code. I would look for race conditions. They will not be obvious. While studying the code, you have to think outside the box, and ask yourself: How can this be attacked? @ariadne Adélie would have switched a few years ago if journald wasn't still joined at the hip with it. If there was an effort to make a systemd without journald I'd be all-in. So tired of dealing with OpenRC bull. See also my thought piece on it: https://catfox.life/2024/01/05/systemd-through-the-eyes-of-a-musl-distribution-maintainer/ |
Gregory's Server
@ariadne Getting off openrc is definetly needed but not to systemd.