[krylon]

At the risk of sounding heretical, I kind of find myself in the middle ground regarding systemd - I was initially highly skeptical of it, and I still think it's problematic that it is so Linux-centric and will cause problems maintaining software to run both on Linux/systemd and on *BSD. The way it was pushed on distros was problematic, in my opinion.

But having used a couple of Linux systems running systemd - Raspian Jessie and openSUSE - I have to admit it's not that bad. In practice - on laptops and desktop systems (assuming one counts the Pi as a desktop system; for my use case, I do) - I had no problems with it. Enabling and disabling services is a lot easier. I do not think is as great as its proponents claim, but it's not as bad as some people think, either. Personally, I have come to appreciate journald, even though I still agree that binary logs are a bad idea. At least there is still the option of installing a syslog daemon.

[microtonal]

I am also in the middle ground, but I have moved from the opposite direction. I used to like systemd a lot, especially for its simple unit files (compared to ugly System V shell scripts) and the fact that it could properly track processes and restart them on failure.

I have become a bit more skeptical, because most of the problems that I recently had seemed to be related to systemd. Including some networking problems, long boot delays because systemd decides to wait 90 seconds be default on some conditions that it considers to be errors, and problems such as having to restart systemd-logind manually because of some d-bus update [1]. Before the update, logging in via SSH blocked for a large amount of time.

The most annoying part is that some of the problems take quite a bit of work to debug due to the opaque nature of modern systemd/d-bus/...-based systems.

[1] https://major.io/2015/07/27/very-slow-ssh-logins-on-fedora-2...

[pawadu]

I think systemd would benefit from a slower adaptation.

The network and boot issues that practically everyone have encountered are mostly due to incorrect default configurations. This shows that the maintainers are not ready to use systemd as they don't yet fully understand it.

[sevensor]

Like PulseAudio in its early years, systemd bothers a lot of people because it was pushed out before it was quite ready, and therefore breaks things that used to work. But also like PulseAudio, it solves a whole lot of problems for which the solutions were becoming increasingly hacky and unstable. I don't believe a slower roll-out would have helped in either case, because many of the issues were undetectable without a broad user base.

Anti-Lennart partisans would say here that both pieces of software are broken by design and leave in a huff. I sympathize with their aversion to complexity, but I'll take a complex init system and simple configuration over a simple init system with baroque configuration.

[pawadu]

From a users point of view there is little difference between software that crashes because its garbage and software that crashes because it is in early stage of development but otherwise a good solution.

Lennart should write more robust software and maintainers should do more QA when doing this type of system-wide changes.

[microtonal]

I agree very much with the points that you are making.

It would also help if small parts of a system would be replaced at a time. Replacing daemon/process supervision, login handling, logging, network configuration, etc. all at the same time in distributions that are used by millions of users is quite risky.

[digi_owl]

Sadly the best you will get out of the systemd camp is "tough luck, should have joined from the start to avoid the pain".

[rkangel]

> The most annoying part is that some of the problems take quite a bit of work to debug due to the opaque nature of modern systemd/d-bus/...-based systems.

This is a reasonable criticism of systemd. The other points seem mostly to be a criticisum of the various distro implementations that use systemd. The sort of thing that gets tidied up over time anyway.

[throw2016]

The bigger question is whether an init should be a continuously developed project with rapidly increasing scope as now various distributions are on differing versions of systemd with widely varying compatibility and feature sets.

[cakes]

Generally agreed. I know that my priorities for what should be done in systemd are not going to match someone else's but there are also some clearly problematic things that just seem to go unaddressed no matter the scale (e.g. rebooting nspawn containers [1], problems with DNS/resolved [2]).

systemd can do a lot of really useful things but when I can't reliably reboot machines or struggle with resolving things using DNS...it's hard to be optimistic.

[1] https://github.com/systemd/systemd/issues/2809 [2] https://github.com/systemd/systemd/issues/3649

[digi_owl]

The whole systemd for containers thing seems like a massive cause of "because we can". Also allowed them a better pitch towards devops and RHEL than "faster boot"...

[digi_owl]

Some parts may be useful, some parts are downright awful, but the clincher is that it is all a big wadded up ball of code.

Damn it, the LFS team basically adopted eudev, of Gentoo fame, because extracting udev from systemd required manual intervention over and over.

[noinsight]

> a big wadded up ball of code.

To be clear, they're all under the same umbrella project, but separate components and not everything is in PID 1. People seem to be confused by that.

[digi_owl]

Plenty of the "separate" components share core code at compile time. If they were truly separate they could be downloaded piecemeal and compiled independently.

[scrollaway]

It's kind of annoying reading people lecturing projects they clearly don't know the internals of on how much better their code would be if they did X.

This applies not just to your comment here but to a ton of comments that pop up on HN all the time. Why not in Go? Why not in Rust? Why not in React and node and electron and why don't you use my library that's still in alpha? It's not OOP. You're not using tabs. MIT is too permissive. GPL is too restrictive. And obviously, this should be a set of tiny separate libraries, how dare you work on free software with different ideas than mine.

I once found a project called Razor-qt. It was a desktop environment that included a bunch of interdependant binaries all under the same repo. I didn't like that very much. I joined it, worked on it, ended up leading the project and merging it with LXDE into LXQt. When came the time for the reorganization, I did push to create tiny components that "could be downloaded piecemeal and compiled independently". And we did end up going that route.

You know what I didn't do? I didn't go on HN and complain about a project I didn't know the internals of at the time.

But hey, maybe you know better. ¯\_(ツ)_/¯

[jcadam]

Ah, but did you force others to use your project? People find that sort of thing annoying at best, infuriating at worst, and they will tend to act out in various ways (to include finding fault with the thing they never asked for that's being shoved down their throat).

[scrollaway]

All my life I've been forced to use things such as Windows, Flash, Skype and Photoshop. Forced because of lock-in strategies in a field with difficult alternatives.

"Forced" is not a term that applies to systemd. People say "forced" because their distro adopted it - guess why their distro adopted it? Because they researched it and found it was good. That is the common theme.

Nobody forced you. If you're an arch linux user, for example, one of the distros that switched the earliest, you'd have been more than welcome to discuss counter-points to systemd on the mailing list.

Of course, most of those that attempted doing so were ridiculed out because in free software, or at least on the Arch ML, there is very little tolerance for bullshit. Most (MOST, not all) of the arguments against systemd are in fact bullshit. Hell, even on HN I've seen people crap on systemd because "it's lennartware".

PS: To be clear, there is plenty wrong with systemd. It's far from perfect, it's still very young and I'm not particularly fond of its "all in one" tendencies myself. But most people in this thread have clearly zero ground to comment on its internals, yet many do.

[krylon]

OTOH, sharing code between different components developed under an umbrella project is not bad per se - if they require the functionality, re-implementing it from scratch for each component would not be a good idea, either. Duplicating and manually syncing the code also has its share of problems.

[JdeBP]

Is there any chance -- any chance at all -- that we cannot do the same dance of ineptly-phrased-objection followed by rebuttal-that-misses-the-point when it comes to this particular facet of the discussion?

Both sides of this are wrong. The people complaining about "monolithic" are groping in the dark for ideas such as low coupling. The people saying "but count the binaries!" are not addressing the questions of fully documented interfaces between said binaries, composability, and interoperability.

The "uselessd guy" explained this quite well, as have many other people. Can you please advance to not dancing this same old dance every time?

* https://news.ycombinator.com/item?id=12879771

* https://news.ycombinator.com/item?id=12652071

* http://uselessd.darknedgy.net/ProSystemdAntiSystemd/

[d33]

It's not only about whether you do it, it's also about HOW you do it. I once saw a slide from FOSDEM which listed lots of CLI tools that systemd replaced. Some of them seemed quite trivial and if they all depend on low-level systemd, I believe it really is bad design.

[wott]

But this tends towards Windows model, not a form of UNIX-like model. If I wanted a Windows-like, I'd use a Windows.

[rkrzr]

This is indeed an issue in practice:

I recently wanted to use the "systemd-journal-gatewayd" component in Ubuntu 16.04, which ships with systemd v229. Yet, the feature I needed was only available in v231.

Although I'm only interested in a newer version of "systemd-journal-gatewayd" there is no way to upgrade just this one component, it seems.

[traviscj]

I don't get this. How do you know that the v231 for that component will work with older versions of everything else? If you do, why not just compile it yourself? If you don't like that, why not upgrade everything to v231?

[Elhana]

That is the point - you often can't just recompile journald part, because it is tied to systemd interfaces and you might not be able to easily upgrade systemd, because it is a production system you can't simply reboot like your home server. The only way to do that is backporting specific patches to the older version.

If it were a separate component, it would have a bunch of ifdefs covering several versions of systemd, possibly with some features disabled if older version doesn't support it. However, that somewhat increases code complexity for developers and systemd devs refuse to do that.

That is the point of 'monolithic' criticism - despite being many binaries, you can't easily just build single one and make that work.

[ripdog]

There is systemctl reexec, so can't you upgrade systemd without a reboot using that?

[tyfon]

I'm a bit more on the positive side. I actually really like systemd. When it was first introduced I spent 10-15 minutes learning how it operated and after that it has been so much better than the old init systems.

And the best part is that it's on all the major distros so I don't have to keep relearning the init system if I try something new.

My guess has been that the majority of users enjoy it and a few very vocal opponents have such hate for anything new that they will latch on to every small bug as if it's the worlds end.

(Anecdotally, this is the first time I have written a comment about systemd as other discussions have been non-productive flame fests without substance).

[1_2__3]

If your effort to learn how systemd functions took you ten minutes it's unlikely you're involved enough in the internals of it to understand the debate.

[pmlnr]

> I had no problems with it.

You're lucky. For me, systemd randomly fails to execute a reboot, then, because of this, fails to do halt, and I have to force power off the machine.

And this is just one.

[digi_owl]

Freedesktop, recreating Windows one project at a time...

[bitwize]

> The way it was pushed on distros was problematic, in my opinion.

The technical term for this is "precommitment", and it comes from Tom Schelling. It's actually quite advantageous: once you're precommitted to a particular direction, you're emotionally invested in getting the most out of it. By precommitting you to systemd, the distros hope to get the community to leverage systemd's benefits.

[digi_owl]

Sounds like a restatement of Thatcher's TINA (There Is No Alternative)...