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 599002
To read all comments associated with this story, please click here.
This article.
by hussam on Wed 5th Nov 2014 16:09 UTC
hussam
Member since:
2006-08-17

This article is properly written but it doesn't present sources to some of its claims.

People in favour faithfully (and sometimes falsely) make wonderful claims about what systemd is and what it can supposedly do.

This part is pure flaming of systemd. I would like to see an example of those false claims.

The things people praise systemd for are socket activation and other service management mechanisms, and the use of various modern Linux features.
What part of that is false claims?

I think you've nailed the issue perfectly without realizing it. FOSS software being a meritocracy doesn't hold true anymore especially in the context of systemd. That's because systemd is fundamentally a RedHat technology. It's free, the source's available, etc... but the majority of the development is done by paid RedHat employees and decisions on its direction are taken by RedHat employees.


I would like to add to this that some of the tools that ship with systemd like systemd-networkd and plenty of patches for systemd-journald have been contributed by Arch Linux.
Other distributions don't seem very keen on contributing code.

I also need to mention that systemd needs a few months of feature freeze while bugs are ironed out. 217 was just released and the archlinux package already has a few backported bugfixing patches from trunk.

Edited 2014-11-05 16:18 UTC

Reply Score: 4

RE: This article.
by jessesmith on Wed 5th Nov 2014 16:34 in reply to "This article."
jessesmith Member since:
2010-03-11

One false claim is that systemd is faster than SysV at booting the system. Almost every discussion I've ever read concerning systemd has proponents that claim systemd boots faster. In some edge cases it might, but in all my tests systemd has been slower or the same speed at SysV.
http://distrowatch.com/weekly.php?issue=20141027#qa

Another is that systemd will unify Linux distributions, making skills cross-platform. This is false for two reasons. 1. Distributions have many other compatibility issues that have nothing to do with systemd. 2. There will always be outlying distros (Slackware, Pisi, Gentoo) that do not conform. And the point is not really relevant to anyone who uses Linux + other operating systems. For example, many people switch between FreeBSD and Linux and will not gain unity.

Another is that when systemd orders a service to stop it always stops. This is also false, I've seen several cases of systemd ordering processes to stop and the function fails.

Finally, some claim systemd is 100% compatible with SysV. This is not true and I know of a few daemons that have had to be patched to wrk with systemd and its quirks.

Reply Parent Score: 5

RE[2]: This article.
by Valhalla on Wed 5th Nov 2014 18:12 in reply to "RE: This article."
Valhalla Member since:
2006-01-24

One false claim is that systemd is faster than SysV at booting the system. In some edge cases it might, but in all my tests systemd has been slower or the same speed at SysV.


Having four machines running Arch, and all of them booting and rebooting faster with systemd than with sysv, I offer different anecdotal evidence ;)


There will always be outlying distros (Slackware, Pisi, Gentoo) that do not conform.

There will always be 'outlying distros' for every aspect out there, from which libc they use up to what desktop wallpaper they ship as default.

Unification around systemd is already happening, Red Hat, Suse, Arch, Ubuntu, Debian, Mageia, CoreOS, NixOS are already defaulting to systemd or in progress of doing so, these include the largest Linux distros who will all be defaulting to the same core functionality (init + system tools), that is certainly a huge unification across the Linux distro landscape which previously was more or less Linux kernel+glibc as far as 'standard' went.


And the point is not really relevant to anyone who uses Linux + other operating systems. For example, many people switch between FreeBSD and Linux and will not gain unity.


Huh ? This was no more true before systemd either, I fail to see what your point is here.

As for the editorial, the whole Debian 'freedom of choice' is not something that is magically conjured out of some 'community spirit', whatever choice there is ends up being provided by Debian maintainers, and when they loose interest that choice goes away.

KFreeBSD, part of what you are using to paint this picture of a 'buffet of choices' is on the verge of being dropped, not because of systemd, but due to lack of developer interest (as in keeping it up and running).

The 'tying of people' to one init system only happens when developers no longer want to work on supporting alternatives (just as the case with kFreeBSD, Hurd etc), and the debate here is not of people not being able to continue using sysv, they can, the discussion is instead about software which relies on functionality provided as part of an init system.

Currently Gnome is dependent on systemd because it uses logind, a user login daemon which replaces the no longer maintained consolekit.

Now it doesn't have to be logind, it can be any other daemon offering the same functionality, and systemd-shim is such a project but it is apparently not very actively developed and lacking in compability with systemd.

Which again brings us back to the actual point, any choice you have in FOSS is there because someone steps up and provides it, not because there is some distro consensus of 'offering choice'.

When developers no longer want to work on things, the 'choice' they offer is no longer available.

Now the group within Debian which proposed this GR want to force developers wanting to use systemd functionality to either provide alternatives for said functionality or not use said systemd functionality, else the package won't be allowed in Debian.

The result of this is a burden on maintainers that they are very unlikely to carry, and if the GR supporters are expecting that this grandstanding will affect upstream then they are deluded indeed, upstream chose systemd because it offers the functionality they want/need while ridding them of lots of maintenance, they are happy with systemd.

Not that it really matters since I'm dead certain this GR will be voted down.

Debian will soon either turn its back on its tradition of freedom or it will become one of the very few Linux distributions to continue to offer opinions.


I assume you meant 'options' rather than 'opinions' ?

Either way, options are again only there when someone actively provides them, and it's not as if Debian supports alternatives for glibc, udev, gcc, if you want to run alternatives you are on your own, just like with alternatives to systemd.

That is what the 'freedom' in FOSS actually boils down to, not some branding of 'choice' which you decided to place on Debian in order to support your rather one-sided narrative.

Reply Parent Score: 5