[cyberdelica]

> Not sure why you're saying that -- moving it to a library is basically what happened. The libudev code got moved to libsystemd, and now libudev is a wrapper around that.

Oh, so now one has to include "libsystemd" if one wants to use "udev" - is that what you're writing? Hence the original comment:

> By devouring the udev project, the systemd maintainers have guaranteed that dealing with USB devices on non-systemd systems was going to be a giant pain.

[zxzax]

I don't understand, is this not what you were asking for initially? libsystemd.so is just a shared library, it's not any more of a giant pain than any other library.

[cyberdelica]

Why not just include libudev, in systemd instead?

[zxzax]

Because that would not reduce code duplication. I don't know if you have ever worked on any of the low-level Linux libraries written in C, but the amount of unnecessary code duplication across them is awful. The standard library features provided by glibc are extremely inadequate for modern applications, every non-trivial C project I've seen starts to include their own private implementations of various C++ things like hashmaps, binary trees, dynamically sized strings, unicode support, async event loops, etc.

For utilities that have to interact with low level kernel APIs it's even worse, every library seems to have to reimplement their own parsing of various other random things like netlink, or in the various pseudo filesystems like sysfs, procfs, cgroupfs, etc etc, the situation is really way out of hand. I don't know how to solve this in a reasonable manner beyond what systemd is already doing. Yes people will complain that they have a systemd dependency now but what else can you do? This is the exact reason the BSDs update the kernel, libc, init and core utils in tandem and consider a lot of the kernel API to be private, Linux was just slow to catch on in that regard.

[cyberdelica]

> Because that would not reduce code duplication.

I don't want to call you out for making a disingenuous argument, but it was either subsumed by systemd for code duplication reasons, or it wasn't?!

Duplicate code, could be refactored out to a shared library, that could then be incorporated in both udev, and systemd. That would mean, anyone looking to incorporate udev into a system, could do so without depending on libsystemd.

Instead, it would seem udev code, has been subsumed by libsystemd (in your own words) - which would appear to the sceptical eye, as a power play on the part of red hat - to force other distributions into using libsystemd, which would logically end with them also using systemd itself.

> I don't know if you have ever worked on any of the low-level Linux libraries written in C [...]

Yes, I have.

[zxzax]

The issue is not with the actual udev device event logic itself, but with all the other bits I talked about. Those are the things that would need to be duplicated.

>to force other distributions into using libsystemd, which would logically end with them also using systemd itself.

As I said elsewhere, libsystemd is just a library with some generic functions provided for convenience. This is like saying that installing python libraries on your system logically means that the PSF is trying to take over your system and forcibly rewrite everything in python, it doesn't make any sense.

[ticviking]

Why can't there be a libredhat that provide these things to the community with a stable interface?

Lots of communities manage to have widely used data-structure and algorithm libraries that aren't closely in the same repo as other unrelated projects, is there some special problem with this kind of systems programming that prevents that?

[jhasse]

> Duplicate code, could be refactored out to a shared library, that could then be incorporated in both udev, and systemd.

That's basically what has been done. The library was named libsystemd.

You seem to have a problem with the name "libsystemd".

[kaba0]

Feel free to rename it libNotSystemdButAGeneralSharedLib and link that.. it is named systemd, not systemd-the-init-system itself.