Using Udev Without Systemd Is Going To Become Harder

[curaga]

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.

Read that in the context of this thread: no udev without systemd.

[stqn]

Soon we?ll see systemd start to depend on some gnome service or maybe Gtk3. Oh, it will be optional at first, no worries. And one year later we?ll have the ?choice? to either rewrite the whole Linux ecosystem, use Red Hat OS, or go back to Windows.

[You-]

Well, good thing I just took the time to upgrade my old Gentoo installation on my tablet that used OpenRC to using systemd. It should be more or less smooth sailing from here.

Actually no, that is where the problem lies - with non systemd not providing the features and interfaces that udev wants.

The headsup is that if no one does the work to provide those interfaced when udev finally starts to use them, those systems will be broken with the latest udev.

Those calling for modularity need to provide the modularity - this is just one more technology that has been given a heads-up of future requirements. Even outside the systemd tree you can't force maintainers to not use new features that make their lives easier.

Otherwise you will get to the same point as consolekit v logind where over 2 years advance was given but modularity was lost because no one stepped up to the plate to maintain consolekit/provide an alternative with the relevant interfaces.

[bkor]

Soon we?ll see systemd start to depend on some gnome service or maybe Gtk3. Oh, it will be optional at first, no worries. And one year later we?ll have the ?choice? to either rewrite the whole Linux ecosystem, use Red Hat OS, or go back to Windows.

The dependency list of systemd is very minimal. Don't look at the requirements of a systemd package, look at the actual requirements. A lot of things are optional. There are various components which can use a lot of extra functionality (and thus dependencies), but it is really minimal.

Anyway, having systemd depend on GNOME or gtk+ is pretty ridiculous. Maybe at one point some optional tool is added which uses gtk+. At which point some distributions might show a gtk+ dependency and there will be huge threads about it.

In the various years since the creation of systemd, the minimum requirements have been pretty much the same: very recent kernel, very recent dependencies, not a lot of minimal dependencies. Various optional ones.

I don't understand the need to make up all these weird "this might happen" that I see so often on Phoronix..

[bkor]

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...)

From what I understood is that for limited embedded use cases (smartphone is also called embedded I think while that is a bit weird as my smartphone has 3GB of memory), a lot of software is adjusted to make it work with the hardware. So either to reduce memory usage, make it work with work with some half broken hardware, etc. Slight customization of systemd to remove NLS support is just one more tickbox. If there is a need to remove NLS, then likely other functionality also needs to be ripped out of other components.

I understood that usually those embedded cases are pretty much one-off. Make adjustments (kernel, etc), make the hardware, sell a lot, move on to the next hardware. My knowledge of embedded is really limited (just read what other people say about it), but having systemd (or any component) support specific adjustments would be a "nice to have" to me. Systemd easily works on a raspberry pi, and that hardware is old (meaning: for same price I'd expect you'd get -as a company- a much higher specification hardware).

[ssuominen]

I got corrected, and rightfully so.

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.)

Err, how could I have missed that! Could have sworn I've looked at it. I think I'll write a new patch and try to get it applied for NLS-less glibc just like you said.

Thanks,
Samuli

[mike4]

How could such a crappy udev been accepted. It's such a can of bugs not even my CH Pedals are working anymore! Unbelievable, no wonder many people move to OSX. Such will push down the number of Linux users for X-Plane from ~2% below 1%.-

[Vim_User]

How could such a crappy udev been accepted. It's such a can of bugs not even my CH Pedals are working anymore! Unbelievable, no wonder many people move to OSX. Such will push down the number of Linux users for X-Plane from ~2% below 1%.-

So, have you reported that bug or are you only complaining on random forums about it?

[TheBlackCat]

So, have you reported that bug or are you only complaining on random forums about it?

He complains about it on pretty much every systemd thread.

[xeekei]

How could such a crappy udev been accepted. It's such a can of bugs not even my CH Pedals are working anymore! Unbelievable, no wonder many people move to OSX. Such will push down the number of Linux users for X-Plane from ~2% below 1%.-

If it's such a "can of bugs", why is your bloody CH Pedals not working the only damned bug you keep mentioning? Or shouting about, rather.