Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Systemd, ten years later: a historical and technical retrospective

blog.darknedgy.net

Post reply on HN
Print view View original

221–230 of 458 posts

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

#221

Post by dijit »

k_bx wrote: post #218

Can I just say, from a non-sysadmin perspective, how happy am I that these days I don't have to install something like Supervisord and just use the systemd + journald toolchain. Setup script is just one cp and few systemctl commands (start/stop/enable).

Yeah, that's nice.

I think there's a lot of people who get caught up in the merits of systemd and assume that there's nothing better. Or that the alternative is the old sysvinit which was in dire need of being replaced- but that's not true.

Process supervision is totally feasible in init (just look at runit, Solaris' SMF and MacOS's launchd) even Windows has one.

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

#222

Post by TA0x0 »

cycloptic wrote: post #147
TA0x0 wrote: post #120

Earlier quoted context omitted.

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.

The functionality existed 25 years ago. systemd coming along and poorly implementing it provides nothing.

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

#223

Post by dvfjsdhgfv »

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…

> User A likes to leave their executables on their machine after logout, so we need a cleanup script.

Of all examples you gave, this one is the least convincing reason to introduce this Behemoth on our systems.

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

#224

Post by sneak »

bzb3 wrote: post #143
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.

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

Seems to me there are several options:

1) run the last version of gnome that works without systemd

2) run a patched later version of gnome from another distro that works without systemd

3) don't use gnome, use a different desktop environment

4) fork/patch gnome and remove the dependency yourself

systemd can't take any of those away from you.

If the people actually working on gnome want to add another dependency to gnome, that's their business, is it not? It doesn't break the existing, pre-systemd versions of gnome.

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

#225

Post by x3blah »

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…

Sounds more like the problem is with the packages and a general lack of quality control with respect to the userland than with GNU init. Perhaps that is why BSD projects, which do have some quality control over userland, can still use BSD init.

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

#226

Post by grandinj »

ttctciyf wrote: post #9

As a somewhat dilettante and casual home sysadmin (currently) I was messing around with screen on a box downstairs and ran into this: https://www.reddit.com/r/programming/comments/4ldewx/systemd... Namely that systemd doesn't allow persistent processes started from the shell by default, preferring to terminate them when the user logs out. This would include processes like "screen" whose entire raison d'etre is to per…

Given the insanely vitriolic level of personal criticism leveled at the systemd people on an ongoing basis, some degree of glibness is an unfortunate byproduct.

How about we give them some benefit of the doubt, that they are mostly trying to make things better, and instead ask them "what is the technically correct way, in the systemd world, of implementing this functionality?"

I suspect the answer, for screen, would probably require some degree of messing with the user manager daemon.

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

#227

Post by mr_isomies »

Getting 10 engineers to agree on how to implement a padding function is nearly impossible. Was there ever hope to get thousands to agree at something that front and center? There was literally decades to come up with a solution. I'm sure things where proposed during that time. What systemd did right was get (or coerce) buy-in from enough entities & people to get a big enough purchase to grow. For me, that's the takeaway. It's not on the engineering merit of their solution.

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

#228

Post by dijit »

Jonnax wrote: post #6
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…

I think on the social level there's a lot of people that go "urgh systemd" because that's the popular opinion but overestimate their actual technical knowledge to comment on the matter. I remember reading some advice about not doing rm -rf / on UEFI systems and looking that up, it looked like some MSI laptops would brick if certain UEFI variables were wiped. I found an issue in systemd's issue tracker. And from what…

This is a hard point to refute because it's basically "some unknown number of people who don't like systemd are possibly technically illiterate" which is always going to be true but to an unknown extent.

If we're going on technical credentials, I have a few minor ones. I'm not writing dozens and dozens of lines of C every day, and I'm definitely not writing kernel components- but I've been doing low level technology stuff for 15 years now.

Everything from watching access patterns on drives and recombining data to writing/patching memory allocators and aggressively tuning system internals. I'm currently responsible for automating the deployment of the largest always online game my publisher has ever known. I'm relatively technical and highly regarded for my technical competence.

When it comes to systemd; you could argue that I'm "stuck in my ways"; but I've used systemd since fedora 21, I saw bugs you couldn't imagine, I read the code, I saw the hostility of the developers (maybe it's just defensiveness?) and I was a little worried, but ok, it's just fedora, it'll be better in RedHat when it releases... and while a lot of the lower hanging bugs went away for most use-cases; many remained in the edges. Instead of them being fixed though there's been a propensity to build a software eco-system and "system layer" to the OS.

My argument has never really been that "systemd totally sucks" it's that the conversation surrounding it is very hostile.. If you say that you don't like journald (because it's very easy to corrupt and has access drawbacks, encoding issues, tooling is sub-par etc) then people shout at you: "YOU CAN USE OTHERS", but you can never turn journald off.. it's wasted IOPs, IOPs are not free.

The biggest issues I had with systemd is the fact that (unlike Solaris' SMF, which is great btw) it will hide failure from you, and failure can happen relatively randomly because nothing is deterministic. This is not a holdover from being multi-threaded, there is actually a dependency graph that gets generated. But I've never been able to access that. (Maybe that's changed?)

My argument has always been, instead: "systemd's tight coupling of so many components means that we will never be able to have an alternative or successor to systemd". Because re-implementing single components is next to impossible and the sheer scope of the "system layer" is many times more lines of code than the kernel itself.

Anyway the conversation is steeped in some level of tribalism.. Which I truly hate.

You can't talk about systemd without being "pro" or "against" and then people take extreme stances, like "systemd saved my baby" and "sysvinit was trash" (and on my side: "unix philosophy!", and "systemd ate my utility!")

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

#229

Post by sneak »

AnthonyMouse wrote: post #142
sneak wrote: post #118

Earlier quoted context omitted.

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.

That's their business, and their decision if they're the ones doing the work. You can always simply not use that big interdependent blob, same as ever. I'm not sure what the problem is.

I recently installed a Gentoo system with ConsoleKit and KDE Plasma, and it works great, not a trace of systemd anywhere. I also understand the original Gentoo guy forked Gentoo and made a new distribution (Funtoo) where systemd isn't a configurable option even if you want it - it just doesn't exist in that distribution at all, as far as I know. In normal Gentoo you can use OpenRC (default) or systemd.

AFAIK Gentoo also supports Gnome with just logind, too. Haven't tried out that config.

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

#230

Post by gjvc »

riskyfive wrote: post #140
Nextgrid wrote: post #124

Earlier quoted context omitted.

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?

It's unpopular. It has funding. No other project in the space has funding, so it wins by default.

Exactly. This is the measure of the situation. Well put.
Post reply on HN