The perspective from which I care about the advantages is that of a programmer writing daemons: running under a daemon manager (such as, but not limited to, systemd) lets me omit a bunch of code around forking off, daemonisation, automatic restarts, switching uid/gid, logging and rotation. The important thing about these pieces of functionality is that they provide no competitive advantage.
As someone who wants to write a daemon, you need them, but there’s no room to delight anyone by doing them well (unlike the actual functionality for which your daemon is being written) and there’s plenty of room to mess them up and have people yell at you. This is exactly the definition of a losing game.
Eliminating duplicated functionality (that isn’t common, there’s no libdaemonize that everything just links in) reduces the total amount of chaos in the ecosystem.
(I wonder how many incomplete “reimplement systemd in Rust” projects silently exist in different peoples’ home directories?)
BTW: good, clear diction, smooth delivery. You’re doing well at the video part.
I’m considering doing some more articles as videos in the future. It’s just very awkward to reference my speaking notes in VR lol. I need to find a better way to capture my facial movements. Those awkward pauses were because I lost my mouse cursor :D
FD: I’m not a large supporter of SystemD after using it when it was first introduced in Fedora and watching it take over the ecosystem, I do use it and as a sysadmin/SRE type I’m heavily versed in it and how it functions, so, everything with a pinch of salt.
I gave the video a good shot, half the time is spent going over some systemd-ecosystem basics;
The author then makes the case that Alpine is a less attractive development/production-deployment platform due to lack of this ecosystem (though they make effort to avoid directly saying that systemd would be a good solution itself.)
I couldn’t disagree more honestly. I love the concept of Alpine: as small as possible and no smaller.
The attention to minimise dependencies makes it the distro of choice in containers; I’ve even considered (strongly) running it on some machines where systemd would have been a lot of needless complexity.
I think deviating from this path for alpine is a grave error, there will always be a place for a niche system that is small; especially when it’s commonly paired with some other log managment/service orchestrator like Alpine is.
Additionally, it gives people like me an option to run without init systems that could be considered heavy and intrusive with heavy dependency chains.
This seems like a vicious cycle: bloated linux distro is too bloated -> use lightweight distro instead -> lightweight distro does not have all the bells and whistles to support my bloated apps -> introduce bloat to lightweight distro -> bloated linux distro is too bloated -> oh hey, here we go again.
snerk I bet you can observe the same cycle more easily with niche efforts in fields like, say, text editors or X11 WMs? since the lifecycles are probably shorter for individual programs than whole distros. Like how biologists study fruit flies because they don’t have to wait too long for the things to go through entire generations (and they don’t drink human blood).
I’ve seen someone claim that, to study the computer hardware industry, you should study the history of storage devices, because storage manufacturers are the equivalent of the fruit fly: they spawned and died faster than other types of vendors. :)
Since you mentioned WMs… I think dwm is a decent example of a simple program, but if you want to add tons of bells and whistles, there’s a gazillion patches that you can add to your own version of it. Making something bloated by default alienates all users who want something small/simple.
Sort of. What is missing here is the modularity. I need a distro that does not have all the bells and whistles and I can introduce those without the bloat coming with it. There are quite often too many dependencies. Have you seen what is getting installed with something like nodejs? It is madness.
To be fair I’m not advocating for Alpine to adopt systemd, that’s likely technically infeasible. I’m advocating for Alpine to have something similar to the core philosophies of systemd.
Well, in fact systemd does only one thing - start process on system event. That is it, all other things are the consequence of this approach:
we want to activate job on the incoming connection - we need to have a way to specify port on which we want to listen and a way to pass the connection to started process, that is why we need our own approach to inetd/xinetd (and in fact it is IMHO way better approach, as easily support long-running systems, like Erlang, instead spawning new process for each request like it was done in inetd)
we want to activate job depending on date and time - we need to have a way to send event to the PID 1 that “it is a time” and we need to keep time close to “real time”
we want to activate job when there is particular device/path is available - we need a way to send message to the PID 1 about that - we ingested udev
Etc.
So in the end it is simple design that just to provide all of it’s features required some changes in a lot of components to have all events it needed for full power. Could it be messaged better to the community, maintainers could be less of a pricks, etc. But in the end, the core concept is quite simple.
That’s like saying “in fact a nuclear power plant does only one thing - generate electricity from steam. That is it, all other things are the consequence of this approach”
Well, most power plants can be reduced to “we need to spin this rod” (all except PV works like that) and we have few ways to do so:
use steam
use gravity
use wind
And in short it is it. In case of the steam we jus have few different ways to produce it, and nuclear heater is one of them. But I do not see what you wanted to say there. systemd, when dissected, do not have complex ideas behind it. I would even say that these are very good ideas. The problem is that an implementation could be better, similarly to containers and Docker or Unix and files (see Plan 9). With time I have found, that some concepts of the systemd are very nice and provide great improvement over what we had before in Linux world. For example socket activation from systemd is awesome and super simple to handle on the client side, I used exactly the same approach in my Dolores proxy to provide reliable way to listen or request. Passing FDs between processes is something really under appreciated in the *nix world.
Well, apart from the first one ‘too small to fail’, anyway, because who gets to define how small that is exactly? Systemd has a specific goal, to subsume common service management tasks, so clearly it needs to do more things than just an exec(3) call.
… maybe this is a misplaced answer? I want to know where systemd’s philosophy is written down, because you claimed that my preferences are the same as theirs… and I don’t believe that. Or if it’s true, they’re really, really bad at implementing them.
I don’t know about your preferences, but based on the points you stated, and on the points stated in the OP, there is clearly a quite large correspondence. Perhaps you should re-read the OP.
The following description of the ideas behind the systemd approach was first published in the German magazine c’t 13/11 and has been updated in various places before appearing in The H Open.
I don’t know if it fulfills your desires for an overarching philosophy statement though. And frankly, I don’t see why such a document is required. To me systemd fits well into the Unix philosophy of pragmatic problem-solving, not elaborate theory-building.
I read it. It has no statement of goals; it’s literally a high-level tour of what systemd does.
“I don’t see why such a document is required”
If you don’t have goals, you won’t know when you achieved them.
If you don’t publish your goals, people don’t know what they are.
From observation, the goals of systemd are to:
take over all other system daemons, reducing functionality and introducing bugs along the way
make logs hard to search and read (i.e. make it hard to debug)
make machines more fragile
claim speed of boot and dynamic loading as the things that make the suffering worthwhile
It’s utterly against the actual UNIX philosophy, which is this: at any moment a user may change roles to sysadmin or developer, and it is a program’s duty to all three of those roles along with whatever it was going to do in the first place.
Not necessarily! The systemd people clearly have a driving motivation or philosophy that is important to them, and we can glean what it is from what they’ve said about it:
Apologies if I made it sound as if you were, I just didn’t see any mention of anything which follows similar paradigms (like Solaris’ SMF).
Regardless, those things come at a cost (CPU, memory, storage, dependencies, development time, keeping synced with the way systemd is doing things) and you do mention that it is preferable to have a closely integrated ecosystem; which I also wholeheartedly disagree with.
The perspective from which I care about the advantages is that of a programmer writing daemons: running under a daemon manager (such as, but not limited to, systemd) lets me omit a bunch of code around forking off, daemonisation, automatic restarts, switching uid/gid, logging and rotation. The important thing about these pieces of functionality is that they provide no competitive advantage.
As someone who wants to write a daemon, you need them, but there’s no room to delight anyone by doing them well (unlike the actual functionality for which your daemon is being written) and there’s plenty of room to mess them up and have people yell at you. This is exactly the definition of a losing game.
Eliminating duplicated functionality (that isn’t common, there’s no libdaemonize that everything just links in) reduces the total amount of chaos in the ecosystem.
(I wonder how many incomplete “reimplement systemd in Rust” projects silently exist in different peoples’ home directories?)
BTW: good, clear diction, smooth delivery. You’re doing well at the video part.
For $DEITY’s sake, please don’t give Poettering any more ideas!
;)
I’m considering doing some more articles as videos in the future. It’s just very awkward to reference my speaking notes in VR lol. I need to find a better way to capture my facial movements. Those awkward pauses were because I lost my mouse cursor :D
I didn’t notice any pauses? Anything shorter than the time it takes to take a sip of water is just going to get ignored.
FD: I’m not a large supporter of SystemD after using it when it was first introduced in Fedora and watching it take over the ecosystem, I do use it and as a sysadmin/SRE type I’m heavily versed in it and how it functions, so, everything with a pinch of salt.
I gave the video a good shot, half the time is spent going over some systemd-ecosystem basics;
The author then makes the case that Alpine is a less attractive development/production-deployment platform due to lack of this ecosystem (though they make effort to avoid directly saying that systemd would be a good solution itself.)
I couldn’t disagree more honestly. I love the concept of Alpine: as small as possible and no smaller.
The attention to minimise dependencies makes it the distro of choice in containers; I’ve even considered (strongly) running it on some machines where systemd would have been a lot of needless complexity.
I think deviating from this path for alpine is a grave error, there will always be a place for a niche system that is small; especially when it’s commonly paired with some other log managment/service orchestrator like Alpine is.
Additionally, it gives people like me an option to run without init systems that could be considered heavy and intrusive with heavy dependency chains.
So, kindly, Alpine: please don’t.
This seems like a vicious cycle: bloated linux distro is too bloated -> use lightweight distro instead -> lightweight distro does not have all the bells and whistles to support my bloated apps -> introduce bloat to lightweight distro -> bloated linux distro is too bloated -> oh hey, here we go again.
snerk I bet you can observe the same cycle more easily with niche efforts in fields like, say, text editors or X11 WMs? since the lifecycles are probably shorter for individual programs than whole distros. Like how biologists study fruit flies because they don’t have to wait too long for the things to go through entire generations (and they don’t drink human blood).
I’ve seen someone claim that, to study the computer hardware industry, you should study the history of storage devices, because storage manufacturers are the equivalent of the fruit fly: they spawned and died faster than other types of vendors. :)
Since you mentioned WMs… I think dwm is a decent example of a simple program, but if you want to add tons of bells and whistles, there’s a gazillion patches that you can add to your own version of it. Making something bloated by default alienates all users who want something small/simple.
There are SO many mayfly tiling x11 WMs that I couldn’t distinguish from one another, despite the fact that many are customisable. :)
Sort of. What is missing here is the modularity. I need a distro that does not have all the bells and whistles and I can introduce those without the bloat coming with it. There are quite often too many dependencies. Have you seen what is getting installed with something like nodejs? It is madness.
To be fair I’m not advocating for Alpine to adopt systemd, that’s likely technically infeasible. I’m advocating for Alpine to have something similar to the core philosophies of systemd.
Can you enumerate those core philosophies in a way that both systemd developers and critics would agree with?
My preferred core philosophies for system init and management might include:
keep PID 0 so simple that it cannot fail
play well with existing and future services
be easy to debug
name things clearly
make current state obvious
Those are exactly systemd core philosophies.
I mean, clearly not:
Systemd is plausibly many things but simple is without doubt not one of them.
Well, in fact systemd does only one thing - start process on system event. That is it, all other things are the consequence of this approach:
inetd/xinetd(and in fact it is IMHO way better approach, as easily support long-running systems, like Erlang, instead spawning new process for each request like it was done ininetd)udevEtc.
So in the end it is simple design that just to provide all of it’s features required some changes in a lot of components to have all events it needed for full power. Could it be messaged better to the community, maintainers could be less of a pricks, etc. But in the end, the core concept is quite simple.
(laughs)
That’s like saying “in fact a nuclear power plant does only one thing - generate electricity from steam. That is it, all other things are the consequence of this approach”
Well, most power plants can be reduced to “we need to spin this rod” (all except PV works like that) and we have few ways to do so:
And in short it is it. In case of the steam we jus have few different ways to produce it, and nuclear heater is one of them. But I do not see what you wanted to say there. systemd, when dissected, do not have complex ideas behind it. I would even say that these are very good ideas. The problem is that an implementation could be better, similarly to containers and Docker or Unix and files (see Plan 9). With time I have found, that some concepts of the systemd are very nice and provide great improvement over what we had before in Linux world. For example socket activation from systemd is awesome and super simple to handle on the client side, I used exactly the same approach in my Dolores proxy to provide reliable way to listen or request. Passing FDs between processes is something really under appreciated in the *nix world.
Well, apart from that one :-)
That’s great to hear. Where is it written down?
Well, apart from the first one ‘too small to fail’, anyway, because who gets to define how small that is exactly? Systemd has a specific goal, to subsume common service management tasks, so clearly it needs to do more things than just an
exec(3)call.… maybe this is a misplaced answer? I want to know where systemd’s philosophy is written down, because you claimed that my preferences are the same as theirs… and I don’t believe that. Or if it’s true, they’re really, really bad at implementing them.
I don’t know about your preferences, but based on the points you stated, and on the points stated in the OP, there is clearly a quite large correspondence. Perhaps you should re-read the OP.
If these principles were important to systemd, they would be written down, probably in a place so obvious that google would find it.
Google does not.
I found this article linked from https://www.freedesktop.org/wiki/Software/systemd/:
http://www.h-online.com/open/features/Control-Centre-The-systemd-Linux-init-system-1565543.html (2012)
From the preamble:
I don’t know if it fulfills your desires for an overarching philosophy statement though. And frankly, I don’t see why such a document is required. To me systemd fits well into the Unix philosophy of pragmatic problem-solving, not elaborate theory-building.
I read it. It has no statement of goals; it’s literally a high-level tour of what systemd does.
“I don’t see why such a document is required”
If you don’t have goals, you won’t know when you achieved them.
If you don’t publish your goals, people don’t know what they are.
From observation, the goals of systemd are to:
take over all other system daemons, reducing functionality and introducing bugs along the way
make logs hard to search and read (i.e. make it hard to debug)
make machines more fragile
claim speed of boot and dynamic loading as the things that make the suffering worthwhile
It’s utterly against the actual UNIX philosophy, which is this: at any moment a user may change roles to sysadmin or developer, and it is a program’s duty to all three of those roles along with whatever it was going to do in the first place.
Not necessarily! The systemd people clearly have a driving motivation or philosophy that is important to them, and we can glean what it is from what they’ve said about it:
But they may not think in exactly the same way as you do, and writing down a philosophy document may never even have entered their minds.
Are you aware of this project which aims to address exactly this problem for alpine? https://skarnet.com/projects/service-manager.html
Yes, I have been talking with skarnet for a while about these ideas.
Apologies if I made it sound as if you were, I just didn’t see any mention of anything which follows similar paradigms (like Solaris’ SMF).
Regardless, those things come at a cost (CPU, memory, storage, dependencies, development time, keeping synced with the way systemd is doing things) and you do mention that it is preferable to have a closely integrated ecosystem; which I also wholeheartedly disagree with.
I’ve never used SMF so I don’t really feel comfortable commenting on it.
I know it’s popular but aren’t you over stating this a bit?
Not really. It’s tremendously popular compared to others leading to threads like:
https://news.ycombinator.com/item?id=19861921
And
https://www.quora.com/Why-is-Alpine-Linux-so-popular-as-base-Docker-image
And it has over 1Billion pulls on docker hub no idea how it compares really
I’m aware it’s popular (I work on containers for the day job) but I’m interested in seeing support that it’s the most popular.
Docker Hub caps at 1Billion. Which has only two OS containers at that level: Ubuntu and Alpine.
It’s impossible to know for certain (with limited time) how proportional the usage of Alpine vs Ubuntu is as an upstream.
But we can get veeeery rough estimates on usage, from scraping GitHub frequency.
11,600 google results for “FROM alpine site:github.com inurl:Dockerfile”
6,650 google results for “ FROM ubuntu site:github.com inurl:Dockerfile”
This is of course counts every tiny little toy project as much as it counts hugely popular repos-
(official) docker repos like Redis, Postgres et al. seem to use Debian by default.
So, shrug
Alpine is personally what I reach for.
The two Google search strings are identical. Which one is which?
First is alpine, second is ubuntu