Live data from Hacker News

Linux distros without systemd

ungleich.ch

421–430 of 449 posts

Re: Linux distros without systemd

#421

Earlier quoted context omitted.

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…

To start off with: Maybe I'm not on the same page, but your tone feels quite aggressive to me right now. I'm not telling you that you're wrong for choosing to use the software that you use. This isn't a flamewar, I'm not trying to tell you to do different things. I'm just explaining why the OP's criteria for an init manager don't apply to me.

It's also 3am my time, and I've had quite a bit to drink. If anything in my post comes off as aggressive, please let me know and I'll edit it in the morning.

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

No. OpenRC is very happy sitting on top of busybox init instead of sysvinit.[0] When I encountered problems with my gentoo system built on musl (instead of glibc, #1 source of problems) and busybox (instead of coreutils #2 source of problems, and sysvinit #3 source of problems) they got fixed. A major part of why OpenRC is what it is is to prevent reinventing sysvinit/busybox's wheel.

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

Security is a concern on all of my systems, however, I do not agree that logind/consolekit add any security (at all) to most systems, or that they add substantial security to a small minority (say 5%) of systems. I would wager that 95+% of all linux systems are one of the following: A) no one is permitted access to any hardware, (video/sound/input) (headless systems, ie server farms, multiuser systems in a university, etc) B) single user account systems, (ie, my laptop. If someone has write access to my .bashrc file, they might as well have root access, and consolekit/logind can't bandaid anything by limiting access to my video device hardware) or C) hpc compute farms. (where the assumption is that all processes have god given write access to the GPUs) In the first class of systems, consolekit/elogind do not add security because all accesses are blocked, (in fact, the existence of consolekit/elogind simply expands the attack surface, making it less secure) in the second class no security is added because the video card is a more difficult attack vector than editing all the common home scripts, in the third class no security is added because whitelist-asterisk-to-video-card is the only sane configuration policy.

logind/consolekit are super awesome for eg educational institutions which have computers with multiple seats. Have four schoolchildren sitting at four monitors and four keyboards attached to one desktop computer? Sweet. (actually most schools use chromebooks now, which last I checked uses OpenRC) It's great that projects like consolekit/elogind exist to support those groups. But pretending like that's a common usecase, or pretending that sysvinint can't support those usecases- stop.

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

This statement is, at best, disingenuous. If you want to install Gnome on Gentoo, you need to do one of two things: install systemd (Gentoo supports systemd as a first.point.five class citizen (my terminology))[1] or install elogind. elogind is a Gentoo specific forked version of systemd with everything that is not logind-related removed.[2] This code is still all upstream systemd code, and there is not a meaningful path towards an independent fork, the way busybox init exists independently of sysvinit, or syslog-ng exists independent of syslogd, or xorg-x11 exists independently of XFree11.

The fact that non-systemd installations of Gnome can possibly exist on Gentoo is a result of Gentoo developers going above and beyond the call of duty, despite barriers placed by the systemd team. And non-linux posix systems, eg FreeBSD - forget it.

> It's also not like the GNOME devs are stupid and got tricked into depending on logind or something.

I have nothing but respect for the Gnome team. I never implied anything of the sort. I am disgusted by your insinuation. Please walk this statement back.

I think that many of the things that the systemd monolith has to offer are valuable. If systemd were a federated constellation of small daemons speaking a reasonably stable API that didn't all have hard dependencies on each other, I would probably be quite happy with it. The problem - again - with systemd is the unforgiving, colossal monolith. I don't have the privilege of dipping my toes into the good parts without having to swallow whole the bad parts. And the bad parts are disgusting. (this is the same problem I have with Microsoft Windows) Modularity is a good thing; systemd is the antithesis of that.

[0] https://wiki.gentoo.org/wiki/OpenRC#Replacing_init

[1] https://wiki.gentoo.org/wiki/Systemd

[2] https://wiki.gentoo.org/wiki/Elogind

Re: Linux distros without systemd

#422

Earlier quoted context omitted.

Are you saying something in C++ is preventing you from issuing that 'rm -rf' command?

He is saying that Bash can also cause catastrophic behaviors by an as simple mistake as unsetting $DIR. C++ at least reject to compile when a variable is not set.

Any language can cause a catastrophic scenario like that. It's not a feature of the language. Not even the goal of the language to protect from something like rm -rf. The variable could have been set to empty string and C++ would just comply with what the programmer wrote (not what they meant, but that's a completely different thing).

Re: Linux distros without systemd

#423
post #118

Earlier quoted context omitted.

dbus is also a dependency though. If you are on the bus (heh) that says systemd is a hard dependency that should be avoided then dbus is also the same thing.

I agree with your logical consistency, but I'm curious: is D-Bus sufficiently specified that one could write an alternative to it? That is, is it a hard dependency or is it itself an interface? I'm not nearly sufficiently experienced with desktop Linux application development to know. ;)

Yeah it is. It is a bit complex, but it has a spec that should allow for independent implementations (AFAIK KDE has its own, for example).

Re: Linux distros without systemd

#424

Earlier quoted context omitted.

This is always the case with any new software. Things may get a bit worse before they get better. Honestly Systemd addresses the complexities of a modern system in the simplest fashion but no simpler, and that is the key. It is in the same spirit as launchd on macOS. It works well overall and end up being more portable and consistent in the long run. Hatred for it seems to come mostly out of dogma, something to be av…

> This is always the case with any new software. Things may get a bit worse before they get better. So why should I currently opt for the worse solution? Is the overall design of it promising? > Honestly Systemd addresses the complexities of a modern system in the simplest fashion but no simpler, and that is the key. What complexities does it address? I lost track of everything an init system is apparently responsibl…

I don't believe typical developers use "plain POSIX environments," whatever that's supposed to mean.

Re: Linux distros without systemd

#425
post #139

Earlier quoted context omitted.

When there was a problem with a sysvinit procedure, one could simply fix it. As a result, mostly nobody ever had a problem with it. When there is a bug with systemd, you have to fix systemd. And your version of systemd is completely different from the head, because head was rewritten last month (in a process that persists bugs) and yours is a year old. You can't just use head either, because every low level system on…

> When there was a problem with a sysvinit procedure, one could simply fix it. As a result, mostly nobody ever had a problem with it. To the extent that this isn't flat-out wrong, it's only because SysV init had so few features and so the actual patch had to go to one of many different upstreams. Having had to fix the same classes of problem in hundreds of different places like that has given me an appreciation for h…

> it's only because SysV init had so few features and so the actual patch had to go to one of many different upstreams

Yes.

Yet systemd is unfixable. The fact that it does too much was the most popular complaint at the time it got pushed into every distro... while I disagree, my main concern is that it's unmaintainable.

Re: Linux distros without systemd

#426

Earlier quoted context omitted.

> This is always the case with any new software. Things may get a bit worse before they get better. So why should I currently opt for the worse solution? Is the overall design of it promising? > Honestly Systemd addresses the complexities of a modern system in the simplest fashion but no simpler, and that is the key. What complexities does it address? I lost track of everything an init system is apparently responsibl…

I don't believe typical developers use "plain POSIX environments," whatever that's supposed to mean.

I'm not going to discuss the merits of portability or what "typical developers use". I'm questioning the idea that systemd is somehow more portable than its alternatives. That belief can only be rooted in plain ignorance of the actual situation. It has absolutely nothing to do with what typical developers use, and to that end your comment is a pointless derailment.

What I mean is that there are init systems that only require POSIX compliant APIs and as such are portable across systems that implement POSIX, e.g. GNU/Linux, BSD, Solaris, AIX...

systemd requires (in addition to POSIX) Linux APIs and is therefore not particularly portable by any reasonable definition of the word. You can use it if you are running a Linux kernel, and that's it.

Re: Linux distros without systemd

#427

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.

> People do not write million lines of code applications in bash, for a reason And that reason is that one rarely needs to write a million lines of Bash: http://catb.org/esr/writings/unix-koans/ten-thousand.html

If they'd picked Perl, they could have written an init system in one line... (hopefully, obviously /s)

Re: Linux distros without systemd

#428

Earlier quoted context omitted.

> that there is nothing there that helps me debug what is going on That's not really true. Journald is your friend. I find many of the complaints about systemd stem from unfamiliarity with its tools. The Arch Wiki gives a really nice overview of the most common usage scenarios[1] & [2], that's worth investing some time into. Also [3] is your friend. Just refusing to put any time into learning systemd and then complai…

> "Journald is your friend." With friends like these, who needs enemies?

Sure, if you live by 'ignorance is strength', I totally get your sentiment.

Re: Linux distros without systemd

#429

Most arguments about systemd will devolve into a Motte and Bailey argument. The problems with systemd are all the stuff tacked on that are mandatory, but if you criticize them you'll get people switching to try to put words into your mouth about how the init replacement is good/bad. The Motte is all the shovelware attached to systemd that is nearly impossible to detatch and the Bailey is the init replacement.

There's a lot of truth in what you're saying, but I think you have "Motte" and "Bailey" backwards.

You are right! Fortunately the sense can be easily obtained.

Re: Linux distros without systemd

#430
post #196

This anti-systemd meme is getting tiring. I generally find it is perpetuated by people who use Linux at a hobby level. Rarely do I speak with guys in Ops who dislike systemd. I am not trying to discredit people here, there are hobby users who are more knowledgeable about Linux related systems than many guys who are professionals. My point is that Linux and systemd are both meant for use on servers, in production, whe…

Hi, ops guy; Fuck systemd. Boot time: A possible 5-10 extra seconds from sysvinit is the problem here not the 5 minutes of BIOS/EFI POST time for those server boxen? Logs: Where's the storage of the log data in journalctl and what tools can I use to read that data in a small PXE rescue environment? But hot damn I didn't have to ls /var/log so that's nice. Sarcasm aside how does it make your life any easier? I got a s…

> A possible 5-10 extra seconds

> the 5 minutes of BIOS/EFI POST time

Yeah we measure boot up in seconds. If I restart a machine and it takes more than ~10 seconds to boot I send a ticket to our infra guys to figure out why the server is configured poorly/troubleshoot the slow start.

>Logs

I guess I prefer `journalctl -u service.service -f` or `journalctl -p "crit" --since "2 days ago"` to the ole `ls /var/log` and then `grep`ing

Honestly, I don't understand how it makes life harder. To me, systemd is a huge QoL impovement. Even in the most mundane tasks like `systemctl restart tomcat-*`

Post reply on HN