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

261–270 of 458 posts

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

#261

Post by tomatocracy »

cycloptic wrote: post #177
lmm wrote: post #164

Earlier quoted context omitted.

Systemd deliberately refused to conform to standardised interfaces and got other packages to be changed to explicitly depend on it instead (e.g. RedHat made changes to Gnome to make it break under non-systemd). This was not necessary to achieve the technical things that systemd wanted to achieve - competing alternatives (e.g. runit) didn't need that. (Though it probably was necessary to force adoption).

This is not true in any way. Gnome still works on non-systemd systems but you have to install elogind. And, there were valid technical reasons to have gnome depend on a login manager, in particular supporting multi-seat securely is very difficult without one. I should also mention that the previous "standardised interface" for this was ConsoleKit which was also written by the same developers as gnome and systemd. So…

I noticed the ConsoleKit->logind change at the time being largely justified by support for multiseat but had forgotten about it. It seems like a rather extreme case of the tail wagging the dog but perhaps I'm missing something. How many people use multi-seat in large deployments? Where and why?

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

#262

Post by phatfish »

novok wrote: post #219
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,…

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

It's tribalism and jealousy, and becomes loudest when one side perceives they have "lost" and don't have the skills to do anything about it.

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

#263

Post by sjwright »

novok wrote: post #219
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,…

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

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

#264

Post by duncan_bayne »

kelnos wrote: post #208
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.

I think this subthread is talking about the complexity of a system's implementation, not that of its user interface.

... which is as I recall, one of the main differences between the New Jersey Style and the MIT Style (per Gabriel).

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

#265

Post by rini17 »

sjwright wrote: post #250
aerique wrote: post #214

Earlier quoted context omitted.

Basically to annoy you. Yes, it's childish but also very satisfying. Do you want us to even give that up now that we're stuck with SystemD?

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.

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

#266

Post by dTal »

lorenzhs wrote: post #242
dTal wrote: post #207

Earlier quoted context omitted.

And if that's all it did, we wouldn't be having this discussion. Instead it is becoming some sort of self-appointed "userland middleware", which nobody asked for. People resent "better init" turning into "henceforth home directories will behave differently".

That's a dishonest argument and you know it. The entire home directories thing is aimed at enterprises, and nobody wants to enable it for individuals' machines. Poettering said as much in the talk where he presented it. It would be much more reasonable to respond to people who dislike systemd if they wouldn't constantly make bad-faith dishonest claims about it.

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, and a radical one at that. It is aiming to replace huge swathes of stuff that no one except seemingly Poettering believes is broken in the first place. I think distros would have been more hesitant to adopt systemd as an "init system" if this roadmap had been clear upfront.

I have heard the opinion ventured that systemd is actually a power play by Red Hat to introduce an API layer between userland and the kernel - one controlled by Red Hat. It's not implausible - as Red Hat is funded by selling consultancy services, they have a financial incentive to convert as much of Linux as possible into Red Hat Linux.

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

#267

Post by cycloptic »

vezzy-fnord wrote: post #178
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…

The problem with this straightforward thesis is twofold: firstly, distribution developers did not have any coherent position on the disadvantages of sysvinit or initscripts; secondly, the problem was mostly an iatrogenic one, as the very attempts to 'solve' or 'reform' it made things even less sustainable. When it comes to Upstart, it was almost never used except as a wrapper around initscripts. Effectively you boote…

The distro has historically always been the place that gets pointed at because they are the ones who distribute to end users. No system-level component is going to change this, ever.

I am also confused why you're complaining about the job model and all its churn and conceptual problems when the whole point is that systemd was offering to handle that for the distros, which is exactly what they did and are continuing to do now. You can claim they are doing a bad job (which is probably true in some sense because of the impossibly large scope of the task) but the previous alternative was that nothing was being done about it at all. Which you did acknowledge, but then you went back to the same criticism as before. Why? It seems obvious to me that the gritty technical aspects and/or perceptions and fears about some kind of false dichotomy are not what could have ever influenced this kind of decision. Nobody else is invested enough in it for that to have happened.

The other reality I've seen is that there is no standard way to actually implement a daemon. Nobody does it in quite the same way and using things like daemon(3) don't help. So you can choose to A. patch all your daemons, or B. you can attempt to simplify the task by writing more tooling. Every single Linux distro I've seen, when given the choice, has chosen option B. So really, I don't see anything here that is surprising or farcical at all.

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

#268

Post by deathcakes »

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…

This, exactly this - I remember one of the most bandied about reasons for the binary log format was that it made replication over the network easier, or something.

Fast forward 10 years and I still cannot find a reliable way to do this with journald, apart from forcing it to output to syslogd and then shipping the syslog logs.

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

#269

Post by rcxdude »

rleigh wrote: post #156
0zymandiass wrote: post #39

Earlier quoted context omitted.

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

> Everything else was delegated to higher levels

Read: A confusing mess of different daemons, scripts, and configuration files, which neither worked together elegantly, were simple to configure, nor were easy to debug. Before systemd I would avoid writing custom daemon configurations at all costs because when I did I would need to learn how this version of this distro did it, fiddle with the byzantine mess of scripts, and inevitibly debug multiple subtle issues, now it's basically trivial to get a new daemon running, and I extremely rarely need to debug issues (And I have had to track down systemd bugs due to obscure use cases like one systemd unit modifying other systemd unit configs at the same time another systemd unit with multiple execstart lines is running).

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

#270

Post by dTal »

a-nikolaev wrote: post #83
pknopf wrote: post #74

Earlier quoted context omitted.

I'm not seeing a lot of hope here. There is an incredible investment in systemd by distributions, there is no turning back. Help me..

Void Linux, amazingly awesome distro.

Second this, an incredible distro with an impressive package manager.
Post reply on HN