4 ms·

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 ques

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.

egberts1 5y ago
I can’t firewall systemd from making network socket calls. So, YEET! Artix and Devuan, it is.
- zxzax 5y ago
  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.
  - egberts1 5y ago
    systemd makes various network socket calls. Like DHCP
- toolz 5y ago
  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.
  - egberts1 5y ago
    One word, DHCP.
ofubd8kc 5y ago
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....
- zxzax 5y ago
  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.html 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.
  - therealjumbo 5y ago
    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.

egberts1 5y ago

I can’t firewall systemd from making network socket calls. So, YEET! Artix and Devuan, it is.

zxzax 5y ago
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.
- egberts1 5y ago
  systemd makes various network socket calls. Like DHCP
toolz 5y ago
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.
- egberts1 5y ago
  One word, DHCP.

ofubd8kc 5y ago

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

zxzax 5y ago
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.html 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.
- therealjumbo 5y ago
  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.