Email or username:

Password:

Forgot your password?
Top-level
Ariadne Conill 🐰

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.

22 comments
Doridian

@ariadne Not to mention that writing service definitions with systemd is much easier as well <.<

Ariadne Conill 🐰

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…

Howard Chu @ Symas

@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 Conill 🐰

@hyc you can build and deploy udev without the rest of the systemd components

Howard Chu @ Symas

@ariadne you can? hadn't seen anyone do that ever since it got absorbed as systemd-udevd.

Ariadne Conill 🐰

@hyc yes, alpine has considered doing it over eudev

Space Hobo Actual

@ariadne
Me, an intellectual: uses an OS built around busybox, and eschews an init system that combines too many systems into a single runtime.

Ariadne Conill 🐰

@spacehobo but systemd doesn’t actually do that. its a monorepo, but it generates tons of binaries.

Space Hobo Actual

@ariadne Yeah, I was hoping to wave hands a little wider than I did with the word "runtime", really.

Laurent Bercot

@ariadne The granularity of binaries on disk is a very partial indication of the modularity of the software. systemd has good granularity, but it is NOT modular.

Modularity, or lack of, is a property of the *design* and architecture of the software. When I say "systemd is not modular", I mean that its architecture is hostile, it centralizes control and disempowers users.

When I look at one part of systemd, say, one given binary, say I want to replace it: can I do it with knowledge that is purely local to this binary? And the answer is no: the necessary knowledge is still the full
global workings of systemd.

Another example is the sd_notify mechanism, which assumes that the fd you send the notification to (via an overengineered, bloated protocol) is a socket. 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.

@ariadne The granularity of binaries on disk is a very partial indication of the modularity of the software. systemd has good granularity, but it is NOT modular.

Modularity, or lack of, is a property of the *design* and architecture of the software. When I say "systemd is not modular", I mean that its architecture is hostile, it centralizes control and disempowers users.

Lennart Poettering

@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 ;-)

Ariadne Conill 🐰

@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.

Erin 💽✨

@ariadne @ska also i dont’ see why it has to be a central daemon; each supervisor can just listen on whatever socket it wants and set NOTIFY_SOCKET appopriately.

jade

@ska

> 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.

it's zip!

@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

it's zip!

@ariadne basically i want a better service management system with like, comments in every systemd service file telling you which manpage to read as a transitional demand

s00ner🌈

@ariadne I like this philosophy. The first time I installed something with apk, the operation completed so quickly I thought it wasn't working properly. On the flipside, I found openrc to be poorly documented and lacking examples.

LisPi
@ariadne So all management interfaces in Alphine are interactive-first (or only)?

That's the main way I see of making such self-documentation even remotely practical.
Kevin Karhan

@ariadne well, #SystemD is the de-facto Standard for a reason.

#SystemVinit was kinda unworkable, a single #init file quickly becomes unworkable outside of minimalist embedded distros like @OS1337 and #SMF from #Solaris is very intertwined it's Kerbel and Userland

In fact, systemd is a good reimplementation of #LaunchD from #macOS.

And since it has RedHat-Level money and engineering behind it, it works quite well...

And as much as many long for somethibg simpler and easier, I simply doubt we'll see that for the next 5-25 years from now...
youtube.com/watch?v=o_AIw9bGog

@ariadne well, #SystemD is the de-facto Standard for a reason.

#SystemVinit was kinda unworkable, a single #init file quickly becomes unworkable outside of minimalist embedded distros like @OS1337 and #SMF from #Solaris is very intertwined it's Kerbel and Userland

In fact, systemd is a good reimplementation of #LaunchD from #macOS.

Go Up