Hacker News Reader

Arch is primarily a systemd distro.

I think it sounds like you should seriously sit down and think about why don't you want systemd, but answer some other questions first. You're running windows with all of its telemetry and longstanding security and performance issues but a different init system on Linux is holding you back? That doesn't seem right, I would sit down and honestly think about what you're trying to accomplish with your machines and why. And why does linux vs windows help vs hinder that goal? Then why does glibc or systemd hinder that goal?

I think most people's objections to systemd sound similar to google's objection to systemd. Their objection amounted to "complexity in PID 1" and security. Around the same time they pushed android binder into the kernel, which is just yet another reimplentation of IPC. That spawned some very serious security issues. If they really didn't like the current IPC systems, they probably could have (and should have) implemented one of them on top of AF_UNIX sockets in userspace. So at the end of the day, they apparently don't take "security" as seriously as their objections to systemd would have you believe. What it really boils down to is that they don't like the piece of software for some vague hard to define reason. Ok sure, but that isn't going to help you accomplish your designs since it doesn't inform you on what direction your design should go. I would try to articulate why I don't like it very precisely, and then back it up with data. I can make that argument for windows for example. If I can't do that then my objection was probably emotional and irrational.

I compared systemd vs. OpenRC code size in another post, but here is Musl vs glibc code size:

  $ git clone git://git.musl-libc.org/musl; cd musl
  $ wc `find . \( -name \*.c -o -name \*.h \) -print`
    [...]
        7      11      94 ./src/unistd/_exit.c
    104637  330017 2883975 total

  $ git clone https://sourceware.org/git/glibc.git; cd glibc
  $ wc `find . \( -name \*.c -o -name \*.h \) -print`
    [...]
        49      216     1647 ./wctype/wctype_l.c
   1389414  6823487 52867225 total

So 104,637 lines vs 1,389,414 lines. There are more human programmers on this planet who can audit 104,637 lines than can audit 1,389,414 lines. What is glibc doing that is so terribly useful that it needs to be 13 times the size of Musl? It's just standard GNU bloat. And why does GNU awk (gawk) need to add network socket programming support? Isn't this beyond the scope of what awk does well and does best? Keep adding features, keep increasing the attack surface....

Do you think a manual audit of 100k lines of code will uncover multi-threading or memory issues or any other security issue?

Experience has shown that for c code for the first two, no it won't. And for any language code, manual audits won't find issues in the last category either. It may help, but it won't excise them all (or even close to all). To get them out, you need real world testing. The system that sees more real world usage, probably gets more testing. Any security analysis would want to take this into account also.

My earlier point about "what do you want to get out of your systems" is that you alluded to the reliability of debian being desirable. Distro maintainers by and large switched to systemd since it saved them a ton of work. They could then spend that extra time on the rest of the activities of being a distribution. So debian could focus on being more debian-like instead of debian-like + maintaining a creaky init system. So if what you want is debian, and you see very few distros like it that also don't have systemd, think about why and if what you're asking is detrimental to the other goal of what you want.

FWIW, I've maintained embedded linux distros at a couple companies, at my most previous employer we used systemd, the current one we don't. It isn't the right choice in all scenarios, but it is a lot of the time.

From what glibc developers have told me, glibc supports a huge number of systems, and a lot of the "bloat" in glibc comes from supporting various architectures and operating systems accumulated over the last 30 years. In general, code is not deposited in glibc at random, so somebody did see a good reason to do whatever it is at the time it was done. Musl is nice but it's not a strict replacement for glibc in all cases, and the musl developers seem to be pretty honest about that, for example here: https://wiki.musl-libc.org/functional-differences-from-glibc...

Also in my experience, the attack surface cannot be strictly reduced by removing features -- if users want a specific feature, they will just get it from something else, so at some point one needs to have code on the machine somewhere that does it.

ofubd8kc: Right, so straight and such superficial comparisons are wrong for this reason. Most of the glibc code isn't used for any given compilation. Similarly for systemd, most of the code is being compiled into binaries outside of systemd-init, for things like systemd-networkd. Whether or not systemd-networkd should just be a separate git repo is a good question, but it isn't really relevant. A similar question would be should glibc carry around support for these other systems?

Similarly, for systemd-init, the comparison should be, the other init system + all the code for the init scripts + all the code for all the utilities that are called inside the init scripts not counting the program being started. You should be looking at the system as a whole, not just a part of it.

I can’t firewall systemd from making network socket calls. So, YEET!

Artix and Devuan, it is.

I'm not sure what that means or how the second statement follows. You can't firewall the kernel from making network socket calls either, because the kernel is what implements the firewall. Of course the service manager is going to have higher privileges than every other process on the system, because it has to supervise all the other processes.

systemd makes various network socket calls.

Like DHCP

Can you expand on this? Systemd doesn't make network calls, so presumably you mean services started by systemd, which there exists an API specifically so you can do things like start a firewall before the network is brought up.

One word, DHCP.

The article has somewhat of a clickbait title. The bug was actually in polkit, which is available on every single one of those distributions you mentioned, and is a dependency of a bunch of other low-level daemons. It happens to be an optional compile-time dependency of systemd, but a distro can ship a version with polkit disabled and just use sudo, if that's what was wanted.

WSL is probably very similar to other containerized Linux scenarios, where you might want a small init to function as a sub-reaper within the container. I don't think that is much of a specialized case at all, as far as inits go anyway.

Don't forget about Void Linux.

I use it daily and it's a pleasure.

It baffles me that Void is so obscure. It's everything good about Arch, plus a better package manager and larger repositories and no systemd. I even put in on my appliance Raspberry Pis because they boot in 4 seconds.

However it is rolling release which it sounds like OP doesn't want.

Slackware, Void, GuixSD, MX Linux, PCLinuxOS, GoboLinux, and CRUX are some of the more well-known Systemd-less distros. There's also all the BSDs.