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

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

#141

Post by cycloptic » Mon, May 04, 2020, 6:04 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…

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

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

#142

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

sneak wrote: post #118

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…

It's astounding to me the issues people have with this. systemd's existence doesn't preclude anyone from using the old, pre-systemd ways of doing things. There are thousands of linux distributions, and afaik there are at least a dozen which are primarily defined as never-using-systemd. Face it: the linux userspace has always sucked. Linus punted on it way-back-when (to be fair, he was a solo dev working on a kernel,…

> Traditions are not always inherently valuable. Try new things. Discard the ones that don't work for you.

But that's the trouble. The people who make systemd keep integrating it with everything else they make and vice versa, which makes it harder to try new things because instead of things coming in pieces you might replace, it comes as one big interdependent blob.

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

#143

Post by bzb3 » Mon, May 04, 2020, 6:05 AM UTC

sneak wrote: post #122

gjvc wrote: post #45

Earlier quoted context omitted.

It's worth considering why the topic makes such a regular appearance. I suggest it might be because that so many users of this website find it to be a remarkable example of not only how something so widely unpopular can become so widely established, but also being something that they have to contend with frequently.

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

Red Hat made systemd a hard dependency for gnome, forcing all distros that have no manpower to patch gnome to use systemd.

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

#144

Post by arpa » Mon, May 04, 2020, 6:05 AM UTC

sergeykish wrote: post #57

acdha wrote: post #34

Earlier quoted context omitted.

> An init system is harder then it seems ? You and Jonnax seem to think that unless you made it you have no right to say anything. Have you ever made an init system ? Researched what exactly goes into it ? Sure, there's more then just starting programs. But not much more. The only really complicated thing about getting a [linux] computer from kernel boot to firefox is setting up devices. And even that [udev,"hotplug"…

There is no competitor because there was no problem. For most of use cases SysV, rc.d worked. Just like ifconfig. Arch Linux switched to systemd earlier than Debian. And I have not noticed. Arch community accepts breaking changes. Debian? I believe they value stability. Systemd should have matured, proved its citizenship and qualities. And it would have been accepted. Instead it usurped. People had no choice but to a…

Debian used to value stability. Nowadays - not so much.

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

#145

Post by anilakar » Mon, May 04, 2020, 6:05 AM UTC

Spivak wrote: post #70

dooglius wrote: post #36

Earlier quoted context omitted.

Why exactly should students not be able to use CPU cycles while not logged in? I certainly did this as a student and would probably not have complained if it decided to kill my processes when doing so.

You don’t deserve the downvotes. This is precisely the use-case this feature is good for. Multi-user systems where persistent background tasks for unprivileged users doesn’t make sense and is more indicative of a misbehaving program than a user trying to run a job. Oh my god the number of times we had to bounce systems because the unintended background processes of long gone users overloaded the system.

While it's a valid argument, it's also a prime example of a special case that should not be the default - especially so because in my university, people were instructed to use the Linux workstations remotely for long-running tasks.

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

#146

Post by meddlepal » Mon, May 04, 2020, 6:11 AM UTC

Nextgrid wrote: post #124

gjvc wrote: post #45

Earlier quoted context omitted.

It's worth considering why the topic makes such a regular appearance. I suggest it might be because that so many users of this website find it to be a remarkable example of not only how something so widely unpopular can become so widely established, but also being something that they have to contend with frequently.

Is it actually unpopular or is there just a vocal minority constantly complaining about it while a much larger part of the user base is happily using it?

Mostly just unpopular here from what I've seen in industry as a programmer with lots of sysadmin, ops, and infra engineering experience.

The usual arguments are it is not "Unixy" and then fall back on original designer intent and philosophical attacks, or worse ad hominems against Red Hat or Linus Pottering.

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

#147

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

TA0x0 wrote: post #120

Spivak wrote: post #70

Earlier quoted context omitted.

You don’t deserve the downvotes. This is precisely the use-case this feature is good for. Multi-user systems where persistent background tasks for unprivileged users doesn’t make sense and is more indicative of a misbehaving program than a user trying to run a job. Oh my god the number of times we had to bounce systems because the unintended background processes of long gone users overloaded the system.

Sounds like you had junior admins at best leading your university's *NIX department. A mid-level admin in 1995 could have easily made a 100 line script to kill background processes from non-logged in users that were running over three hours (or whatever). systemd brought nothing to this arena.

I don't understand this angle. You acknowledge the functionality could have been useful even 25 years ago; it makes perfect sense for a daemon developer to integrate the functionality into a session manager and put it behind a config flag which is exactly what they did.

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

#148

Post by WesternStar » Mon, May 04, 2020, 6:15 AM UTC

kimikimi wrote: post #121

WesternStar wrote: post #115

Earlier quoted context omitted.

I see this kind of talking about stuff like the Unix way and existing conventions and programs. I almost have to ask myself when did we end up in a mausoleum. The Unix way is just a guideline from a time some folks wrote some code. A seminal and important time. Its just one(perhaps of many) piece of anecdata. Old code is old code. It's useful but the patterns and conventions it was built on may no longer be relevant.…

It's a good question and infects all of our software "sacred cows." The underlying thing is that we keep driving ourselves to "forward progress" in the sense of a collaborative hegemony, and only in those terms. Either a business wants to own the platform, or the developer wants to build that platform. To do that they have to achieve buy-in from existing stakeholders, but simultaneously reinvent incompatible things.…

Healthy skepticism is necessary for any technologist. However, you do have to use it in both directions. I know my biases are that I prefer new technology to old. So I pay attention to that. However, it is just as bad to reflexively consign something as premature or ill-considered. Sometimes the collective hegemony gets it right. They may have missed on microservices but they didn't miss on the cloud really. I do try to be eclectic in my technology choices if only for cognitive reasons.

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

#149

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

cycloptic wrote: post #141

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…

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.

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

#150

Post by jbverschoor » Mon, May 04, 2020, 6:17 AM UTC

theamk wrote: post #127

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…

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…

Exactly. I was immensely frustrated with sysvinit for over 15 years. Jumped over to systemd as soon as it was available on Debian, never looked back, only one had a problem due to symlinking.