[m45t3r]

I don't really understand this feature creep argument against systemd. I mean, this is not like this is a feature included in PID1, it is a new binary so a separate feature (and I am pretty sure that you can choose to not compile it too if you don't want, like almost any other systemd feature with the exception of systemd itself and journald).

Also, the way I understand systemd nowadays is it isn't an init system, it is an API for Linux systems that abstracts low level features in kernel in a consistent way (either using unit files or systemd C interface). It has an init system because it needs control from early boot so it can offer a nice interface for services. Ditto for dbus, mount system, timers, logging, etc. You can use as much or as little as you want, but if you choose not too you need to invent your own way (that was what most distros used to do before systemd).

Also, integration between those subsystems (say, init systemd and cron) was basically writing glue code, while in systemd world they're meant to be integrated (unit files of any type can depend of each other, so you can have a service that depends on a timer, a disk mount and a udev event, for example).

So yeah, you may not like the way that systemd does things, but at least use valid arguments like the fact that things are more opaque (but this is understandable, this is an abstraction layer), or that the declarative approach of systemd makes some things harder (true enough, but you can always fallback to use scripts and you still have all the power of systemd dependency system).

[turminal]

> I don't really understand this feature creep argument against systemd.

> Also, the way I understand systemd nowadays is it isn't an init system, it is an API for Linux systems that abstracts low level features in kernel in a consistent way (either using unit files or systemd C interface).

Starting as an init system and becoming a general API that abstracts low level kernel features seems like feature creep.

> You can use as much or as little as you want, but if you choose not too you need to invent your own way

Correct. The problem arises when you try using tools not provided by systemd in conjunction with systemd and systemd actively makes that hard. The accepted solution to that problem in the systemd world is to rewrite more tools the way systemd sees fit with the side effect of extinguishing every other approach and dragging linux further away from its BSD/Illumos cousins. This is again a form of feature creep.

Don't get me wrong. I think the tooling available 15 years ago mostly sucked and there was definitely a need for something new. I just don't believe cleaning a mess with a giant monolith is the way to go.

[m45t3r]

> Starting as an init system and becoming a general API that abstracts low level kernel features seems like feature creep.

I think the initial presentation of systemd as a faster init system hurt it more than helped, because people started to think that systemd "was just an init system". And it never was really, even early on there were blog posts showing how powerful was its declarative approach. But it seems that the only blog post people remember is the "faster init" one (that even this one did more emphasis on the fact that systemd did dependencies the right way them the fact that it was fast).

> every other approach and dragging linux further away from its BSD/Illumos cousins

The way I think about systemd is that it make it closer to the approach of BSD and other *nix systems does. Portability is never something easy, specially when you're doing complicated things like power or network management. A good example is that all the different BSDs have difference between on how you manage networks, and the way it was on Linux before systemd was that *every* distro reinvented their own network management system (and each one was slightly broken in some fun way).

So what systemd does? They standardized everything. Now if your distro uses systemd-networkd, you can finally write a service that depends on a specific network topology that is portable across multiple Linux distros.

BSD don't need something like systemd because they're already tightly integrated, because the kernel and user space is both developed by the same team. Each part of a Linux user space used to be developed by different people, and it was the work of the distro to integrate everything. Now systemd provides a good foundation for many things in user space, and most distros stopped to ship their own solutions except for package management and some other integration bits that they need for their specific purposes.

So if you say to me that systemd is feature creep, it is as much feature creep them the whole FreeBSD or OpenBSD. And this just doesn't make sense.

[iio7]

> I don't really understand this feature creep argument against systemd. I mean, this is not like this is a feature included in PID1, it is a new binary so a separate feature (and I am pretty sure that you can choose to not compile it too if you don't want, like almost any other systemd feature with the exception of systemd itself and journald).

AFAIK systemd and the different components has so many internal dependencies on each other than not much works if you try to pull things apart. You can remove systemd completely, yes, but try to only have systemd as an init system and nothing works!

[m45t3r]

Unless you give me a more concrete example, I don't really think this is true.

For example, right now neither my desktop nor my notebook uses `systemd-networkd` and it works fine. Actually, since I use NixOS even basic things like `hostnamectl` or `timedatectl` are "disabled" (they work in read-only mode since those configs are managed by NixOS). But I do use `systemd-bootd` (so I can get boot information from the early UEFI until user space, try doing the same thing with GRUB+sysVinit).

The only two components that I know it can't be disabled in systemd is the init part and journalctl (because all the other parts of systemd depends on it).