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 598965
To read all comments associated with this story, please click here.
woegjiub
Member since:
2008-11-25

Systemd is about unifying Linux with a Core OS that is rigorously tested and well integrated, as opposed to the hodge-podge of random bash scripts that people used to have to write for sysv.

There's really no need for choice in init systems; upstart is soon to be unmaintained, openRC is not capable, sys V is a joke.
Systemd is the only modern option, and by leveraging every strength Linux offers, and ignoring BSD compatibility, it pushes forwards the Linux platform.

The individuals arguing against systemd seem to not understand that *none of the upstream developers* want to have to keep reinventing wheels and having overhead in maintenance when they can get universal, superior options from systemd, such as logind.

In short, the future of Linux is systemd. If you don't like that, move to an actual unix.

Reply Score: 8

ddjones Member since:
2014-10-28

I'm so happy that we have you to make decisions for every one else. Imagine if we had to study the issue, analyze the facts and make a decision on the merits or lack thereof ourselves! What a lot of effort and wasted time! Fortunately, we have you to do that for us so everyone else can get on with their lives and forget about the issue. It's truly kind and noble of you to sacrifice so much so that the rest of us can don't have to.

Reply Parent Score: 7

woegjiub Member since:
2008-11-25

It's a non-issue, I'm just pointing out the way the wind's blowing.

There are *zero* benefits to using sysv init on a pure Linux install-base, and Linux has been held back by limiting itself to the lowest common denominator for far too long.
Now we have proper, seamless cgroup usage in init! Using containers is simpler and nicer than ever, all of the core os binaries are rigorously standardised, documented and unit-tested, in cooperation with each other. The level of innovation at the userland level has never been this high.

It's no surprise application and distro developers want to make use of all of the great features and opportunities systemd provides. It's not up to them to work on legacy init-system support instead of stomping bugs and adding features that directly relate to the program, as opposed to being about the management of programs by the OS.
If you want sysv support for applications, write some scripts.
If you want sysv support in a distro, make one.
Most projects have already decided; that's crap that they're sick of having to do, and systemd provides a superior future.

There's no downside to you, either: don't like binary logging? Set journald to use files.
Want to write bash scripts instead of reliable, predictable service files? Go ahead, sysvinit scripts are fully supported.

Systemd just means more stability and a more common core os for all distros. If we're lucky, a lot of the distros will die off, sparing us that ridiculous duplication of effort.

Edited 2014-11-05 12:16 UTC

Reply Parent Score: 6

Coxy Member since:
2006-07-01

He is not making the decision... I find it funny that people are always banging on about how great linux is, because if you don't like something, you can view the code and rewrite it yourself... poettering has... and everyone is complaining that he shouldn't have... well that's what happens if you keep banging on about people being able to write their own code.

If you and the other grey beards want a unix like OS, use one. I use linux, not unix, couldn't care about recursive accronyms (and whether or not they are funny), I couldn't care about the unix way of doing things. If you do, you know the drill: write your own code, submit a patch, if all else fails fork it.

To be honest, as an end user - I really couldn't give a fuck what is used, whether it is teh DE, the display manager or anything else... I can understand why some people hate poettering (see: https://www.youtube.com/watch?v=ZTdUmlGxVo0) but all he is done is do what linux/unix advocates have been advocating for donkey's years.

Reply Parent Score: 9

Valhalla Member since:
2006-01-24

I'm so happy that we have you to make decisions for every one else.

The people who do the actual work, as in making/providing the software, are indeed the ones who get to make the decisions for those who aren't.

There's nothing new here, if upstream chooses to take their software in a different directon than you want you can certainly ask them not to, but in the end the choice is theirs.

Your choice is to either step up and maintain a fork/patches which corresponds to your needs, or vote with your feet.

Reply Parent Score: 6

Carewolf Member since:
2005-09-08

That is not really true, but you are close.

The problem is not that SysV or OpenRC are not working, they are working fine and will continue to be maintained sufficiently. The problem is that everything else isn't maintained with them. There are probably a thousand open source projects that would need to have special handling of alternative init systems, and those scripts are unlikely to be maintained, and is also why Debian is not making an easy choice for maintaining a choice. They don't want to maintain all those scripts and patches to make projects that only support systemd out of the box support other init systems as well.

Reply Parent Score: 3

woegjiub Member since:
2008-11-25

Don't get me wrong, I'm fully aware that this is the case ;)

By sysv and OpenRC are inadequate, I meant either through lacking features such as are provided by logind and journald, or by lacking core systemd features which mean proper process management.

All of these developers aren't swapping for no reason, even if that reason is "it's easier to maintain unit files, and journalctl is really nice."

Reply Parent Score: 3

Sully Member since:
2014-11-05

It might be "...rigorously tested", however systemd has bugs, and the attitude towards those bugs from the developers (from Poettering down) is cavalier. https://bugzilla.redhat.com/show_bug.cgi?id=1023737 Is one example of a fundamental task that does not work as it should. There are others. That bug is a year old.

There's really no need for choice in init systems; upstart is soon to be unmaintained, openRC is not capable, sys V is a joke.


There's a very good argument for diversity in init systems, notwithstanding the fact that administrators know how they work, can troubleshoot them, and customise them without knowing a black-box language like C. What, specifically, are OpenRC and Sys V not capable of? Choice is a cornerstone of the Linux ecosystem.

The individuals arguing against systemd seem to not understand that *none of the upstream developers* want to have to keep reinventing wheels and having overhead in maintenance when they can get universal, superior options from systemd, such as logind.


Upstream developer laziness is not the fault of users; and reinvention of the wheel is an ironic argument to use in the systemd discussion, being as that is one of the prime reasons people do not like it. There is little that systemd does that is not already a feature of current systems. They were not first to use cgroups, parallelisation, or socket activation. All of these are available already.

It is monolithic (Even Poettering's argument against this is essentially semantic), tightly coupled, enforces dependencies for no good reason than to grow itself, and will be extraordinarily difficult to replace if it continues to supercede GNU core utilities.

You should find this worrying if you're a supporter of Linux; it is walking down a road one cannot easily come back from.

Reply Parent Score: 6

grat Member since:
2006-02-02

https://bugzilla.redhat.com/show_bug.cgi?id=1023737 Is one example of a fundamental task that does not work as it should. There are others. That bug is a year old.


Oh, that's lovely. Wonder if Red Hat 7 has the same problem. I'll have to test my (currently only) production RH7 box.

Appreciate the info.

Reply Parent Score: 2

woegjiub Member since:
2008-11-25

It might be "...rigorously tested", however systemd has bugs, and the attitude towards those bugs from the developers (from Poettering down) is cavalier. https://bugzilla.redhat.com/show_bug.cgi?id=1023737 Is one example of a fundamental task that does not work as it should. There are others. That bug is a year old.


All software has bugs. This one has a workaround posted on that very page.

Also, you can use mount units instead of fstab, you know?

There's a very good argument for diversity in init systems, notwithstanding the fact that administrators know how they work, can troubleshoot them, and customise them without knowing a black-box language like C. What, specifically, are OpenRC and Sys V not capable of? Choice is a cornerstone of the Linux ecosystem.


http://islinuxaboutchoice.com/
Linux is not about choice.

Systemd is very well documented, with all of the defaults explained at length in the man pages.
They're much more predictable than having to read through a bunch of shell code that will differ from distro to distro and version to version.

The primary advantages of systemd, apart from the increase in predictability, reliability and ubiquity, is that of its project, as opposed to systemd the daemon.
The matrix of programs that fall under the project umbrella are all constantly unit tested against each other, so as to give a solid base platform that can be relied upon, as opposed to each distro needing to attach different binaries for different purposes.

Upstream developer laziness is not the fault of users; and reinvention of the wheel is an ironic argument to use in the systemd discussion, being as that is one of the prime reasons people do not like it. There is little that systemd does that is not already a feature of current systems. They were not first to use cgroups, parallelisation, or socket activation. All of these are available already.

It is monolithic (Even Poettering's argument against this is essentially semantic), tightly coupled, enforces dependencies for no good reason than to grow itself, and will be extraordinarily difficult to replace if it continues to supercede GNU core utilities.

You should find this worrying if you're a supporter of Linux; it is walking down a road one cannot easily come back from.


How is it lazy for developers to not want to have to support code that is not actually related to the point of their project?
Why should they have to write init scripts for their software, when all they want is for it to be reliably started and stopped?
Why should they have to maintain their own helper libraries for functionality that exists in most modern linuxes out of the box?
Time spent on those helper libraries could be better spent improving their actual projects.

Systemd may not have been the first to have those features, but it was the first to make them simple to take advantage of from everywhere.

The kernel is monolithic; what's your point?
The APIs of all of their binaries are well documented. Want to use a different getty? Go ahead. You'll just have to take care of making sure it works with the other binaries in the userland... which is what you already had to do anyway.

Projects are brought under the umbrella so as to remove uncertainty in OS design and state. If the whole of the core OS is in one tree, like with the BSDs, you can more easily ensure it all plays nicely together, and releases are in a state where everything works with everything else.

The only argument that isn't one to tradition ("It's not following the Unix philosophy"... GNU's Not Unix) that I've heard is that the current maintainers may lead the project in a direction that is bad for others.
In that case, it's all non-CLA'd and GLP'd. Fork the lot from the last good state.

Reply Parent Score: 2

hobgoblin Member since:
2005-07-06

Systemd has all kinds of issue with mounts, NFS mounts in particular.

Apparently someone thought it would be clever to delegate the task of mounting to systemd rather than leave it in the hands of mount.

end result is that systemd keeps barfing over slightly odd fstab files that mount has no problems with.

Or do things like yank down the network before dismounting NFS mounts, and then dead hang on the dismount step of shutdown because NFS just wont let go.

This kind of crap is why unix have "do one thing and do it well" binaries tied together with shell scripts.

But here comes systemd and replace a binary that has worked for decades, because "reasons".

Reply Parent Score: 4

puenktchen Member since:
2007-07-27

It isn't the only viable option, there is still Apple's launchd. Modern, still under development, compatible licence (Apache).

But as systemd is more or less linux's answer to launchd I guess there isn't much to gain by using launchd instead.

Edited 2014-11-05 17:16 UTC

Reply Parent Score: 3

maccouch Member since:
2012-03-14

didn't knew that launchd was Apache licensed. If it's freely available, how exactly does launchd stacks against systemd?

Reply Parent Score: 1

grat Member since:
2006-02-02

Ah yes-- "We know better than you do, so shaddup".

Perfect example of why I left Gnome years ago, and can't stand the default desktop setup in Gnome.

Reply Parent Score: 2

hobgoblin Member since:
2005-07-06

https://plus.google.com/+TheodoreTso/posts/4W6rrMMvhWU

"It's not entirely fair to charge all of this to Systemd's account, but I think one of the reasons why this happens is because +Kay Sievers and +Lennart Poettering often have the same response style to criticisms as the +GNOME developers --- go away, you're clueless, we know better than you, and besides, we have commit privs and you don't, so go away."

Reply Parent Score: 3