Slashdot Mirror

Background: I've professionally administered Unix and Linux machines for >25 years, including various BSDs, Linuxes, Irix, HP-UX, Solaris/SunOS, AIX, etc. I've been certified by several vendors or distributions, including, since 1999, Red Hat (which gives me quite a bit of background on their specific implementations over the years). I don't work for a company doing development of any OS or platform. heck, other than random 401K type aggregate ownership, I don't own stock in any company that cares about this issue at a deep level, to the best of my knowledge :)

Personal Bias about this thread: You pretty much lose all the credibility possible with me when you start of with "I ... dislike systemd because ... it looks ... like a poorly-described, gigantic mess I know nothing about ... ." (It's the "disliking something you know nothing about" that bugs me). Otherwise, I don't care much about this debate on a personal level. I currently admin boxes using systemd as well as everything else, and nothing about systemd has caused me anywhere near the heartache that it seems people who haven't used it much seem to feel about it.

Seriously, there're thousands of pages of documentation about what it is, how it works, and what most if not all of the design basis decisions are/were. I'll link you to a few of them because hey, you can get to slashdot and post, but you can't seem to use Google ;) (tongue in cheeck, of course). There're plenty of folks who DO have great detailed reasons on why they don't like bits and pieces of it, and you should be able to compare them to the various info I'm linking below.

Systemd has tons of upside and tons of downside. Most are pretty well detailed, although many of the gut reactions people seem to have to it are based on a lack of understanding about how it works and what it's compatible with, to wit "I can't use shell scripts for anything at startup anymore!" , "All of my old chkconfig or SysV scripts can't be included at all!", "It kills off syslog!", "The only reason it exists is to make laptops boot faster and in the server world we don't care", etc. Those are easily researched and the actual basis (or lack thereof) pretty easily found.

So, for why the systemd setup looks like it does, you can go back 4.5 years to where the announcement and rationale is described. Speed is part of it, as is device changability, as is double-forking, resource limits, and service state checking and recovery. Yes, it's a load of stuff. Definitely a system-wide approach VS a semi-random collection of various ways to do things all tacked together (which is, frankly, what most Unix and Unixlike systems are, through survival of the fittest).

http://0pointer.de/blog/projec...
http://0pointer.de/blog/projec...
http://0pointer.de/blog/projec...
http://0pointer.de/blog/projec...
http://0pointer.de/blog/projec...

Since RedHat's obviously the largest major proponent and arguably the source of the most production users, here's their documentation:

https://access.redhat.com/docu...

Here's the project page with loads of links about the software and uses cases:

http://www.freedesktop.org/wik...

And of course so many questions have been raised the developers have posted their rebuttals to myths or misunderstandings.

http:/

Background: I've professionally administered Unix and Linux machines for >25 years, including various BSDs, Linuxes, Irix, HP-UX, Solaris/SunOS, AIX, etc. I've been certified by several vendors or distributions, including, since 1999, Red Hat (which gives me quite a bit of background on their specific implementations over the years). I don't work for a company doing development of any OS or platform. heck, other than random 401K type aggregate ownership, I don't own stock in any company that cares about this issue at a deep level, to the best of my knowledge :)

Personal Bias about this thread: You pretty much lose all the credibility possible with me when you start of with "I ... dislike systemd because ... it looks ... like a poorly-described, gigantic mess I know nothing about ... ." (It's the "disliking something you know nothing about" that bugs me). Otherwise, I don't care much about this debate on a personal level. I currently admin boxes using systemd as well as everything else, and nothing about systemd has caused me anywhere near the heartache that it seems people who haven't used it much seem to feel about it.

Seriously, there're thousands of pages of documentation about what it is, how it works, and what most if not all of the design basis decisions are/were. I'll link you to a few of them because hey, you can get to slashdot and post, but you can't seem to use Google ;) (tongue in cheeck, of course). There're plenty of folks who DO have great detailed reasons on why they don't like bits and pieces of it, and you should be able to compare them to the various info I'm linking below.

Systemd has tons of upside and tons of downside. Most are pretty well detailed, although many of the gut reactions people seem to have to it are based on a lack of understanding about how it works and what it's compatible with, to wit "I can't use shell scripts for anything at startup anymore!" , "All of my old chkconfig or SysV scripts can't be included at all!", "It kills off syslog!", "The only reason it exists is to make laptops boot faster and in the server world we don't care", etc. Those are easily researched and the actual basis (or lack thereof) pretty easily found.

So, for why the systemd setup looks like it does, you can go back 4.5 years to where the announcement and rationale is described. Speed is part of it, as is device changability, as is double-forking, resource limits, and service state checking and recovery. Yes, it's a load of stuff. Definitely a system-wide approach VS a semi-random collection of various ways to do things all tacked together (which is, frankly, what most Unix and Unixlike systems are, through survival of the fittest).

http://0pointer.de/blog/projec...
http://0pointer.de/blog/projec...
http://0pointer.de/blog/projec...
http://0pointer.de/blog/projec...
http://0pointer.de/blog/projec...

Since RedHat's obviously the largest major proponent and arguably the source of the most production users, here's their documentation:

https://access.redhat.com/docu...

Here's the project page with loads of links about the software and uses cases:

http://www.freedesktop.org/wik...

And of course so many questions have been raised the developers have posted their rebuttals to myths or misunderstandings.

http:/

Background: I've professionally administered Unix and Linux machines for >25 years, including various BSDs, Linuxes, Irix, HP-UX, Solaris/SunOS, AIX, etc. I've been certified by several vendors or distributions, including, since 1999, Red Hat (which gives me quite a bit of background on their specific implementations over the years). I don't work for a company doing development of any OS or platform. heck, other than random 401K type aggregate ownership, I don't own stock in any company that cares about this issue at a deep level, to the best of my knowledge :)

Personal Bias about this thread: You pretty much lose all the credibility possible with me when you start of with "I ... dislike systemd because ... it looks ... like a poorly-described, gigantic mess I know nothing about ... ." (It's the "disliking something you know nothing about" that bugs me). Otherwise, I don't care much about this debate on a personal level. I currently admin boxes using systemd as well as everything else, and nothing about systemd has caused me anywhere near the heartache that it seems people who haven't used it much seem to feel about it.

Seriously, there're thousands of pages of documentation about what it is, how it works, and what most if not all of the design basis decisions are/were. I'll link you to a few of them because hey, you can get to slashdot and post, but you can't seem to use Google ;) (tongue in cheeck, of course). There're plenty of folks who DO have great detailed reasons on why they don't like bits and pieces of it, and you should be able to compare them to the various info I'm linking below.

Systemd has tons of upside and tons of downside. Most are pretty well detailed, although many of the gut reactions people seem to have to it are based on a lack of understanding about how it works and what it's compatible with, to wit "I can't use shell scripts for anything at startup anymore!" , "All of my old chkconfig or SysV scripts can't be included at all!", "It kills off syslog!", "The only reason it exists is to make laptops boot faster and in the server world we don't care", etc. Those are easily researched and the actual basis (or lack thereof) pretty easily found.

So, for why the systemd setup looks like it does, you can go back 4.5 years to where the announcement and rationale is described. Speed is part of it, as is device changability, as is double-forking, resource limits, and service state checking and recovery. Yes, it's a load of stuff. Definitely a system-wide approach VS a semi-random collection of various ways to do things all tacked together (which is, frankly, what most Unix and Unixlike systems are, through survival of the fittest).

http://0pointer.de/blog/projec...
http://0pointer.de/blog/projec...
http://0pointer.de/blog/projec...
http://0pointer.de/blog/projec...
http://0pointer.de/blog/projec...

Since RedHat's obviously the largest major proponent and arguably the source of the most production users, here's their documentation:

https://access.redhat.com/docu...

Here's the project page with loads of links about the software and uses cases:

http://www.freedesktop.org/wik...

And of course so many questions have been raised the developers have posted their rebuttals to myths or misunderstandings.

http:/

Systemd during a normal boot is doing some detailed logging of the boot process that let's you do a simper version of bootchart. This allows you to find out how long each service took to boot and also do a graph of them.

It's concerned complimentary to the actual bootchart...

[1] http://0pointer.de/blog/projec...

(stay with me here...) Once upon a time there was a community. In the community were lots of different opinions - Slackware, Redhat, Debian, the weird *BSD folk - we all worked together, despite being of different religions. We'd yell at each other, and to an outsider we'd look as though we hated each other, but we were yelling at each other at the same bar while buying each other drinks. We yelled at each other because that's just what we liked to do. We had a certain set of rules that we all followed - and those rules were our real religion. We contributed code upstream. We filed bug reports. We did code review. We contributed. We Kept It Simple, Stupid. RMS was one of our major prophets - maybe even a god (though, we often started rolling our eyes and heading home for the night if he showed up at the bar to drink with us). We laughed at people who would declare, year after year, that this would be the Year of The Linux Desktop.

Then, along came two things - Ubuntu, and modern capitalism/culture/media/whatever - a mindset where there should be no plan, just go go go new feature new feature new feature go go go (I'm looking at you Agile, facebook, google...). Suddenly, the highest and best praise your project can get became whether it was "disruptive."

The *NIX/FOSS community would not have been a place for this to take hold, were it not for Ubuntu. Ubuntu decided they would break all our paradigms - they'd refuse to contribute patches upstream, they'd take simple processes that worked well and left tremendous power in the user's hands, and replace them with very broken messes of stuff. (In contrast to what we had...) they'd make an experience that mostly worked for complete novices - to be distinguished from most other distros that rarely worried much if even their initial installer failed because meh, you should know enough to know how to fix it yourself. They'd ignore religious ideals like only using OSS. And last but most certainly not least, they replaced init.d.

Problem is, when a lot of new people started in on the scene via Ubuntu (and the like), the established distros decided that they had always wanted their distro to be the desktop featured in The Year of the Linux Desktop, and realized they were losing overall "market" share (@#$%@ for those nitwits thinking of people as a "market," when we had been a "community" for ages), even though the number of users of each of the major distros was still increasing. So they looked around at what Ubuntu was doing to become popular, and tried to decide what to adopt from it. Unfortunately, this new crop of people included the likes of Lennart Poettering, who would have ideas such as this one, regarding systemd. Instead of seeing diversity and differences as good things, those of his ilk decided to destroy (yes, a harsh word...but it's pretty much accurate) the FOSS community. An entire set of ideals just...disappeared. No longer are simple things kept simple, no longer is "Do one thing and do it well" followed, no longer do we try to let open inter-connectivity organically solve problems of integration (instead, we just birth a giant Rock Biter to mow our laws).

Systemd came from a new set of ideals where solving problems that don't exist is great, so long as the big bad Establishment is taken out. I actually saw it as a bit of agism - where youth expected to be peers to those who had been around for ages, and when they weren't immediately accepted as experts they just co-opted the entire environment and left us old farts without any toys anymore. Oh wait...you wanted something good about systemd. Um, well, my laptop now boots 0.5 seconds faster than it otherwise would have, even if I no longer know why and can no longer really do anything about it. That's good, right?

sysvinit is full of hacks, like start-stop-daemon, the mysterious /etc/init.d/functions, environment variables hackery like "# Check that networking is up.
[ "${NETWORKING}" = "no" ] && exit 6", loops, pid files, and so on. Which all belongs in a proper init system.

As PID 1 it is the parent process of all services, therefore it can observe them all. No PID file hackery needed.

rsyslog vs. journald you can read for yourself
http://blog.gerhards.net/2011/...
http://blog.gerhards.net/2011/...
http://lwn.net/Articles/470058...

xinetd and systemd
http://0pointer.de/blog/projec...
IMHO socket activation belongs into a init-system.

That being said, the design of systemd confuses me. It seems ripe for all manner of stability and security problems. As I understand it, it bundles a large number of services into a single process, which takes place of the init daemon. That's guaranteed to cause all kinds of system crashes.

What I don't get is why it isn't split up into multiple processes. All the same functionality could be provided by having a simple core init daemon that loads a set (perhaps a small set) of child processes. It wouldn't take longer to load. The services and behavior would be identical. But it would be a lot more stable, because a child process could be restarted if it crashes, keeping init to a bare minimum.

Eh, this is myth #1 in http://0pointer.de/blog/projec... . systemd consists of 69 different binaries (by now, probably more). That being said, it's true that the PID 1 (/sbin/init) is larger than the corresponding SysV init, since it does more things (e.g. cgroups for service management, support for new-style daemons, Dbus interface).

Yet again, people who don't want to learn something different. They learned the old way (so get off their lawn). There is no question the old BSD and sysv stuff has served its purpose well. For the past 10-15 years I really wished the startup would do things better. There was no reason to cling to those old ways especially with the new hardware. None at all. New stuff makes sense and isn't that hard to learn. Tear yourself away from looking at porn or games for an evening and learn it. It won't hurt, I promise. RedHat has a man ( for dummies if that helps ) page here - https://fedoraproject.org/wiki... . For most of you that's all you'll ever need to know. For guys like me - http://0pointer.de/blog/projec... .

Never see these discussions with Microsoft. It's their way (or the highway), right or wrong (mostly wrong). I didn't like it either. Spend about an hour, learn it, enjoy.

It's been running under 'real-world conditions' for years already - do you think no-one runs real-world systems on Fedora, or that Red Hat doesn't run releases in production internally before they go out, or that RH has no customers who test pre-releases?

"Seems to me that's the largest reason it's being pushed"

Nope. I think this impression originally came from Lennart's original post on systemd, years and years ago - http://0pointer.de/blog/projec... - because it starts out talking about boot speed. But even that very first post moves on, in the sections "Keeping Track of Processes" and later, to talk about the really interesting bits of systemd - better service management, and more capable service configuration. As systemd development continued, it's become much more about the latter and much less about boot times - I think that's where Lennart *started* thinking about systemd, but it's really not what systemd is for any more. Red Hat certainly wasn't interested in systemd because it might make servers boot three seconds faster, RH was interested because it can make service management on servers much better.

I am sure some people are interested in the topic on its own right, but obviously most just want to escape from systemd. In this case, please first read this paper. Even if you think the end result is crap, there are some very lucid ideas in there. You would do well to at least consider them as you adopt OpenRC or whatever in your thin Linux distribution. I swear that I have no relationship with systemd project and only occasional hobbyist relationship with Linux.

Why do we need this? I've been in unix for over 20 years and never even heard of kill -1.

I'm in the same boat. Is linux so unreliable and prone to disaster that "kill -1" used on a regular basis? There seems to be so much whining about "systemd", you just can't work out how much is complete FUD and whats a genuine gripe. Most of the gripes seems to be neutered by the Myths page http://0pointer.de/blog/projec...

There is an old saying that Unix is user friendly, it is just particular about who it chooses for friends. Maybe the two of you have been hanging around *nix for years, but how well do you really know it? Kill -1 (aka kill -HUP) is pretty handing if you are running infrastructure that other people rely upon for uninterrupted service. Just rereading a config file for updates is generally better and easier than stopping and restarting daemons*, and plenty of standard daemons expect it. It also a handy command since at times it will kill things that other variations of the kill command won't, including kill -9. It also can be a good place to start since "gentle" kills give a process an opportunity to clean up after themselves.

If you take into account all of the standard utilities of Unix and its derivatives there is an enormous amount of functionality and multiple ways to accomplish the same task. I haven't met anyone yet that was fluent in every tool and facility in standard Unixland. That is part of what I like about it - there is so much you can learn and apply, and knowing which tools can scratch particular itches. Even "obsolete" tools can be useful.

* Although there are times when stopping and restarting is a good thing too.

See Myth 20 at http://0pointer.de/blog/projec...

"Cramming all of that functionality into PID 1 as a unwieldy monolith seems like such a deeply flawed exercise." - from the info i searched out only systemd appears to be the only process running on PID1 - http://0pointer.de/blog/projec... - maybe i'm reading it wrong

But the kernel is monolithic, any complaints there or do you recommend using Hurd instead? See Myths 1 & 6

"Literally everything inside systemd is intertwined using the D-Bus". - see Myth 30

"So yes, a crash of one of the systemd daemons might cause deadlock/hang or even crash of the rest of the systemd, and consequently affect the processes running under it." - systemd can monitor dæmons (only if they use the systemd watchdog facilities) and automatically restart them if they stop talking. http://0pointer.de/blog/projec...

go and read this first http://0pointer.de/blog/projec..., there is a section on monolithic design

I'm in the same boat. Is linux so unreliable and prone to disaster that "kill -1" used on a regular basis? There seems to be so much whining about "systemd", you just can't work out how much is complete FUD and whats a genuine gripe. Most of the gripes seems to be neutered by the Myths page http://0pointer.de/blog/projec...

Systemd takes that into account and buffers things with sockets. If one process needs another and gets running first it can still send its messages the socket will hold them and wait for the other process then the other process gets the message and answers as it should. It should not fail because nothing is listening for the message and the message is lost. if you want you can read about it more here... http://0pointer.de/blog/projec... I am cautiously optimistic about systemd at worst if it does not work it and Gnome3 will die not exactly a bad thing in my book. If you want to sit out on the sidelines, and play wait and see, you can run Ubuntu LTS, Debian old stable or RHT6 until we know if systemd is a winner or not. Or you can jump in play with the new init system whichever.

And that is part of the problem, that it is presented as a init vs init issue.

It has long since grown past that. Systemd, as a package, now holds udev, journald, its own cron replacement, a network manager, dhcp, ntp, inetd, etc etc etc.

There are several inaccuracies on that list; systemd has timers that may be used as a cron substitute, but really is a different design, so therefore cron can happily co-exist, and nobody forces anybody to use the systemd solution. Systemd doesn't have a replacement for a NTP server, it just has a simple sNTP client. Like the systemd dhcp client, it was made with a special user case in mind, namely OS containers, where existing solutions simply where too slow and noisy (when starting 1000 OS containers at the same time, it really matters if each dhcp client connection takes 60 seconds or 3). AFAIK, the dhcp code is mostly a library that can be ripped out of the systemd source tree.
Nobody forces anybody to use them; they are alternatives, not replacements.

Again, systemd doesn't have an "inetd" server. Systemd uses socket activation as pioneered by inetd, but there are important differences. Lennart has several blog pages about it, here are a couple: http://0pointer.de/blog/projec...
http://0pointer.de/blog/projec...

systemd can use "inetd" prepared services, but inetd may happily co-exist together with systemd, and inetd provides services that systemd doesn't provide such as TCPMUX and RPC services.

The journal was a part of systemd early on, because in order to have great service management, you need the best logging possible.

But the crowning achievement may well be logind, that more and more DEs are getting a dependency on.

And logind can only function with systemd as the init, full stop.

logind was part of systemd early on. It has never been a separate project. It has never been meant to work outside systemd. Systemd opponents seems to have this bizarre love-hate relationship with systemd code; they curse it and the open source developers who make it, claiming the code is bad etc. etc. But at the same time they lust for the code, claiming systemd should be split up in smaller modules so they can use it anyway.

It has been a seriously mistake for the systemd opponents that they have become so fixated on systemd's "logind". Why should they care about how systemd solves user session problems? Upstream projects like Gnome and KDE have warned about for years, that an _alternative_ to logind/ConsoleKit should be developed.

Upstream projects like Gnome and KDE becomes dependent on systemd's login, because it solves real problems, like no other maintained program does. If there was an alternative API, from a program with similar functionality, they would happily support that. But no-one seems to care enough to start developing such a program.

It has been said many, many times; the systemd opponents should start to solve their own problems that lie in front of them, instead of wasting breath on trash-talking systemd.
More code, less ranting.

And that is part of the problem, that it is presented as a init vs init issue.

It has long since grown past that. Systemd, as a package, now holds udev, journald, its own cron replacement, a network manager, dhcp, ntp, inetd, etc etc etc.

There are several inaccuracies on that list; systemd has timers that may be used as a cron substitute, but really is a different design, so therefore cron can happily co-exist, and nobody forces anybody to use the systemd solution. Systemd doesn't have a replacement for a NTP server, it just has a simple sNTP client. Like the systemd dhcp client, it was made with a special user case in mind, namely OS containers, where existing solutions simply where too slow and noisy (when starting 1000 OS containers at the same time, it really matters if each dhcp client connection takes 60 seconds or 3). AFAIK, the dhcp code is mostly a library that can be ripped out of the systemd source tree.
Nobody forces anybody to use them; they are alternatives, not replacements.

Again, systemd doesn't have an "inetd" server. Systemd uses socket activation as pioneered by inetd, but there are important differences. Lennart has several blog pages about it, here are a couple: http://0pointer.de/blog/projec...
http://0pointer.de/blog/projec...

systemd can use "inetd" prepared services, but inetd may happily co-exist together with systemd, and inetd provides services that systemd doesn't provide such as TCPMUX and RPC services.

The journal was a part of systemd early on, because in order to have great service management, you need the best logging possible.

But the crowning achievement may well be logind, that more and more DEs are getting a dependency on.

And logind can only function with systemd as the init, full stop.

logind was part of systemd early on. It has never been a separate project. It has never been meant to work outside systemd. Systemd opponents seems to have this bizarre love-hate relationship with systemd code; they curse it and the open source developers who make it, claiming the code is bad etc. etc. But at the same time they lust for the code, claiming systemd should be split up in smaller modules so they can use it anyway.

It has been a seriously mistake for the systemd opponents that they have become so fixated on systemd's "logind". Why should they care about how systemd solves user session problems? Upstream projects like Gnome and KDE have warned about for years, that an _alternative_ to logind/ConsoleKit should be developed.

Upstream projects like Gnome and KDE becomes dependent on systemd's login, because it solves real problems, like no other maintained program does. If there was an alternative API, from a program with similar functionality, they would happily support that. But no-one seems to care enough to start developing such a program.

It has been said many, many times; the systemd opponents should start to solve their own problems that lie in front of them, instead of wasting breath on trash-talking systemd.
More code, less ranting.

That's true, but pid 2 crashing won't halt the system, because pid 1 can restart it. If pid 1 crashes, it's power cycle time.

If PID2 is responsible for critical features like eg. cgroups which affects all running processes, including PID1, then it won't make a difference.

I do really think that the systemd designers have actually done their homework quite well when they started out. PID1 is quite small and only contain what is needed, everything else runs as helper processes.

Besides that, systemd can supervise itself (PID1) by using a watchdog, so the system can react if PID1 doesn't answer the watchdog "ping".
http://0pointer.de/blog/projec...

logind is just one example

Does nothing a script can't do

Do you really think it is a serious argument is that you could re-implement "logind" as a bash script? We are talking serious hardcore system stuff here, which is why no-one have made an alternative to "logind" or "ConsoleKit" despite upstream projects have pleaded for such a program for several years.

Systemd doesn't even fucking use capabilities, just cgroups. Which we could use before systemd. Systemd manages permissions in lieu of using capabilities, e.g. apparmor or selinux.

You are seriously misinformed on how systemd works and what it can do:
It uses kernel namespaces and capabilities to protect the system; this is on top of SELinux etc.

Here is a general overview:
http://0pointer.de/blog/projec...

Here are some of the config options for the daemons you can use. See "CapabilityBoundingSet=" for one way of using kernel "capabilities":
http://0pointer.de/public/syst...

There are so many freaking cool security features in systemd. As time goes by, developers, distro maintainer, and systemd administrators, can add more and more options to the running processes, like "NoNewPrivileges=" to prevent privilege escalation, or "ProtectHome=" to prevent malware and exploited processes from stealing info from /home, even if they otherwise had permission to read in home.

All this great new stuff can be turned on and used by adding a simple keyword to a structured text file. As time goes by, systemd distros will become ever more hardened.

It only runs one process as PID1, the daemon "systemd" which is rather small. This daemon however, is capable of "talking" with with several other processes, which gives it many advantages,

This is making init do stuff it doesn't need to do, which makes it more complex, which makes it more fragile. You should not need a detailed explanation to understand why this is a bad thing.

Well, it does need to be handled somewhere; if you want features, you will get complexity, it is that simple. But as explained, the features and complexity isn't running in PID1; PID1 (systemd) is just a hub for relaying those features to other processes.

I really think so much of the systemd opponents talk about "Unix way" and "PID1" should be simple, is hand waving to gloss over the fact that the non-systemd distros have no feature parity with systemd to speak of; SysVinit is crude and no one in their right mind would design a init system these days with executable config files. Service configuration files should be non-executable text only.

General and vague criticism against systemd really doesn't convince anybody. Anyway, the Linux community have spoken with a large majority of Linux distros using systemd in the future.

If SysVinit systems really have all the features of systemd, just much better because they are simpler, you would expect a "SysVinit" boom in the future with lots of developers and users.

Personally, I think the systemd opponents are too concerned with negative campaigns against systemd, that they entirely forget to code any alternatives, so I predict ever more distros like Slackware abandoning script based init systems; they simply don't have an alternative.

logind is just one example

Does nothing a script can't do

Do you really think it is a serious argument is that you could re-implement "logind" as a bash script? We are talking serious hardcore system stuff here, which is why no-one have made an alternative to "logind" or "ConsoleKit" despite upstream projects have pleaded for such a program for several years.

Systemd doesn't even fucking use capabilities, just cgroups. Which we could use before systemd. Systemd manages permissions in lieu of using capabilities, e.g. apparmor or selinux.

You are seriously misinformed on how systemd works and what it can do:
It uses kernel namespaces and capabilities to protect the system; this is on top of SELinux etc.

Here is a general overview:
http://0pointer.de/blog/projec...

Here are some of the config options for the daemons you can use. See "CapabilityBoundingSet=" for one way of using kernel "capabilities":
http://0pointer.de/public/syst...

There are so many freaking cool security features in systemd. As time goes by, developers, distro maintainer, and systemd administrators, can add more and more options to the running processes, like "NoNewPrivileges=" to prevent privilege escalation, or "ProtectHome=" to prevent malware and exploited processes from stealing info from /home, even if they otherwise had permission to read in home.

All this great new stuff can be turned on and used by adding a simple keyword to a structured text file. As time goes by, systemd distros will become ever more hardened.

It only runs one process as PID1, the daemon "systemd" which is rather small. This daemon however, is capable of "talking" with with several other processes, which gives it many advantages,

This is making init do stuff it doesn't need to do, which makes it more complex, which makes it more fragile. You should not need a detailed explanation to understand why this is a bad thing.

Well, it does need to be handled somewhere; if you want features, you will get complexity, it is that simple. But as explained, the features and complexity isn't running in PID1; PID1 (systemd) is just a hub for relaying those features to other processes.

I really think so much of the systemd opponents talk about "Unix way" and "PID1" should be simple, is hand waving to gloss over the fact that the non-systemd distros have no feature parity with systemd to speak of; SysVinit is crude and no one in their right mind would design a init system these days with executable config files. Service configuration files should be non-executable text only.

General and vague criticism against systemd really doesn't convince anybody. Anyway, the Linux community have spoken with a large majority of Linux distros using systemd in the future.

If SysVinit systems really have all the features of systemd, just much better because they are simpler, you would expect a "SysVinit" boom in the future with lots of developers and users.

Personally, I think the systemd opponents are too concerned with negative campaigns against systemd, that they entirely forget to code any alternatives, so I predict ever more distros like Slackware abandoning script based init systems; they simply don't have an alternative.

its all down to a bunch of whiners who might have to learn something new so they trash it without really understanding it. They should read this until they understand it http://0pointer.de/blog/projec...

http://0pointer.de/blog/projec...

http://0pointer.de/blog/projec...

Have you had a read of this? Myth buster for systemd. http://0pointer.de/blog/projec...

Please promote "the kool-aid" elsewhere.....

It seems most of your problems are just repeated myths about systemd. For instance http://0pointer.de/blog/projec... debunks all of them and there are numerous other sites that do likewise. While I am not a big fan of systemd, I do understand what they are trying to do and it isn't the end of the world like people want to make it out to be.

So let's now go through and analyse these some more...

Systemd is a necessary replacement for init.d

Systemd is not necessary at least not for the greater majority of Linux users, nor is it a simple replacement for init.d. Systemd does far more than replace your system startup, replacing just about every system daemon it can- including inetd, logind, syslogd, udevd, and it does so in as incompatible way as it possibly can. Binary log files for example break every utility or app which depend on scanning log files (eg. tail -f logfile | grep ...).

The separation between rc.d and inetd was never sensible. The separation between starting daemons and handling hardware was never sensible. Plain text logs from syslog still exist unless you actively work to dissable them. Once you've looked at journalctl you realise it shits all over ad hoc grepping and other crappy solutions that aren't actually as good as what journalctrl just does ootb.

Systemd is a result of careful needs analysis and planning by a mature team of developers

Nope. In Poetterings on words (Apr 2010) initial announcement: "Well, the current code-base is mostly my work, Lennart Poettering (Red Hat). However the design in all its details is result of close cooperation between Kay Sievers (Novell) and me. Other people involved are Harald Hoyer (Red Hat), Dhaval Giani (Formerly IBM), and a few others from various companies such as Intel, SUSE and Nokia."

In other words, the requirements specification, scope, analysis design, initial implementation all belong to Mr Poettering. Quite impressive for one chap.

You take a statement about what systemd is *now* and compare it to an initial announcement from 4½ years ago. Is there any chance that the list of names involved might have changed? Top of the class.

Systemd is similar to upstart

Upstart did a small fraction of what systemd does, as described a year after the initial announcement. Upstart was restricted to indeed simply replacing init.d, and did so in as unobtrusive a manner as possible. You may as well compare apples to oranges, as compare upstart to systemd.

None of the pages linked ever make that claim. Indeed, they contrast how the dependency model is an improvement over upstart.

It seems to me that the referenced article, ostensibly debunking systemd myths, is an exercise in raising red herrings in quick succession, and just as quickly flattening each one. The real problems are brushed under the carpet.

Red herrings work both ways, kthnxbye.

So let's now go through and analyse these some more...

Systemd is a necessary replacement for init.d

Systemd is not necessary at least not for the greater majority of Linux users, nor is it a simple replacement for init.d. Systemd does far more than replace your system startup, replacing just about every system daemon it can- including inetd, logind, syslogd, udevd, and it does so in as incompatible way as it possibly can. Binary log files for example break every utility or app which depend on scanning log files (eg. tail -f logfile | grep ...).

The separation between rc.d and inetd was never sensible. The separation between starting daemons and handling hardware was never sensible. Plain text logs from syslog still exist unless you actively work to dissable them. Once you've looked at journalctl you realise it shits all over ad hoc grepping and other crappy solutions that aren't actually as good as what journalctrl just does ootb.

Systemd is a result of careful needs analysis and planning by a mature team of developers

Nope. In Poetterings on words (Apr 2010) initial announcement: "Well, the current code-base is mostly my work, Lennart Poettering (Red Hat). However the design in all its details is result of close cooperation between Kay Sievers (Novell) and me. Other people involved are Harald Hoyer (Red Hat), Dhaval Giani (Formerly IBM), and a few others from various companies such as Intel, SUSE and Nokia."

In other words, the requirements specification, scope, analysis design, initial implementation all belong to Mr Poettering. Quite impressive for one chap.

You take a statement about what systemd is *now* and compare it to an initial announcement from 4½ years ago. Is there any chance that the list of names involved might have changed? Top of the class.

Systemd is similar to upstart

Upstart did a small fraction of what systemd does, as described a year after the initial announcement. Upstart was restricted to indeed simply replacing init.d, and did so in as unobtrusive a manner as possible. You may as well compare apples to oranges, as compare upstart to systemd.

None of the pages linked ever make that claim. Indeed, they contrast how the dependency model is an improvement over upstart.

It seems to me that the referenced article, ostensibly debunking systemd myths, is an exercise in raising red herrings in quick succession, and just as quickly flattening each one. The real problems are brushed under the carpet.

Red herrings work both ways, kthnxbye.

Biggest myths of systemd:

Systemd is not necessary at least not for the greater majority of Linux users, nor is it a simple replacement for init.d. Systemd does far more than replace your system startup, replacing just about every system daemon it can- including inetd, logind, syslogd, udevd, and it does so in as incompatible way as it possibly can. Binary log files for example break every utility or app which depend on scanning log files (eg. tail -f logfile | grep ...).

Nope. In Poetterings on words (Apr 2010) initial announcement: "Well, the current code-base is mostly my work, Lennart Poettering (Red Hat). However the design in all its details is result of close cooperation between Kay Sievers (Novell) and me. Other people involved are Harald Hoyer (Red Hat), Dhaval Giani (Formerly IBM), and a few others from various companies such as Intel, SUSE and Nokia."

In other words, the requirements specification, scope, analysis design, initial implementation all belong to Mr Poettering. Quite impressive for one chap.

Upstart did a small fraction of what systemd does, as described a year after the initial announcement. Upstart was restricted to indeed simply replacing init.d, and did so in as unobtrusive a manner as possible. You may as well compare apples to oranges, as compare upstart to systemd.

It seems to me that the referenced article, ostensibly debunking systemd myths, is an exercise in raising red herrings in quick succession, and just as quickly flattening each one. The real problems are brushed under the carpet.

Biggest myths of systemd:

Systemd is not necessary at least not for the greater majority of Linux users, nor is it a simple replacement for init.d. Systemd does far more than replace your system startup, replacing just about every system daemon it can- including inetd, logind, syslogd, udevd, and it does so in as incompatible way as it possibly can. Binary log files for example break every utility or app which depend on scanning log files (eg. tail -f logfile | grep ...).

Nope. In Poetterings on words (Apr 2010) initial announcement: "Well, the current code-base is mostly my work, Lennart Poettering (Red Hat). However the design in all its details is result of close cooperation between Kay Sievers (Novell) and me. Other people involved are Harald Hoyer (Red Hat), Dhaval Giani (Formerly IBM), and a few others from various companies such as Intel, SUSE and Nokia."

In other words, the requirements specification, scope, analysis design, initial implementation all belong to Mr Poettering. Quite impressive for one chap.

Upstart did a small fraction of what systemd does, as described a year after the initial announcement. Upstart was restricted to indeed simply replacing init.d, and did so in as unobtrusive a manner as possible. You may as well compare apples to oranges, as compare upstart to systemd.

It seems to me that the referenced article, ostensibly debunking systemd myths, is an exercise in raising red herrings in quick succession, and just as quickly flattening each one. The real problems are brushed under the carpet.

you could try reading up on it. Here's a taster for you..

"systemd is a system and service manager for Linux, compatible with SysV and LSB init scripts. systemd provides aggressive parallelization capabilities, uses socket and D-Bus activation for starting services, offers on-demand starting of daemons, keeps track of processes using Linux control groups, supports snapshotting and restoring of the system state, maintains mount and automount points and implements an elaborate transactional dependency-based service control logic. It can work as a drop-in replacement for sysvinit. "

and if you are in the mood for reading, here's a longer introduction.
http://0pointer.de/blog/projec...

its probably getting rid of SCO stuff from Linux as well as its a Linux specific project

Have you had a read of this? Myth buster for systemd. http://0pointer.de/blog/projec...

> The same command on systemd is "journalctl -f" . Notice how you don't need to give a path. Notice that in both instances you need a executable (tail vs journalctl) to view the logs.
And there is the Problem.
File+Minimal Utility -> SystemD specific tool.
The tail command can easily pointed to the next file, i.e. /var/log/apache/access.log, for systemd you need to remember the tool. Now imagine, every program would bring its own "view my logs" tool ...

You don't need tail, and you don't need to point to some particular daemon's separate logfile when using journactl.
First, the journal contains all logs on the system, so there is no need to hunt around for various logs like "access".
Secondly, it is childs play to filter out a particular deamon's log and tail it like "journalctl -p warning -f /usr/sbin/smartd" (Tail all smartd generated log entries at loglevel "warning".) There are many other filters (see the FIELD values in the man pages).

Sure, journald can easily cope with multiple logfiles and even interleave them using e.g. monotonic timestamps for easy comparisons between different machine boot sequences etc. You just don't need to point on any files without such special needs.

journalctl is just a filtering device like grep, just much easier to use for powerful filtering since the journal is structured and indexed.

You don't need journalctl to read journald logfiles; the journal is well defined, and there are API's and language bindings to create your own journal reader or log-watcher etc. AFAIK, rsyslog already reads journald logfiles.

The bottom line is that systemd's logging facilities are a giant leap forward for Linux, and since basically all Linux distro's are about to use it in the future, it is worth a serious study. This may be a good place to start:
http://0pointer.de/blog/projec...
http://0pointer.de/blog/projec...

> The same command on systemd is "journalctl -f" . Notice how you don't need to give a path. Notice that in both instances you need a executable (tail vs journalctl) to view the logs.
And there is the Problem.
File+Minimal Utility -> SystemD specific tool.
The tail command can easily pointed to the next file, i.e. /var/log/apache/access.log, for systemd you need to remember the tool. Now imagine, every program would bring its own "view my logs" tool ...

You don't need tail, and you don't need to point to some particular daemon's separate logfile when using journactl.
First, the journal contains all logs on the system, so there is no need to hunt around for various logs like "access".
Secondly, it is childs play to filter out a particular deamon's log and tail it like "journalctl -p warning -f /usr/sbin/smartd" (Tail all smartd generated log entries at loglevel "warning".) There are many other filters (see the FIELD values in the man pages).

Sure, journald can easily cope with multiple logfiles and even interleave them using e.g. monotonic timestamps for easy comparisons between different machine boot sequences etc. You just don't need to point on any files without such special needs.

journalctl is just a filtering device like grep, just much easier to use for powerful filtering since the journal is structured and indexed.

You don't need journalctl to read journald logfiles; the journal is well defined, and there are API's and language bindings to create your own journal reader or log-watcher etc. AFAIK, rsyslog already reads journald logfiles.

The bottom line is that systemd's logging facilities are a giant leap forward for Linux, and since basically all Linux distro's are about to use it in the future, it is worth a serious study. This may be a good place to start:
http://0pointer.de/blog/projec...
http://0pointer.de/blog/projec...

I agree with some of the criticism regarding systemd, but reading logs is not one of them. Just learn the systemctl and journalctl syntax before you ask silly questions regarding reading logs.

Also, read http://0pointer.de/blog/projec...

I would be interested in the anyone's response to Lennart Poetterings rebuttal to the common complaints about systemd.

I'm too n00b to know who's right.

Full disclosure: I do not like systemd, although that judgment is based on its merits as I see them relative to my needs.

There seemed to be a pretty concerted determination not to get the point in Lennart's long spiel defending the system. As someone who has been using Unices in anger since the early '90s, I've pretty much seen Linux grow from its infancy. I've seen this kind of attitude before in technology — in Windows, Linux and elsewhere. The article is clearly written (and written clearly) by someone who's clever, articulate and... far too concerned with being right. It's not a healthy perspective.

Being technically correct is not generally optional. It's just not ever nearly as conclusive as some people think it is.

Having the humility to accept an imperfect universe — and to admit that it's imperfect in a particular way for a large number of particular reasons — is a virtue that fewer and fewer people seem to possess these days.

(It's the lack of this virtue that makes people say, for example, 'less and less' where I used 'fewer and fewer' and when someone corrects them, they trot out the grammar nazi epithet and say, 'Everybody knows what I mean. Deal with it.' And the lack of this virtue as well that will make people pick on the triviality of this example to discard my entire post. The temerity of such an approach cannot be explained to those who suffer from it.)

Systemd is clearly not change for change's sake. Lennart and the dozen and a half others who have commit rights are clearly scratching an itch. But regardless of the technical merits of the system, it is horribly, horribly wrong to impose this new system —any new system— on Linux wholesale without a significant maturing process. And by significant, I mean years.

And this is where Lennart's most completely mistaken. He thinks that the technical arguments are the decisive ones, in spite of the fact that technical merit is not why systemd is going to become prevalent. He therefore tries to write a technical opus in defence of the indefensible, which requires more than a few straw men (binary config files? shyeah....), several big ommissions (binary log files) and a clearly unwilled but nonetheless unforgivable ignorance of the fact that he's winning because he's RedHat, not because he's better. (Yeah yeah yeah, it's not all RH; it's others too, you're technically awesome - I read that part and remain utterly unconvinced by the argument.)

Paul Venezia's screed, on the other hand, is just plain substance-free. He's not arguing either technical merit or political power. He's simply looking at a looming mess and saying, well, that it's going to be messy. And to that extent, he's right. Systemd is going to make a mess, and that's precisely because its proponents think that they're perfectly within their rights to claim, 'Well, nobody's forcing anything on anyone.'

What they don't realise is that that is not how cooperation works. And believing you're better or righter than others is an absolutely shit way of improving your own software.

I would be interested in the anyone's response to Lennart Poetterings rebuttal to the common complaints about systemd.

I'm too n00b to know who's right.

The rebuttal from the guy the broke every distribution's sound system (and still does because it doesn't get fully installed on any setup) with the cluster that is PulseAudio.

I would be interested in the anyone's response to Lennart Poetterings rebuttal to the common complaints about systemd.

I'm too n00b to know who's right.

I thought this was a nice response, and I would be interested in the naysayers' response to this response: The Biggest Myths, by Lennart Poettering.

Also, the main complaint against systemd is that it is big and monolithic, instead of a series of simple tools strung together, like cat, awk, and sed. But what about Apache, OpenOffice, and PostgreSQL?

Disclaimer: I am just a lowly web programmer, not an operating system developer or even a sysadmin.

I believe you can do at least some of that with systemd user sessions and resource restrictions
http://0pointer.de/blog/projects/resources.html
User sessions are currently kind of beta-ish but they're getting better / more useful... I already launch emacs and a MIDI synth through it on login, and it works wonderfully (ironically, though, PulseAudio, the other Lennart project that got a lot of flak, doesn't launch through this mechanism yet).

...But I remain skeptical that a server "needs" systemd - witness that BSD servers work fine and none of them have systemd.

"Need" is an elastic term. Sure, sysvinit worked on Linux servers for many years despite its many shortcomings, but it was always a very resource intensive endeavor to make it work and support it (think; all distros have different init scripts for each service and everybody of them hard to debug and prone to bugs). All the missing functionality of sysvinit had to be made up with complex scripting at each and every service.

But the old sysvinit model relied heavily on a certain way of doing computing, basically running servers directly on the metal with a few selected services and often with lots of "scripting" glue hand crafted for each server. They where individual servers, maintained by admins that needed a rather thorough knowledge about how a particular server worked.
But that model have changed considerably over the years and that is the main reason why old style script based systems no longer is working as well as it used to do.

Massive and rapid deployment of servers, virtualization, OS-containers, instantiated services etc. are becoming important. OS's needs to be automatically configured, or mass configured by machines. It is all about speed and hardware density in order to stay competetive. Take for example a hosting provider that has 10.000 Linux instances hosted. It used to be that they would have to run 10.000 instances of sshd or similar, even though only 1000 users where active at the time. With systemd they only need to run exactly the amount of services as there are current users, since services can be "on-demand socket activated". (no, it isn't like inetd, read here: http://0pointer.de/blog/projec... )

In short, the provider can pack more users into each hardware unit, that saves money.

systemd also makes it possible to upgrade a service and restarting it without breaking any end user connections (it buffers the client requests).

There are many systemd enhancements for servers because it isn't just simple init systems. I think that in order to stay relevant, BSD will have to start cloning a considerable amount of systemd features. It will be different on BSD because they don't suffer the same fragmentation chaos as Linux, but the main points of systemd, like (k)dbus service communication, intelligent PID1 that utilizes kernel features like security modules making them available to services without reprogramming, a total service and process superviser chain, early "metal-to-metal" logging etc. will be cloned by BSD. It is only a matter of time.

One reason why systemd simply routs any opposition is, that when people actually study it, they find that is has awesome new features and solve so many of the sysvinit shortcomings. From terminating services correctly http://0pointer.de/blog/projec...
to actually tracking and supervising all running processes http://0pointer.de/blog/projec...

And because of its design, it also offer superior security features, because as PID1 it can hook into advanced kernel features like "kernel capabilities" http://man7.org/linux/man-page... and "cgroup", and soon, also kdbus. Systemd works as a Linux plumbing layer, making all these features available for end users and distro maintainers, and making them easy to use by just adding simple keywords into a text config file.

Systemd is also a cross distro comparability layer; that means upstream projects can develop against systemd, and be sure it works across many different distros. It is easy to develop DE developers to make a GUI for setting networks or NTP/time or keyboard layout etc, on a systemd OS. On non-systemd distros, everything is scattered and fragmented, making it impossible to do.

The end result is, that all new development will be done with systemd. And because people like you think that nothing needs to be changed, the non-system distros will remain utterly fragmented and unsupported from upstream projects.

The bottom line is, that if people want to use non-systemd distros in the future, they better start getting off their couches and start develop an alternative. Not only do they need to maintain sysvinit infrastructure now that the "big boys" like Red Hat and Debian and Suse and Ubuntu are converting to systemd and therefore drops sysvinit/upstart development, but also extend the present infrastructure to deal with eg. safely using rootless X. They also ought to organize to help upstream projects like KDE and Gnome, by making a similar compatibility layer that work across the few remaining non-systemd distros.

One reason why systemd simply routs any opposition is, that when people actually study it, they find that is has awesome new features and solve so many of the sysvinit shortcomings. From terminating services correctly http://0pointer.de/blog/projec...
to actually tracking and supervising all running processes http://0pointer.de/blog/projec...

And because of its design, it also offer superior security features, because as PID1 it can hook into advanced kernel features like "kernel capabilities" http://man7.org/linux/man-page... and "cgroup", and soon, also kdbus. Systemd works as a Linux plumbing layer, making all these features available for end users and distro maintainers, and making them easy to use by just adding simple keywords into a text config file.

Systemd is also a cross distro comparability layer; that means upstream projects can develop against systemd, and be sure it works across many different distros. It is easy to develop DE developers to make a GUI for setting networks or NTP/time or keyboard layout etc, on a systemd OS. On non-systemd distros, everything is scattered and fragmented, making it impossible to do.

The end result is, that all new development will be done with systemd. And because people like you think that nothing needs to be changed, the non-system distros will remain utterly fragmented and unsupported from upstream projects.

The bottom line is, that if people want to use non-systemd distros in the future, they better start getting off their couches and start develop an alternative. Not only do they need to maintain sysvinit infrastructure now that the "big boys" like Red Hat and Debian and Suse and Ubuntu are converting to systemd and therefore drops sysvinit/upstart development, but also extend the present infrastructure to deal with eg. safely using rootless X. They also ought to organize to help upstream projects like KDE and Gnome, by making a similar compatibility layer that work across the few remaining non-systemd distros.

We've really entered bizarro-land in this discussion now that communicating over dbus has been declared wrong because it is the "Windows-way", whatever that means. Dbus is just IPC, that is all.

How about instead of misinterpreting what somebody said on a discussion forum on an unrelated matter, you read what the actual architect of systemd says.

Myth: systemd is monolithic.

If you build systemd with all configuration options enabled you will build 69 individual binaries. These binaries all serve different tasks, and are neatly separated for a number of reasons. For example, we designed systemd with security in mind, hence most daemons run at minimal privileges (using kernel capabilities, for example) and are responsible for very specific tasks only, to minimize their security surface and impact. Also, systemd parallelizes the boot more than any prior solution. This parallization happens by running more processes in parallel. Thus it is essential that systemd is nicely split up into many binaries and thus processes. In fact, many of these binaries[1] are separated out so nicely, that they are very useful outside of systemd, too.

A package involving 69 individual binaries can hardly be called monolithic. What is different from prior solutions however, is that we ship more components in a single tarball, and maintain them upstream in a single repository with a unified release cycle.

Myth: systemd is not modular.

Not true at all. At compile time you have a number of configure switches to select what you want to build, and what not. And we document how you can select in even more detail what you need, going beyond our configure switches.

This modularity is not totally unlike the one of the Linux kernel, where you can select many features individually at compile time. If the kernel is modular enough for you then systemd should be pretty close, too.

There are more of those here,
http://0pointer.de/blog/projec...

- It breaks expectations of experienced Unix/Linux users.

I disagree. First of all because there is no reason to disregard something just because it acts a bit differently. Second, it is not as different from standard unix ways as people are determined to think. It is different from sysV, but even sysV was different from other competing systems at the time it was introduced. Not having console logging would be a serious shortcoming if it were true. Thankfully, logging is quite configurable and you can get almost anything you want from journald.

- Non-deterministic.

I would need some more information before I could conclude that it is non-deterministic. The only information I have at this point is "something stopped working." The cause can be any number of things which might be the fault of systemd or might not.

KISS is a principle because experience shows that simpler things work better.

A lot of people have been saying sysV is simpler with pretty much nothing to back it up. Systemd is not that complicated.
http://0pointer.de/blog/projec...

It's a massive, complicated, and very poorly behaved substitute for a simple, robust, and well behaved program. And it's not just a regular program, it is (if used as intended) a critical system component that will take your entire system down when it goes wrong.

Not at all. Don't substitute you not understanding a system with complicated and poorly behaved.

Being difficult to understand is a definition of complicated.

There are careful design decisions and planning of systemd. You may not agree with them, but that doesn't make it wrong.

Systemd is openly trying to do pretty much 'everything' at startup instead of having multiple things that do one thing well working together. I've worked with both systemd-like mono systems and with modular systems. The modular systems are less complicated, period. They are also easier to understand, fix, maintain and extend. Systemd is truly bad by design. And yes, that makes it wrong. That fact that is also critical to the system make it a catastrophe.

Systemd is increasingly more popular for a number of very good reasons.

Systemd is more popular because it is being shoved down peoples throats. It 'more popular' for politically reasons, not technical. Very, very few people would use it if their distributions provided a choice.

It has become a freedesktop.org standard. You could start by reading this, http://0pointer.de/blog/projec...

But since you probably won't, let me just say this. Serially executing a bunch of arbitrary shell scripts has got to be the worst possible way to design an init system.

Yes, parallel processing a bunch of arbitrary scripts is much better. Heavily limiting what those scripts can do is better still.

The fact that it works doesn't make it good. First of all, each script is code. Second, no script is aware of any other scripts presence, although intrinsically linked to and dependent on those other scripts. Third, a typical shell script is >100 lines of block logic to implement the equivalent of "service start". A configuration file for systemd for a single service can often be less than 10 lines and very easy to read.

I know I know, none of that matters, it is too "massive" and "complicated".

Yes, trading bash scripts for a large blob of binary code that interprets another layer of text scripts is much less complicated, If you're just comparing the bash scripts to the large binary blob's scripts.

I suspect that the people responsible for systemd never even thought to look at already-existing alternatives

Poettering was most definitely aware of launchd.

Is this really Lennart Poettering's blog? I find the part where he describes the Solaris init quite ironic.

There are other init systems besides sysvinit, Upstart and launchd. Most of them offer little substantial more than Upstart or sysvinit. The most interesting other contender is Solaris SMF, which supports proper dependencies between services. However, in many ways it is overly complex and, let's say, a bit academic with its excessive use of XML and new terminology for known things. It is also closely bound to Solaris specific features such as the contract system.

Just change Solaris to Linux and "in many ways it is overly complex" and "closely bound to Solaris specific features" sounds like an apt description of systemd.

In my first message I was chatty but I cited some. Anyway: cgroups, reliable mount handling (boot time barrier and during system uptime), socket and filesystem based activation. These features alone remove plenty of race conditions in services life cycle."

I dont see anything there that Slackware has ever given me a problem with. I know it supports cgroups, mount handling? You mean automounting removable drives on insertion? That was working for years before anyone ever heard of systemd.

On the other hand socket activation is not to the best of my knowledge supported, but I think that's a good thing. What a horrible hack! They took something very simple, logical, and robust (serial activation of services) and made it orders of magnitude more complicated, doubtless creating bugs that we will be discovering for many years to come in the process, and for what? To shave 5 seconds off a task that that you might need to do once a year? In what twisted alternate reality would this possibly seem like a good idea to anyone?

These features alone remove plenty of race conditions in services life cycle.

You know what is even more effective at removing race conditions? Serial activation. And all it costs is a few extra seconds in the rare event of a reboot.

I suspect that the people responsible for systemd never even thought to look at already-existing alternatives

Poettering was most definitely aware of launchd.