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

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

#311

Post by squeed » Mon, May 04, 2020, 12:21 PM UTC

majewsky wrote: post #284

josteink wrote: post #167

Earlier quoted context omitted.

Simple... for what? I’d like to setup a service, which depends on another service, and which must always be running, and if it goes down, it needs to have all forked processes killed, must be restarted, and it needs to run as a specific user. With systemd? 5 lines or so of boilerplate, independent of distro. I don’t know about you, but I call that simple.

Technically (and I think this is what this thread's misunderstanding is coming from), this is not systemd being simple . It's systemd being easy . Simplicity is an intrinsic property of a product, describing that it solves a problem without needing many parts. Easiness is a property of the product's user experience, describing that it can be used without much training.

Systemd reflects the underlying system it is meant to support: the Linux kernel. And the Linux kernel is neither easy nor complex.

That Systemd can make the mania of Linux knobs usable is, IMHO, a huge achievement.

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

#312

Post by AsyncAwait » Mon, May 04, 2020, 12:21 PM UTC

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

I don't know why, but it bothers me when someone's trying to criticize systemd, without even bothering to get the case right. It smells of not having looked at it any more than to form the run of the mill opinion on systemd, while looking at what came before with healthy dose of romantic nostalgia.

I don't want my init system to be a series of garage-quality bash scripts with slightly different error rate tolerances etc, systemd solves that. I don't want my system to just blindly shut down, even if it's not necessarily safe to do so immediately, systemd solves that.

What systemd critics often miss is that it's also a rather valuable resource manager in general. I know that many would say this should not be part of systemd, but the thing is while that sounds nice, nobody built anything remotely as convenient for Linux as systemd in this area.

It's nice to say what systemd got wrong, but I haven't seen anything actually built that can seriously compete with it.

I now actively avoid distros without systemd, because the admin experience of those distros has generally been much less consistent.

We can all talk about the right way to do things, but unless there's code that's clearly superior to what systemd offers me today, am not interested.

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

#313

Post by keymone » Mon, May 04, 2020, 12:22 PM UTC

One thing I’m surprised about in the init wars of past decade(s?) is that in almost half a century of Unix nobody got up and said “why don’t we, instead of bickering about implementation details, come up with single format to declare desired system startup behavior, and then users can pick whichever implementation they like to read and execute that format”?

Can’t be impossible to distill some basics about service startup configuration and dependencies, can it?

Then make it extensible and cry about differences in extension support like we do about per-browser css options, but at least converge on some basics.

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

#314

Post by vezzy-fnord » Mon, May 04, 2020, 12:24 PM UTC

cycloptic wrote: post #278

vezzy-fnord wrote: post #272

Earlier quoted context omitted.

The 'job model' is the wrong abstraction, as is the unit concept which tries to reduce things that have irreducible differences. I'm also rather amused how you're conceding that they're doing a "bad job," but still shrug it off as better than nothing. If you're offering a mediocre solution to an "impossibly large scope" of a task, then you ought to rethink things. Even then, a poorly implemented feature can be worse…

The entire purpose of designing models is to reduce things that have irreducible differences and then tell people to shut up and deal with it. There is nothing else there. What is it exactly that you think IT gets paid to do other than this? We have finite time on this planet. Also, things are constantly being rethought. That is quite literally what the churn encompasses. You can't complain about this while asking fo…

All models are wrong, some are useful, others not so much. There's no need to treat me with these banalities. The job model ought to have died with Upstart. It did not. Oh well.

> The core problem has already moved to a different area and that's why it really doesn't matter if they are doing a bad job.

Yes, I agree.

Still, the losers of history deserve their voice, too.

"Nobody" is a significant overstatement. A lot of (certainly not all) daemons that used to only support double-forking and PID files were fixed in the wake of daemontools. systemd and other init systems benefited from this work when they appeared. Still, PID files are subject to TOCTTOU regardless of what you use, so that's a given.

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

#315

Post by zozbot234 » Mon, May 04, 2020, 12:27 PM UTC

pas wrote: post #306

zozbot234 wrote: post #294

Earlier quoted context omitted.

> 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 s…

The user shouldn't be concerned. That's why the distro should solve this. But as we all know, abstractions are leaky, and encapsulation only goes so far. How should anyone know what the user really intends. When I start a tmux in a graphical session and click log out I want the system to stop my things completely, (almost) like I haven't even logged in. After all, my session never was set up to be an always-on server…

> When I start a tmux in a graphical session and click log out I want the system to stop my things completely.[] The distro never advertised this, etc.

The graphical environment could advertise that you have launched something that will persist upon disconnecting the session, and give you an option to terminate it entirely instead. (It's after all easier for graphical environments to offer these sorts of "user friendly" hints than for terminal-based workflows.)

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

#316

Post by vezzy-fnord » Mon, May 04, 2020, 12:31 PM UTC

majewsky wrote: post #285

vezzy-fnord wrote: post #160

Earlier quoted context omitted.

> it's nice to see you back again! Not for long, probably. I drifted out of this sphere years ago, and came back specifically for systemd's 10 year anniversary, as I felt obligated to at least do that. Judging by the tone of the comments, 10 years later is still too soon to discuss systemd dispassionately, but when I come back in 10 more years I'll see if things have changed.

Honest question: Which relevant technology is ever discussed dispassionately?

If we can't ever perfectly adhere to an ideal, then I guess we ought to go full on with the connivery and deceit, then.

Regardless, I did have at least some expectation that people would actually focus on the original post and not brawl in the comment section over tangents that often aren't even part of it.

Oh, well. And hey, if other people down the road read this and it makes something click for them, I'll be happy with that.

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

#317

Post by rini17 » Mon, May 04, 2020, 12:32 PM UTC

sjwright wrote: post #293

rini17 wrote: post #265

Earlier quoted context omitted.

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.

These are very broadly defined categories and everything can be conveniently rationalized to fit into them. For example I expect this be downvoted and filed under 3 or 5. (tl;dr: systemd broke a "debug" kernel parameter and handwaved it away with "Generic terms are generic, not the first user owns them." )

https://bugs.freedesktop.org/show_bug.cgi?id=76935

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

#318

Post by fetbaffe » Mon, May 04, 2020, 12:32 PM UTC

dTal wrote: post #300

majewsky wrote: post #274

Earlier quoted context omitted.

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…

Correct, Red Hat will decide the future of Linux userland, not the distros, they will just have to follow. This is a way of building one distro with many flavors instead of many separate distros.

"One distro to rule them all".

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

#319

Post by AsyncAwait » Mon, May 04, 2020, 12:37 PM UTC

BiteCode_dev wrote: post #236

AnthonyMouse wrote: post #138

Earlier quoted context omitted.

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…

I hear that a lot. It's not my experience. Setuping services has been a pain for 15 years for me. Then with systemd it was suddenly easy. Detractors keep repeating systemd sucks, but that this point, Debian and Fedora apparently decided it was good enough. And I never heard an end user complain. I've stopped to be open to convincing.

Exactly, my biggest problem with the systemd complainers is that it's all kind of abstract things, like it's not the Unix philosophy, which in practice doesn't mean much and certainly doesn't automatically mean it's a bad thing.

SysVinit was a horrible, inconsistent mess of bash scripts of per-individual-developer variations in quality and not insignificant variations between distros, or even individual services within the same disto, I wouldn't hold that as the cornerstone of the Unix philosophy, that is if one's intention is to paint it in a positive light.

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

#320

Post by zeveb » Mon, May 04, 2020, 12:38 PM UTC

sjwright wrote: post #263

novok wrote: post #219

Earlier quoted context omitted.

Linux types I've noticed tend to be more holy war orientated. Where did the classic vim vs emacs holy war come from also?

And that was one of the sillier holy wars, since text editors have near-zero network effects and it's trivial for distros to ship both. (FWIW I use nano.)

> And that was one of the sillier holy wars, since text editors have near-zero network effects and it's trivial for distros to ship both.

Text editors like vi may have near-zero network effects, but operating systems like emacs and vim have plenty of network effects. If I spend months building an amazing interface to git in Emacs but my colleague uses vim, our organisation is hurt.

That's (I think) why people care: they want to collaborate.

> (FWIW I use nano.)

boggle