Hacker News

It's not really UEFI issue, but what modules were loaded, how it was configured/wired up - and sometimes it ends up serializing on slow boot of some components (like DDR5 memory), and weird crappy add-ons from manufacturer.

On many machines with DDR5 you get the lengthy memory training every boot and that comes on top of the already long UEFI initialization time.

I dont have parallel boot enabled as well as it is disabled by default. Looking at this Systemd post triggered this thought to experiment with it one weekend. I have this laptop where I run Gentoo like a control freak. There is nothing in it other than the core system running as openrc services. So, I might play around adding readiness gates to those and see if anything at all can be parallelized.

> ... Linux boot time is so much shorter than whatever the BIOS does before it hands control over

On which system? Is your machine, for whatever reason, re-doing "memory training" everytime it boots? This is one can be really slow.

For me, it is pushing Linux in the opposite direction of the main reason why I like Linux.

I was attracted to Linux because unlike Windows or macOS, I actually have choice with Linux. I can choose my filesystem, my libc, my init system, my bootloader, my system encryption, my window manager, etc.

Sure, it's not perfect: many programs assume that you have glibc, or dbus, or X11, or wayland, etc. Actually many programs assume that you run Ubuntu. And it is frustrating when you would want to use a program and can't because of such an assumption. But again on Linux, there is (or used to be?) a big open source culture. This program is assuming glibc? I can patch it to work with musl. Etc.

Systemd, to me, sounds like it says: "why would I care about interoperability? I am the best, you should use me. And if you want something else, you should make that something else interoperable with me, because I make the rules". It's not like systemd is trying to standardise stuff to allow alternative components to exist, right? It doesn't actively try to prevent alternatives, but that's pretty much it.

And normally I wouldn't care (again, Linux is about freedom of choice for me). But systemd being as successful as it is dramatically reduces my freedom. And systemd it seemingly trying to take over more and more components. And the more adoption it gets, the more power it has. You didn't want systemd to replace that part of your system? Too bad, it will. What are you gonna do anyway, systemd is too big to care about you at this point.

Not the OP, but to provide a short perspective:

    - Too many parts.
    - Doing too many things, sometimes poorly.
    - Fights with other services, no graceful fallback & logging (i.e. aggressive).
    - As a result, unnecessarily complex, brittle and fragile.
    - Harder to secure (at code level) than simpler tools.
    - Project is too aggressive and want to replace any and every service.
    - Sometimes break in unexpected ways.
    - Not faster than Parallel Sys-V.

> Why?

The thing with the whole systemd hate thing is everyone now knows why people might hate systemd (I am not a fan). I think a lot of features around isolation and systemd containers where useful but now probably using your containerization system that best suits your needs.

For me when I get really mad at it is when I want to build small nixos Images and want to minimize the footprint of systemd and run few services (some of that is on nixos as well).

I think it's better suited for desktop systems then server systems and it's quite annoying how prevalent it is. D-bus is one thing that always annoys me and how everything in systemd wants to use it and you can run into issues disabling it (Also don't like D-bus even on a desktop system).

Overall I think and hope we will see a rise not necessarily in openrc but in simpler init 1 systems that try to do less and provide good strong primitives that allow for easily using what ever daemon configured how you want, rather then trying to provide coupled implementations for everything.

Again I know these criticism are something of a meme, but they still are true.

The XZ backdoor. That's why.

Only Rube-Goldberg complexity on the scale of systemd made the XZ backdoor possible. Systemd was made by despicable individuals who went on to work for despicable companies (as a big fuck you to open-source lovers) and then later on to work on even more despicable surveillance project (as a big fuck you to humanity).

systemd has its tentacles meddling in every single part of the Linux ecosystem.

But thankfully there's light at the end of the tunnel: thanks to VMs and containers and the need for speed, we've seen many minimal distros (I'm thinking stuff like Talos for Kubernetes) and those of course don't use systemd.

As soon as I get the time to switch away from my current hypervisor (Proxmox, so Debian, so systemd) to an hypervisor not running under Linux, like maybe bhyve on FreeBSD, I'll have all my VMs and containers and hypervisor totally systemd free (my VMs and containers are already systemd free: I did in anticipation of, at long last, giving systemd the middle finger).

But of course none of this matter much because according to HN we're already at a point in time where we can write: "Plz rewrite an init system".

The real question is: why don't people hate a rube-goldberg init system made by someone who went to work for Microsoft, while using crypto made up by his brother (certainly secure we're sure), and who then went on to create a full-on surveillance company working on locking down hardware?

Regain control of PID 1 people.