| I think the author is right on just about everything. But the author is especially right on the need for competition. So I am working on it. I am building a build system, and I am making it usable as a library. When I have made it so, I will implement an near drop-in [1] replacement for systemd. You'll be able to use systemd unit files, and there will be an option to have binaries with the same name (off by default to not interfere, though) so that users don't have to learn new stuff right away. [1]: I am not going to implement journald for example; logs will be text, even if they are structured internally. Besides, implementing things to be perfectly compatible would only strengthen the monoculture, not weaken it. The plan is to be compatible on the things that matter for distro integration, so that distros can ship both with little work, but have other things different, so that users can choose what works best for them between the two. |
The author is very wrong on the systemd-resolved bit.
Not understanding the ability to have per-interface specific zones is ok; it is a thing for desktops with multiple interfaces that come and go (like VPNs, for example). There is no other resolver on Linux capable of doing it and integrating with NetworkManager. You can kinda-sorta make dnsmasq do it, but with some limitations.
But the crown is taken by the "mDNS is better taken care of by a dedicated package like Avahi." Uh, oh. It is like saying, that you don't need Chrome, it's duties are better taken care by nginx. Similarly, you can use Avahi for _advertising_ mDNS services, but not for _resolving_. Which, as an user, you probably are interested in.