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

451–458 of 458 posts

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

#451

Post by tifadg1 »

dijit wrote: post #410
BiteCode_dev wrote: post #232

Earlier quoted context omitted.

> SystemD feels like the new grad hire who decided the first thing the would do after joining — the opening power play — is to convince the PHB we should rewrite everything in Haskell. I've seen this scenario played out, and it always fails. The product never ships, of ships in such a bad shape the users have a terrible user experience. That's not what happened with systemd. It shipped. And after a few iterations, it…

> Well, I don't care for choice in my init system. I want it to work. We Agree. > And systemd works fine for me. But it doesn't for me, and I am left with no choice but to suffer with it.

so what should be done, in your opinion, if it works very well for 51% of people, good enough for 48% and breaks the work flow of 1%?

easiest answer is to say get rid of the inter-dependencies, but that's throwing money and time at a problem affecting 1% of users, at no benefit to the rest. Maybe it's still the right answer, but who's to pick up the slack?

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

#452

Post by krzyk »

brmgb wrote: post #350
josefx wrote: post #301

Earlier quoted context omitted.

> Lennart and the systemd team did exactly that 10 years ago. Why can't you? It would be impressive if Lennart managed that by himself. Red Hat wanted it done, Ret Hat also has its hands in various open source projects that suddenly started to sprout hard dependencies to systemd. Projects like Gnome were Red Hat is by far the biggest contributor. Not much an individual programmer can do compared to a corporation thro…

> Red Hat wanted it done Red Hat had zero interest into a new init system when Lennart started systemd. They had just moved to upstart and Red Hat customers don't really care about init systems. Red Hat customers pay for their systems to be stable and to have someone to call when something goes wrong. Systemd gives Red Hat no competitive advantage whatsoever. I'm probably not going to make myself a lot of friends by…

> Cron has one of the worst configuration format ever and I'm certainly not going to miss fstab. I would find journald a step in the right direction even if the only thing it brought to the table was the ability to configure logging from the service file and not have to fiddle with logrotate.

What you don't like about cron format? It is nice, consistent. Same for fstab, the only issue I have with it that e.g. Debian doesn't handle mounting network filesystems after the network is up (there are a couple of those and it shouldn't be hard to just grep the file for those).

As for journald, as long as they keep my log files in /var/log in pure text format it can stay.

The issue I have with systemd is that it tries to fiddle with my files, last year I noticed that /etc/resolv.conf contains some strange line with local resolver, WTF? I didn't install one for sure so why (and it was breaking my network).

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

#453

Post by stouset »

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…

I had to build something on top of systemd-journald recently for work. I was prepared for the worst after hearing all of the gripes people have with systemd.

And you know what? It’s fucking awesome. Structured logging is just baked in. I don’t have to parse fields back out that have been smashed into a string. I get full timestamps, machine IDs, pid, uid, gid, and all the rest. I get a cursor that I can use to durably resume consumption of logs between restarts. Shit, the cursor even lets me ensure that I’ve consumed logs even when they’re being aggregated from multiple machines, without a single change to my code.

Sure there are a few warts here and there. Everything has them. But it took less than a week for me to be convinced that it’s past time for plaintext logs to die.

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

#454

Post by rezonant »

rstuart4133 wrote: post #415
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…

> What you are missing is that it is possible for two things to be true at once. Actually, it's possible for more than two things to be true at once. It could be: 1. It could be true sysv init sucked. (Actually, it wasn't that bad as a modular version of local.rc, but parallel and delayed startup was always just a kludge). 2. It could be true that systemd is a good init system. (For me it's a step change improvement…

> Keeping things in separate source databases with explicit interfaces is a well understood way of reducing the chances of ending up with a ball of mud.

I don't think this invalidates the thrust of your point, and I don't necessarily subscribe to the concept of monorepos, but Google is a monorepo, so senior engineers are definitely signing off on this sort of thing. Is it a ball of mud though? Actually does seem true more and more as time goes on.

Probably the biggest difference is that well-disciplined engineers utilizing monorepo do sustain those well-defined interfaces. The example of systemd-logind having no interface guarantees (cited in the linked article) is a sign of trouble.

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

#455

Post by rezonant »

cycloptic wrote: post #185
xfs wrote: post #174

Earlier quoted context omitted.

This is the kind of false argument being thrown around often in OSS discourse that ignores the structural power differential. Don't like it? Write your own/Leave. The fact is you can't go back to it as an individual, because the system has changed and as an individual you're powerless to change the situation at all, especially against an army of developers paid full-time. The latest news from Debian is sysvinit suppo…

If you can't pull your own weight and don't want to try anymore then yes, you should leave and come back when you can. Sorry if that sounds rude but this is the way it is. OSS (and software in general) has always been driven by people who are fortunate enough to have access to expensive computers and who have the free time and motivation to spend programming. You can't let what they do bother you, and there's nothing…

Before I comment here: I am a fan of systemd in many ways, and I happily use it on my systems. That being said, you do really have to think about the systemic factors at play here. As noted in the original article, Debian found itself in a position where the amount of work to sustain a non-systemd path in a systemd-dominated ecosystem would be too much work _for them_. If you personally have more development time then the entirety of the Debian project, then by all means. Let's just not assume that this is a feasible thing for a single person to handle, and really for all intents and purposes, trying to maintain a Linux distribution (or even just a personal Linux system) without using systemd at this point is folly, no matter how much you dislike it.

That being said, SysV init is (in fact) terrible. I'd say put the effort into something that can supercede systemd some day. That part of the problem is tractable, though success is quite a long-shot given its entrenchment.

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

#456

Post by rezonant »

rezonant wrote: post #455
cycloptic wrote: post #185

Earlier quoted context omitted.

If you can't pull your own weight and don't want to try anymore then yes, you should leave and come back when you can. Sorry if that sounds rude but this is the way it is. OSS (and software in general) has always been driven by people who are fortunate enough to have access to expensive computers and who have the free time and motivation to spend programming. You can't let what they do bother you, and there's nothing…

Before I comment here: I am a fan of systemd in many ways, and I happily use it on my systems. That being said, you do really have to think about the systemic factors at play here. As noted in the original article, Debian found itself in a position where the amount of work to sustain a non-systemd path in a systemd-dominated ecosystem would be too much work _for them_. If you personally have more development time the…

I do want to say that despite my comment here, seems like projects like Devuan, Void, and Arch are doing OK with this, in concert with projects like elogind and eudev etc that forego systemd while providing compatible replacements.

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

#457

Post by JdeBP »

rezonant wrote: post #455
cycloptic wrote: post #185

Earlier quoted context omitted.

If you can't pull your own weight and don't want to try anymore then yes, you should leave and come back when you can. Sorry if that sounds rude but this is the way it is. OSS (and software in general) has always been driven by people who are fortunate enough to have access to expensive computers and who have the free time and motivation to spend programming. You can't let what they do bother you, and there's nothing…

Before I comment here: I am a fan of systemd in many ways, and I happily use it on my systems. That being said, you do really have to think about the systemic factors at play here. As noted in the original article, Debian found itself in a position where the amount of work to sustain a non-systemd path in a systemd-dominated ecosystem would be too much work _for them_. If you personally have more development time the…

The person who wrote the headlined article also wrote commentary back in 2014 on discussions of systemd, which highlighted the false dichotomy that people propound that the decision is between van Smoorenburg init+rc and systemd. You are doing that very thing, years later.

That was never the case, especially so for Debian that you mention. In the Debian Hoo-Hah, the choices were van Smoorenburg init+rc, OpenRC, Upstart and systemd; the latter three being the main contenders, as was acknowledged partway through the affair. In Fedora and Ubuntu, the choice was between Upstart and systemd, Upstart having been what they used for some years before systemd.

* https://web.archive.org/web/20141222234706/http://uselessd.d...

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

#458

Post by martinflack »

rezonant wrote: post #455
cycloptic wrote: post #185

Earlier quoted context omitted.

If you can't pull your own weight and don't want to try anymore then yes, you should leave and come back when you can. Sorry if that sounds rude but this is the way it is. OSS (and software in general) has always been driven by people who are fortunate enough to have access to expensive computers and who have the free time and motivation to spend programming. You can't let what they do bother you, and there's nothing…

Before I comment here: I am a fan of systemd in many ways, and I happily use it on my systems. That being said, you do really have to think about the systemic factors at play here. As noted in the original article, Debian found itself in a position where the amount of work to sustain a non-systemd path in a systemd-dominated ecosystem would be too much work _for them_. If you personally have more development time the…

> Debian found itself in a position where the amount of work to sustain a non-systemd path in a systemd-dominated ecosystem would be too much work _for them_

Just as a side note for the interested, there is a project named Devuan that launched to keep alive a Debian sans systemd.

https://devuan.org/

(I've never run it myself; I just happen to know it exists.)

Post reply on HN