Hacker News Reader

Comment by chris_wot | Hacker News Reader

I'm a tad confused... you cite that famous Unix philosophy quote "This is the Unix philosophy: Write programs that do one thing and do it well. Write programs to work together"... but I don't see how that doesn't apply to systemd?

Could you clarify?

View on HN

"Systemd" isn't really a single program, it's a collection of 69 binaries, that together handle a number of functions that were traditionally handled by separately-developed pieces of software. It handles init, user logins, the console, system event logging, network interface configuration, time+date settings, and device management (udev was merged into Systemd in 2012, apparently).

A lot of those components have interdependencies (so they can't all be replaced piecemeal), and some userspace things like Gnome have come to have dependencies on things provided by parts of Systemd.

This has benefits: Things tied tighter together know more about the states of other parts, and that enables various optimizations. This has issues: Replacing individual components (if you don't like their behavior) becomes more difficult. Whether it's worth it or not seems like a philosophical debate.

I was genuinely not aware that the components are that intertwined that they rely on each other. Which components are problematic?

In terms of Gnome - well, Gnome is Gnome. I'm not going to start defending their decisions, I disagree with quite a few of them myself.

Udev (AFAIK a program that recognises and mounts plug-in devices, but I'm not sure) is developped by systemd guys and they recently told that they won't care about the case where it is used w/o systemd. It is an important part of GNU/Linux distros. Tho I used Arch for about two-three years I guess (since just before it switched to systemd as default til two monts ago), and I never had to fiddle with it, so I don't know how it affects people. Gentoo forked it to maintain a version that did not depend on systemd.

Yeah, that's precisely what it does - it's a daemon that interacts with the kernel for hotplug devices, etc.

Is udevd used by anything other than the kernel though? If not, then I don't think it's a huge issue if those who want to use a different init system maintain their own version!

Why waste all that effort of maintaining forks when it can be avoided? Systemd folks are being hostile to the wider community of Linux users with that.

You don't need to - there shouldn't be anything that stops other init systems from using it.

The people currently mantaining udev do not want them to.

> Unless the systemd-haters prepare another kdbus userspace until then this will effectively also mean that we will not support non-systemd systems with udev anymore starting at that point. Gentoo folks, this is your wakeup call.

https://lists.freedesktop.org/archives/systemd-devel/2014-Ma...

But there is, and that's why people forked it.

https://wiki.gentoo.org/wiki/Project:Eudev

Uh, that wasn't forked because udev can't work, it was forked because it fit the needs of Gentoo...

Have a look at Devuan, I think you'll find that they use the same udev as Ubuntu and Debian.

It's not hostile if someone forks a project to meet their requirements but the old software is used by everyone else!

> Have a look at Devuan, I think you'll find that they use the same udev as Ubuntu and Debian.

Yes, in amongst all of this systemd discussion, please do look at the notional actual topic of this page. And discover vdev. It's explicitly mentioned in the release notes.

* https://github.com/jcnelson/vdev

* http://judecnelson.blogspot.co.uk/2015/01/introducing-vdev.h...

* http://www.linuxquestions.org/questions/debian-26/devuan-417...

Ah! Thanks - I didn't see this! Appreciate the info :-)

Interesting - so vdev might be ported to OpenBSD! That's pretty awesome :-)

Can the person down voting please explain why? I'm going to assume you believe I've been factually inaccurate. If that's the case, I don't mind the downvotes as much as you not explaining where I'm wrong or making any attempt to engage in discourse.

If I'm not wrong, then perhaps you should reconsider your actions, because I'll still say what I believe even though you may not like it, karma be damned!

udevd is used by everything, sometimes directly, other times indirectly. It's needed to create device nodes for everything from audio devices to webcams to storage devices to stuff like modems and terminals, graphics cards, etc. Most desktop environments call it directly for stuff like USB drive automounting. Some non-desktop systems like Android and OpenWRT with very constrained hardware have their own replacements for it, but that's not officially supported by the kernel developers and the kernel APIs it relies on aren't documented or guaranteed to remain stable - they want you to use udev (and soon that'll mean systemd too).

Basically, the only people who've managed to get away with not using udev are those with their own kernel fork and a completely customised stack on top. I'm not sure if any of them even use glibc or the GNU userland either.

The basic problem is that the same people that maintain udev also maintain the kernel API it relies on. How Torvalds have allowed this to continue for so long i do not know.

Never mind that udev existed as a independent project for nearly a decade before being folded into systemd, thus leaving various distros high and dry. Either adopt systemd, or develop an alternative to udev (that still have to rely on the badly documented and changing kernel API).

http://www.landley.net/notes-2015.html#05-07-2015

At this point in time it seems that GregKH has mastered the art of passive-aggressiveness...

The way systemd is structured it's next to impossible to use any parts of it outside of systemd, nomenclature is ridiculous (system daemon, what's that even supposed to mean?), it suffers greatly from feature creep, took over logging using a binary format, gained basic firewall controls , assimilated udev, incorporated a bootloader, ... and some additional things people took/take offence with: introduced to quickly, criticism was shut out instead of being debated, promises were broken, main developers behind it are quite arrogant and often ignorant when dealing with complaints/bugs... et cetera

there is a reason why Lennart is good in stirring up controversy, and it's not because everyone is just against him for no reason.

some further reading/links that might interest you:

https://lkml.org/lkml/2014/8/12/459

http://without-systemd.org/wiki/index.php/Arguments_against_...

http://www.infoworld.com/article/2608798/data-center/systemd...

http://www.infoworld.com/article/2608864/data-center/choose-...

http://www.infoworld.com/article/2608870/linux/you-have-your...

http://blog.darknedgy.net/technology/2015/10/11/0//

http://suckless.org/sucks/systemd

edit: systemd might be perfect for you or other people, I don't doubt that, it might make things easier for some, in some respects in might do some things better, but if the debate (as it is now) is whether it follows the unix philosophy or not, I don't think one can reasonably make the case that it does

I notice you have added an aside :-)

> edit: systemd might be perfect for you or other people, I don't doubt that, it might make things easier for some, in some respects in might do some things better, but if the debate (as it is now) is whether it follows the unix philosophy or not, I don't think one can reasonably make the case that it does

I can and have made that case :-) I guess we'll agree to disagree.

> The way systemd is structured it's next to impossible to use any parts of it outside of systemd

Well that's not true. If you want to swap out a systemd daemon with another one, then you just have to write another service configuration file - see here: https://www.freedesktop.org/software/systemd/man/systemd.ser...

> nomenclature is ridiculous (system daemon, what's that even supposed to mean?)

It's the daemon that runs the system. init, you realise, is a daemon process? As in, it's a process that runs in the background that is not under direct user control?

> it suffers greatly from feature creep

A lot of folks quite like the features it has introduced, but that's subjective

> took over logging using a binary format

journald can be configured to do text logging...

> gained basic firewall controls

It's a component of the system, which doesn't have to be used.

> assimilated udev

I just cannot understand why this is such a big deal. udev is a userspace daemon that interacts with the kernel, it has had zero negative effect on anyone and it makes total sense for the ones maintaining the init system to integrate it into their tree and maintain it going forward!

> incorporated a bootloader

You can swap it out. Why is this a concern?

> ... and some additional things people took/take offence with: introduced to quickly, criticism was shut out instead of being debated, promises were broken, main developers behind it are quite arrogant and often ignorant when dealing with complaints/bugs... et cetera there is a reason why Lennart is good in stirring up controversy, and it's not because everyone is just against him for no reason.

I'll stick with technical issues, not personalities.

Just reviewing your links:

https://lkml.org/lkml/2014/8/12/459

No technical reasons given as to the concern over systemd, only some personality clashes ("Kick these fucking carpetbaggers to the curb!" - now there's a convincing argument!)

---

http://without-systemd.org/wiki/index.php/Arguments_against_...

Yeah, I've read most of these, I'm really not convinced by any of the arguments

---

http://www.infoworld.com/article/2608798/data-center/systemd...

The guy rehashes the same arguments you are making, and I've already addressed each of them - I disagree!

---

http://www.infoworld.com/article/2608864/data-center/choose-...

Same author, same arguments - but with a side-dish of "what would the grey-beards think?" and concocted outrage over an apparent schism within the Linux community.

---

http://www.infoworld.com/article/2608870/linux/you-have-your...

Same author again, and this time the argument is:

You have your Windows in my Linux

Ultimately, the schism over systemd could lead to a separation of desktop and server distros, or Linux server admins moving to FreeBSD

---

http://blog.darknedgy.net/technology/2015/10/11/0//

Yeah, that article was largely prompted by myself I think. I promised vezzny-ford I'd read this, and I never got around to it. I'll eventually do so :-)

---

http://suckless.org/sucks/systemd

I'll have a read - looks interesting.

I would imagine people have a hard time lumping: service management, logging, login, network management, etc together as 'one thing'. As a CentOS 7 user, I certainly wouldn't describe it as 'doing it well'.

I think people initially were pretty stoked for the revamped init process, and then it started heaping on a lot more stuff. Poettering's communication style and other history didn't help either.

Really? System V init, which is what it replaced, did all of those things. It handles daemons and starts login, depending on the runlevel, and the startup scripts turn on logging, network services - and you use those same scripts to stop and start services.

So what in particular, other than Lennart's supposed abrasive nature, do you have an issue with? I'm genuinely not following some of this reasoning, at least from a purely technical level.

Incidentally, really need to speak to some of the BSD guys about what they think of SysV-style init. Now that could prove to be an interesting flame war :-)

Scripts are just a simple abstraction that allows to manage all kinds of daemons, which allows SysV to happily work with anything it finds in the init directories.

We give you this thing that replaces half the system with utilities (re)written by us, but hey don't complain you're free use something else!

So that's your argument? That it's different?

Reply on news.ycombinator.com