Linked by jessesmith on Wed 5th Nov 2014 10:39 UTC
Linux Over the past year I've been reading a lot of opinions on the new init technology, systemd. Some people think systemd is wonderful, the bee's knees. Others claim that systemd is broken by design. Some see systemd as a unifying force, a way to unite the majority of the Linux distributions. Others see systemd as a growing blob that is slowly becoming an overly large portion of the operating system. One thing that has surprised me a little is just how much people care about systemd, whether their opinion of the technology is good or bad. People in favour faithfully (and sometimes falsely) make wonderful claims about what systemd is and what it can supposedly do. Opponents claim systemd will divide the Linux community and drive many technical users to other operating systems. There is a lot of hype and surprisingly few people presenting facts.
Thread beginning with comment 599049
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE: A cople of comments.
by gilboa on Wed 5th Nov 2014 22:15 UTC in reply to "A cople of comments."
gilboa
Member since:
2005-07-06

I wanted to add something:

My company develops a complex network security system that has a large number components (some user space, others kernel space, with multiple processes, users and capabilities).
Needless to say, all of this must be started in-order and there are a lot of inter-dependencies.
Back in the pre-systemd days we had a huge arrays of bash scripts that used ugly waits, sleeps and cat /proc/pids to get the system running. (I was the idiot who wrote many of them).
The scripts never worked - mostly due to external problems. (E.g. You can never reliably check if /etc/init.d/network actually managed to initialize the [many] network devices correctly.)
We actually reached the point that we actually had helper C-based init services, to help us circumvent system initialization issues. (Upstart was no better).
But then came systemd, and we simply throw out all the ugly, never-really-working scripts and replaced them with (simple!) unit files.
Suddenly, I don't have to worry about ulimit, chroot, init.d/network not being set or initialized correctly, suddenly I don't need to manually manage the order in which each component is started, stopped and restarted.
I simply write a 10-20 line unit file, maybe add a small bash script to set some environment switch that systemd doesn't support and I'm done. Heck, we reached the point that we actually have a helper bash script that automatically write most of the systemd unit file based on a template file and a configuration file.
It works in the first time. It works in the 1000'th time and I no longer need to worry about it.

As the saying goes, you'll have to prey systemd out of my cold dead hands.

- Gilboa

Edited 2014-11-05 22:18 UTC

Reply Parent Score: 4

RE[2]: A cople of comments.
by hobgoblin on Thu 6th Nov 2014 18:34 in reply to "RE: A cople of comments."
hobgoblin Member since:
2005-07-06

And here is the thing. In the past, deciding what kind of init to use was up to the admin in charge.

But with systemd and the ongoing feature creep and near insistence that if you want to play you need to use APIs (the alternatives are rickety: http://ewontfix.com/15/) result in a removal of choice.

I am right now running a distro with a somewhat esoteric boot system. But i can still get things like consolekit up and running. but if i want to upgrade to a more recent Gnome i need to bring in logind and therefore systemd.

Now if i could set systemd to run in a minimal fashion on top of what i already have, i would not be sitting here commenting. But all of a sudden i have to redo my setup from the init up because i want to upgrade the point release of Gnome?!

Reply Parent Score: 2

RE[3]: A cople of comments.
by edomaur on Thu 6th Nov 2014 21:46 in reply to "RE[2]: A cople of comments."
edomaur Member since:
2005-08-07

And here is the thing. In the past, deciding what kind of init to use was up to the admin in charge.

That's bullshit. Admin are using default init. If they weren't, the systemd outcry would not have been, ever.

Reply Parent Score: 2

RE[3]: A cople of comments.
by gilboa on Fri 7th Nov 2014 07:59 in reply to "RE[2]: A cople of comments."
gilboa Member since:
2005-07-06

And here is the thing. In the past, deciding what kind of init to use was up to the admin in charge.

But with systemd and the ongoing feature creep and near insistence that if you want to play you need to use APIs (the alternatives are rickety: http://ewontfix.com/15/) result in a removal of choice.

I am right now running a distro with a somewhat esoteric boot system. But i can still get things like consolekit up and running. but if i want to upgrade to a more recent Gnome i need to bring in logind and therefore systemd.

Now if i could set systemd to run in a minimal fashion on top of what i already have, i would not be sitting here commenting. But all of a sudden i have to redo my setup from the init up because i want to upgrade the point release of Gnome?!


I understand your pain, I really do.
But you must understand the Linux was *way* overdue to have a coherent int *and* base system infrastructure. As an embedded and kernel developer I can say, that as much as I dislike Windows and the Win32/WinNT APIs, Windows' service and service environment management was *light* years ahead of Linux'.

Once such a coherent base system infrastructure started getting built, other projects (GNOME, KDE, etc) were bound to support as it solved a lot of pain on *their* end.
More-ever, the so called feature creep is neither "feature" nor "creep". The idea behind systemd is to create a *complete* base system infrastructure, either by assimilating other projects (udev) or by creating modern alternative. I'd venture and guess that its just a mater of time until NetworkManager find itself under the systemd umbrella.

Now, people that dislike systemd for both valid or invalid reasons are left with one of 3 options:
1. Be constructive: Develop an alternative base system infrastructure that supply the same systemd APIs without the so-called bloat and while keeping to the original Unix way (Hard, but possible).
2. Completely fork the current user-space part of Linux, and maintain a pristine systemd-free OS from ~2013, forward forking new features from the systemd world (Doable in the short run, may become impossible in the long run).
3. Expect (vocally) that somehow their appeals will be heard and the train will reverse back to the station (Won't happen, sorry).

In my view Debian, by itself, may have sufficient man power to select option "2" for a year or two, but not more. Option "1" is feasible, but it'll require cross distribution cooperation on a massive scale (Just like, err, systemd).
3 is a non-starter, and I would imagine most people already understand it.

- Gilboa

Edited 2014-11-07 08:01 UTC

Reply Parent Score: 4