Live data from Hacker News

Linux distros without systemd

ungleich.ch

341–350 of 449 posts

Re: Linux distros without systemd

#341
post #8

I get no end of bemusement from open source advocates that think it makes any kind of rational sense to campaign against an open source project. THIS IS ALL OPEN SOURCE. Freedom and choice is the whole point, isn't it? If you prefer an alternative or forebear to systemd, that is great. Use it. Advocate for the system you prefer. Convince people that the choice you have made is better. Meanwhile the vast majority of d…

It's not SystemD itself that's the problem; it's just technically terrible, but, as you say, it's open source. A lot of open source software is terrible but popular. It's Debian violating their social contract that was the problem for me. What the vast majority of distributions do is irrelevant, a lot of them are chasing popularity or have a proprietary interest in having a "unified platform", but I had come to expec…

> It's Debian violating their social contract that was the problem for me.

Which clause of the social contract did Debian violate?

https://www.debian.org/social_contract

Re: Linux distros without systemd

#342

I get that not everybody likes systemd, but a lot of the criticisms seem misguided and looking at sysvinit with role-colored glasses. For example, people are complaining about logind being included, but forget that consolekit was unmaintained before that. Yes, there's parts to systemd that not everyone will use, like container support, but in that case you can pretty safely ignore that use case. For me, systemd has p…

I get that systemd works for you, and I'm not telling you (or others) that you shouldn't use it. The problem is the systemd monoculture. Wayland, Gnome etc are non-starters because they have hard dependencies on systemd, which is ridiculous.

> For example, people are complaining about logind being included, but forget that consolekit was unmaintained before that.

I use neither logind nor consolekit. These are solutions for problems I don't have. Moreover, they often get in the way: when I ssh into my media PC, I don't want logind/consolekit to tell me I'm not allowed to access the sound or video cards. The only function that machine performs is to do the thing that logind/consolekit are designed to prevent. And it's a required component of systemd.

I'm glad it's easier for you to manage services with systemd. But it's easier for me to manage services with OpenRC, and there's nothing wrong with that. As far as handling modern hardware- huh? I guess it's not clear to me what interactions an init manager is supposed to have with hardware.

Which really speaks to my primary issue with systemd: it's a freaking monster. It does nine million things, but I only need it to do like three things: start services when I tell it to start services, stop them when I tell it to stop them, and restart them if they crash. (if it's configured to do so) That's it. Why do I need or want it to interact with my hardware? Why does it need an integrated web server in order to start apache? Why does it a logging daemon in order to start syslog-ng? Why do I have to use its built in log reader instead of tail, less, grep etc? Where is the boundary between systemd and the rest of my system?

Re: Linux distros without systemd

#343
post #228

Earlier quoted context omitted.

If you run or write that command into script without checking what DIR variable contains, the problem is in your lack of experience with shell, not the language choice. Also nowadays, rm itself has --preserve-root as default, so this won't delete your root fs.

This is true if you are running the GNU userland. It's not necessarily true with other userlands that are often run on top of Linux. In a discussion touching on systemd, it strikes me as a little surprising that somebody would rely on a quirk of another replaceable component. ;)

I’m sure the irony is not lost on you regarding the fact that systemd can not possibly run on an alternative platform, thus the situation you just ascribed is not “better” with systemd.

Re: Linux distros without systemd

#345

Earlier quoted context omitted.

Memory safety is not the alpha and omega of programming languages. People do not write million lines of code applications in bash, for a reason, trade-offs are to be made. That said I agree they should have picked Go instead /s.

Sure, there are other concerns and bash is not an ideal language, but memory safety is responsible for quite a large number of security flaws, since its lack turns bugs into code execution vulnerabilities on a regular basis. I don't really have an opinion on what language should have been picked instead, though OCaml may be a good candidate.

To be fair, erlang would have been the better choice here. Memory safety, concurrency and solid error handling all in one.

Re: Linux distros without systemd

#346
post #81
post #63

Earlier quoted context omitted.

https://www.freedesktop.org/software/systemd/man/systemd.exe... and some other directives documented on the same page.

I had completely forgotten about these directives! It's things like this that make me glad systemd is a choice, honestly.

SystemD did not invent cgroups. Not only is it possible to use cgroups without systemd it is often easier for small cases and binaries can call cgroups themselves for any child processes they create.

The timing of these systems releasing does not equate to causation here. Google themselves (creators of cgroups) do not even use systemd on their own hypervisors which leverage cgroups heavily.

Re: Linux distros without systemd

#347
post #248

Earlier quoted context omitted.

> I just want my systems to boot, run my simple applications, then shutdown when I ask them to Which is what you get out of the box with systemd. The only problems you mentioned either apply equally (e.g. shutdown delays due to blocked processes — having supported NFS clients, let me tell you that was not a new problem in the 90s…) or are due to misunderstandings about how to use other components. For example, if you…

you are not listening or being are deliberately obtuse I have stated three times that I accept that these processes are incorrectly specified, and that my problem is not this -- the problem is that I cannot discover these missing dependencies by any reasonable process whoever set them up 20 years ago is long gone, and what was reliable is now not this is a regression (and let's not get started that my brand new insta…

> you are not listening or being are deliberately obtuse

Any time you find yourself writing something like that, ask whether you’ve done a good job explaining your point first. In this case, you’ve been vague about everything except that you think systemd is the source of your non-deterministic behavior.

From what little information you’ve provided, it really sounds like the problem is a combination of blaming the init system for things which happen outside of it (i.e. processes hanging) and not learning how to use it. For example, launching a networked process under cron at boot with no retry mechanism has always been a problem because cron never guaranteed networking. Using the init system would have avoided that - even on SysV.

As far as how to discover it goes, fault tolerance has lots of edge cases — e.g. try mounting NFS and firewalling the server, `kill -STOP` a daemon with a clean shutdown process, reboot without a network or DNS (i.e. like you’d have during a facilities outage), etc. — but most of it comes down to learning to work with the way the distribution is intended to be used: use the init system (whatever it is) to launch processes, enable automatic restarts for everything, configure full dependencies on everything you need, etc.

Note that none of that depends on systemd - you can get better results on everything this way, but if you do it you’ll probably gain a better understanding the systemd developers made the choices they did. If you really can’t figure out how to be comfortable with it, switching to a distribution which doesn’t use it will be much better than fighting it and getting angry when the developers don’t support hammering a screw.

Re: Linux distros without systemd

#348
post #343

Earlier quoted context omitted.

This is true if you are running the GNU userland. It's not necessarily true with other userlands that are often run on top of Linux. In a discussion touching on systemd, it strikes me as a little surprising that somebody would rely on a quirk of another replaceable component. ;)

I’m sure the irony is not lost on you regarding the fact that systemd can not possibly run on an alternative platform, thus the situation you just ascribed is not “better” with systemd.

Sure. That wasn't in favor of systemd, though? I comfortably write code against the GNU userland and I use systemd where it crops up. Just not a big deal to me; if somebody wanted to use my stuff elsewhere I'd just say "pull requests welcome!". I found the inconsistency striking, that's all.

Re: Linux distros without systemd

#349

Earlier quoted context omitted.

It's not SystemD itself that's the problem; it's just technically terrible, but, as you say, it's open source. A lot of open source software is terrible but popular. It's Debian violating their social contract that was the problem for me. What the vast majority of distributions do is irrelevant, a lot of them are chasing popularity or have a proprietary interest in having a "unified platform", but I had come to expec…

> It's Debian violating their social contract that was the problem for me. Which clause of the social contract did Debian violate? https://www.debian.org/social_contract

"Our priorities are our users and free software"

Debian ranked SystemD adoption over their users, since it broke users' computers, even though there were viable alternatives available that would have not broken these systems.

I still like Debian, but I'm not letting them (directly) near my systems again.

Re: Linux distros without systemd

#350

I get that not everybody likes systemd, but a lot of the criticisms seem misguided and looking at sysvinit with role-colored glasses. For example, people are complaining about logind being included, but forget that consolekit was unmaintained before that. Yes, there's parts to systemd that not everyone will use, like container support, but in that case you can pretty safely ignore that use case. For me, systemd has p…

I get that systemd works for you, and I'm not telling you (or others) that you shouldn't use it. The problem is the systemd monoculture. Wayland, Gnome etc are non-starters because they have hard dependencies on systemd, which is ridiculous. > For example, people are complaining about logind being included, but forget that consolekit was unmaintained before that. I use neither logind nor consolekit. These are solutio…

> The problem is the systemd monoculture.

And sysvinit wasn't pretty much a monocultur?. I mean even OpenRC is basically sysvinit with a lipstick.

> These are solutions for problems I don't have.

Good for you. But event handling is something that many systems today do need and I think we should try to optimize for the common use case.

As for you not needing logind/consolekit, sure, if security is not a concern on a system, they're not needed, but again, that's not true for most systems.

GNOME etc. also don't really have a hard dependency on systemd, they depend on logind, which does not necessarily require systemd and indeed GNOME ships on Gentoo, Void etc.

It's also not like the GNOME devs are stupid and got tricked into depending on logind or something. Mo, it solves real problems for them, so they depend on it. Why is this hard to grasp?

Post reply on HN