Systemd eats udev, poettering says breaking not their problem | Hacker News Reader

Systemd eats udev, poettering says breaking not their problem

github.com

33 pointsdogecoinbase10 comments

From a related issue [0]:

> We would switch over to sg3_utils when it is able to replace the udev tools, and remove the udev tools. It is just that someone who understands these devices needs to do the work. None of the systemd maintainers can do that.

I find it sensible that systemd wants to not maintain things they don't have the experience to handle. That is great.

But answering a perfectly valid prompts like [1]:

> @poettering I get that. The current situation is unsustainable. And we will talk to our storage guys to find some solution. But meantime, we need some synchronization between downstreams. Otherwise everyone will implement a different naming scheme with downstream patches.

With [2]:

> Someone with knowlegde in that area should move them to a separate package that can be maintained outside of systemd/udev. Hannes worked on moving parts of scsi_id to sg3_utils, finishing that would be the first step I assume.

> Closing this pull request, for the above mentioned reasons.

There is a problem with systemd right now. The right move is to move it into an external library, and work is under way for that.

In the meantime however, and it may be a very long meantime, systemd has some serious compatibility problems with udev, which can have some really serious side-effects.

A middle-point is needed.

People working with RHEL seem willing to help, but systemd won't take any of it on board. It's not their problem.

I don't find that comfortable.

[0] https://github.com/systemd/systemd/pull/2363#issuecomment-17...

[1] https://github.com/systemd/systemd/pull/2500#issuecomment-17...

[2] https://github.com/systemd/systemd/pull/2665#issuecomment-18...

Can anyone summarize what the debate is about here? I feel like I'm reading a very tiny slice of a larger debate. Is this just another example of systemd aggressively dropping legacy support, or is there more going on here?

My thinking is "basically yes" to your last question given my reading of the thread.

Yeah, it's confusing. Without more context it's hard to tell what we should get out of this. From what I've read, he seems to have a good point. You want to submit patches, that are not testable, or maintainable.

The title is totally editorialized to make it seem like this person is holding something up but he makes good point.

Udev existed for nearly a decade on its own before it was merged with systemd. And upon that merger, Sievers, the then maintainer of udev and a close buddy of Poettering, promised that udev would still be usable without systemd.

But since then every time the topic comes up, the systemd devs (Poettering and Sievers in particular) as gone back on that promise.

The larger debate is that Lennart and company, developers with very poor histories of playing nice with the community at large, are continuing to swallow more items that are outside the scope of an init daemon, and creating a monolithic replacement for the separated core utilities (and GNU itself), very much against the UNIX/Plan9/Inferno traditions of many small apps that "do one thing, and do it well".

In this case, they are attempting to embrace/extend/extinguish forks of udev by making them wholly incompatible with systemd's implementation going forward. These are not actions that are welcome in the community, hence the large amount of vitriol from those opposed to it.

According to my limited understanding, some time back Poettering called for udev to be subsumed into systemd. When systemd.udev breaks something his response is. It shouldn't be in udev in the first place, it isn't my problem, we lack the skills to make it work. Going on Poetterings past utterances in response to criticisms of systemd, I have to say I am not impressed. It demonstrates an arrogance, immaturity and lack of people skills. Perhaps someone else should take over the helm.

Reply on news.ycombinator.com