Using Udev Without Systemd Is Going To Become Harder

[Luke_Wolf]

And you think this *disproves* my claim that modularity adds complexity? Now you have three interfaces instead of one, and calling code having to do type-checking to work out which capabilities it can rely on. It might be more architecturally pure, but there's no way that's simpler. We're talking abstract cases, of course, but my point is that, depending on the problem, it may be a much better decision to couple things more tightly with an unstable interface. Modular design is just a tool - you use it when it's a good fit, but more importantly, you don't use it when it's not.

If you look at the trees and not the forest, yes. However you have simpler components with a better understood design which means that the total effective complexity has gone down, which means that maintenance and extension are also easier. Now I will grant you that for small projects where there is one clearly defined purpose that will never be extended, that modularity does increase complexity vs not doing so. Anything that is significantly complex or needs to be extended however, benefits from a more modular design. Guess which category most projects fall into?

[Delgarde]

What a weird world view. If in your country suddenly there is a political change towards theocracy or a dictatorial regime, would you ride it or stand in its way? What about climate change? Rather ride it then do what we can to prevent it?

You misunderstand. I'm not saying you have to live with every change, that you should just accept them as they come - I'm saying you'll achieve nothing by standing in front of a runaway train and shouting "Stop!". You *can* do something about political change or climate change or technological change - but only by actually doing something, not by standing around talking about how something needs to be done.

That's the vibe I often get both online and in real-life... a lot of complaining, not a lot of action. It's actions that make a difference.

[Delgarde]

If you look at the trees and not the forest, yes. However you have simpler components with a better understood design which means that the total effective complexity has gone down, which means that maintenance and extension are also easier. Now I will grant you that for small projects where there is one clearly defined purpose that will never be extended, that modularity does increase complexity vs not doing so. Anything that is significantly complex or needs to be extended however, benefits from a more modular design. Guess which category most projects fall into?

You're reducing it to an either/or scenario - it's either modular, or not. Notice that I'm (repeatedly) not saying that modular is bad - only that there's such a things as being *too* modular. Taken to one extreme, you have an incomprehensible monolith that nobody understands - but taken to the opposite extreme, you have a hundred well-understood trivial pieces, but nobody understands how they all fit together. As ever, the best case is somewhere between the two... maybe it's optimal to have a dozen modules, or maybe its half that, or twice that. I've seen as many problems from people overdoing modularity as from not doing it enough.

[ssuominen]

systemd is glibc -only init system, uclibc and musl is now dead?

Some facts first:

- systemd is using glibc specific functions like secure_getenv() and is by design, for glibc only, and patches that would add uclibc or musl support, are actively rejected
- if it weren't for eudev, there wouldn't be other udev provider than systemd-udevd, and even if you build only systemd-udevd from systemd tree using the MinimalBuilds
wiki page systemd has for building certain components only, they made udev's logging use secure_getenv() too

So, anyone who wants to use uclibc or musl or some other libc, don't have anything else now than:

- devtmpfs + eudev
- devtmpfs + static /dev
- devtmpfs + mdev from busybox
- ???

And Gentoo is actively supporting development on alternative libc's. This is the main reason Gentoo people are unhappy. It's not about what Lennart or Kay or anyone has said,
it's not about politics, the problems boil down to technical facts, and to them only

I just wanted to clarify this, since it seems people are thinking Gentoo is doing this based on some political view, which isn't true...

Thanks,
Samuli

[BlackStar]

Some facts first:

- systemd is using glibc specific functions like secure_getenv() and is by design, for glibc only, and patches that would add uclibc or musl support, are actively rejected
- if it weren't for eudev, there wouldn't be other udev provider than systemd-udevd, and even if you build only systemd-udevd from systemd tree using the MinimalBuilds
wiki page systemd has for building certain components only, they made udev's logging use secure_getenv() too
[...]
I just wanted to clarify this, since it seems people are thinking Gentoo is doing this based on some political view, which isn't true...

Why not implement the missing interfaces in uclibc then, or even as a compatibility shim? I can certainly understand why systemd would not want to carry patches for alternative libc implementations.

[Luke_Wolf]

Some facts first:

- systemd is using glibc specific functions like secure_getenv() and is by design, for glibc only, and patches that would add uclibc or musl support, are actively rejected
- if it weren't for eudev, there wouldn't be other udev provider than systemd-udevd, and even if you build only systemd-udevd from systemd tree using the MinimalBuilds
wiki page systemd has for building certain components only, they made udev's logging use secure_getenv() too

So, anyone who wants to use uclibc or musl or some other libc, don't have anything else now than:

- devtmpfs + eudev
- devtmpfs + static /dev
- devtmpfs + mdev from busybox
- ???

And Gentoo is actively supporting development on alternative libc's. This is the main reason Gentoo people are unhappy. It's not about what Lennart or Kay or anyone has said,
it's not about politics, the problems boil down to technical facts, and to them only

I just wanted to clarify this, since it seems people are thinking Gentoo is doing this based on some political view, which isn't true...

Thanks,
Samuli

They could always try porting FreeBSD's devd

[ssuominen]

It's possible to build uClibc without NLS support, but systemd forces NLS use

Why not implement the missing interfaces in uclibc then, or even as a compatibility shim? I can certainly understand why systemd would not want to carry patches for alternative libc implementations.

That has happened already for some other functions that were missing, Gentoo's Mike Frysinger sent a patch to uClibc which got applied. The secure_getenv() didn't go in, at least yet,
because it's only for logging. We will see if it will go in as well later on.

However, even if we'd sent every function to uClibc head to imitate glibc, systemd maintainers have also refused to make locale_t and other NLS specific functions optional, even
though it would be trivial, and uClibc supports NLS-less builds, so that'll stay broken anyway. uClibc without NLS is often used by embedded platforms.

[bkor]

However, even if we'd sent every function to uClibc head to imitate glibc, systemd maintainers have also refused to make locale_t and other NLS specific functions optional, even
though it would be trivial, and uClibc supports NLS-less builds, so that'll stay broken anyway. uClibc without NLS is often used by embedded platforms.

It might be trivial, but systemd doesn't want to support it. So why blame systemd? Why isn't the problem within uClibc? This is a perfect examle of introducing complexity due to modularity. Systemd developers say the complexity of modularity is totally not their burden (complexity should be in the people going for modularity). No matter how small the additional complexity, they don't want it.

Hating them for this? They're quite clear on this, so understand you dislike it, but IMO you're just noticing all the little things that you have to do to make modularity possible.

[BlackStar]

That has happened already for some other functions that were missing, Gentoo's Mike Frysinger sent a patch to uClibc which got applied. The secure_getenv() didn't go in, at least yet,
because it's only for logging. We will see if it will go in as well later on.

However, even if we'd sent every function to uClibc head to imitate glibc, systemd maintainers have also refused to make locale_t and other NLS specific functions optional, even
though it would be trivial, and uClibc supports NLS-less builds, so that'll stay broken anyway. uClibc without NLS is often used by embedded platforms.

Is there really a use case for systemd + uclibc + NLS-less on an embedded platform, or is this just a nice to have option? If NLS is too heavy for a given embedded platform, then I'd expect systemd to be out of the question anyway.

But then again linux is already too heavy for the DSPs I work with, so yeah. (Spending a year with SYS/BIOS 6 gives you some perspective on just how much nicer linux+systemd is...)

[BlackStar]

It appears glibc can be built without NLS. That's worth trying out, the systemd people might accept patches making that work (and indirectly fixing uclibc in the process.)