Live data from Hacker News

Knoppix 8.6 abandons systemd

techrepublic.com

161–170 of 191 posts

Re: Knoppix 8.6 abandons systemd

#161
I wish systemd would just die a fiery death. Every two years I replace my environment - by design, to force growth. I've been doing this on Linux since 1993. In my most recent go-around, I hunted for a Unix distribution that could meet my needs, and played with: Void, Solus, Manjaro, Fedora, Tumbleweed, TridentBSD, and GhostBSD. Heck were there docker support on *BSD I'd be back there happily for the first time since 2001.

SystemD needs to die because it violates Unix principles, not because of it's new key combinations. Unix is built on the notion that everything is a file, and that purpose built binaries make sense. SystemD breaks the latter - meaning it's now significantly more work to do the same things when it comes to log investigation, service analysis, and related events.

Perhaps the worst part is the extension of a subsystem for service initialization to everything other than that. The folks at suckless (https://suckless.org/sucks/systemd/) did the argument significantly more justice than I ever could.

Re: Knoppix 8.6 abandons systemd

#162

Earlier quoted context omitted.

> Wayland is nearly vaporware Fedora has been defaulting to Wayland on fresh installs for at least two or three releases and generally it’s working okish. There’s still a lot of software lacking proper wayland support, though.

Does single window screen sharing work yet? Perhaps it's just me but I haven't found an xorg problem in my life that's fixed in wayland but I've had a few problems in wayland that don't exist in xorg. My display needs are rudimentary though, so perhaps I'm not the target audience. Putting wayland aside... is exactly what I've done. I don't need wayland, so I don't use it. With systemd, not only do many of us have pro…

Haven’t tried screen sharing, but wayland does fix problems. Mixing HiDPI screens and regular screens (think: laptop/desk screen) without having lego-block-sized pixels on at least one of them. Sadly apps without wayland support don’t support that properly yet.

Re: Knoppix 8.6 abandons systemd

#163

I am a bit surprised that they (seemingly? not clear in the article) went back to sysv init rather than exploring other options. I assume they just wanted to go back to something with which they were very familiar (and for which they probably already had scripts). But after going to void linux, I've found runit [1] to be an excellent init system. I was able to sit down and read the documentation in under an hour and…

Knopper wrote his own init system called "knoppix-autoconfig" according to DistroWatch. [0] That information is not included in the release notes, though. [0] https://distrowatch.com/index-mobile.php?distribution=knoppi...

Not really.

From this German article[0]:

> Knoppix' Startvorgang läuft nach wie vor per Sys-V-Init mit wenigen Bash-Skripten, welche die Systemdienste effizient sequenziell oder parallel starten.

> Knoppix' boot sequence still uses Sys-V-Ini, with some bash scripts which start the system services efficiently sequential or in parallel.

So it has still all the downsides of sysvinit, except that might start sevices in a more efficient order or some in parallel.

[0]: https://www.golem.de/news/live-linux-knoppix-8-0-bringt-mode...

Re: Knoppix 8.6 abandons systemd

#164

I wish voidlinux gained more attention from the community and got adapted to serious production stuff. It has all the good elements on paper except the maturity and user base.

What are the benefits of void in production compared to Alpine?

I always considered Alpine to be that slim OS image that is used as Docker containers. I have never considered it as a serious bare-metal host. May be it is indeed better than void for that purpose.

I wrote about void because it “felt” like the philosophy of BSDs in the Linux land. Which is quite a draw for me. Binary packages, up-to-date kernel, and a sane init system felt fresh and in KiSS realm.

Re: Knoppix 8.6 abandons systemd

#165
post #98
post #93

Earlier quoted context omitted.

> When I want to write a script that runs on startup, I expect that I can just put (or link) it in some directory where the scripts are that get started on startup This is not very specific, have you never had any race-condition with this? There is a reason SystemD ask some informations regarding the service that needs to be launched. I don't see how ignoring those makes a good argument against SystemD.

Many simple systems don't do parallel service startup like systemd, if that is what you mean.

They mean that you can specify dependencies. So start some service Y only after X has been started. I use this extensively in my home automation services. Can't start other services if the MQTT-Server hasn't started and that isn't done until the network is initialized.

Re: Knoppix 8.6 abandons systemd

#166
post #95

Earlier quoted context omitted.

I think you are missing the point: Something like systemd has a good reason to exist. But the devil is in the creating team. We've seen pulseaudio, a good system in theory, but an untrustworthy unstable system in practice. And if it wont work, it is so complicated and non-transparent that you need a specialist. Taking a step backward from Alsa is hard, and they managed to do it. Now that same team is messing with sys…

Pulse has been fine for ... I dunno, a decade or so now. I remember when it was problematic, and then one day I discovered I could do things like send sound to other computers, control different applications independently, turn on bluetooth headphones and just have them work. All the sort of things you'd expect a modern sound system (which ALSA certainly is not) to be able to do without having to edit configs or what…

Yeah so good that alternative are in the work ? See https://github.com/PipeWire/pipewire/wiki

Pulseaudio is in the same park as SystemD today. It works as long as you don't demand too much of it and don't stray from whatever they deem to be The True Path. It is better for your simple needs. Believe me, those who have advanced professional needs don't think highly of it.

The support for this systems come from people that just use it as packaged and don't have specific needs. Which would be fine IF they weren't getting in the way when you really have specifics needs.

Even if some of the concepts are sound, execution is terrible. As the saying goes, the road to Hell is paved with good intentions.

Re: Knoppix 8.6 abandons systemd

#167

Earlier quoted context omitted.

Honestly there have been zero angry sysadmins in the picture. Actually very few if any sysadmins in the picture since 2016. Anything I touch that requires sysadmins is outsourced one way or another, either via managed services like rds or in house dbas. If aws or in house dbas have strong opinions about systemd it doesn't impact me.

Yea, sysadmin is a shrinking job field. Dev ops is eating heavily with what they used to do with config driven management of servers be it kubernetes, docker, terraform, puppet, etc.

Some one is administering the system. Whatever its title. The grip I hear from those who _do_ (and I agree with them) administer SystemD servers (note I did not say desktop here) is that when it fails, it is often very hard to debug because of too much implicit and hardly documented.

Re: Knoppix 8.6 abandons systemd

#168
post #125

Earlier quoted context omitted.

> It's complex because it does a complex work Hence it's pointless because it doesn't make things any simpler. All it does is making things monolithic and wrapping concepts that are perfectly fine by themselves, forcing third-party software to write to systemd's APIs. > Systemd actually does ONE thing and does it well: it manages the system. "Managing systems" is not what is meant by "doing one thing, and doing it we…

> Hence it's pointless because it doesn't make things any simpler. That is exactly my opinion too. Systemd managed to replace the nasty cruft pile that was SysV init with something even less transparent, more confusing, clunkier to use, and with a steeper learning curve to do simple things like add or change a system service. There is too much to list, but let's start with the beginning: why name one of the most comm…

I agree. However, let me help you: there is a way to bypass that problem by defining shell wrapper function with names that you like in .bashrc.

Re: Knoppix 8.6 abandons systemd

#169
post #77

Earlier quoted context omitted.

The list in the Linux desktop world is honestly pretty long and could be extended at will. Some examples: Wayland, GNOME 3, KDE Plasma, Nvidia drivers, PulseAudio, DBus

Wayland is nearly vaporware, gnome 3 is optional, kde plasma is optional, nvidia drivers are optional and have functional FOSS replacements, pulse I'll grant you (and hope you see the irony) and dbus I can't honestly comment on because the little direct interaction I've had with it was fine but mostly I don't think about it. The flaw with your list is that half of it is optional and anyone who doesn't like those thin…

Why do you think Wayland is vaporware? The concept, protocol, reference implementations are clear, done, the development of protocol extensions are chugging along nicely, and clients are shedding their legacy layers year-by-year (release-by-release). It was never going to be a quick and dirty hack.

Sure, you can use XWayland and just call it a day, but that doesn't really help.

The reality is that exactly due to the enormous legacy baggage of the "X ecosystem" it's not easy to just switch "to Wayland". GTK, Qt, and (again, due to the required hacks) all major apps (eg. Firefox) have to do serious work (as in finally implement something sane, now that it's an option) to work.

DBus is okay. Though bus1 might be an improvement, and having it in kernel would be a bit more efficient (zero copy, better security, etc).

Re: Knoppix 8.6 abandons systemd

#170
post #90

Everything I know about systemd is bad. When I want to write a script that runs on startup, I expect that I can just put (or link) it in some directory where the scripts are that get started on startup. Or that there is one main script that calls all scripts that are intended to be startet on startup. I do not want to write a "service" that has some "only run once and then discard" flag or whatever. When I want to lo…

> When I want to write a script that runs on startup, I expect that I can just put (or link) it in some directory where the scripts are that get started on startup. Or that there is one main script that calls all scripts that are intended to be startet on startup.

AFAIK, systemd is compatible with sysv init scripts.

> I do not want to write a "service" that has some "only run once and then discard" flag or whatever.

Why? Writing one isn't so complicated.

> When I want to look at logs, I want to use the tools I like. less, grep, tail etc. I do not want to dabble with some binary format and its tooling.

Well, nothing prevents you from piping output from journalctl to whichever tool you prefer. In fact, people do it all the time.

> When I want to start or stop a service, I want to call a script that does that. A script which I can look at and see what it does. Like /etc/init.d/apache2. I do not want to execute some magic command like "service apache start" which I have to guess or look up and which gives me no clue about what it does.

I don't see how sysv init is any better than systemd in this regard. You'd still have to look at indidual scripts to see what it does. It's not like systemd hides the contents of the service files.

Post reply on HN