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

161–170 of 458 posts

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

#161

Post by josteink »

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…

> It is well understood and has been studied and critiqued by many, including me.

It seems a lot of people simply don’t want to understand systemd, and go out of their way to avoid learning anything about it.

Could that be considered a social factor?

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

#162

Post by nine_k »

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

I mostly agree with you. I see two sad things:

* Systemd was not exactly great when it had to be considered "the" replaecment for SysV init (which does suck), and happened to be much more than an init system;

* The big distros like CentOS and Debian (and then many smaller) had little choice but to adopt systemd, because Gnome had it as a hard dependency.

It's unfortunate that of all SysV init replacements, the evolution chose systemd. By its spirit, it's very anti-Linux: it's often seen as "monolithic" even though it technically isn't, because it tries to control nearly everything, and it does not mind breaking the old ways when it sees fit (and not when the old ways are broken).

Quite likely, we're stuck with it as a mainstream solution for another decade, or two, much as we're stuck with X. (And in two decades, Linux the kernel may become irrelevant, due to hardware and OS research progress.)

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

#163

Post by kelnos »

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…

> Debian, Ubuntu, Arch all chose the systemd voluntarily.

My understanding (I believe detailed in the article) is that Debian, at least, chose systemd because they were forced to if they wanted a reasonable default GNOME experience for their users. If they hadn't, GNOME would have been missing some features that would have been obvious and jarring.

You can certainly argue that they made the wrong call there, and that they should have pushed back (though arguably by the time Debian got there, that ship had already sailed), but "chose systemd voluntarily" is an incorrect simplification.

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

#164

Post by lmm »

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

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

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

#165

Post by jiggawatts »

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…

> rewrite everything in Haskell.

Yes please!

Pure functional languages are very well suited to declarative configuration, especially where you need significant flexibility not afforded by purely static "data" formats such as YAML or JSON.

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

#166

Post by kelnos »

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

I think the point is that a software platform that imposes these requirements is inherently brittle and prone to ossification.

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

#167

Post by josteink »

downerending wrote: post #72
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!

Systemd has many pluses, but simplicity and intuitiveness are most certainly not among them.

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.

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

#168

Post by nine_k »

hnarn wrote: post #154
nine_k wrote: post #116

Earlier quoted context omitted.

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.

Quoting: "Killing of user process are enabled by default in upstream but disabled by default in every distro that I know."

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

#169

Post by jacquesm »

aganame wrote: post #123
dman wrote: post #101

Earlier quoted context omitted.

As a person who does not work as a system administrator professionally but does use self administered linux machines as workstations systemd has not brought any new productivity gains but it sure has increased the learning curve.

As a person for whom Linux and BSDs have been a hobby since 1996, I have no idea what you're talking about.

A hobbyist making hiring decisions and maintaining a blacklist of professionals who bitch about a change they had no control over? You're not helping.

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

#170

Post by cycloptic »

AnthonyMouse wrote: post #157
cycloptic wrote: post #153

Earlier quoted context omitted.

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.

Yes, they did. It they didn't break it was because those inits were compatible with sysvinit scripts. You lose that once you start porting your init scripts over to rc or whatever it is you replaced your init with, and now your system will break if you try to switch to something else.
Post reply on HN