Hacker News Reader

Comment by ultramancool | Hacker News Reader

I'm no fan of systemd, but do we really need to be nitpicking its every failing? The alternatives are certainly not perfect either. If you don't like it, don't use it. Many distros are still committed to supporting other init systems along side systemd and many BSDs have a very good philosophy with things like this and may be worth a look too.

Can we just agree to move on? I'm sick of the endless banter. If you like systemd, use it, if you don't like it, don't. If you think it needs more time to mature, stay away from it for a while and experiment occasionally. That's my plan at least.

View on HN

Within all the noise about systemd I think posts like this are quite beneficial. Instead of discussing politics or throwing out buzzwords, it presents a specific technical shortcoming. Positive or negative, these are the types of things that people should be reading about in relation to systemd.

The problem is that people are deciding whether or not they like systemd based on "do you like Lennart" or "do you like The UNIX Philosophy", because that's what people are making noise about.

As I said in another comment, I really wish it went into more detail on the actual problem.

The problems with journalctl are usability ones, which doesn't make them any less of a problem, but doesn't point to an underlying technical failure either.

The problems with systemd are basically stated as "a Fedora upgrade causes systemd to go bad." Is this a systemd problem or a Fedora problem?

Some anti-fragility on the part of both Fedora and systemd would help here. Maybe a statically compiled init would be a start?

systemd does not support static linking due to its use of NSS. See: http://lists.freedesktop.org/archives/systemd-devel/2014-Mar...

> Only the most trivial libraries actually support it.

... what kind of nonsense is that? Almost every library supports static linking to a basic degree at least. Heck, I statically link giant things like Qt and Boost every day at work.

Well the core of the issue here is you can't really staticly link against a library that depends on dlopen/dlsym (nss system is built around this).

I mean, you could, but now your staticly linked binary still depends on other dlsym'd code. So whats the point?

(Not trying to make an argument that this is good or bad behaviour)

I understand, but the question then becomes why your library depends on dlopen and why you don't offer an alternative static method as Qt's "plugins" do. Doesn't seem like good design on the part of the NSS devs to me, and probably a poor choice of library on the part of the systemd devs to me. But maybe I'm missing something.

The library that depends on dlopen is glibc.

You can statically link glibc, so I'm pretty sure that's not right...

systemd does not support static linking due to its use of NSS.

Well, that is a surprise to me. And something of a concern.

I can see systemd as a whole not supporting static linking. But systemd is a collection of many different binaries that each do their thing, so would it be possible for systemd (the pid 1 executable) to be statically linked while the other supporting executables are dynamically linked?

The systemd developers try to avoid using NSS on PID 1 (for very good reasons), so NSS wouldn't be a problem for static linking PID 1.

* See for instance https://bugzilla.redhat.com/show_bug.cgi?id=915912#c18

Sounds like it would just need some changes to their build setup to allow the PID 1 piece to be compiled statically, which doesn't seem too bad.

Of course, this may not even solve the root cause of the problem this article talks about. It would make PID 1 a little more resillient though.

Anti-fragility isn't the same as robustness. It should rarely be used as a term.

I'm not even sure how any software could be described (accurately) as anti-fragile. Robust, yes. But anti-fragility indicates that performance improves with stressors or catastrophic/unexpected events.

Given that Fedora and systemd has been developing in lockstep over the last few years, one would think they worked well together...

I'd hope that any distribution would be packaged to work well with it's init system, regardless of which init system that is. After all, the whole point of a distribution is to have a core set of software[0] that works together reasonably well.

[0] With the number of different packages in a modern Linux, I don't expect everything in a distributions repository to work perfectly, but core stuff (like the stuff that gets you from a cold boot to a login prompt, etc) should be rock solid.

those are completely valid criteria. What's wrong with wanting your system to follow the closest thing to a known axiom in operational computer science that has ever existed?

I don't really have a good or bad opinion about systemd, to me the init system and things around it are just pieces that needs to work.

The points discussed here are serious, should be filed as bug reports, and should be acted on by the developers. But the article also just sounds like systemd bashing, software has bugs and poor thought out solutions - which can be fixed or improved - it's just code.

I could probably have written a similar article about many, many Fedora (and Debian) upgrades over the course of a decade or so about core components such as distro upgrades making the init system crashing, failing to start services, glibc upgrades screwing up servers, grub upgrades calling for a 2 hour car drive to fix and so on. But I didn't, I either filed a bug report, fixed the code, or was just too plain busy getting things back to working.

if you like systemd, use it, if you don't like it, don't.

That is so naive. No one chooses to use systemd. People choose a distro. It's being forced on long time users of distros without any of the users having a say.

Yeah, I can switch from one distro to another. That's a choice I have. But it's not so simple as you make it sound.

Yeah, I can switch from one distro to another. That's a choice I have. But it's not so simple as you make it sound.

Switching distros is like moving to a new city. If you stay in the same state (or at least in the same country) it isn't too disorienting. But switching to something completely different (like on another continent, or going from an RPM-based to deb-based distro) will require some significant effort to adapt to the new situation.

We pick our distro of choice based on a number of factors. Just because it has some downsides doesn't mean we have to move immediately. But that doesn't mean we can't give (constructive!) feedback if there are problems.

> No one chooses to use systemd.

I did. I've been systematically installing systemd on my Debian machines.

> It's being forced on long time users of distros without any of the users having a say.

It's being adopted by distributions in accordance with the stated and implied wishes of the developers, maintainers, and users of the distributions.

The reason that (e.g.) Arch dropped support for legacy init so quickly was because they literally failed to find anyone who wanted to go through all the work of maintaining the old init system. If none of the users want to do the work, then nothing's being "forced" - that's the way community-organized FOSS projects work![0]

Same goes for Debian, who made the switch in accordiance with their normal development process (including a general resolution in support of systemd!). Debian has promised to maintain systemd-shim (supporting other init systems) through at least Jessie, and possibly longer, depending on whether there is enough demand for alternative init systems, and support from developers for maintaining it in future releases.

Ironically, the biggest threat to systemd-shim in Jessie's successor are people who claim they want to fork Debian - if all the people who hate systemd leave Debian, then nobody who wants to actually do the work to maintain the alternative init systems will remain with the Debian project[1].

[0] Even then, you can still find an AUR package for it (https://aur.archlinux.org/packages/initscripts-fork/), though as with everything in the AUR, it's subject to much less testing. Note that the package has only 27 votes - this means that only 27 people actually said that they care about moving this package back into the main distro.

[1] This may be a bad or a good thing, depending on who you ask.

>The reason that (e.g.) Arch dropped support for legacy init so quickly was because they literally failed to find anyone who wanted to go through all the work of maintaining the old init system. If none of the users want to do the work, then nothing's being "forced" - that's the way community-organized FOSS projects work![0]

Users != developers

I am not a developer. I'm an administrator. I know enough C to be able to poke around source code and understand what is happening when I get an error, but not enough of it or anything else to maintain an init system. A lot of admins don't know this much. A lot of desktop users don't know this much.

I'm not disagreeing with your overall sentiment here - but it's not so simple as "If the users of the product liked it, they'd maintain it" - sometimes they don't have the skills required to. Not everyone who drives is a mechanic, etc.

> Not everyone who drives is a mechanic, etc.

If you car requires more knowledge to maintain than you have, you can get a different car, pay someone to maintain it or get a bike. Those are the only options I see. I don't see how init is any different than a car. You have those same options. I'm sure someone somewhere is paying RH or canonical or in house devs/admins to maintain init scripts for their application stacks.

I hesitated to make the analogy because I expected a response like this, stretching the analogy too far.

It isn't a matter of managing init scripts - that's easy. Continually updating a distro to use your init system of choice is a wholly different matter. I can change the oil in my car. I can't replace the transmission.

> I'm not disagreeing with your overall sentiment here - but it's not so simple as "If the users of the product liked it, they'd maintain it" - sometimes they don't have the skills required to. Not everyone who drives is a mechanic, etc.

What I find quite unfair is that many people say that they don't have the technical skills to effectively contribute to the project, let alone develop or maintain any alternative, yet accuse the systemd team (or the GNOME team, or the NetworkManager team, or the XFCE team, or whatever) of producing sub-standard software. Given the self-asserted lack of skills, on which basis such a severe judgement is done?

Can we please go back to trusting each other, praising who actually do some useful work or at least avoiding open attacks to them? Technical disagreement is welcome, but it has to be backed by some skills to be useful.

Because its a free software project you are not paying for and use as a gratis gift from the developers and maintainers of the distro.

And those developers and maintainers wanted to use systemd.

If, as a user, you disagree with the developers and maintainers of your choice distribution, you picked the wrong distro, and should either find developers and maintainers that align with your views or fork it and become a developer / maintainer yourself if nobody provides for your use case.

You cannot bitch on a high horse when not paying a cent for any of this about how the developers and maintainers are doing what they want with their distro. Well, you can, but nothing will ever happen - they already made their choice based on their needs and use cases.

I think ongoing constructive discussion about the technical and philosophical issues with software design, particularly of open-source software that affects huge numbers of users, is always valuable. The OP here even likes systemd, so the article isn't nitpicking.

As others have pointed out, when your init process faults, that's a major problem. In the real world, for the core elements of an operating system, whatever features they have are less important than how well they fail. In this case, the OP has identified a very very bad failure case.

More importantly, this report makes concrete the theoretical complaint against systemd that its monolithic design is not just a philosophical issue, but a practical one. The init process needs to be rock solid, but a law of software is that bigger software is less stable. So if the sprawling nature of systemd means it will tend to become less stable over time, then we have a major practical issue that needs to be addressed.

This is not a matter of not moving on. Rather, given that systemd has been adopted by several major Linux distributions, it's actually far more important now to criticize its design failures, to draw attention to get things fixed. If "moving on" means we shouldn't critique the software, then how will it ever improve?

Not sure if /sbin/init failing is a nitpick. its kind of a catastrophic failure as far operating systems are concerned.

Never mind that it results in a zombie state where you still have a shell, but no commands actually work.

> I'm no fan of systemd, but do we really need to be nitpicking its every failing?

Yes. When some developers are pushing down your (and mine) throat critical software that sucks _that_ much, that's the least someone can do.

Some developers wrote some code and published it in a software package under a free software license.

Other developers picked up said package and added it to the package collection they are maintaining.

You choose to use the package collection maintained by said developers, which means that you trust their technical decisions otherwise you'd be running software from people you don't trust, which is not a great idea.

Nobody is pushing software down anyone's throat. Please avoid such hyperbolic mischaracterization, it really does not contribute anything to the discussion.

> You choose to use the package collection maintained by said developers, which means that you trust their technical decisions

This does not however mean that I must silently accept their bad choices. If they were about to step out in front of a bus I wouldn't remain silent because I trust their judgement. Sometimes people you respect excercise poor judgement. This is one of those cases.

Feedback is a thing. You're giving it here. Why shouldn't I give it to the distros that certainly are trying to force systemd on me?

> This does not however mean that I must silently accept their bad choices.

But there are proper places to discuss this issue with them, and HN is totally not one of those.

> Sometimes people you respect excercise poor judgement. This is one of those cases.

Sure, but have you considered that the one exercising poor judgement in this case may be you?

I don't know which distro you're using, but Debian has extensively discussed the issue and the first tech CTTE resolution made lots of valid technical points in favour of systemd. For sure it's not an obviously bad choice, and if your maintainers have chosen to ship it they may have valid reasons to do so. Not to mention that's still entirely possible to avoid systemd for whatever reason, at least if you're using Debian it's trivial.

> Feedback is a thing. You're giving it here. Why shouldn't I give it to the distros that certainly are trying to force systemd on me?

Right, but I'm here trying to give feedback to you for your actions in this thread. You're here giving feedback on HN to people that probably don't read HN, and doing so with a rather inflammatory tone.

If you want to give feedback to your distro maintainers, please get in touch with them in the appropriate channels (IRC, mailing lists) and ask them their reasons, but please first check if they haven't already stated those, one can just get annoyed if every person in the world keeps asking stuff that has been answered countless times.

> Can we just agree to move on?

No, we can't. Sorry but that's just how the world works. Just like every Go language post has "generics or crap" mentioned, every systemd post will have "The Unix Way" mentioned.

A price of freedom of speech is having to deal with self-filtering idiotic viewpoints. Worth it in my opinion, but I'm an anti-censorship for EVERYTHING person.

I'm not suggesting censorship of any sort. I'm certainly the same way. I'm just suggesting level-headedness and a willingness to take or leave it and move on with life.

I understand, I also agree with your suggestion. I guess my point is really that even though a nice ideal, based on my experience, likely not attainable.

> If you don't like it, don't use it.

Have you tried removing systemd from latest Ubuntu? I didn't go very well for me. I imagine removing it from RHEL 7 won't go well over either.

> I'm sick of the endless banter.

Ok but "use something else" or "fork it" is not exactly solving the problem either.

And thats the thing. If it was "just a init", it would be just as replaceable as sysv, openrc or runit. But it is not, so it is not. As best i can tell, a major argument for going systemd is that something more user facing (Gnome) depends on a subsystem of systemd, and that in turn requires that systemd is used as init. In other words, systemd as a project is invasive and insidious.

The people that develop GNOME chose to depend on the D-Bus interfaces exported by some systemd-provided services (eg. logind) because they actually solve some problems they were facing with a clean and robust solution. Yet they made sure that the dependency is optional, to accomodate those that for a reason of another do not use systemd.

This means that systemd is not insidious, it's valuable.

> Have you tried removing systemd from latest Ubuntu? I didn't go very well for me. I imagine removing it from RHEL 7 won't go well over either.

Ubuntu is not the Universal Operating System, that's Debian. This means that Ubuntu is definitely opinionated in its software selection, and rightly so. You couldn't replace Upstart and now Ubuntu relies on systemd. If you have the skills to fully evaluate the costs and benefits of mixing and matching random pieces of software, distribution like Debian or Gentoo may be a better fit for you.

Indeed, switching to sysvinit in Debian is trivial and the systemd team worked really really hard to make sure the transition is smooth even if one keeps switching back and forth. They should really be praised for the effort they've put in it.

Given the huge ambitions of the project maintainers and how everyone's rushing to adopt it even amidst sloppy integration work, yes, the criticism is worth it.

"The alternatives are certainly not perfect" is no consolation. At all. Especially considering the vast majority were never fairly considered to begin with.

I had the same sort of annoyances, but instead of whining, I simply ditched it for now. I don't see why people have such a problem doing this.

>If you like systemd, use it, if you don't like it, don't.

I think people would care less about systemd if that was a realistic choice. I strongly believe that the whole systemd debate would go away if systemd wasn't a dependency of GNOME and other stuff.

Personally I have no strong feelings one way or the other, but I do fear that the BSDs are going to be left behind as they to some extend have been piggybacking on Linux in terms of desktop software.

you're missing the point... SystemD is about RedHat trying to take over the entire Linux ecosystem. It's intentionally designed so if you use any part of it (which there are good parts) then you have to use all of it (which there are many bad parts). Oh and conveniently RedHat is the main project maintainers.

Reply on news.ycombinator.com