Live data from Hacker News

Linux distros without systemd

ungleich.ch

201–210 of 449 posts

Re: Linux distros without systemd

#201
post #178

Earlier quoted context omitted.

Earlier versions of systemd were fairly buggy, but then it was still in its infancy and its in a much better state now. systemd (not SystemD) changes a core part of the OS, we go from a userspace being bootstrapped by a bunch of different shell scripts calling a dozen individual binaries, to an actual system and service manager configured with unit files. It's a large change, although one other operating systems went…

By that standard SystemD proponents' fetishization of ineptly implemented change for change's sake clearly makes their position invalid.

Why on earth do systemd haters insist on capitalizing the D? It's really amazing how people think mistyping the name is some kind of useful or novel criticism of the software.

Re: Linux distros without systemd

#202
post #168

Earlier quoted context omitted.

All of those issues happened with SysV init, as well — there are literally decades of history of people working around things like unmounting failed filesystems, watchdogs to kill -9 hung daemons, etc. For example, you mentioned crond startup before the network but that's hardly new with systemd — checking the oldest system I have access to shows that it's configured with two dependencies: “# Required-Start: $local_f…

it's the non-determinism that's the problem as I said, I can fix the issues one by one as I notice them, but if they only occur 1 boot in 10, or maybe 1 in 100 it's miserable and a much less reliable system than before but hey, the systems now boot 2 seconds faster (if they boot at all...)

Again, you already had a problem. It might not have been as obvious because it was enough slower to avoid the race condition under normal circumstances but I’ve hit those problems many times over the years.

Re: Linux distros without systemd

#203
post #3

Alpine is great. I have nothing against systemd but Alpine stands on it's own for containers and VMs. I haven't given it a try on baremetal but I imagine it does just as well there. Not really desktop focused but if you want to run it with a GUI on a laptop it's technically possible.

I've actually tried it on my new notebook a few days ago, it runs quite nice: https://www.nico.schottelius.org/blog/alpine-linux-on-the-hp...

Quite nice...?

>checkout why the firefox package is broken

You call that... nice?

Re: Linux distros without systemd

#204
post #198

Earlier quoted context omitted.

D-Bus, as discussed elsewhere in this thread (where I learned about this, too), is a specification rather than a concrete implementation. Are you asserting that systemd does not work with alternative D-Bus implmentations? That would be weird, seeing as how they wrote an alternative one... Also, since I've been "reading more", and I can check after I get back from lunch--at least at some point Debian shipped systemd w…

> Are you asserting You need to stop constructing straw men, too. I asserted what I actually wrote. And Lennart Poettering asserted that > D-Bus has been a core component of Linux systems since more than 10 years. and > D-Bus refers to both a specification, and a reference implementation. back in 2015. I suggest that instead of arguing fallaciously about something that you tell us you have only just learned about, th…

Asking for clarification isn't a strawman, sorry. And it sure seemed like you were correcting me, which is why I asked. But I said that journald was the only mandatory component of systemd outside of PID1. You said this was wrong. I'm waiting for you to extrapolate? Does systemd only work with the "canonical" dbus-broker? Or does it want ("want" as I'm reading stuff that suggests it isn't absolutely required, but I'm not sure and I'm happy to caveat where I'm not sure) a D-Bus broker? Because if it's the latter, and as it's specified and they seem big on meeting specs I'm betting that it's the case, then what I said is correct and you're just being kind of a jerk about it.

Or you can keep trying to big-time me instead of engage on the merits of your position. That's cool people stuff, I guess.

Re: Linux distros without systemd

#205

Earlier quoted context omitted.

Most of the problem I have it is with the imperialistic culture that came with it and with the serious security bugs that they keep sweeping under the rug. It is easier to configure and is convenient to have one holistic system in a lot of ways, but... They pushed for Gnome to have a hard dependency on it so that everyone would be _forced_ to use it instead of just letting it be accepted by merits. They have a track…

> They have a track record of labeling serious bugs as non-issues, ignoring them, or just not filing them as CVEs. Serious issues keep coming up. Additionally, this is not likely to stop, since they took an init system that was (mostly) written in a memory-safe language (bash) and rewrote it in a memory-unsafe language (C++), thus enabling a whole class of systemic security issues that will keep popping up in the fut…

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.

Re: Linux distros without systemd

#206

Earlier quoted context omitted.

Most of the problem I have it is with the imperialistic culture that came with it and with the serious security bugs that they keep sweeping under the rug. It is easier to configure and is convenient to have one holistic system in a lot of ways, but... They pushed for Gnome to have a hard dependency on it so that everyone would be _forced_ to use it instead of just letting it be accepted by merits. They have a track…

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…

> addresses the complexities of a modern system in the simplest fashion but no simpler

I have a serious contention with the statement that systemd is the simplest possible solution for this problem. Especially since it involves not only service management, but user logins, a data bus, logging management, file system mounting, initd, and a host of other things.

Are all of those pieces necessary? Arguably yes. But not all in one system(d).

Re: Linux distros without systemd

#207

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…

Agreed, I very much like systemd. The documentation could be a bit better (though I haven't looked at it much in the last year), but overall it's a good improvement.

I first started using systemd with Arch before it got pulled into Ubuntu. It definitely took a little bit to get used to, but once you understand how to write services instead of cron jobs, it's way more betterer.

Re: Linux distros without systemd

#208

Earlier quoted context omitted.

> They have a track record of labeling serious bugs as non-issues, ignoring them, or just not filing them as CVEs. Serious issues keep coming up. Additionally, this is not likely to stop, since they took an init system that was (mostly) written in a memory-safe language (bash) and rewrote it in a memory-unsafe language (C++), thus enabling a whole class of systemic security issues that will keep popping up in the fut…

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.

I'm not such a lover of Go, but: non-sarcastically, Go may well have been a good choice.

Re: Linux distros without systemd

#209

Earlier quoted context omitted.

Most of the problem I have it is with the imperialistic culture that came with it and with the serious security bugs that they keep sweeping under the rug. It is easier to configure and is convenient to have one holistic system in a lot of ways, but... They pushed for Gnome to have a hard dependency on it so that everyone would be _forced_ to use it instead of just letting it be accepted by merits. They have a track…

> They have a track record of labeling serious bugs as non-issues, ignoring them, or just not filing them as CVEs. Serious issues keep coming up. Additionally, this is not likely to stop, since they took an init system that was (mostly) written in a memory-safe language (bash) and rewrote it in a memory-unsafe language (C++), thus enabling a whole class of systemic security issues that will keep popping up in the fut…

Bash is memory safe until you run 'rm -rf $DIR/' when DIR is unset.

Let's just say the language choice went from bad to equally bad.

Re: Linux distros without systemd

#210

I mainly use FreeBSD, but I have a number of Linux VMs that I use where appropriate. The big thing, for me, that systemd brings to the table is consistency. Managing services on CentOS is the same as managing them on Debian which is the same as managing them on OpenSUSE. This makes it a lot easier to deal with the various different Linuxes. Also, it seems to make writing a service a lot easier. Instead of the service…

> Managing services on CentOS is the same as managing them on Debian which is the same as managing them on OpenSUSE.

It's not really the same, some systemd-based distros diverge a lot and anything non-systemd much more so, including FreeBSD. Even something as basic as network configuration could be completely different on systemd distros, like Ubuntu with its netplan weirdness and Archlinux going into the opposite direction and forcing you to choose how to deal with network yourself from the start.

But still, if you want any sanity in your deployment across different distros - you simply have to avoid using systemd or other host's init and service management systems for anything and bring your own service management with you. It could be as simple as a script starting from root's cron at @reboot (this particular trick survived for decades for example).

Post reply on HN