[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?

[zxzax]

Does it really make a difference whether it's called libsystemd or something else? If you're talking about the other functionality that's private and unstable, it's not included in a separate library for exactly that reason: it's considered private and unstable (Also I'm not sure if you're joking with that name but I really doubt there would ever be something like this literally called "libredhat," that makes about as much sense as putting a random b-tree implementation in a library called libubuntu or a libgentoo).

[ticviking]

>Does it really make a difference whether it's called libsystemd or something else?

Probably not. But when I think of something named "libsystemd" I think of a library to interact with systemd, not a collection of random hashmap and B-tree implementations.

> If you're talking about the other functionality that's private and unstable

Why would I talk about factoring out private and unstable code into a shared library.

But if udev is depending on that private and unstable code I do have a lot more sympathy for the packagers who are wary of the merger. It's kind of disengenuois to claim that they're totally separate projects, and can reliably be deployed separately when they both depend on some private special sauce. Even if the sauce is open sourced.

> Also I'm not sure if you're joking with that name

Half a joke and half trying to avoid the "I hate the name" problem.

You have clarified a little bit of what that library is actually doing. And why it seems to make sense to have udev pick up the dependency. Thank you.

[zxzax]

Sorry I wasn't clear -- most of the stuff I was talking about (hashmaps, b-trees, parsers, low-level utility functions, etc) is the private and unstable stuff, in the sense that it's a little too specialized towards systemd's style of C coding to warrant making it a public API, but it's useful enough to be shared between all the systemd components including udev. That's all the "private special sauce" is, it really doesn't make it any harder to deploy separately. They're not totally separate projects but there also is nothing really in common between them besides the build time dependency. Does that make sense?

[ticviking]

Yeah it does.

It seems to be a symptom of the kind of social and political problems that appears to be the root of quite a lot of systemd hate.

Ultimately those who dislike it are probably better of maintaining some kind of alternative than writing rants on forums though.

I really appreciate your time helping me understand this particular issue.

[bkor]

You're assuming libsystemd does things which it doesn't. Saying there should've been a libudev says enough. Too much assumption the lib does loads of things around the init system part of systemd. The unneeded dislike of the library is exactly why I used to make fun of the Devuan project. Loads of decisions that pretend to be made on a technical basis, but are actually mostly emotional and "gut"-feeling.

[ticviking]

I think you're confusing me with another poster in this thread.

I'm mildy "not a fan of systemd" in that my minimalist sense of what a "good" system is is bothered by it and it doesn't pass my "gut-feeling" but I run way more systems with systemd than without so...

The way this whole thing is divisive fascinates me though. Systemd seems to work, and work fairly well, but also attract phenomenally loud detractors. I can't think of any other piece of software that does that. Not even PHP triggers as much back and forth. This whole udev and libsystemd thing is one of the only arguments that seems technical to me.

[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".