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

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

#151

Post by cycloptic » Mon, May 04, 2020, 6:18 AM UTC

Karunamon wrote: post #112

CountSessine wrote: post #107

Earlier quoted context omitted.

Very narcissistic. If it’s so awful for you then don’t use it. But it solved a lot of other peoples problems, like rogue sessions on lab computers and broken executables that accidentally signal() themselves into orphan-hood because SIGHUP is truly one of the dumbest legacies of posix around, maybe just short of posix AIO. Seriously - don’t use it if you hate it so much.

Yes, my systems are primarily operated for my benefit. This should not be a controversial stance, and certainly not one worth hurling insults about. > Seriously - don’t use it if you hate it so much. Oh how I WISH that were a viable option. Few things would make me happier than that overcomplicated, opinionated, arrogant pile of unsafe code being excised viscera ex machnia from any system I have the misfortune of man…

What benefit are you really getting from using mainstream distros if you find their choices to be so objectionable and don't agree with their decisions? And have you looked at the state of the kernel or at your CPU lately? I would really suggest not using Linux or any modern x86_64 processor if you are worried about "overcomplicated, opinionated, arrogant piles of unsafe code" at the lowest possible levels of your system.

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

#152

Post by vezzy-fnord » Mon, May 04, 2020, 6:19 AM UTC

ratsmack wrote: post #2

>systemd still remains poorly understood and understudied from both a technical and social level despite paradoxically having disproportionate levels of attention focused on it. This statement makes no sense. It is well understood and has been studied and critiqued by many, including me. Also, I don't know what "social level" has to do with anything here. It was just created for the commercial aspect of Linux and for…

Well, my point is that (for instance) the specifics of its dependency model are still fairly obscure and undocumented knowledge. So I would say the statement is quite justified. And it also has a fascinating history that often gets reduced to culture war-related soundbites, which too deserved to be told.

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

#153

Post by cycloptic » Mon, May 04, 2020, 6:24 AM UTC

AnthonyMouse wrote: post #149

cycloptic wrote: post #141

Earlier quoted context omitted.

Sysvinit is still around, you can always go back to it if you really want. The package is even still in debian.

The problem is not that sysvinit doesn't exist, it's that other packages now have dependencies on systemd, so it doesn't just swap out.

I don't see how that is the problem. It's exactly what you asked for. If you're replacing a low-level component with something else that hasn't been updated in years and doesn't implement features that other packages do then yeah, you have to be prepared to accept that some newer things will break, and you'll have to revert a lot of other packages to older versions too. What else can we do? This isn't even a systemd-specific thing.

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

#154

Post by hnarn » Mon, May 04, 2020, 6:27 AM UTC

nine_k wrote: post #116

m45t3r wrote: post #108

Earlier quoted context omitted.

> Are user processes allowed to run after logout? Which DNS to use during startup? What logging in should look like? In each such case, existing behavior which was widely considered as not broken was replaced by a different behavior, often even without an escape hatch. The new behavior(s) in such cases should be made possible, but the default should be the old behavior. All those examples you gave are possible to dis…

Good thing sanity prevails in distro maintainers! But not in upstream, as you duly note. I also remember that even 2-3 years ago the situation was not as nice yet. I think what became systemd could have been great software, if not for the, mmm, cavalier attitude of its creators (not necessarily personal; it might be amended by RH corporate deadlines).

"Not in upstream" doesn't seem to correspond with the comment you replied to.

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

#155

Post by llarsson » Mon, May 04, 2020, 6:27 AM UTC

blibble wrote: post #111

cmeacham98 wrote: post #32

Earlier quoted context omitted.

This is such a classic example of the type of argument I see from most anti-systemd proponents that it made me laugh out loud when I clicked your link. For the lazy, here's the context of that cherry-picked sentence: > In order not to break screen we currently do not set kill-user=1 or kill-session=1. > Note that in some cases it might be a good thing to kill screen sessions when the user otherwise logs out (think un…

at university I remember working around the auto-killing of logged out users processes by running screen, then inside that screen ssh'ing into localhost

Beautiful.

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

#156

Post by rleigh » Mon, May 04, 2020, 6:27 AM UTC

0zymandiass wrote: post #39

zozbot234 wrote: post #7

Systemd is an amazingly clear example of the second-system effect, as described in The Mythical Man Month . I fully expect it to be replaced down the line by something dramatically simpler and more intuitive, but that might take some time. Nonetheless, it does seem to solve some real problems with the earlier, rc-scripts approach.

It's dramatically simpler and more intuitive than what it replaced, so I'm super excited when someone comes up with something even better!

> 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 single and very simple configuration file (inittab). Everything else was delegated to higher levels. Simple, flexible, and extensible. But above all, understandable in its entirety, and completely predictable.

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

#157

Post by AnthonyMouse » Mon, May 04, 2020, 6:29 AM UTC

cycloptic wrote: post #153

AnthonyMouse wrote: post #149

Earlier quoted context omitted.

The problem is not that sysvinit doesn't exist, it's that other packages now have dependencies on systemd, so it doesn't just swap out.

I don't see how that is the problem. It's exactly what you asked for. If you're replacing a low-level component with something else that hasn't been updated in years and doesn't implement features that other packages do then yeah, you have to be prepared to accept that some newer things will break, and you'll have to revert a lot of other packages to older versions too. What else can we do? This isn't even a systemd-…

They didn't used to break if you wanted to switch from one init system to another.

What you could do is to reduce unnecessary interdependencies. And where there is inherently interaction between separate packages, use a stable interface and publish the standard so that alternative implementations can replace a single package in a standard way without breaking several others.

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

#158

Post by saati » Mon, May 04, 2020, 6:33 AM UTC

theamk wrote: post #129

nine_k wrote: post #86

My beef with systemd is not its reinventing things. That part may actually be good. One problem is that a number of reinventions were poorly made. E.g. the log format. Yes, unstructured logs have a ton of drawbacks. Can we take some ridiculously well-tested, reliable embedded database or serialization format (like sqlite) and use it as log storage? Alas. Another problem is the "I know better" attitude. Are user proce…

You don't want to use sqlite for logs -- it is way too complex, and in particular, it may roll back (=lose log entries) if it is low on space, and permanently damage data when writing onto disks with errors. It also makes wrong performance tradeoffs for logging -- your choices are either sync() all the time, or roll back on unexpected termination. I don't like the that journald goes backwards in space and updates ind…

No local logging will work without disk space, and if the disk is bad anything can get corrupted.

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

#159

Post by rleigh » Mon, May 04, 2020, 6:33 AM UTC

dralley wrote: post #132

sneak wrote: post #122

Earlier quoted context omitted.

It would appear from distribution adoption that systemd is a lot more popular than it is unpopular.

One of the reasons distributions appreciate systemd because systemd unit files are easy to write and can easily be written and maintained upstream and used with very few if any modifications downstream. Your average HN user doesn't see or particularly care that it makes things easier for distro maintainers, so it's much easier to push the corporate conspiracy angle than to accept that a lot of the hand-wringing takes…

This is one thing which is often claimed, but to my mind is poorly justified.

As a (Debian) package maintainer for over a decade, this used to be a non-issue. They were write and forget. The average package was just some simple boilerplate.

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

#160

Post by vezzy-fnord » Mon, May 04, 2020, 6:34 AM UTC

whereistimbo wrote: post #41

vezzy-fnord! I have always enjoyed your commentary and perspective of operating system, it's nice to see you back again!

> 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.