Making too many assumptions about the user environment is not smart. Then you start putting constraints and becoming defensive when these assumptions are questioned. This is becoming a pattern for systemd as is blaming everyone else. [1]
Those who need the complexity or some features should adopt the technical debt, there is zero rationale to enable it by default and impose it on everyone.
For instance if you have too many network interfaces and naming is a problem then switch on predictable network names which btw is anything but predictable for human beings and let the 97% who don't carry on.
12 digit random names are simply not predictable or better for human beings than eth0, wlan0? If there is a problem predictable network names is not the solution.
Similarly if you need binary logging and an audit trail then turn on binary logging but don't impose it on everyone else.
Its time to move beyond silly accusations of 'hate' etc every time there is a discussion about systemd because at the moment it just serves to deflect criticism and avoid accountability for questionable decisions.
Those who need the complexity or some features should adopt the technical debt, there is zero rationale to enable it by default and impose it on everyone.
Indeed. Even if I have multiple ethernet interfaces, I'd prefer to map a MAC address to eth[0-9] myself. But most machines only have one ethernet interface and one WiFi interface anyway.
These things pop up all over the place. E.g.: why would I want to have NetworkManager on a server, which never switch networks and need to set up a VPN connection? Why do I need firewalld on a server? I rarely need a zone-based firewall on my laptop (probably like most users, I just block all incoming traffic), let alone a server.
Layer upon layer is piled to solve hypothetical situations that do not arise for > 90% of the population.
(I do like systemd as a service manager, but systemd and the surrounding ecosystem has made it terribly difficult to understand and debug UNIX systems.)
Most of my machines have more than 1 wired interface, and guess what? Those predictable names have caused me way more problems than they ever fixed. And those problems have always been harder to fix. Just stable names, like udev used to do were enough for nearly everything.
> why would I want to have NetworkManager on a server, which never switch networks and need to set up a VPN connection?
It's funnier because NetworkManager must wait for the filesystems to be mounted, but then, networked filesystems (that are, those ones, important there) need a functioning network that NetworkManager postpones to after it's up.
systemd runs services as uid 0 because it can't parse a valid user name (of a non-uid 0 user). Of course it's not systemd's fault. It's not even a problem at all.
Unless he can introduce a layer he controls. Observe that rather than work with Alsa to find some way to handle transient audio devices, he introduces Pulseaudio.
Those who need the complexity or some features should adopt the technical debt, there is zero rationale to enable it by default and impose it on everyone.
For instance if you have too many network interfaces and naming is a problem then switch on predictable network names which btw is anything but predictable for human beings and let the 97% who don't carry on.
12 digit random names are simply not predictable or better for human beings than eth0, wlan0? If there is a problem predictable network names is not the solution.
Similarly if you need binary logging and an audit trail then turn on binary logging but don't impose it on everyone else.
Its time to move beyond silly accusations of 'hate' etc every time there is a discussion about systemd because at the moment it just serves to deflect criticism and avoid accountability for questionable decisions.
[1] https://github.com/systemd/systemd/issues/2407