Gregory's Server(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.)
|
104 comments
 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.   @luis_in_brief 😭:but I have to run systemctl daemon-reload after I edit a config file for the changes to take effect.  @c0dec0dec0de @luis_in_brief @ariadne auto-reload only makes sense if every possible change you could do touches a single file only. That might be fine for trivial services. But for anything even remotely more complex than hello world you might need to edit two config files, a service file or two, and you really don't want anything to load the cfg while you are just half-way done. Explicit configuration reload is a *good* thing, it allows you to schedule application of multiple changes as one  @pid_eins @c0dec0dec0de @luis_in_brief @ariadne Not only that, I also reflexively save multiple times while editing config files, often with them in unworkable intermediate states. @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  @leftpaddotpy @ariadne @dysfun And it was all modelled on COM by folks who thought Windows was doing things that made sense... @dalias @leftpaddotpy @dysfun well, DCOM really, which is an entirely different animal @leftpaddotpy @ariadne @dysfun There is really a clash of two *philosophies* here: One that believes software systems should be tightly coupled with every piece of software interacting with the events and data of one another, mediated through object oriented abstractions. And one that believes software should be decoupled, staying out of each other's way and exchanging data and reacting to events only through standard data formats and system interfaces. @leftpaddotpy @ariadne @dysfun The former is largely seen as "polished" and "professional looking" and "user-friendly" by techies and industry UX folks. But it also enables a lot of really user-hostile behavior. @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. @ska @ariadne OK, I did not expect to read that today: that sd_notify() is "over-engineered" and "bloated". It's *literally* a frickin env-var-like text string in a datagram to an AF_UNIX socket whose path is passed in an env var. I mean, I can explain the protocol this in a single (one!) sentence. If that's "bloated", then I think you are smoking some really really really good dope, man. No shame in that, but maybe don't comment on the Internet when you do ;-) @ska i don’t think your sd_notify example holds. a child supervisor could hoist the socket along to its parent to solve this problem using SCM_RIGHTS. > This assumption means that the only way to implement readiness notification management in systemd is to have a central supervisor for all the services, which is the exact opposite of modularity. Just set NOTIFY_SOCKET to the socket implementing the trivial protocol, which can be named at random? There is no reason this protocol is at all incompatible with multiple decentralized managers? You just run a socket on each? I can't understand the problem here. @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 I would like to tell you about how I hacked runit until it was mostly unrecognizable, to use on Finnix back in the day. I would like to tell you this as a cautionary tale. @ariadne very interesting thoughts! One thing I wondered through this whole process with postmarketOS, and keep wondering to this date, is why all the people doing alternative init systems to systemd don't sit together and design some spec, that takes proven-right design decisions from systemd. Like let's say, having service-file (like @craftyguy did with superd) and DBUS-api compatibility with systemd. It's day-dreaming to hope that everybody else will adapt to something completely different. |
@ariadne
I wonder if systemd is able to implement a tamagotchi like pet, so we could have an actual pet init system