Choose Your Side On the Linux Divide

snydeq writes The battle over systemd exposes a fundamental gap between the old Unix guard and a new guard of Linux developers and admins, writes Deep End's Paul Venezia. "Last week I posted about the schism brewing over systemd and the curiously fast adoption of this massive change to many Linux distributions. If there's one thing that systemd does extremely well, it is to spark heated discussions that devolve into wild, teeth-gnashing rants from both sides. Clearly, systemd is a polarizing subject. If nothing else, that very fact should give one pause. Fundamental changes in the structure of most Linux distributions should not be met with such fervent opposition. It indicates that no matter how reasonable a change may seem, if enough established and learned folks disagree with the change, then perhaps it bears further inspection before going to production. Clearly, that hasn't happened with systemd."

Comments

My opinion on the matter.

[Z00L00K]

Who really needs systemd?

It may provide some features not previously existing, but it also breaks a lot of stuff that people "knew" were there.

Re:My opinion on the matter.

[jedidiah]

> Fundamental changes in the structure of most Linux distributions should not be met with such fervent opposition.

Sure it should. At the very least, such sweeping changes should be met with some skepticism based purely on mundane ideas about change control. Why are changes with such a massive impact being considered? What is being done to mitigate risks? How is this going to impact how Linux fits in with other Unixen?

What's broken exactly?

Re:My opinion on the matter.

[loony]

Who cares if you have to relearn stuff? Its the fact that systemd is less than stable... In many cases, you end up with corrupt binary log file after a crash, have services that don't (run a process that does heavy syslogging to the tune of 25-30K messages per second. Yes, its bad app design but come on - this thing worked for years and now its suddenly broken???) that used to work just fine before and then top it off with really braindead configuration options (go ahead and change the pgsql listen port - and see how long it takes you...)

I'm all for systemd - once its been stable for a while, but till then it would be nice to have at least a choice...

Peter.

Re:My opinion on the matter.

[jedidiah]

> Who cares if you have to relearn stuff?

Anyone that uses something besides Linux. One great thing about Unixen is how they share common interfaces. The more you change that, the less interchangeable the various Unixen become. The more reason their will be to resist moving from one to another.

This is something that has benefited Linux greatly in the past: the fact that a Solaris user could feel fairly comfortable with picking up Linux and just dive in.

The anti-dinosaur sentiment should not be an excuse to blindly and gratuitously change things just because of "new shiny shiny".

All of your substantive complaints seem to be a direct result of ignoring the principle "don't fix what isn't broken".

Re:My opinion on the matter.

[Anonymous Coward]

Much like pulseaudio, it will probably become quite good when Lennart stops working on it and hands it over to someone else to maintain.

Re:My opinion on the matter.

[Anonymous Coward]

Basically we *need* something like systemd, which is why it's gaining ground. It's providing a lot of sorely-needed features, efficiency, and cleanup in a ton of areas. The are a handful primary meta-downsides that cause all the teeth-gnashing can be summarized as follows (all of which are avoidable in theory...):

1) The developers are often uncooperative assholes - True of many projects in the OSS world, sadly. Generally not a deal-breaker when everything else is fine, but it really exacerbates problems with the other points below.

2) Emacs Syndrome - systemd has begun to be the kitchen sink of Linux. They're adopting a philosophy that anything anything which touches/interacts with systemd and doesn't work for them (doesn't fit their new radical model) should be re-written into compliance, and since too many of the authors of these non-compliant projects are also systemd grumblers, the project has taken to the habit of rewriting these components themselves and making them a part of systemd. Thus systemd's scope has grown tremendously, and it's bundling a ton of risk into a single meta-package. Even things as far removed as NTP functionality are now rolling into systemd (did you know systemd is trying to replace ntpd?).

3) Reinventing APIs radically - The big case here is the basic OS interfaces for networked daemons. For a traditional *nix daemon, this means the collection of POSIX-y system calls that deal with things like privilege management, daemonization, logging, socket binding, etc. The systemd model tries to replace all of this with declarative service configuration files which set all of this up from outside the daemon before it's launched, allowing it to focus on merely processing socket traffic. Think of this as a much more advanced variant of the inetd model. The problems with this approach are three-fold (and you'll see examples of these problems in other areas of systemd as well):

3a) They haven't mirrored every possible legitimate use of the old POSIX-y syscall API in the new declarative configuration. In little ways this means things like not supporting every socket option in the normal socket APIs. In big ways, this means more complex behavior patterns. For example, a traditional *nix daemon might be capable of managing its daemonization in an advanced way with the flexibility of the POSIX APIs (e.g. allowing a controlled 'restart' behavior for reducing downtime that starts a new daemon overlapped with the old one and uses some IPC to coordinate the handoff of live sockets, etc). Systemd's declarative model is far more limited in scope and can't possibly map to all of these creatively-beneficial uses of POSIX behaviors. Also, a full conversion of a system to systemd doesn't work well with just leaving some daemons as traditional sysv-init style, and the long course is to get rid of sysv init compatibility completely. This really screws these cases.

3b) It introduces a new latency in exposing new APIs. Before if, say, a new socket option appeared that was useful to a daemon, it first appeared in the kernel, then later in glibc, at which point it's at least conditionally available in a reasonable manner to portable (among linux versions/variants) software. Now we must wait for it to hit the kernel, then glibc, then systemd, and only then can the application take advantage of the feature. Who's coordinating this the way that kernel/glibc APIs are coordinated? This stuff isn't even documented.

3c) In general, while they minimally accommodate server-side daemon software, most of the development focus of systemd is for the desktop user's use-case. Thus these APIs aren't well-thought-out for the server-like case, and the concerns of authors of that sort of software are not being taken very seriously (see point 1). However, the distros which have all (how the hell?) been convinced it's a good idea to move their whole distro to systemd in the long run will obviously be using the same init system in both cases. I know we all want some year to be the Yea

Re:My opinion on the matter.

[LVSlushdat]

Who really needs systemd?

I've been working with Linux since 1995, where I started with Slackware, moved over to Redhat until it went all "enterprise-y", at which time I moved to Fedora.. Stayed there till a friend turned me on to Ubuntu in 2007, where I stayed pretty much till the recent Unity shitfest over there, where I then moved to Debian.. I cut my teeth on /etc/init.d and a stock standard init() process.. I could do pretty anything I needed to do in troubleshooting/starting/stopping daemons from memory.. Can't remember the last time I consulted a man page regarding anything having to with init() or logging.. Now with this $#@$%%$#@ systemd, I have manpages up ALL the time just to do simple shit that I could do with init() and standard logging in my sleep before systemd. It also seems like this crap is spreading like sewage over pretty much of the standard distros.. Debian/Fedora/CentOS.. The only one I'm somewhat familiar with (haven't used it recently) is Slackware and from what I've heard Patrick and the devs over there feel the same way I do about systemd.... Maybe its time to revisit an old friend.....

Re:My opinion on the matter.

[0123456]

Everyone hates X, so lets compare this thing I don't like to X. Even thought its obviously very different from X.

A few loud-mouths hate X. Most people who use X don't even know it exists. Those who use X the way it was designed (i.e. network transparency) can't understand why the loudmouths want to throw that away to build something like Windows, when Windows is dying.

Re:My opinion on the matter.

[thaylin]

In at least some cases the change as made because they have a dependency and that dependency will now only support systemd. Fedora/RHEL have a personal bias as they were the ones who developed systemd

Re:My opinion on the matter.

[CajunArson]

TL;DR version: You spend around 20 years getting used to the old way of doing it and now you can't stand change.

My story: Been using Linux heavily since 2000. Arch adopted Systemd big-time in 2013 or so. I spent a little while learning the new commands, and now it's just as easy/hard/whatever as the old RC system was. Oh, but my boot times are way shorter than they used to be.

Re:My opinion on the matter.

[psergiu]

Systemd's strenghts are:
- Fast startup & shutdown (compared to sysVinit);
- Better on-demand loading and stopping services and processes and changing network settings.

Compared with all the problem it brings:

- That is useful on a tablet or phone - where you never have to modify the factory configuration;
- A bit useful on a laptop - if you only use GUI tools that can do a limited ammount of config editing for you;
- Not very usefullon a desktop - unless you are prepared to get your hands dirty with systemD's smelly and poorly-documented guts;
- Useless on a server - where you only reboot 4 times a year or so and never have to hot-plug anything or change wireless networks.

For a server situation, the BSDrc style startup is even better than sysVinit.

Re:My opinion on the matter.

[Anonymous Coward]

What's broken is that some people would rather change Linux into something else fundamentally, rather than wait for the rest of the world to catch up. The result is going to be the same kind of pain that's happening in the browser arena. There, you have reasonable standards bodies who move "too slowly" for a few, who wish to replace the web with a new version that's obviously even more flawed, all in the name of progress. Sometimes the old guard aren't just holding back progress, but don't tell that to inexperienced youths and bitter old men who want to make a name for themselves.

Re:My opinion on the matter.

[0123456]

Was that so hard?

Hey, guess what? I did that, and it didn't work.

Hint: you missed at least one more place where you have to change the port number.

Re:My opinion on the matter.

[RabidReindeer]

This is the problem with systemd, Gnome 3 and a lot of other recent stuff.

Unix was originally designed rather like a tinkertoy set. The individual parts might not be very smart, but you could glue them together however you wanted. A "RISC" architecture, if you will.

Recent "improvements" to Linux have attempted to be all-in-one solutions. By making them one-size-fits-all, you lose useful, important, sometimes critical functionality. Because no one system can be all things to all people. It's a "CISC" solution, and what you are left with is what the designed wanted you to have, not what you wanted to have.

So that's the Great Divide. Turn into another Apple, where you can have any solution you want as long as it's the one the providers want to give you or retain the original spirt of the system, and allow it to be powerful at the expense of the presumed masses who'd gladly chuck Windows if only Linux was more friendly to the casual user.

Re:My opinion on the matter.

[RabidReindeer]

I think, for a lot of people, they don't have the challanges that systemd solves.

Conversely, systemd daily inserts problems that never existed before.

Actually they did. I dealt with binary log formats in Windows, OS/2, and IBM's mainframes. IBM has a really bad habit of creating a different binary format logfile for every app, complete with special binary utilities to be able to read them in any way you like - as long as it's a way IBM supports.

The old text logfiles might not be as tidy, but I constantly string together strange concatenations of the text utilities to garner critical information from them. Something that's nowhere near as easy when the logs are in binary form.

What systemd reminds me of is the Windows Registry. A fine concept that turned out to be a nightmare in practice.

Re:My opinion on the matter.

[geek]

My question then is why are we seeing a near universal switch?

Because Lennart works for Red Hat which is pretty much the only profitable Linux distro out there and has a massive amount of control in the Linux arena. If the change happens in Red Hat there is a 90% chance it'll happen everywhere else, which is basically what we're seeing with only a few holdouts on systemd like Gentoo.

Re:My opinion on the matter.

[TheCarp]

That, I must say, is one of the arguments that turns me off to it. I really could not possibly care less how long it takes any system other than my laptop to boot. My laptop does run a distro with systemd, and I do like that it boots fast....I would not hesistate for a second to give that speed up if I needed to for something I do once a day usually and twice a day at most.

The majority of systems I deal with are servers. They mostly have plenty of CPU and memory available and typically run very few services..... they boot plenty fast without systemd.

Really the most annoying thing about it for me isn't going to be learning it, its going to be training other people to deal with it and supporting them when they find the software they are installing isn't setup for it properly and they need to troubleshoot and fix it.

If there was some real benefit, I am all for it but....boot speed? Talk about not worth it if that is the "benefit"

Re:My opinion on the matter.

[Anonymous Coward]

This is something that has benefited Linux greatly in the past: the fact that a Solaris user could feel fairly comfortable with picking up Linux and just dive in.

http://en.wikipedia.org/wiki/S...

Re:My opinion on the matter.

[geminidomino]

It amuses me greatly that both replies to this post responded as if Bill was talking about "X" the windowing system rather than a placeholder variable.

Should've used $X. ;)

Re:My opinion on the matter.

[beelsebob]

Anyone that uses something besides Linux. One great thing about Unixen is how they share common interfaces. The more you change that, the less interchangeable the various Unixen become. The more reason their will be to resist moving from one to another.

Except that's actually false. Unixen really don't share common interfaces. Mac OS uses launchd, FreeBSD uses init.d, many Linuxes use systemd.

On Linux you'll find devices named /dev/hda(n) and sda(n), while on OS X you'll find /dev/disk(n)s(m), and on solaris you'll find /dev/dsk/c(n)t(m)d(l)s(o).

All unixes differ. Trying to claim that the way it happens to have been done in Linux for a while is the "one true unix way" is frankly bullshit.

Re:My opinion on the matter.

[gweihir]

Nothing is broken with Linux. But by now I believe something very fundamental is broken in a highly dangerous fashion with the systemd developers. They hardly seem to qualify as UNIX folks at all with their mind-set....

Re:My opinion on the matter.

[mrchaotica]

That sounds like a good way to create an infinite loop of crashing and restarting services.

Re:My opinion on the matter.

[geek]

Scientific/CentOS/Fedora/Fuduntu/OpenSUSE just to name a few. I could also list off all the spins like Korora etc. Yes it is a monoculture where the only people using DEB's are the hobbyists. Ubuntu was the one shining hope for something other than RPM but they crapped all over that.

If you want a job doing any type of linux work, you better know RPM. Period.

Re:My opinion on the matter.

[sabri]

You got a bunch of "upstarts" who don't know, or don't care, about Linux's roots and want to turn it into something it just never was meant to be

When I was a junior network engineer, I sometimes had to work on (what we now consider ancient) technology such as ATM, Frame Relay and ISDN. I even had my share of IPX/SPX. Back in those days, the experienced network engineers with 20+ years of experience despised Ethernet while complaining about those junior folks who knew nothing about the established technologies. As it turned out, all of them are out of a job now.

Bottom line is, when it comes to technology progress, roots are pretty much irrelevant. I don't care if something has been done like this for 1000 years. If we can find a better way to do it, let's do it.

The question should be whether or not systemd is progress, or an unnecessary burden. History is irrelevant in this case.

Re:My opinion on the matter.

[gweihir]

KISS is not a "religious idea" or a "sacred cow". KISS is the very foundation of all working engineering. Systemd throws KISS out the window.

Re:My opinion on the matter.

[Freultwah]

From what I read, I think the point was that if such changes *are* met with such fervent opposition, it is high time to step on the brakes and reevaluate the situation, and perhaps revert the changes.

Re:My opinion on the matter.

[evilviper]

- Useless on a server - where you only reboot 4 times a year or so and never have to hot-plug anything or change wireless networks.

Bull. Lots of servers currently run daemontools or similar, or else they use some other hack, because the SysVinit doesn't have any way to restart services (like crond) the one time they exit after running fine for months...

Alternatively, somebody has to take the time to set-up exhaustive monitoring, including ALL the trivial services running on the servers, and some dummy has to watch it around the clock, and manually perform this extremely simple and menial task. Or else maybe you're the dummy who gets paged at 3AM to do a trivial service restart, due to some simple and transitory event.

I would have been just as happy with upstart or anything else, but it was a dammed nuisance lacking that 30 year-old feature, and downright embarrassing that Linux still lacked it, while it's been working well in the base of Windows since the first version of NT.

Re:My opinion on the matter.

[Mordok-DestroyerOfWo]

Hell, most of my servers spend so much time in their boot process initializing RAID controllers, mem testing, etc. that the performance gain with systemd vs init is really not going to make that much of a difference. Add to that the fact that most of us have servers whose uptimes are measured in years, boot performance is pretty much the last thing I give a damn about.

Re:My opinion on the matter.

[Savage-Rabbit]

Everyone hates X, so lets compare this thing I don't like to X. Even thought its obviously very different from X.

A few loud-mouths hate X. Most people who use X don't even know it exists. Those who use X the way it was designed (i.e. network transparency) can't understand why the loudmouths want to throw that away to build something like Windows, when Windows is dying.

I mostly hate X11 because I have to program for it... It's like eating a cactus and washing it down with a whole bottle of Carolina Reaper Chili Sauce.

Re:My opinion on the matter.

[whoever57]

and I've lost count of the amount of times when I simply wanted to just find a way to make the init system restart a service automatically when it crashes

I cannot understand what your problem is. I have systems that run continuously for years without processes dying. I have systems where the OOM killer inadvertantly kills some system task, in which case, simply re-starting that task isn't likely to be a helpful response.

From the perspective of re-starting system tasks, systemd is a solution to a non-problem.

Re:My opinion on the matter.

[RR]

One great thing about Unixen is how they share common interfaces. The more you change that, the less interchangeable the various Unixen become.

The init system is a very poor example of Unix common interfaces. As beelsebob and oursland point out, different Unix systems use different init systems. The Linux alternatives, upstart and systemd, were actually inspired by the clear advantages displayed by MacOS X's launchd.

And even in Linux, with SysVinit, there are different interfaces. When you want a script to run at boot, do you use update-rc.d, like Debian? Do you use rc-update like Gentoo's OpenRC? Or chkconfig like Red Hat? Or insserv like SuSE? And where do you find important details like the hostname and network configuration?

I don't find systemd to be a pleasing design, and I especially don't share their love of long command names with lots of consonants, but I think their work is very important.

Re:My opinion on the matter.

[kthreadd]

RHEL 6.5 uses Upstart. It does not have Systemd.

Re:My opinion on the matter.

[Etcetera]

What's funny is it actually has the ability, and nobody uses it except for gettys.

This. Actually, in RHEL/CentOS, you can simply run /etc/rc every minute via cron and it'll sync what's running with what's supposed to be, assuming things have been /sbin/service stopped. (And if they haven't been cleanly stopped, you need a specialized tool that understands how to *TEST* the service rather than rely on subsys.)

Re:My opinion on the matter.

[Pentium100]

Are you also using 'cat | grep'?

What's wrong with that?

It is more convenient for me, for example
cat /some/file/somewhere| grep something (hmm, didn't get what I wanted)
cat /some/file/somewhere| grep some (good)

If I do grep something /some/file/somewhere and and to edit my search string, I have to move the cursor further than in the cat|grep version.

Also, I sometimes replace tail with cat when looking at a log file
tail -n 2000 | grep (it wasn't here, let's look at the whole file)
cat | grep (found it)

Re:My opinion on the matter.

[blue9steel]

Wait, why would I would the system init function to be monitoring and restarting services? That's an unwarranted scope expansion. Yes, I may want that capability, but there is no reason for the init function do be doing it.

Re:My opinion on the matter.

[Peter H.S.]

Re 1: Developers uncooperative?
Looking at the mailing list this doesn't appear to be the case. +500 developers have contributed to systemd, that points to excellent leadership where even small contributions are welcomed.

Re 2: Emacs syndrome.
It is popular but totally wrong meme that systemd just pile on features. Its scope have been quite narrow for years. Yes, it have gained new features, but almost all new systemd features are related to the original scope of stateless booting and light weight containers.
So people who hasn't bothered following systemd gets totally surprised when a new version of systemd has new features, but that is just because they don't really know systemd.

Re 5: Total disregard for everything outside of Linux,
All daemons made when sysvinit was king will work with systemd. It is backward compatible, even with sysvinit scripts (there are some few documented corner cases)

So daemon authors don't have to change a single line of code if they don't want to. The distribution managers can just add a service file instead of the sysvinit script. (probably remove some bugs that way too)

No other certified UNIX uses sysvinit scripts, they all have init systems more less like systemd. Does that mean they have a total disregard for anything e.g. not Solaris? (SMF).

I find the idea that all progress on Linux should be stopped if there is a danger that it progressed faster than other Unix'es (read BSD) a rather silly idea. Especially because those other Unix'es generally hate and despise Linux because it is a successful competitor.

systemd is the greatest thing happening to Linux for a decade, and probably the biggest shake up ever.

Re:My opinion on the matter.

[Darinbob]

The new guard in most arenas seem predisposed to think that newer is the same as better. And sometimes that is true. In the case of systemd it's a mix of some new stuff that's good and desirable but inseparable from other parts which are new but not so good. So the conflict seems to be in the push to get the new+good stuff out soon while other people are concerned rightly about all the new+bad stuff being pushed out without any plan or discussion.

Similarly, there's the ubuntu unity style of stuff: a big push by new guard that want tablet/phone presence, and an old guard wondering what corrupted their desktop (you could probably peek inside Microsoft and see the same divide in the Windows 8 debacle). You can see this in the Mozilla Firefox version deathmarch probably.

Ultimately it's the push to get new stuff in as soon as possible that leads to the conflict.

Re:My opinion on the matter.

[Attila Dimedici]

Bottom line is, when it comes to technology progress, roots are pretty much irrelevant.

Translation: "Why should I learn from the mistakes made in the past? I'll just make them all over again. All in the name of progress."

Re:My opinion on the matter.

[Vellmont]

I don't think the seasoned admins will argue that systemd is bad because it doesn't follow history, they'll argue it's bad because it doesn't follow well established design principles.

(I'd also dispute that there really were a large percentage of Network engineeres who really disliked Ethernet. I heard some complaints 20 years ago from people who did real-time process control systems, but that's quite a small nitch.)

I've been doing Linux admin in some fashion or another for 20+ years, so in many ways I'm part of the "old guard". The argument about small being better, making programs that do one thing well, etc is a good design element that's worked for years. At the same time I've also often been bitten by the problem of having to port "yet-another-shell-script-for distributiion-X" problem that seems like it should have a more standardized way of doing things. So from a replacing init-scripts perspective, I can see the appeal.

I'm not heavily involved in administration like I once was, so I don't have experience with systemd as of yet. (My systems run Ubuntu or Debian, no RHEL7). With that said, the monolithic design and trying to do everything sounds like a major design flaw to me.

Re:My opinion on the matter.

[DamnOregonian]

Entirely false. In an environment with ~400 servers, it's not remotely close to a full-time job. For services that suck or are prone to crashing (very, very few on our deployments) an inittab restart directive does the trick, or for things that are prone to hanging and going full retard, monit does the trick.

You know what sucks my ass though? Not being able to modify the init scripts as I need. I'm so glad we've made a daemon that will make sure I never need to alter the low-level starting dynamics of a service again. At least I assume it does that, since it *does* deprive me of my ability to.

Re: My opinion on the matter.

[Selivanow]

If that is the case then someone at Redhat needs to be hit with a Clue-by-four (tm). A system should have absolutely ZERO binaries/files that are required to boot into a working (if only minimal) system in /usr. Stupid, man. It's universally stupid.

Re:My opinion on the matter.

[DamnOregonian]

One could call it a limitation, but it's also manifestation of the UNIX security model.

Any random Joe Schmuck can also make a required change to the blinkenlightsd init script to programmatically alter its startup characteristics to fit his unique system startup requirements. He can't do that with systemd. I call that a limitation. So what we're really arguing is whether or not the status quo limitations are less important than the new limitations you want to introduce.

Re:My opinion on the matter.

[blue9steel]

A properly designed browser using *nix philosophy wouldn't do those things directly, instead it would use plugins to add that functionality.

An init system should do one thing and do it well, manage the startup of services when called. A proper *nix designed system for monitoring and restart would CALL init, but it shouldn't BE init, otherwise it violates the principle of modularity.

Consider for example looking for all the active settings in a standard Linux config file:

grep -v ^# ldap.conf | tr -s '\n'

By using two standard tools you can do something pretty fancy, basically stripping out all the comments. Could grep be enhanced to include the newline trimming feature? Of course it could, but that's not grep's job, its purpose is to match things not trim things. By keeping the scope narrow you reduce the error space and provide a more flexible toolset.

If you design the monitoring system into init then it can't be used generically to monitor other things and you lose half the value of the tool you've created.

Re:My opinion on the matter.

[Smallpond]

Embedded systems are exactly the ones that don't want a bloated init system that requires dbus for communication.

Re:My opinion on the matter.

[Electricity Likes Me]

Run blah every X seconds is just about the dumbest way we can be doing things on a computer. It's a closed system. It can know exactly when a process dies, and handle the event then. The inability to do this is a huge flaw.

Re:My opinion on the matter.

[Rakarra]

Also, what advantage does X forwarding offer over VNC?

Integration with your existing desktop; the forwarded app works just like an existing app.

It's like you get married and instead of you and your wife moving into the same house you just move your houses together so you have two external windows that are touching and you can look into her house. That's such a stupid analogy but it just occurred to me so of course I have to jot it down here.

Re:My opinion on the matter.

[Peter H.S.]

Despite what people claim, systemd is a perfect example of one tool does one job and does it well. Systemd is an umbrella project where a collection of tools are developed in the same place, and with the specific aim of making the tools work together in a modular integrated fashion. There is nothing monolithic about systemd and the way it works.

So "systemctl" controls stopping and starting services, "journalctl" filters log files and displays the output via a pager ("less" is standard, but it is easily changed), "hostnamectl" sets and display hostnames etc.

All the tools can be chained together with standard pipes, so they are just like any other Linux tool, though remarkable well made (tiny and fast) and well documented. bash-completion is also well integrated, so "hostnamectl " will show all possible keywords.

Regarding network engineers disliking ethernet; I heard plenty of that in those days. Remember, ATM was once king in telecom, and Token ring in the LAN world. Believe me, at lot of those network guys really looked down on ethernet in the beginning; they saw it as primitive and that it did everything the wrong way. The "happy-go-lucky" ethernet attitude to network collision grated on their nerves.

Re:My opinion on the matter.

[GigaplexNZ]

There is no "fundamental change" to Linux with systemd

I'd call moving DBUS into the kernel, assimilating udev, and making the init system a large complex system that does lots of things rather than the old school ideology of doing one thing and doing it well, some pretty big, somewhat fundamental changes to GNU/Linux.

Re:My opinion on the matter.

[evilviper]

you can simply run /etc/rc every minute via cron and it'll sync what's running with what's supposed to be assuming things have been /sbin/service stopped.

A "crash" does not involve anyone running "service X stop" so you're providing a solution for a problem nobody wants nor asked about.

(And if they haven't been cleanly stopped, you need a specialized tool that understands how to *TEST* the service rather than rely on subsys.)

And that specialized tool is... wait for it...

THE SERVICE'S OWN INIT SCRIPT!!!

That's right, you can iterate through service "$X" status on everything, and do a restart on anything that has terminated, but that's just a hack, and something that can be done infinitely superior within the software handling the service startup... namely, upstart or systemd.

I hate Lennart Poettering and PulseAudio as much as anybody, but SysVinit is broken, and systemd is a fix. Angry zealots repeatedly denying that there's a problem, is probably why it's taken so very long before a fix finally arrived.

Re:My opinion on the matter.

[TheRaven64]

The problem is that X was designed for network transparency in a usage model that no longer exists. X is great for network transparency when the server is doing all of the drawing. Unfortunately, the server can't do simple things like antialised line drawing, so people render on the client and then push (uncompressed) pixmaps to the server. A few issues with X11:

Some trivial things, like the fact that command IDs are 8 bits and over half of them are taken up by 'core protocol' things that no one uses anymore. this means that every extension (i.e. the stuff people actually do use) ends up providing a single 'do stuff' command and then a load of subcommands. This limits the number of extensions that you can have loaded and, because the assignment of extensions to command numbers is dynamic, makes intelligent proxies just that little bit harder to write.

There's no easy way for an application to get all of its server-side state. This means that you can't, for example, have the X server crash (or even restart cleanly after an upgrade) and have all clients reconnect and recreate their windows. The Windows and BeOS display servers, for example, have this feature. You also can't tell an application to disconnect from one server and move its windows to another easily. This ought to be basic functionality for a client-server windowing system. There are proxies that try to do this, but they break in the presence of certain (commonly used) extensions.

There is no security model. Any app can get the entire input stream. Keyloggers for X are trivial to write as are programs that inject keystrokes into other applications. Neither requires any special privilege, nor do applications that subvert the display hierarchy (e.g. window managers).

The XRender extension is basically useless. It lets you do server-side compositing, which ought to make things fast. OS X gets a lot of speedup from doing this for text rendering: programs (well, system libraries that programs use) render glyphs in a font to server-side buffers and then the server composites them in the correct place. This doesn't work well with X, because most toolkits aren't set up to do text drawing on the server but everything else on the client (which is needed because the server doesn't provide a rich set of drawing primitives). Fixing this would mean adding something like the full set of PostScript or PDF drawing commands to the server.

XLib is an abomination. It starts with an asynchronous protocol designed for latency hiding and then wraps it up in a synchronous interface. It's basically impossible to use XLib to write an application that performs well over high-latency (more than a few tens of ms) link. XCB is somewhat better, but it's fighting toolkits that were designed around the XLib model so ends up being used synchronously.

None of the network-transparent audio extensions caught on, so your remote apps can't even make notification beeps (worse - they can, but on the remote machine).

If you designed a modern protocol for a network-transparent windowing system, you'd end up with something a lot like a web browser. You'd want PostScript drawing contexts (canvas tags, in HTML5 parlance), server-side caching of images and sound samples (image and audio tags, in HTML5 parlance), and OpenGL contexts. The library would keep a list of all of the contexts that it held on behalf of the program and would be able to recreate them on demand and request that the program reinitialise them. You'd be able to run small snippets of interpreted code on the server (so that things like pressing buttons or opening menus didn't require a full network round-trip - something that DPS and NeWS got right in the '80s, but X11 got wrong). You'd ensure that input events only went to the current view or its immediate parent (if explicitly delegated), or to a program that the user had designated as privileged.

It's possible to do a lot better than X11. Unfortunately, most projects that try seem to focus on irrelevant issues and not the real ones.

Re:My opinion on the matter.

[Rich0]

From every experience I've had with systemd, I'd say that it is NOT progress. I don't want every little thing integrated in the manner systemd does.

Integrated in what way? Sure, they have a bundled suite of applications, but you can swap out journald for syslog just as you can swap out koffice for libreoffice if you run KDE. It has some dependencies like udev and dbus, but that's just a design choice.

And frankly, OpenRC is a lot better.

How do you figure? I've been using OpenRC for more than a decade and there are a LOT of things it doesn't accomplish like:
1. Having upstream-provided service scripts for most packages. Most OpenRC scripts are custom-built by Gentoo maintainers. If a Gentoo maintainer doesn't maintain a script, you will have to write your own.
2. Actually stopping services thoroughly. If a service doesn't clean up children properly. OpenRC doesn't care.
3. Optional auto-restart.
4. Sane network configuration. The networkd configuration is much simpler than oldnet/newnet/whatever.
5. Drop-ins. I like a Gentoo-provided openrc script, but I want to set ionice. That means hacking up the script, and then merging in changes every time it is upgraded. With systemd I just stick a drop-in file into /etc that sets that one setting and systemd merges it in every time.
6. Booting in milliseconds in a container. I'm not sure how well it boots in a container at all, though I know this is being worked on.
7. Clean shutdowns when you're using stuff like lvm/raid/etc. Systemd can drop to dracut and allow the initramfs to do a full clean unmount. Sure, the read-only approach works reasonably well, but it always bothered me seeing OpenRC shut down with in-use messages.

OpenRC is about as good as it gets for a traditional bash-based service management system. I've always been happy to use it. However, unless I'm stuck on BSD or something I doubt I'll be using it much in the future.

My distro is better than your distro

[NotDrWho]

And THAT pretty much sums up what has always held Linux back (and probably always will).

What battle? (2010 wants its article back?)

[xxxJonBoyxxx]

At the moment, just about every major distribution except Slackware and Gentoo not only supports systemd, but ships with it on by default.

So...what "battle" are we talking about? (Or did this post just fall forward five years from the past?)

This is just a rant

[MobyDisk]

This article is just a rant, full one one-liner insults and clichés. There are probably good debates on this topic, but this is not one of them.

systemd adds to and supports the old model

[Eravnrekaree]

the general concept behind systemd makes sense, its mainly some additional features on top of the current model, such as the ability to have processes started on certain system events. The fact is, if you want your bootup process to be controlled by bash scripts, all you need to do is configure systemd to start your bash script and youve got a more traditional init system. So, systemd does not take away any functionality, only adds it. Systemd supports the system v init process features so you still have all the old model functionality available to you. So, it does not make much sense that people complain about this when they can easily configure things however they want, including having a BSD style init, by having systemd hand off control to your own scripts, including to work the way things always have. People act like systemd has taken away something when it has not, i think many people just hears some soundbite about systemd introducing a new model and assume that they can no longer use things the way they do currently, which is not the case. it seems like people who don't like systemd don't want people to have the additional functionality that it provides, because it does not take away anything. Its open source software, and its something that you can control and configure to your hearts content. Its much ado about nothing. systemd, while being configurable, also will make things easier to use for many users. I think the ado about systemd is more about Linux people who think that Linux should be hard to use except for a small elite and do not want the OS to be useful to less technically adept users. This is even though making it more useable for less adept users does not in any way harm or take away flexibility from experts, who can still configure everything if they want they want to.

Re:systemd adds to and supports the old model

[CRCulver]

I think the ado about systemd is more about Linux people who think that Linux should be hard to use except for a small elite and do not want the OS to be useful to less technically adept users.

If by "less technically adept users" you mean ordinary PC users who are being encouraged to adopt the Linux desktop, there is no reason that the init process has to be changed to woo them, because such users won't ever touch the system internals anyway, whether they be sysvinit or systemd.

If by "less technically adept users" you mean people with some command-line skills but who are not yet Unix wizards, well, arguably systemd makes things more difficult for them. One of the biggest reasons systemd adoption has pissed people off is that for the systemd devs, documentation is at best an afterthought. The API has changed significantly over the last couple of years, but most documentation one can find on the internet is now out of date, and it has not been replaced with docs for the current state of systemd. sysvinit, on the other hand, is extremely well documented from a number of sources, and the technology remains accessible to anyone with some bash skills.

A plague on both their houses

[Anonymous Coward]

Yes, the old SysV init of hordes of scripts running in series was broken - especially for large-scale systems that have to do a lot of things during startup.

But systemd is just plain FUCKED UP. Read the dependencies.

Why the fuck does the startup process have to depend on the IPv6 kernel module? The other dependencies are no better.

Re:Display server

[psergiu]

As long as xterm & the web browser are running on Wayland, nobody will complain.
X.org has became such a mess itself (compared to the old XFree86) so anything smaller, simpler, faster and 100% compatible is welcome.

OTOH systemD is not smaller, simpler and 100% compatible with the systemV init and BSD rc - so it requires everybody relearning a lot of concepts for scratch just to gain 4-5 seconds at boot time - unsually on a server that you reboot only a couple of times a year.

Re:Choosing Sides

[present_arms]

What system V and systemd do is initialise the OS, let me kinda explain, you turn on your pc, it loads the bootloader which in turn loads the init system, the init's systems job is to hand off certain jobs to certain programs, getty so you have cli, X so you have a nice GUI, and starts or stops services. This is a very simplistic explanation. Now it's my belief that Init should be made with separate components, for instance system V will read the scripts from /etc/rc.d and depending on those scripts depends what's loaded at boot time. Now the problem with systemd is (from what I believe) is that it's a one-stop for all, encompassing all the scripts needed, and gaining bloat (mostly not needed) at the same time. It's starting to be the "registry" of the linux world. and NO-ONE with a hint of intelligence wanted the Windows registry, let alone a clone of one.

Re:Still on

[Eravnrekaree]

Systemd still supports the system V boot process features, you can still run init scripts from systemd if you wish.

Re:Not in this instance

[jedidiah]

> GNU/Linux is still pretty irrelevant outside of cheap server

Linux is the flagship platform for a leading enterprise software vendor that sells their product for 60K per CPU.

One single server installation of their product can cost more then your domicile. This is true regardless of where you live or what kind of structure you live in.

Linux isn't just "relegated to cheap servers".

not reasonable at all

[rubycodez]

A complex startup system that logs to a database rather than a text log, is just poor engineering.

And to answer any systemd apologist who will mention that it can configured to log to syslog, that won't help if there is a problem in the vast complexity of systemd that prevents it from ever getting started to that point.

Just the requirement for dbus proves systemd far too complex and bloated a thing, it is against the Unix way of doing things. Failures and problems in a needlessly complicated black box may well be too difficult to even troubleshoot

Re:If systemd is deemed going against unix philoso

[rubycodez]

Yes, the bloated pigware Sun/Oracle has put into Solaris is against the Unix philosphy and bad. I speak as Sun Certified Systems Engineer with 24 years experience in Solaris/SunOS. Happy?

MacOSX is a desktop system, who cares how complex Apple makes it to be easy for non-admin to use? not relevant to this discussion of a bloated complex thing for servers.

There, your questions have been answered.

Re:A complex, fragile, unmanageable TURD

[HiThere]

It actually did need more than just streamlining, e.g. it needed to use multiple processors if available. But systemd seems "a bridge too far". OTOH, I prever grub over either lilo or grub2. Grub gave me enough control and was easy enough to understand for the simple features I wanted to use. Grub2 is inintelligible, and all the readable files say "warning: This file will be automatically overwritten". And lilo didn't give me any control over what what happening.

I'm not deep into systems administration, and I don't want to be. OTOH, I do want to configure my own system to do what *I* want. And what I want is often not what the designers of the software expect, even though it's well within the range of things handled by the software. So I dislike systems that are either too automagic or too inflexible. Systemd is, from all reports, too automagic, and simultaneously too inflexible. So I'm seriously thinking about switching to Gentoo or Slackware. Or even one of the BSDs, though I don't know enough to even guess which one. (I have a desktop orientation, not a server or minimalist orientation, but I need to do some server style jobs. Most Linux systems will handle this easily, but I think that some BSD systmes are too heavily oriented towards server setups.)

Re:I call TROLL ALERT

[HiThere]

It's true that most distros are committed to using systemd. That doesn't make it a good choice, and it was often a very narrow vote that approved it, because that are lots of things to hate about systemd. Also, a large number of people don't really trust the lead developer. And .... well, there are a large number of things not to like about it.

I'll probably wait to decide that I won't have anything to do with it for awhile, though. Perhaps it won't turn out to be as much of a blivet as it looks like. But in the meantime I'm going to be checking out alternatives. Just in case. If it's as bad as some have reported, I may be switching to some flavor of BSD.

Re:It's job security

[msobkow]

System admins both old and new that are worth anything don't want things changing just for the sake of change.

It boils down to the old adage: "If it ain't broke, don't fix it."

Which further boils down to something admins care very much about: stability and reliability. Changing something that's been in production for 5, 10, or more years just because someone decided to roll out the new "shiny, shiny" is not an effective use of the admin's time.

Last but not least, admins are often responsible for systems from multiple vendors. Having a unique configuration model for each system goes against the whole point of things like POSIX APIs and standardized startup processing.

Sure on a desktop or developer system, the difference is probably irrelevant. But when your main job is configuring and maintaining services on servers instead of just using a box, the arguments and priorities change for damned good reasons.

Yep, cheap $390 million supercomputer servers

[raymorris]

I notice that of the top 500 fastest computers in the world, 97% run Linux. http://www.top500.org/statisti... That would include the $390 million Tianhe-2. Oak Ridge National Laboratory spent $60 million to upgrade the $104 million Jaguar to become Titan, both running Linux. So yeah, if you're definition of "cheap" includes "the most expensive and powerful in the world", I guess you're right.

Mirrors industry schisms...

[Etcetera]

You can see this in Development vs Operations, Bay Area Startup Hipster Programmers vs System Administrators Who Have To Carry The Pager, Big Data vs Simpler Analysis, and a lot of other places in the industry right now....

There's an influx of talent that doesn't seem to understand the fundamentals of system architecture, or assumes they have all the answers and can/should hard-code them into the design, preventing "the Unix Philosophy" from being applied by the operator who's trying to deal with the crisis at 3 in the morning. "whatcouldpossiblygowrong", ergo I shall design this in C, and if you need more flexibility than I'm offering then You're Doing It Wrong.

What they don't understand is that they don't have all the answers... Nobody does. The only solution is to leave as much flexibility available as far down the stack as possible to allow the folks who have to deal with this (eg, system administrators) the ability to do their jobs. Replacing shell scripts with C code and the unix toolkit with monolithic binary blobs does not help the situation.

systemd does a few things right (cgroup management, for one), and promotes the state of the art in a few areas that probably only could be dealt with at the PID1 level... Also, as the original article admits, there's nothing inherently wrong with working to speed up boot times across the board. All of these things are irrelevant and outweighed by enforcing declarative styles on system configuration, and the sheer philosophical hazard of taking all these disparate functions and putting them into a program.

It makes absolute sense for Android, and perhaps an embedded system that just needs systemd and busybox. For a regular Linux userland, it takes us in the wrong direction.

Re:What battle? (2010 wants its article back?)

[blue9steel]

I've yet to read something I'd consider a valid argument against it.

It violates basic *nix design philosophy, which basically has two pieces: 1) Everything is a text file 2) Lots of small tools that can be chained together to do big things

Boot time is essentially irrelevant, I don't see why everyone gets so excited about it.

Re:What battle? (2010 wants its article back?)

[davek]

At the moment, just about every major distribution except Slackware and Gentoo not only supports systemd, but ships with it on by default.

So...what "battle" are we talking about? (Or did this post just fall forward five years from the past?)

Ubuntu is the largest distro I know of and it doesn't support it by default.

But you're right, all the arguments I've read against it boil down to Linus hating on one of the developers on the project and/or "It's too complicated and unmanageable!" I've yet to read something I'd consider a valid argument against it. A bunch of neck beards yelling "Get off my lawn!" is not and argument I can get any value out of.

When the neck beards speak, it's often prudent to at least listen.

I'm reminded of a myth, of when the Ancients were sitting down to design Unix, someone said "Why would we ever need a special file, that never contains any data, and always throws away everything written to it?" The Ancient replied, "Trust me, you'll need it." And thus, /dev/null was born.

Re:Display server

[CajunArson]

[quote]Right now I'm running two copies of Eclipse from a VM, displaying on the host machine's desktop using X-forwarding. Under Wayland, that'll require either pushing megabytes of pixels every time I scroll a window, or using some god-awful VNC crap.[/quote]

Let me fix that for you:

Using X-forwarding *right freaking now* you are pushing megabytes of pixels every time you scroll a window because every single modern toolkit operates that way and you have obviously got problems distinguishing between a simple tutorial on the 1985 version of xterm vs. how real applications that are forwarded over sockets in the real world actually behave.

Re:Better question

[fnj]

Nobody is forcing the adoption? Really? You do know that Gnome3 has a dependency on logind and logind has a dependency on ... yes, kids ... systemd.

Re:Choosing Sides

[Zocalo]

Not just the Registry, but it's also rapidly becoming the equivalent of "svchost.exe". I probably wouldn't have a problem with SystemD if it were designed to be *much* more modular, but the design goals for the package seem to be to embrace, extend and extinguish a significant number of other processes essential to the Linux boot process and to bring most of it straight into PID1. That's just asking for major problems if/when anything goes wrong, and makes troubleshooting a nightmare because you have one huge black box instead of a bunch of daemons. If the SystemD team want to manage network startup, system logging, firewalls and whatever else takes their fancy, then fine, go right ahead; just do it in a way that makes it easier for system admins to disable it and plug in a more fully featured and/or stable alternative, and do it as a child of PID1 so if/when it does crash it doesn't bring the whole system down with it.

If you want an eye opener take a look at the dependency list for SystemD and those packages that depend on SystemD some time, note how entries appear in both lists, then consider the following questions: Bearing in mind that SystemD is the first thing that is loaded after the Kernel; does that look like a good design to you? Does it explain why so many distros have adopted it, given that many of those dependencies either won't work without SystemD underneath or require a considerable amount of customisation to use any alternative?

Still, there's always BSD.

Re:Choosing Sides

[Anaerin]

You're posting a lot on the drawbacks of SystemD, but you're not including any of the drawbacks for SystemV.

• SysV starts every task and service one at a time, waiting for the previous one to finish before it starts the next. This is fine for single-core single-threaded workloads, but most systems these days are multi-core. It also means that startup is slow. SystemD, on the other hand, can (and does) start up services in parallel, making sure that dependencies are resolved before starting the next item. This makes SystemD MUCH faster at booting.
• SysV only handles the initial bringing up, and the final tearing down, of services. Any service failures are not noticed, any errors are not dealt with. SystemD monitors services even while they're running, and can re-start them if they fail, handle crash reporting and log rotation. This makes SystemD more error resilient and stable.
• SysV only runs the services, and doesn't care about their configuration, so basic configuration and dependencies have to be handled in a myriad of ways, different for every service. SystemD attempts to be a central repository for ports (and handling the necessary firewall rules for them), configuration files, logging locations, and the rest. While this does make startup a touch more difficult to configure, it makes the system as a whole a lot simpler to deal with.

Re:snydeq = InfoWorld

[satch89450]

I felt it was enough a problem to submit a bug report to the CentOS people: https://bugs.centos.org/view.p... -- the problem I see is that the documentation for systemd and the observed results are different. Further, there are no instructions on how to take a System V init and convert it cleanly to systemd. I don't have a Red Hat Enterprise support license, so I couldn't report the issue to Red Hat. One of the problem of using an alternate distribution.

To this developer's eye, the systemd documentation is not ready for prime time. Note that this bug was reported against 6.5, not 7. I'll be looking at 7 when I get a round tuit.

The init system

[jbolden]

What's broken is this. The initt system assumes:

1) All the subsystems boot quickly
2) None of them need to communicate back and forth about status in complex ways
3) The list isn't too long

There exists lots of users for which one or more of those 3 assumptions are false. If you don't assume those 3 then you would design boot differently.

What is being done to mitigate risks?

What's being done is large Unix distributions are heading the effort that deal with thousands of packages. The risk is being handled by going through package by package by package and resolving any small problems.

How is this going to impact how Linux fits in with other Unixen?

The 2nd most used Unix is OSX. That uses launchd. That of course handles the problem of integrating in daemon tools and cron like features into the launch system which is different than either init or systemd. If the goal were better compatibility with other Unixes that not init would be the target.

Anyway the big change is likely to be that more and more linux software is going to assume systemd as hard dependency which means that other Unixes are going to have to switch or at least support systemd if they want to be able to port from Linux.

Re:The init system

[Anonymous Coward]

1) systemd cannot be ported to other unices because it depends on a feature, cgroups, that not even the Linux kernel maintainers like. No way will cgroups ever make it onto another Unix. It's a stupid design, but Linux is stuck with it because of Linus' ABI guarantee.

2) Software not written by idiots will continue to be portable. Network software which relies on systmd, kdbus, or glib is fundamentally a piece of trash. Desktop/application software doesn't typically have a direct dependency on systemd, and regular, user-space DBUS is portable and already runs everything. And while glib is trash, it's acceptable for desktop software.

3) The problem with systemd isn't that it's a new init system. If that's all it did people wouldn't care nearly as much. What's happening is that systemd is slowly becoming a replacement for all kinds of other things, such as NSS, PAM, etc. Basically, when Red Hat can't get their way with an upstream maintainer (including Linus and the kernel!), Lennart says, "hey, we can just add that feature into systemd and then we don't have to care about compatibility or working with those maintainers".

I write portable server software. All of my stuff currently compiles and runs on Linux, FreeBSD, NetBSD, OpenBSD, Solaris, and AIX (in other words, all the extent, server-grade Unix platforms). It's much more trivial than people believe, thanks to continually improving POSIX support by all vendors. Most of the portability horror stories are from the 1990s. I don't even bother with autotools, since it's trivial to build and install dynamic libraries on all those platforms.

I'm sad to see systemd evolve the way it has because it heralds the fact that a large part of the FOSS community has decided to give up on portability. Any software that directly depends on systemd's geometrically growing feature set will always be completely and utterly unportable. It'll also be largely crappy software. One reason I focus on portability is because compiling and running software on different environments tends to bring more bugs to the surface, and do so more quickly. I've found compile-time and run-time errors on OS X or Solaris that actually uncovered bugs which would have effected behavior on Linux, but which would have been much more difficult to discover on Linux because of the different types and slightly different run-time behavior.

Re:The init system

[shutdown -p now]

systemd developers explicitly stated that they do not care about other OSes at all. If it is ported, then whoever ports it has to maintain it. Not to mention that they'll either need to port all the Linux-specific OS APIs it depends on, as well (and then maintain them), or else rewrite huge chunks of it. Basically, it's non-portable by design.

This is why the effects of this are so big that they go beyond Linux even. It means that software, in some cases, has to make a choice over whether it wants to support other platforms at all, or at least with reduced functionality. This doesn't bode well for *BSDs.

Discordian date

[RDW]

Never mind trivial things like systemd - the real watershed moment for Old Unix vs New Linux was back in 2011, when a humourless package maintainer excluded 'ddate' from the default build of util-linux:

http://en.wikipedia.org/wiki/D...

https://git.kernel.org/cgit/ut...

https://bugzilla.redhat.com/sh...

A Windows-like UNIX

[Anonymous Coward]

I was involved in another discussion in one distro where the idea was floated to replace all of /etc XML files. A number of people even proposed replacing /etc with a mysql database that could be stored on or off the local system. Of course the idea was shot full of holes but having said that, the Next Generation (TM) thinking is that of replacing the UNIX paradigm of chaining simple tools together with larger monolithic tools. One of the arguments against was that if any of this broke the only recourse would be to re-image the box (reminds me of Windows). As a "dinosaur" myself I'm not enamoured with the idea that Linux (and Solaris and *BSD to a lesser degree) are becoming more Windows-like, Personally, I'd rather be in control and I don't like it when software "thinks" it's smarter than I am.

Re:Display server

[organgtool]

In addition to that, it is theoretically possible to get RDP in Wayland working similar to X-forwarding. RDP has superior performance to X since it supports compression and it can be used to share a single application or an entire desktop, just like X. At that point, X will hold absolutely no advantages over Wayland.

OpenRC

[jbolden]

OpenRC is a really good replacement for SysV init. A serious enhancement that keeps with the spirit, an upgrade rather than a rip out and replace. OpenRC doen't keep daemons alive but that would be easy to add. Ultimately then there is only one hard problem what to do about hardware that changes. OpenRC doesn't architecturally have any good way for handing that while systemd does.

Certainly if the argument were OpenRC vs. systemd instead of SysV init vs. systemd I suspect the advantages of systemd wouldn't have outweighed the huge shift. I hope distributions like Slackware which don't have systemd move to OpenRC so that it gets tested in environments other than Gentoo.

PID1 - A Controllable Master Control Program

[LordMyren]

Launchd is the young whippersnapper on the block. Solaris has had daemon administration for years.

The old guard is a huge fan of PID1 doing it's thing then going away: it's up to everyone else to manage the world after PID1 kicks everything off. The new world- the people who like systemd- are enthusiastic beyond belief to have a PID1 which serves as a master control point where the system can continue to be managed. Every systemd subsystem has a DBUS API we can program and talk to, we can schedule coordinate and manage processes over systemd's core DBUs endpoint- this speaks of the new dawn where we might not be able to hack our shell scripts to do whatever, but we can write higher level code to effectively manage their operation. Which is something that royally sucked egg in the old guard's world.

Sure some of this could sort of be dealt with by continuing to add more shell scripts. But the init script world is mess. Individual daemons have radically different ideas of what kind of responsibility they need to handle in their init scripts and even though for the most part the skeleton is visible across all, it's a hack job that outsiders have to wrack their brain to understand. Conversely, systemd gives us uniform control over the system: the master control program PID1 that is systemd will let us start/stop things, AND will tell us the status of things (over either shell interfaces or DBus).

I look at this more like the innovation of steering- which permitted four wheel vehicles- than I do a particular engine configuration (different muscle, same end). Sure you could get there with the old two wheel drive cart, but as it turns out you have a lot more flexibility when the platform has consistent stability that permits being added to. Where the cam goes is an argument that affirms the lie that systemd is just a really complex initscript: it's not, it's a resident system control daemon.