Live data from Hacker News

Linux distros without systemd

ungleich.ch

371–380 of 449 posts

Re: Linux distros without systemd

#371

Earlier quoted context omitted.

systemd errs on the safe side and thus it tries really hard to shut things down safely vs just yanking the plug. The timeouts are easily configurable if that's a problem for you, but I'd argue that if services hang too often for you, there's an underlying problem with your system somewhere, (i.e. your mounts or such, I'd consult journald for dependency cycles).

There might be some way in which I had run a system that caused those endless slowdowns. But the point is, and that's why I think systemd is garbage, that there is nothing there that helps me debug what is going on. If the shutdown is hanging there is nothing to do except the reset button or waiting for an eventual reboot. In neither case will there be any forensics about what exactly systemd had tried to do and how…

> 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 complaining about it, is one approach, but not a particularly productive one.

In your case, I'd try something like `systemd-analyze verify default.target` and go from there.

Additionally, look into /etc/system.d/system.conf, specifically adjusting the Timeout values to a less conservative value.

1 - https://wiki.archlinux.org/index.php/Systemd

2 - https://wiki.archlinux.org/index.php/Systemd/Journal#Filteri...

3 - https://www.freedesktop.org/software/systemd/man/systemd-ana...

Re: Linux distros without systemd

#372

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…

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

Thing is, though, most of those things are different systems. systemd-logind systemd, systemd-udevd, and journald (and others) are different systems in the same project. They're a bit tied together (through dbus and I'm not sure what else), but that doesn't mean they're the same system.

Re: Linux distros without systemd

#373

Earlier quoted context omitted.

One of my biggest issues with systemd is that I don't like the idea of not being able to replace pieces of it. If I don't like their logging, dns, or ntp daemons, I can't easily replace them without feeling like a second-class citizen and/or having the overhead you've mentioned. From my understanding, alternatives _could_ be written, but haven't yet and that means we currently having to ignore more battle-hardened so…

The ntp and dns are easy to replace, they're not part of the actual systemd binary. Fedora from what I remember, doesn't even enable systemds ntp service on Workstation. Logging is a bit different, but you can tell journald to use syslog.

> The ntp and dns are easy to replace, they're not part of the actual systemd binary.

They really aren't. It took us a full week of work to get dnsmasq to work in place of systemd-resolved. The problem is that they are tied in to the dhcp client and it only seems to know how to update systemd-resolved's configuration. So getting our custom search path out of dhcp was a huge pain.

I like almost every other part of systemd, but trying to excise systemd-resolved from Ubuntu 18.04 was massively frustrating to the point where I started thinking, "maybe the systemd haters are right…"

Re: Linux distros without systemd

#374

It's comical how people get so "jazzed" about something like not liking systemd and make a whole movement about it (with their t-shirts and everything). I get people may not love everything about systemd (or maybe they hate it), but I'm not convinced it's so bad. I've been using it since RHEL 7 and I've really gotten used to all of the benefits of systemd. It also doesn't hurt that I went to the session on pid 1 by L…

The simple reason is that everybody is forced to deal with it. So you either like the way it works, or you dislike it, but there's no real option to just ignore it in Linux land anymore. For a lot of people, that means that their favorite distro suddenly works in a different way.

This happens every time you significantly change something that people use and have existing workflows for, regardless of whether your change is beneficial on the whole.

Re: Linux distros without systemd

#375
post #176

Earlier quoted context omitted.

I strongly agree that git has a UX issue, and the widespread adoption of it over mercurial is a perfect example of inertia leading us to get stuck in a local minima.

I haven't tried hg but from what I've seen one major advantage of git that gets under-acknowledged is its speed. Git is fast and fast really does matter for a version control system you use constantly. Is hg as fast as git?

Git isn't really all that fast for what it is. The "git is fast" thing came about as a comparison to non-distributed version control systems, where changing what branch you were working on could involve coordinating with some (often overburdened) server on the other side of the planet.

That's not to say git is slow of course. It's just.. basically what you'd expect given it's architecture.

Re: Linux distros without systemd

#376

This list is missing a linux-ey system which doesn't use Systemd that is growing in popularity! WSL! WSL somewhat annoyingly has a custom/proprietary init system. Partially due to it's "interesting" integration with windows, and partially because it's not even really a full linux system yet. I'm curious if with the switch to WSL2 where they will begin shipping a full linux kernel if systemd will be included or will t…

> WSL I think you mean GNU/Windows, or as I've taken to calling it, GNU Plus Windows. (Seriously though, the WSL name is deceptive because it doesn't actually contain any Linux code. There is no Linux in "Windows Subsystem for Linux" )

Soon there will be.

https://devblogs.microsoft.com/commandline/announcing-wsl-2/

Re: Linux distros without systemd

#377

Earlier quoted context omitted.

There might be some way in which I had run a system that caused those endless slowdowns. But the point is, and that's why I think systemd is garbage, that there is nothing there that helps me debug what is going on. If the shutdown is hanging there is nothing to do except the reset button or waiting for an eventual reboot. In neither case will there be any forensics about what exactly systemd had tried to do and how…

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

Re: Linux distros without systemd

#378
post #353
post #346

Earlier quoted context omitted.

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.

Nobody said they did. You’re putting words in my mouth. The ease of use with 2-3 directives in a way that just works is what they brought to the table.

boramalper 8 hours ago | parent | flag | favorite | on: Linux distros without systemd

> For example, using Docker when the basic isolation features of systemd would do

Re: Linux distros without systemd

#379
post #321

Earlier quoted context omitted.

The point stands, Go isn't a good option for this type of process.

The only thing that I can think of for that 2019 Go that would be a problem for this use case is binary size. None of the rest of the usual complaints would be stoppers or even that big a deal, and most of them, I'd pay to have a memory-safe language being used at that level. Init systems are a type of code that we don't have a good word for, but that I tend to end up in a lot, the code that isn't CPU intensive, or d…

I understand there's a much more limited subset of developers for Rust or even Go vs. C/C++. Also, I recall hearing about Rust before systemd, but am not sure. Today, it would probably be my first choice. Not that go is a bad choice, I just don't think it's a good spot for it. I also agree that either are probably quite a bit better than C/C++ options.

I'm not against go, other than gc and some size considerations. Given that a lot of k8s infrastructure for the likes of CoreOS and similar are written in it, it's definitely not a bad option. I think that today, and more so in late summer as async/await syntax settles, that Rust should be a first consideration for any low-level system code.

Re: Linux distros without systemd

#380

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 currently use Alpine as my daily driver with GNOME, which is an odd mix I guess, but works nicely :)
Post reply on HN