Comment by schainks
3 months ago
In the last two years I have spun up new-ish, actively supported versions of ubuntu for pre-production rollout that were shipped with a systemd-resolvd that would occasionally just stop responding for no reason. Logs said nothing was wrong, process was UP and saying it is ready to do work. strace shows a hung process.
Stuff like this is possibly where the complaints from some people begin.
Fortunately, I can find a tracked bug that is active. New updates get pushed, as the honestly phenomenal community of people intended this process to go. But How may years have some of those people been patching bugs like this in systemd on a regular basis? Did that time have to be spent if systemd's architecture was better from the get go?
The Trail of Bugs to get to the point we are at today has truly taken a monumental effort from MANY people. Why wasn't systemd's community doing things well "enough" from the beginning before being folded into so many OSes?
Let's be real. From then till now they have put in hard work, in the face of huge community pushback, because someone had to do it.
Diehards feel it felt "foisted" upon us before it was fully baked, everyone knew sysvinit was way past its prime. Put up or shut up. Plug in a different init for your OS and move on.
But, you know, people like talking and complaining to each other. It's a very important part of solving technical problems!
> Diehards feel it felt "foisted" upon us before it was fully baked
That was the minor problem. The major meta-problems are that:
1. The baked form itself is broken. It has numerous fundamentally flawed aspects to its design (and to its existence as a project). More baking would not have helped this.
2. It is not intended as an option, nor even just the default option - but to make more and more utilities and libraries for managing various system facilities and services become unusable and incompatible, to be taken over by systemd. It's not like foisting, say, Thunderbird instead of Evolution as the default mail client; if you don't like it, you run the other thing. Or even version X of the kernel instead of version Y of the kernel and so on.
> everyone knew sysvinit was way past its prime
At this point we can say with clarity that systemd has almost nothing to do with the choice of init system. You could replace the init system with any number of things - some already existing 15 years ago, some which could be developed in the mean time. In hindsight, this is an excuse and not a reason.
Resolvd is not part of systemd's core. Would some KDE app misbehaving be a fair criticism of the whole project?
Also, I would be delighted to see that mythical program that requires no maintenance and just works^TM.
Also, what does it have to do with systemd's architecture?
The vast majority of criticism of systemd would cease if it were made out of easily mixed and matched components which worked independently of one another.
The goal of systemd is of course to be a highly integrated system which solves everything. As can easily be seen how hard it is to run e.g. dbus without systemd.
> Resolvd is not part of systemd's core
It sure feels like it because Ubuntu insist on installing this incredible piece of software even on the server installs.
I think the previous poster made it clear they were just explaining where the complaining comes from. Why are you trying to debate their description of other people's motivations for complaining?
> Would some KDE app misbehaving be a fair criticism of the whole project?
...yes? If dolphin sucked then that's a fault in KDE.