Live data from Hacker News

Systemd, ten years later: a historical and technical retrospective

blog.darknedgy.net

321–330 of 458 posts

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

#321
post #259
post #176

Earlier quoted context omitted.

> Since the kernel's idea of "a login session" is wrong (it only includes text-terminals), and it can't easily be changed for compatibility reasons This is a CADT attitude. Improving existing interfaces while maintaining compatibility is hard; it's also what makes the difference between a serious software professional and an incompetent vandal.

I agree it would be nice to fix this in the kernel instead, but as the article said, it might not be possible due to compatibility constraints. The fact that the logind developers came to a different solution than you, after spending much more time thinking about it and actually implemented it, doesn't exactly imply logind developers are the ones with an attention deficit, or that logind is bad. ("CADT" apparently me…

> Also, never call out others as "incompetent vandals" if you think of yourself as a "serious software professional". This is the kind of toxic behavior that makes communities non-inclusive and leads to impostor syndrome.

I want to exclude incompetent vandals from the software community; they are impostors.

Some people consistently make bad decisions. Some of them can change, but others cannot. I do not want the ones who cannot or do not learn to make good decisions to make decisions which affect me (I acknowledge that I myself may be one of those people!).

Quality matters. Reckless vandalism matters too. Breaking nohup was and is indefensible.

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

#322
post #301

Earlier quoted context omitted.

Lennart and the systemd team did exactly that 10 years ago. Why can't you? The code is there for someone with enough skill to show how bad systemd is right?

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

> It would be impressive if Lennart managed that by himself. Red Hat wanted it done

RedHat wanted it done once Lennart convinced them it is the right thing to do and Lennart put in the effort to be at RedHat at the right time to have the ability to convince them.

In fact Lennart is one of the few people willing to put in the effort to touch the fundamental building blocks that otherwise rot, but nobody is willing to touch.

> Projects like Gnome were Red Hat is by far the biggest contributor

Yeah, I guess it's not that bad that in FLOSS, the people willing to ultimately sit down and put in the time and effort to actually write the code, even the non-sexy bits, get to steer the project over Hacker News commenters.

That's not the worst outcome out there if you ask me.

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

#323
post #14
post #5

I think this really sums this article up: > One thing I’m certain of is that this shift cannot emerge from dilettantes, outsiders and proverbial basement hackers. One does not unseat a platform without already being part of the patriciate that calls the shots on what gets integrated where across the largest nodes in the ecosystem. It’s a long, turgid “why wasn’t I consulted?” complaint which really just comes back to…

Voting share ? There is no vote unless you work for RH. And even then. 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…

> Funny thing.. most of those on teh internets who are vehement in favor of systemD don't know much about how a computer system boots and what goes into that.

Why can't you have a discussion without childish insults?

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

#324

Earlier quoted context omitted.

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.

And why do you think that is?

It's because systemd offers convenient functionality that those dependent packages want to hook into, because previously they were either maintaining all that themselves and seriosly lacking the manpower to do so or it wasn't being maintained at all and just rotting, (i.e. consolekit)

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

#325
post #129

Earlier quoted context omitted.

You don't want to use sqlite for logs -- it is way too complex, and in particular, it may roll back (=lose log entries) if it is low on space, and permanently damage data when writing onto disks with errors. It also makes wrong performance tradeoffs for logging -- your choices are either sync() all the time, or roll back on unexpected termination. I don't like the that journald goes backwards in space and updates ind…

Sqlite is battle-tested though, it has one of the most comprehensive test suite and is used on billions of devices already. What systemd is doing with this log storage system is reinventing sqlite, because systemd has a fairly new and not battle-tested database implementation, it has shortcomings. I would argue that either they use plain text logs like before or use sqlite but they should not reinvent a new db.

> Sqlite is battle-tested though, it has one of the most comprehensive test suite and is used on billions of devices already.

That's great, but you've completely ignored theamk's argument that sqlite is the wrong tool for the job.

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

#326
post #196

Earlier quoted context omitted.

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…

> This is not true in any way. Gnome still works on non-systemd systems but you have to install elogind. elogind is a stub piece of systemd and systemd refuses to make any commitment to maintain compatibility. It's like saying that windows programs work on Linux, you just have to use wine - it's sort of true for now, but it's not something you can rely on. > And, there were valid technical reasons to have gnome depen…

> elogind is a stub piece of systemd and systemd refuses to make any commitment to maintain compatibility.

You do realize even the Linux kernel doesn't make any commitments regarding API stability, right?

That's kind of an explicit choice to allow the maintainers to move forward with the limited resources they have without too much red tape.

There's always *BSD, if you want compatibility back to the Sun days in some cases, (Win32 is another option). Linux is about being as modern as possible without having to worry much about backwards-compatibility and all the cruft that comes with having to maintain that.

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

#327
post #90
post #53

Earlier quoted context omitted.

The entire repo is a big ball of mud. No one knows which parts can be removed without breaking things. Heck, the author of this article couldn’t even find a design doc or adequate manual for the init part of the train wreck, and it’s been in development for ten years .

Just set ENABLE_RESOLVE=0 when compiling and resolved is gone?

> Just set ENABLE_RESOLVE=0 when compiling and resolved is gone?

From HHGTTG:

"But the plans were on display …"

"On display? I eventually had to go down to the cellar to find them."

"That's the display department."

"With a flashlight."

"Ah, well, the lights had probably gone."

"So had the stairs."

"But look, you found the notice, didn't you?"

"Yes," said Arthur, "yes I did. It was on display in the bottom of a locked filing cabinet stuck in a disused lavatory with a sign on the door saying 'Beware of the Leopard.'"

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

#328

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…

I hear that a lot. It's not my experience. Setuping services has been a pain for 15 years for me. Then with systemd it was suddenly easy. Detractors keep repeating systemd sucks, but that this point, Debian and Fedora apparently decided it was good enough. And I never heard an end user complain. I've stopped to be open to convincing.

The article did a good job articulating that the "end users" of an init system aren't sysadmins, they're distro maintainers. If most distros have switched then it must make things better for them.

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

#329

Earlier quoted context omitted.

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?

Except you seem to have forgotten the other big reason was that basically nobody was actually maintaining ConsoleKit at the time at it was a horrible, insecure mess when logind replaced it.

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

#330

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…

I hear that a lot. It's not my experience. Setuping services has been a pain for 15 years for me. Then with systemd it was suddenly easy. Detractors keep repeating systemd sucks, but that this point, Debian and Fedora apparently decided it was good enough. And I never heard an end user complain. I've stopped to be open to convincing.

> Debian and Fedora apparently decided

That's not how I remember it. Fedora was pushed to adoption (thread starter characterises it as an internal "power play"), and Debian was presented a fait accompli (article summarises Russ Allbery with "[not] systemd-vs-the-alternatives, but how-much-of-systemd").

> And I never heard an end user complain.

This is ridiculous! I can also claim the world is always dark when I shut my eyes.

Linux mailing lists are full with complaints. A recurring one was an error message that suggests running a command as remedy, only for that command to also error out. (The remedy was formulated wrong.) By then, systemd already had a version number in the hundreds.

Post reply on HN