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.

[present_arms]

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

The difference being is that X is the best windowing system for versatility, nothing else from anywhere is close as bad as it is. There was nothing really wrong with system V the idea of systemd in the beginning was to shave a few seconds off booting to a desktop, and us linux users hardly ever have to boot in the first place (for most, not all I admit, it's nicer to put the machine in to sleep or hibernate.).

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.

[eneville]

Boot up performance is one of the things in its favour. For that alone many people will want it rightnow so there's a lumbering mass gravitating to distros that implement. I for one welcome our new systemd overlord, not because I like it, but because I like the boot performance.

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.

[mysidia]

(go ahead and change the pgsql listen port - and see how long it takes you...)

vi /var/lib/pgsql/data/9.3/postgresql.conf

^] :%s/^#port = 5432/port = 1234/
:wq
semanage port -a -t postgresql_port_t -p tcp 1234
iptables -I INPUT -p tcp --dport 1234 -j ACCEPT
/usr/libexec/iptables.init save
systemctl restart postgresql

Was that so hard?

So sorry that even with iptables-save installed and the new systemctl firewalld turned off... "service iptables save" command has disabled so suddenly, even though it's been used in Redhat for over 15 years.
Yeah... you now have to deal with 'iptables-save > /etc/sysconfig/iptables' or manually finding where the service script's been moved to be able to invoke the save verb which used to be a short 3-word one liner command, But this is "progress".

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.

[jellomizer]

True,
However Linux has shone from time to time that it was able to push Traditional Unix systems to switch to their method of doing things.

However the real question is what is the benefits vs cost of the change.
How will that affect GNU/Linux primary purpose (Server OS).

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.

[dosius]

"What's broken exactly?" - PRECISELY.

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, something other than, well, a *x. And I'll fight that derailment like a tiger if need be.

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.

[Anonymous Coward]

The primary reason everyone is switching to systemd is because it saves the distro and package maintainers a huge pile of time spent integrating packages. Unit files are maintained upstream by the individual projects. "Arch, Debian, Fedora, Mageia, openSUSE, RHEL, Ubuntu and possibly others" can now all use the same unit file published by the upstream project instead of tailoring init scripts.

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.

[gweihir]

You must be really stupid. Otherwise you would be able to use a search-engine and would have found out that there are numerous ways to do so and none of them involve complex software (except the systemd version). Hell, I wrote a python-wrapper in a few hours for that 12 years ago that has since worked flawlessly 24/7.

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.

[gweihir]

Bullshit. There is no "need" for systemd. It does solve a few exotic problems and does to at a huge cost to reliability, security and flexibility.

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.

[evilviper]

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

SysVInit is broken. It doesn't restart services that crash. In an environment with many hundreds of servers, the menial task of restarting services becomes a full-time job.

Re:My opinion on the matter.

[JohnFen]

I have to admit, I've never understood this fetishism for boot times. Boot times stopped being unreasonably long years ago. Why do people still care about modest improvements in speed to something that doesn't happen that often?

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.

[Anonymuous Coward]

:wq

Why?

ex/vi had ':x' (and ':x!') since its very beginning, which has the advantage of not 'touching' the file gratuitously when no changes were made.

There's also the 'ZZ' command while in visual mode.

Are you also using 'cat | grep'? This parrotting of 'geek creed' signs is really getting on my nerves -- better don't show up with your 'wq:' tee-shirt in my neighborhood ;-)

Re:My opinion on the matter.

[Anonymous Coward]

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

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.

[losfromla]

KISS was a shitty band anyhow.

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.

[phoenix_rizzen]

I'm leery of systems that automatically restart services when they crash, especially if the service just crashes again at startup, and you get into an infinite loop that eventually runs you out of disk space with *.core files.

If you need a system to be up that often, it's much nicer to setup a fail-over system or a cluster, where it doesn't matter if individual daemons or systems are running, so long as there's another to take it's place. Then you have time to investigate why things are failing on one node, and can implement a proper fix.

Auto-restarting crashing daemons is not a feature. It's a band-aid over top of poor system administration.

Re:My opinion on the matter.

[Cyberax]

Sure. Systemd also has a watchdog infrastructure - your service can periodically touch a certain file, and if it hasn't been updated for a certain amount of time then systemd will restart your service. Or you can do something totally crazy and simply use systemd to stop/start your service.

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.

[TemporalBeing]

FYI - I've written many daemons. In cases like this, a crash needs to stay down until the admin gets to it.
Why? A restart of the service may very well clear out any logs relevant to the crash.
This is especially true once the service starts relying on things like D-Bus where settings are live and can themselves be the source of the crash, but are not discovered until run-time and there's lots of network/bus talk to get to it.

So no, auto-restart is in 99% of cases NOT a feature.

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.

[Peter H.S.]

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.

Systemd is IMHO the best happing to Linux the +15 years I have been using it as my prime OS.

1. For the first time ever is there a coherent development of core Linux OS features. Take fx. "rootless X". It has been possible on Linux for a long time, but only by opening up massive security holes on multi-user systems. The solutions required cooperation between several kernel subsystem developers, X developers, and userland/systemd developers (session managing) to succeed. So secure rootless X is now possible on systemd Linux distros, simply because the systemd project could function as a developer nexus to coordinate and develop the needed features.

2. Since the entire commercial Linux segment and most other distros are becoming systemd driven, there now is a base compatibility layer on Linux for doing basic things like controlling networking, ntp, getting system information etc. Almost all new Desktop Environment development (KDE/GNOME/LXDE/XFCE) at the moment is based on systemd, simply because systemd offers powerful cross distro features that DE's can take advantage off.

3. It is now staggering easy for both distro maintainers, developers and end users to take advantage of advanced kernel features like CGROUP and Linux Capabilities. A simple edit in a standardized text config file can enable strong security features that prevent e.g., privilege escalation. The Linux kernel is full of advanced features that few take advantage of, simply because it often is hard to do with no basic framework outside the kernel to help the user. With systemd, it is now possible to expose many of these kernel features in an easy and consistent way.

4. systemd have actual end-to-end service supervision; systemd supervises all processes, and its watchdog can be made to supervise systemd itself, conditionally restarting it if it should hang.

5. Regarding "what people know"
Anybody being in the IT business for a decade or more have experienced how well known ways of doing things have disappeared. I knew how to optimize the DOS config.sys in order to have maximum available memory. Useful then, useless now. Overall a great improvement.

The reason why Linux is changing in the systemd direction, is simply because the way we do computing is changing; gone are the days with the OS running directly on metal with a few selected services, and the entire thing glued together with hand crafted scripts that were difficult for outsiders to understand.

These days it is all about virtualisation, OS containers, massive OS /node deployment with automatic processes, automatic zero config deployment, These days the SA's doesn't monitor a dozen processes on single server, but 10.000 or perhaps 100.000 processes on thousands of OS containers/servers etc.

systemd is simply brilliant at all this, and sysvinit is not.

Many reactionary retro grouches hates systemd because they now are forced to learn new stuff.

But this really is a wake up call for people; either they start learning systemd, or their Linux skills will not be in much demand in the future.

Re:My opinion on the matter.

[DamnOregonian]

Why? A restart of the service may very well clear out any logs relevant to the crash.

You wrote some pretty poor daemons. Since you can't be bothered to use the syslog facility, my suggestion is that you start opening files without calling truncate on them after.

Re:My opinion on the matter.

[DamnOregonian]

Well, generally when programs require privileged ports, they must be run as root- and then they drop privileges.

It's kinda been that way since... well, forever. I'm sorry you're so late to the party.
Also, you should talk to your distribution's BIND maintainer about his shitty init scripts.

* CAP_NET_BIND_SERVICE notwithstanding.

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.

[DamnOregonian]

Humorously, back in my IOS hacking days, (original iPhone), where we were altering kernel pagetables to map hardware into userspace processes and dump bootroms, trying to fix startup inconsistencies related to our limited ability for changes, and the fucking disgusting web of unnecessary cross-dependencies that the boot process practically begged be used, launchd was the second-stupidest feature of that operating system I noted. It's not a real surprise that a lot of people have jumped on the "Apple's way is the best way!" bandwagon, really. Half the people maintaining distros these days see Apple as some kind of thing to look up to, in spite of all available market evidence. I can only surmise that it has something to do with upbringing/education.

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.

[Prien715]

A few loud-mouths hate X. Most people who use X don't even know it exists.

The only people who like X are those who have never had to program for it. I don't envy the poor souls at Digia or Gnome who have to plumb its depths.

Re:My opinion on the matter.

[Bill, Shooter of Bul]

D'oh. I meant X as in an unknown thing that is universally disliked by the intended audience, not the display server protocol.

But no, systemd was never about just booting faster. Its always been about managing services better. They looked at upstart and decided they couldn't modify it, due to the Ubuntu copyright assignment, and decided to address some existing problems it had in managing services. It should be noted that upstart also starts machines pretty fast.

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.

[jd]

Skepticism != Cynicism.

When the distinction becomes blurred, you no longer have skepticism.

All things should be questioned. That doesn't mean forever.

All things should be subject to scrutiny. That doesn't mean wasting cycles.

Once an issue is settled, it's settled until new data brings it back into question.

Things should be fixed before they break, not after, but only with something verifiably better. If it's not verified, it's not better.

Enough of the common sense that you yung 'uns lack. Back to the boot process.

The original boot process was never great. A very limited range of states, temperamental scripts, poorly documented behaviours, wide variation in precise behaviour between implementations, potential vulnerabilities, ghastly completion time, horrible dependencies, etc.

This has been replaced with an alternative that is new, shiny and creates exactly the same problems but in a completely new way.

A pox on both your houses.

Still, six is better than the two runlevels offered by Windows, which are even slower, even less stable and even less secure. What's worse than pox. I know, Ebola on Windows.

The lot of you are a disgrace. All three systems are less designed than congealed. And the Unix man pages were written by Vogons. Drunk Vogons. Practicing poetry whilst smashing snails with hammers.

Re:My opinion on the matter.

[vtcodger]

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

I doubt you'll manage to repeat ALL of the mistakes of the past. You'd have to be pretty clever to do that. But with sufficient effort and diligence, you can probably manage to repeat most of them. And maybe even come up with one or two truly innovative cock-ups that we old timers overlooked.

Re: My opinion on the matter.

[keltor]

Solaris started doing this in 1999 FYI - http://www.freedesktop.org/wik...

Re:My opinion on the matter.

[jschrod]

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.

That, from a 6-digit /. id, lower than mine, makes me almost speachless.

If you don't have a setup system that establishs monitoring automatically and without manual intervention on all new systems; if you have manual supervision of basic monitoring events; if you don't have built-in fail-over strategies -- well, good luck in doing your job. FWIW, what you're doing is not state of the art. If you're responsible for it or if you can influence its architecture, you should work hard to improve the state of your affairs.

The 80s have gone, where we could hand-held every single system we had to manage. These lucky times are over. Thinking about it, they weren't so lucky at all. Porting X10 just to have a graphical desktop was no fun, even though I thought so at that time. Young and foolish and so... ;-)

The assignment today for most people in admin area is to handle 100s to 1.000s of systems. One needs to establish proper means to do so; and manual work ain't it. (You won't be in the situation to handle 10,000s to 100,000s or even millions of systems; otherwise you wouldn't have posted the comment cited above.)

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.

[Rakarra]

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

Why?

No, I'm serious, ask "why does this have to be the way it is" other than inertia? The age of booting a tiny root disk and attaching /usr from a network are long, long gone.

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.

[Cramer]

SysVinit doesn't have any way to restart services

Yes it does, and it always has. The problem is init didn't start cron. cron was started by a shell script that was started by a shell script that was a one-shot by init. If cron were a "respawn" task in the inittab, it would, indeed, restart it if it exited. (and disable it if it respawned too often.)

Re:My opinion on the matter.

[phantomfive]

Why do you have to program for it? Why not use......Motif.....or something?

Re:My opinion on the matter.

[ToasterMonkey]

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

It's not THAT hard.

Let's use Apache as an example.
Typical Apache screw up... user reports site is not responding
apachectl restart says ports are already in use...

apachectl stop
pgrep httpd... see's the old httpd session leader and some friends chilling out. /facetokeyboard
"You stupid P.O.S."
pkill -9 httpd
apachectl start

Many of us have been here, and it's very dumb. A modernized service control system should have a basic two way channel to the daemons.
You stay on the line or get whacked, and while you're alive you deal with all your child process problems and let us know.
What's that specialized tool supposed to do that the service itself cannot? This really simple system lets you know all the shades of gray between "running" and "stopped"

Like:
"starting, but I need to do a consistency check, and this may take a while"
"running, sort of..."
"stopping, well I'm not available anymore, but you can't start me again yet"
"I know enough to stop trying on my own until an operator intervenes"

Re:My opinion on the matter.

[Tranzistors]

Can you list all the things the kernel does in one line? coreutils? binutils? bash?

Re:My opinion on the matter.

[epyT-R]

1. The argument isn't against coherency. It's against the specific solution for specific reasons.

2+3+4. init should only be concerned with (re)starting, stopping, and monitoring processes. The cgroups feature fits here, too, and is one of the few interesting things about systemd. The rest of the services and such should be handled by specific daemons. The binary logs should be optional as most people do not need them and prefer the flexibility of coreutils/grep and friends.

5. KISS is not automatically out of date. KISS systems have a high reliability rating for a good reason: they are easily understood which keeps admin and developer mistakes down. The catch is flexibility, yes, but, again, init should not become super-busybox. Most systems still run on metal, btw, and that's not going to change until software runs on vacuum. That 'cloud' shit is the specific use case, and if systemd is meant for that, then fine, but it shouldn't be the default. As far as difficulty goes, all monolithic blobs like systemd do is hide it, making it harder to fix when something goes wrong.

Just because someone is 'reactionary' doesn't mean he's wrong, and threats about the relevance of skillsets aren't justifications for changing.

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.

[Peter H.S.]

Regarding binary logs; they are totally optional. You can just forward everything to rsyslog if that is what you want. The distro maintainers can even make it the default, though it is unlikely on mainstream distros considering how good and convenient the systemd journal is.

grep, tee, sed etc. all work with systemd's binary journal through the well known concept of piping,
in fact the default pager for "journalctl" is good old "less" that just display what journalctl pipes to it. systemd's journal simply enhances the standard Linux text tools.

The systemd logging system is an incredible advance over plain syslog; central collection and display of all log files, including ".xsession-errors" and "utmp" etc. No more hunting around for log files dumped in various places, no need to use "last" to read the binary "wtmp" log files.
The most powerful but easy to use log file filter ever; Want to find all "foo" and "bar" log entries from the second last boot, and display the interleaved result using monotonic timevalues? A simple one-liner with journalctl. There is a consistent straightforward syntax and bash-completion help for everything.

I could go on for pages on how much better systemd's logging facilities are; integrated help database (-X), multi-language support, multi-user support, early boot log info, kernel guarantee that entries aren't faked, integrated consistency check, rate limitation, total knowledge of every single daemon, process or command line that have ever generated a log entry, super powerful log filtering, a consistent API to read the log entries (meaning the daemon can changes its output wording without breaking the log watch scripts)...

Re the KISS principle; This is exactly the principle behind systemd; instead of complex executable config files, you have separation between code and and daemon config files. systemd may be able to do many things, but it does in a simple straightforward way: want to prevent a daemon from forking? a single entry into a text config file, want to limit a daemon to max 50% cpu time? a single entry into a text config file, etc. etc.
systemd makes it simple to use advanced kernel features, using a simple, consistent and coherent framework for doing so. Most of its features are activated by simple keywords in the service configuration (text).

Re obsolete skills;
I do think that the threat of ones skill set rapidly becoming obsolete is a justified reason for change, otherwise you get firmly ejected out of the IT business. All major Linux distros are changing to systemd. In the future you either know systemd well, or you don't work with Linux.

I have seen many people over the decades who got ejected out of IT because they refused to improve their skill sets. They were all very angry at the technology they couldn't or wouldn't master; they would rant endless about how GUI's, OO-programming, tcp/ip, httpd services, java, C++, twisted pair ethernet, etc. was the work of the devil.

In the end, most of them just lost their jobs and couldn't get a new one because they now lacked the skill set needed.

Re:My opinion on the matter.

[Peter H.S.]

You can't list all the things systemd does in one line, it does not do "one thing well" ... in fact its frequently touted benefit is that it does so many things.

"systemd" is a tool and daemon collection. Each of those tools, like "systemctl" or "hostnamectl" or daemons, like "journald" does one thing only, and can therefore easily described with a single line.

some examples:
"localectl" - control the system locale and keyboard layout settings
"hostnamectl" - control the system hostname
"journalctl" - query the systemd journal

So, yes systemd as a project is capable of many things, but it does so in simple, modular way.

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.

Re:My opinion on the matter.

[ChrisGilbert637]

Production sysops and sysadmins are not going to adopt systemd until it's not only stable, but unavoidable. Sysadmins need to keep the servers/services running at all costs and cannot afford the time to troubleshoot a new init-script. After the next generation or two, plus mission critical services/apps require systemd will you see a more wide-spread adoption of systemd in the production environment.

'Til then, the developers and early adopters and power-users can knock themselves out tweaking and polishing and enhancing systemd until it is ready for primtime.

Re:My opinion on the matter.

[Guy Harris]

My story: Been using Linux and BSD heavily since the 90s. I don't really care if you spell "restart foo" as "/etc/init.d/foo restart", "/usr/local/etc/rc.d/foo.sh restart" "service foo restart", "systemctl restart foo", or just "pkill foo && foo".

I spell "restart autofsd" as

$ cat /System/Library/LaunchDaemons/com.apple.autofsd.plist
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple Computer//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
<key>Label</key>
<string>com.apple.autofsd</string>
<key>KeepAlive</key>
<true/>
<key>Program</key>
<string>/usr/libexec/autofsd</string>
<key>ProgramArguments</key>
<array>
<string>autofsd</string>
</array>
<key>EnableTransactions</key>
<true/>
</dict>
</plist>

which is the same way I spell "start autofsd in the first place".

My distro is better than your distro

[NotDrWho]

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

Re:My distro is better than your distro

[i kan reed]

My opinion is that my opinion is false.

Re:My distro is better than your distro

[Kojiro Ganryu Sasaki]

That's your opinion, sure...

Display server

[jones_supa]

I believe X.org versus Wayland would be another pair bridging the old and new Linux world.

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:Display server

[0123456]

Do you see any disadvantages of wayland?

Uh, let's see. 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.

Oh, but the desktop is dead, etc, etc and we'll all be doing software development on phones in future.

Re:Display server

[Anonymous Coward]

You _are_ pushing megabytes of pixels either way. All modern GUI toolkits disregard most of X server APIs and simply send bitmaps.

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:Display server

[Anonymous Coward]

You must have missed it...

Scrolling a pixmap (on the X Server) doesn't require any "megabytes" of pixels... a total of about 100 bytes is needed.

Updating the newly exposed portion COULD take more - but that depends on what the update is. If the data has already been transferred, nope - no action at all.

I wrote a satellite imaging system display using X... Transferring the initial data (a 4k x 12k x 24 bit image 144 MB) over the net did take a while... But scrolling around the image was nearly instant (as long as the target system had more than 8MB of available memory).

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.

Re:Display server

[Eravnrekaree]

MIT shared memory support? This has been in the X server for a long time. Apps can use that to send an image to the server, the server then can take that image and composite it with others for the hardware video output buffer. The application can create the buffer on the server, render to the buffer, and then issue a command to the server that the buffer is finished rendering and can be used for compositing an output frame. The application would be given timing information, such as the frequency and the timebase, so it can know when the deadline is for submitting a finished buffer. Any submission of a buffer after the deadline is saved for the rendering of the next frame. this can work with direct and indirect rendering, in indirect the actual programming of hardware occurs in the X server, you would use GLX to send OpenGL commands to the server.

Still on

[present_arms]

System V scripts here and don't plan to change, even if my distro does, if it gets infected with systemd then I'll change distros. It really is as simple as that. Unless something goes horribly wrong there is always slackware, which as I recall not only still uses system V but still uses LILO to boot, and long may it do so :D.

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:Still on

[JohnFen]

Sortof. But even if this were 100% true, it still doesn't solve the problem that systemd is present.

Choosing Sides

[Mr D from 63]

I don't have a pony in this race. Don't know much about it. But the title says I gotta choose a side, and from the looks of things the new guard is winning, at least with this systemd thingy, so I'll go with them. GO NG GO!

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: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:Choosing Sides

[gbjbaanb]

1. ok, so it needs a bit of rework to multithread its process-starting system. I that significantly more difficult that rewriting the entire loader?

2. So it needs an extension to monitor services. Technically, I think this is better handled by a different task, one that is more into monitoring rather than blindly just continually-restarting a service that's crashed due to some external dependancy failure. Again, its not much of a task to add this than it is to rewrite the entire loader.

3. Individual services should be the ones to care about their configuration. Why would the loader be the one-stop place for all kinds of stuff that should be part of the OS or part of a processes dependancy tree. This is probably the worst bit, making systemd significantly more monolithic than before.

Not in this instance

[tuppe666]

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

Except this is not really a problem with the exception of Slackware and Gentoo two obvious holdouts ...and if you use those distributions you know why.(Go on read the wikipedia on systemd it has some great quotes).

all these distros use systemd - Arch Linux, CoreOS, Debian GNU/Linux(Default for Debian 8 "jessie"),Fedora, Frugalware Linux, Mageia, NixOS, openSUSE,
Red Hat Enterprise Linux, Sabayon, Ubuntu(Coming). The deal is done.

Oh FYI Linux overtook windows back in 2013 is quite well know.

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

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:A plague on both their houses

[Etzos]

I think you missed the part where it said that was an OPTIONAL dependency. It also explains why that dependency is needed (that is, what would be affected if that kernel module isn't loaded, in this case it helps prevent a boot failure).

Re:Fork SystemD

[Tablizer]

It's "forked up", if that's what you mean.

How is this sentence anything but unsupported?

[Artifakt]

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

The more fundamental a change is, the more it changes everything - that's basically why we call it 'fundamental'. Making fundamental changes says there's a lot broken. If I said we need a program to fast track educating doctors for rural areas, that's a moderate change to the US medical system, and might a good or bad fix for one specific problem. If I say we need to shoot all existing physicians and substitute Qui-Gong practicioners, that's a fundamental change to American medicine. If someone asserts a change is fundamental, they have also implied the existing system is nearly or totally borked, so they have a very strong burden of proof shifted entirely to them for making that assertion. Unless they can meet that burden of proof, the other side should win any debates.
          The smart thing to do is to claim that a change is not alll that fundamental, and changes only a limited subset of things. For example, I could argue that gay marriage is a limited change, in that it is still based on a moral principle many of us respect (that the people choosing it are consenting adults with normal understanding), and not a more fundamental change (such as throwing out any moral base, including the principle of informed consent, so that pedophilia would somehow become legal). Notice how it's been mostly anti gay marriage advocates that are trying to paint the issue like everything under the sun will change if the other side wins - that's because many people have figured out how this burden of proof stuff works.

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

[Charliemopps]

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.

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:not reasonable at all

[mvdwege]

Now, if you were honest, you'd apply the same standard to SysV init. If that doesn't start syslog, guess what, you'll have no logs either.

The Unix way of things? That has always been the pragmatic way: adopt what works for most cases, worry about the details later. It gave rise to an entire movement of people who hated it for that, see the Unix Haters Handbook for examples. Unix is not a static monolithic system, complaining about systemd as 'against Unix philosophy' is merely the UHH in another form: pining for systems that history and technological development have surpassed.

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:It's job security

[nine-times]

Old-school Unix admins don't WANT anything to change, or get easier. It threatens their livelihood.

I would have my doubts that this were the real explanation. Maybe for a few people here and there, but most techies that I know wouldn't mind things being much easier. I think it's more of a stubbornness and resistance to change, maybe with a little bit of laziness in the realm of "I don't want to have to relearn things." And as you say, "I've developed some ways to make my life easier, and I don't want to re-develop them all."

Of course, there's also the possibility that some of the new ways of doing things are actually not as good as the old. That can happen too. All of these things can happen, but I don't know many IT people who actually go looking for ways to create job security. For most of us, the "laziness" overcomes that, and we're overloaded enough with other work that we're just looking to make things as easy as possible.

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:It's job security

[vanyel]

Nonsense. systemd doesn't make anything easier or threaten anyone's livelihood, it's just change for the sake of change (at the UI level), as are the changes to network configuration. Whatever benefits there may be to whatever changes under the covers doesn't require replacing the init.d structure, the service command or the network config file formats. System administrators have enough to do without dealing with gratuitous changes that don't buy anyone anything.

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: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:Better question

[JohnFen]

That sounds like a truly excellent reason to stop using Gnome.

False "new vs. old" dichotomies

[MoonlessNights]

(FYI: I haven't followed the systemd saga but I have noticed this fight in a growing number of places)

This seems to be a VERY common problem in the modern computing environment: arguments are reduced to ad hominem labels of their supporters where the proponents of "new" are just "kids fascinated by the trendy at the expense of stability" or other "why maintain it when I can write something better?" inexperienced people and the proponents of "old" are just "out of touch old-timers who are afraid of the unknown" or people "only interested in their own job security".

Of course, the reality is some bits of these straw men, combined with massive doses of reality. The truth is, both sides of the argument make more sense if they are reduced to actual concerns and interests, as opposed to "us versus them" camps.

The truth is that "change for change sake" is a dangerous position and the reality is that the "legacy" moniker is slowly changing from a negative term into something which means "has worked well for a long time".
Alternatively, sometimes new ideas are beneficial since they tend to think of current realities, as opposed to sometimes-extinct realities.

This whole notion of "choosing your side" doesn't help anyone since it isn't actually a division, but a conversation/argument. Sometimes stepping forward is correct while sometimes standing still is correct and neither approach is "always correct". Maybe we would choose our next steps better if we worked together to choose them instead of all lining up in our preassigned trenches.

Re:False "new vs. old" dichotomies

[walterbyrd]

Dumb choice. Gnome3 sucks. Gnome3 is worse, in every way, than Gnome2.

Smart choice would be to gnome. Who needs it? Not as if there are not enough alternative DEs.

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

[TemporalBeing]

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.

Take a look at things like OpenRC. It manages a lot of that kind of stuff really really well. I'd much rather have it than systemd.

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:A Windows-like UNIX

[fisted]

I've yet to see a standard text file editor which is able to view a text file in /etc without the aid of a very non-standard filesystem driver.

What kind of retarded straw-man or obvious troll is that? Where do you think databases store their data? In the magic data cloud? Besides, what does the 'non-standard' part even *mean*?

Besides, when your hard drive crashes it is pretty hard to read the text files on it. On the other hand, when the configuration is stored in a replicated database, your cluster can keep on chugging along.

If the hard drive crashes, data may be lost. If the data is stored redundantly, data may be safe. News at 11. Seriously, where to you *think* databases store their data?
On a side point, /if/ your hard drive crashes, the odds of recovering text files from the mess are way better than recovering database data files, as they are /way/ larger and more complicated.

Even most admins who love text files in /etc stick them in non-text repositories like git just to manage things.

Really, it's beyond embarrassment. Git by its very nature *deals with* text files.

But yes, I am a systemd proponent. :)

Of course you are.

You'll be happy that it [tl;dr]

I really don't care. I abandoned Linux in favour of the BSDs when it started to smell, and you're the perfect example of why it does that nowadays

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.

Re:It's job security

[CRC'99]

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

This is exactly right. I was playing with the last lot of RHEL7 betas - the biggest issue I had was that ethernet adapters would randomly fail to start - and systemd would not give any details as to why. Each time I had to log in over a serial console, stop networking, disable the profile, enable the profile again, and start networking. This would work perfectly - until a random time when rebooting later on (and not every reboot) where networking wouldn't come up again.

This is not what admins need - randomly failing network connections. This is also a problem that was fixed decades ago - until systemd causes it again.

Lets ignore the problems with new aims to recreate consoles etc in systemd / userland and ignore / disable the kernel ones. Because that's a great idea *cough*

Re:snydeq = InfoWorld

[Smallpond]

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.

So why is your bug filed against upstart?

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.

Re:PID1 - A Controllable Master Control Program

[Guy Harris]

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

I.e., since before late April 2005, as that's when OS X 10.5 Tiger, the first release with launchd, came out?

Re:Not UNIX like anymore

[Peter H.S.]

You are obviously demonstrating that you have no personal experience with systemd; systemd is a collection of tools that does one thing a does it well. "hostnamectl" sets and displays hostname information, systemctl stops and starts services, "localectl" control the system locale and keyboard layout settings, etc.

All the systemd tools (*ctl) are just totally normal Linux tools; yes, you can use pipes, direct output, and combine them with all the standard tools like grep, tee, sed...

The systemd tools doesn't break any of those rules you listed.

Sure, some of the systemd daemons (not tools) are specifically designed to talk to each other, in order to have logging info from eg. early boot, or in order to prevent a daemon from forking if the kernel capabilities forbid it, but this behavior is quite common on all unix'es.

Forget what nonsense other people spout about systemd (like that is is a binary, proprietary xml blob made by the NSA/The Greys/Cthulu) and start learning about it in a proper way.
This is a good place to start, together with a Linux distro that uses systemd:
http://www.freedesktop.org/wik...

DID YOU NOT SEE TRON????

[josquin9]

I did. And let me tell you, putting your faith in a Master Control Program is a very, very bad idea.

It's the 1990s all over again

[Casandro]

The time when people who had no idea started to believe they could create something better then UNIX.
This created the mess we had in the 1990s when it was OK to have log files in binary files and you could only view them through a small non-resizable window. A time when you could display the owners of open files on your network share... but you couldn't do anything with that info except for writing it down and manually act upon it. Of course that data was also displayed in a small non-resizable window.

There is a reason why normal init is based on shell scripts, and that reason is simply because there is no reason against it. Shell scripts are perfectly adequate for that job. Binaries on Unix however make it much more difficult to deal with them. If you want to edit a binary you have to get the source code, edit it, make it compile, and then hope it'll run. It's even worse when you have dynamically linked binaries since they depend on other files, particularly for init.

Binaries are just a botched solution to somehow get faster execution. The whole design of Unix doesn't require them. Unlike Windows you shouldn't need to link in a library to have some API you should instead have a little program you can call. (actually Windows now has a little wrapper allowing you to make arbitrary calls to DLLs since even Microsoft has recognized the problem)

Dynamically linked libraries are just a botched solution for the problem of library bloat. You shouldn't need them, if you want some feature you should just call the program implementing it. That's how bc worked originally. All the calculation functionality was in dc and bc just re-formated its input to what dc expects. The problem why this doesn't work well any more is long startup times caused by library bloat.