Hacker News new | past | comments | ask | show | jobs | submit login

I didn't even realize you could use it outside of systemd. I never looked at it in detail, but if something is named systemd- then I think "part of the systemd suite and intended to be used with systemd" is a fairly reasonable assumption.

I'd still be hesitant to use it to be honest, as systemd has on several occasions broke people's systems and the response was "you're holding your phone^H^H^H^H^H systemd wrong". Well, maybe, but you broke my system and before it was perfectly fine, and that's kind of an issue for me. Especially with something as critical as booting my system, I want to be able to just rely on it without breakage "because I was using it wrong". Linus' "we don't break userland"-policy was a great piece of insight. I wish systemd had a similar attitude.

Some of the systemd criticism has gone off the rails (...and then some...), but there's a number of things one could reasonably criticize about the project and development style, IMHO.




Systemd-boot is a dream. Why anyone would tolerate or think grub2 is an acceptable piece of software is beyond my understanding.

grub.cfg used to be human editable, but has evolved & morphed into some massive gnarly twisted mess of inscrutible noise that only multiple layers of shell scripts can output. It's become a write-once-read-never disaster.

And if i recall it's not even live. You still have to install that config.

Systemd-boot (nee gummiboot).is such a huge breath of fresh air. Simple senisible plaintext entries that one cam modify in any old text editor, which have immediate effect. It's so pleasant & simple.

Alas debian doesnt seem to ship any hooks for updating systemd-boot with kernel updates. There's a shell-script to write/remove the entries but one has to go write their own hook & figure out the variables to marshal into the script's arguments. Please Debian!


Oh yes, grub is a pain; no argument there. I didn't even like grub 1 and in grub 2 it got several orders of magnitude worse.

I did almost use systemd-boot a few weeks ago though; I moved my SSD to a different laptop and that somehow accidentally booted some remanent of the Windows boot manager, which automatically and helpfully hijacked the lot and now it didn't boot in either the new or old laptop. I ended up using Grub as my distro doesn't provide systemd-boot at all (let alone update hooks), and aside from the hiccup a few weeks ago I haven't had to look at it in over a decade; so for all its ugliness it does "just work" for me, and I figured looking at alternatives would be a bit of a waste of time.

I miss the times where I used FreeBSD and the MBR bootloader they had (have?) just automatically detected things and it would always work without any keffufing about. Just dd these 512K to the start of your disk and presto!


I loved grub (1)--being able to fix a boot configuration issue during boot time was such a amazing upgrade over lilo. When I first saw grub2 and learned how it worked it struck me as the platonic ideal of the second system syndrome[1]. Everything about it was more complicated, expansive, configurable. The fact that they need `grub-mkconfig` is a sign that it went horribly wrong.

I had not heard of systemd-boot, I will check it out…

[1] https://en.wikipedia.org/wiki/Second-system_effect


> I didn't even realize you could use it outside of systemd. I never looked at it in detail, but if something is named systemd- then I think "part of the systemd suite and intended to be used with systemd" is a fairly reasonable assumption.

The tight coupling of systemD is a popular criticism of it.


And this is another fine case demonstrating how very very wrong that criticism is.

All in all extremely few systemd subsystems require systemd. Systemd's pid1 requires only one subsystem, journald, which one can mostly disable/defang if they really dislike it.

It's much more like a monorepo than monolith. There's standard practices & libraries between the projects- unit files, ability to ask for machine readible outputs, others. But these cross cutting concerns mostly get compiled in. The actual interdependencies between subsystems are few & far between. Feels like the critics dont really understand what they are trying to criticize.


You say this, but systemd-udevd at one point would sigkill every process on the system if it was not started under systemd (or otherwise in its own cgroup).


And udevd used to be it's own stand-alone daemon which didn't need systemd at all, but for some reason it is now essentially tied to it.

* https://en.wikipedia.org/wiki/Udev#History

* https://en.wikipedia.org/wiki/Eudev


So I can take systemd-timesyncd and run it on systemd-less Devuan or FreeBSD? systemd-resolved? systemd-networkd?




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: