Systemd, ten years later: a historical and technical retrospective • Hacker News Board

Re: Systemd, ten years later: a historical and technical retrospective

#291

Post by pas » Mon, May 04, 2020, 11:20 AM UTC

throw0101a wrote: post #28

acdha wrote: post #5

I think this really sums this article up: > One thing I’m certain of is that this shift cannot emerge from dilettantes, outsiders and proverbial basement hackers. One does not unseat a platform without already being part of the patriciate that calls the shots on what gets integrated where across the largest nodes in the ecosystem. It’s a long, turgid “why wasn’t I consulted?” complaint which really just comes back to…

> An init system is harder than it might seem at first […] systemd-as-init-system is not the problem. systemd-as-kitchen-sink is the problem. It's the tight coupling that annoys many people. Does udevd really need to be in the same repo? While there may be some nice things about journald, does it really have to be in the same source package? (And why can't it support remote logging with the industry standard syslog p…

systemd is not an init system. That it has one, it out of necessity. To manage a system you have to manage what runs on it, to manage that you have to manage what gets started and stopped, and so you have to manage boot and shutdown. And now, here's your nametag, there's the counter, don't forget to smile, you're the new init system!

udev doesn't have to be there, but when a handful of people maintain critical parts of the Linux ecosystem and they saw ways to make their maintenance work more effective, they went ahead and made their work more efficient.

I mean, criticizing systemd/udev/Debian/Ubuntu/Arch on how they did stuff, and the technical merits of how things are is completely fair, but criticizing "why" is strange. They did because they saw that it will help them, their projects, their users. (And they probably understood very well that it won't please all of their users.)

Re: Systemd, ten years later: a historical and technical retrospective

#292

Post by api » Mon, May 04, 2020, 11:20 AM UTC

AnthonyMouse wrote: post #138

theamk wrote: post #127

Earlier quoted context omitted.

I think you underestimate how badly the old sysvinit sucked in the world with many good distribution-provided packages. It was pretty good in the good, old days, where a sysadmin could list every daemon the system runs by heart, but it was breaking apart when you had tons of random packages: Package X uses "start-stop-daemon" in ini file, so there is no way to get error messages if config file is incorrect. Package B…

What you are missing is that it is possible for two things to be true at once. It is possible for sysvinit to suck and for systemd to suck in entirely different and potentially much worse ways. It's as though someone is complaining about having to live under the USSR and how bad things are, and then someone responds that the German rocket program has been dismantled and the British never really had much of one and th…

That's exactly my view.

We had a chance to replace sysvinit with something better. Instead we managed to replace it with something that's horrible in an entirely different set of ways.

The most devastating thing I can say about it is that it feels "enterprise." It's unnecessarily obtuse, complex, and clunky. It feels like a port from some other operating system that's been shoehorned into Linux, or like something designed to sell consulting services and training courses by wrapping very simple things in needless complexity.

We could have ended up with something more straightforward, clean, and simple. It's a tragedy.

Re: Systemd, ten years later: a historical and technical retrospective

#293

Post by sjwright » Mon, May 04, 2020, 11:21 AM UTC

rini17 wrote: post #265

sjwright wrote: post #250

Earlier quoted context omitted.

You seem to be under the misapprehension that anyone remotely cares. Childish tantrums are counter-productive as they almost entirely blowback onto your own psychological state rather than affecting anyone else's. You are permanently stuck with the contents of your brain; everyone else has a quick chuckle at the troll and continues scrolling past. Clearly you are immensely frustrated. I suspect this stems from the fa…

6. Very reasonable systemd issues met with unreasonable hostility. There are plenty of linked examples in the article.

Name one that doesn't fit any of my five categories.

Re: Systemd, ten years later: a historical and technical retrospective

#294

Post by zozbot234 » Mon, May 04, 2020, 11:24 AM UTC

pas wrote: post #271

zozbot234 wrote: post #29

Earlier quoted context omitted.

This is yet another example of pointless incidental complexity in systemd. The whole point of "nohup"-based tools like tmux and screen is to cleanly separate the management of user sessions from the incidental mechanism of whether a remote connection is being closed (the 'HUP' in nohup is short for "hang up" i.e. close a [possibly remote] connection). Systemd should simply acknowledge this fact and keep the user sess…

No, it has nothing to do with remote and such. systemd uses cgroups (kernel namespaces), and if you want something to remain after you log out, then start it in a separate cgroup. cgroups are control groups, you know, to control processes. Which was simply missing for decades in Linux. nohup should be enhanced to support systemd, or systemd should provide a nohup wrapper, and just start a new scope (cgroup) for whate…

> systemd uses cgroups (kernel namespaces), and if you want something to remain after you log out, then start it in a separate cgroup.

Why should the user be concerned with how systemd happens to implement its session management. If you start a screen or tmux instance, it's unambiguous that you want that part of the session to persist after logoff and to be reachable upon logging on to the system again. That's what screen and tmux were designed to do.

Re: Systemd, ten years later: a historical and technical retrospective

#295

Post by api » Mon, May 04, 2020, 11:25 AM UTC

The_Colonel wrote: post #288

xfs wrote: post #174

Earlier quoted context omitted.

This is the kind of false argument being thrown around often in OSS discourse that ignores the structural power differential. Don't like it? Write your own/Leave. The fact is you can't go back to it as an individual, because the system has changed and as an individual you're powerless to change the situation at all, especially against an army of developers paid full-time. The latest news from Debian is sysvinit suppo…

> The fact is you can't go back to it as an individual, because the system has changed and as an individual you're powerless to change the situation at all... Use Void Linux, help Devuan etc. You're not alone, but you're clearly in small minority.

My personal favorite is Alpine Linux. It ditches a ton of other unnecessary cruft too. It feels lean and modern.

Re: Systemd, ten years later: a historical and technical retrospective

#296

Post by pas » Mon, May 04, 2020, 11:25 AM UTC

cat199 wrote: post #71

acdha wrote: post #5

I think this really sums this article up: > One thing I’m certain of is that this shift cannot emerge from dilettantes, outsiders and proverbial basement hackers. One does not unseat a platform without already being part of the patriciate that calls the shots on what gets integrated where across the largest nodes in the ecosystem. It’s a long, turgid “why wasn’t I consulted?” complaint which really just comes back to…

> how open-source projects work they work differently depending on the project. so this statement: > requires buy-in from an unusually large number of parties since it affects the OS, everyone shipping daemons, and the operators. is only true in some cases. c.f. rcng, which was developed by a very small few people, and is a generally sane improvement on previous BSD init that i've really never heard any complaints ag…

Debian voted on the issue, and there was a very lengthy discussion. I don't think the Gnome dependency was the linchpin, at all. Debian developers wanted to get rid of thousands of silent but deadly shell scripts shipped in every package doing service management (rc scripts), they wanted nice cgroup integration, and that's it. At least this was my impression.

Re: Systemd, ten years later: a historical and technical retrospective

#297

Post by rleigh » Mon, May 04, 2020, 11:26 AM UTC

jcelerier wrote: post #206

rleigh wrote: post #156

Earlier quoted context omitted.

> It's dramatically simpler and more intuitive than what it replaced I hope you're being deeply ironic. It's several orders of magnitude more complex. It's more difficult to understand and reason about because its internal state is a black box, and the number of interfaces and file formats to understand is again orders of magnitude more complex. sysvinit had a socket interface with a single message type. It had a sin…

> It's several orders of magnitude more complex. It's more difficult to understand and reason about because its internal state is a black box, and the number of interfaces and file formats to understand is again orders of magnitude more complex. As a user I 100% disagree. Before systemd I had to learn a few dozen of different config formats for various things * various distros, now all my systems are configured in a…

You're not disagreeing with anything I said. You're making a completely different point.

systemd might be more convenient from the point of view of an end user. And unit files might seem superficially simpler than a script.

But systemd is not simpler. It provides significantly more complexity, while also providing a lot of features.

systemd is also not more reliable. The previous system, even with LSB dependencies, was usually run in a linear mode with scripts run in a strict sequence. System boot and service startup was deterministic.

If you read the part of the linked article about the sheer quantity and complexity of the internal state managed by systemd, and how it is not deterministic, or even fully understandable even by its authors due to the combinatorial complexity of all the options and how the same settings work differently in different contexts, I'm afraid that I can't do anything further to convince you about the significant design problems it has which directly impact its reliability. Never had it hang irrecoverably at boot, for no discernible reason?

There is a reason people such as myself are appalled by its design. It doesn't even have a comprehensive specification for such a critical piece of functionality. It's defined solely by a single implementation.

The systemd state is a massive hairball. It's effectively a black box, and understanding why the system exhibits certain behaviours is difficult.

The sysvinit state consists of a current runlevel and the state associated with inittab tasks, which is pretty trivial. It doesn't attempt to maintain a mirror image of the state of the whole system, which is largely a constructed fiction.

Re: Systemd, ten years later: a historical and technical retrospective

#298

Post by astrobe_ » Mon, May 04, 2020, 11:30 AM UTC

JoshTriplett wrote: post #235

kelnos wrote: post #163

Earlier quoted context omitted.

> Debian, Ubuntu, Arch all chose the systemd voluntarily. My understanding (I believe detailed in the article) is that Debian, at least, chose systemd because they were forced to if they wanted a reasonable default GNOME experience for their users. If they hadn't, GNOME would have been missing some features that would have been obvious and jarring. You can certainly argue that they made the wrong call there, and that…

> My understanding (I believe detailed in the article) is that Debian, at least, chose systemd because they were forced to This (and much of the article) is incorrect. Debian went through an extensive evaluation process at the time, over the course of 4 months, considering several different init systems, and chose systemd based on this detailed technical evaluation. That evaluation also considered sysvinit, openrc, a…

Debian also ran a poll a few months ago in order to reevaluate that choice, at least partially. Quite the hint that all is not jimmy-dandy.

As a programmer in embedded, Systemd feels like it solves problems we didn't have, and introduces problems we didn't have. I what point is it more conservatism than "if it ain't broken, don't fix it"? God only knows.

Well, every time the Systemd topic pops on HN or Reddit (and even other places where you wouldn't expect it [1]), I go fetch some popcorn... It seems that different people have different needs and different experiences, hence the flamewars.

[1] https://forum.minetest.net/viewtopic.php?t=21490

Re: Systemd, ten years later: a historical and technical retrospective

#299

Post by zapttt » Mon, May 04, 2020, 11:34 AM UTC

BiteCode_dev wrote: post #232

gorgoiler wrote: post #119

When writing software, it’s comparatively easy to come up with grand new ideas and turn them into lines of code and files filled with modules. What’s much harder is (1) to expand ones code without coupling everything together (2) present it in a persuasive way that naturally builds a user base. SystemD feels like the new grad hire who decided the first thing the would do after joining — the opening power play — is to…

> SystemD feels like the new grad hire who decided the first thing the would do after joining — the opening power play — is to convince the PHB we should rewrite everything in Haskell. I've seen this scenario played out, and it always fails. The product never ships, of ships in such a bad shape the users have a terrible user experience. That's not what happened with systemd. It shipped. And after a few iterations, it…

> it shiped

you completely missed the point of the comment and the article.

yes, it shipped, completely broken. lots and lots of functionality was lost for a while (and some not deemed enterpise-worthy still are).

what seems more correct for you in this car anaology: suppose

- some cars have the turn signal on top left stalk

- other cars have the wiper and healigth control on the top stalk.

would you standardize them by:

a) set a industry standard and wait for them to follow, with a period or brands permanently Opting out (let's say golf carts without turn signals)

or b) force legislation from top down to immediately repurpose the top left stalk for turn signals via sopftware update, no matter if some companies will make the headlight control not work for years or keep the now-wrongly marked control permanently?

systemd is option B. the same system did could easily have been done with a standards for init scritpts and opt-in. yet it was done with a top down idiotic decision that was self serving to some players.

Re: Systemd, ten years later: a historical and technical retrospective

#300

Post by dTal » Mon, May 04, 2020, 11:36 AM UTC

majewsky wrote: post #274

dTal wrote: post #266

Earlier quoted context omitted.

The question remains, what do home directories have to do with init, at all? Okay so Poettering wants to "fix" home directories - is there any reason to couple that with systemd, beyond the fact that systemd is his baby (and point of leverage over the rest of the system)? There are dozens of other examples - network configuration? syslog? cron? This is what I mean by 'OS middleware' - systemd is basically a distro, a…

That's one shitty conspiracy. If this were Red Hat's play, why would they do it with a project that other distros can adopt and have adopted? If anything, providing APIs in systemd makes it easier to migrate to other distros as long as they use systemd. (All relevant enterprise distributions use systemd, i.e. RHEL and SLES and Ubuntu Server.)

Up front, let me state that I have no desire to die on this particular hill, which is why I weasel-worded the hell out of my block.

However, in this hypothetical scenario, the idea isn't to make it difficult to migrate away from "official" Fedora - it's to make it increasingly difficult to build a distro that is not, fundamentally, Fedora. And if everyone is building distros around Red Hat's quirky middleware, which distro is going to work best? Red Hat's, of course. Who are you going to hire to tell you how to manage the thing? Red Hat, of course.

(The logical extreme of this is the situation with Darwin. OSX's kernel+"middleware" is technically open source, but it's basically impossible to build an OS around it.)