Announcement

Collapse
No announcement yet.

Using Udev Without Systemd Is Going To Become Harder

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Vim_User
    replied
    Originally posted by mike4 View Post
    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?

    Leave a comment:


  • mike4
    replied
    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%.-

    Leave a comment:


  • ssuominen
    replied
    I got corrected, and rightfully so.

    Originally posted by BlackStar View Post
    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

    Leave a comment:


  • bkor
    replied
    Originally posted by BlackStar View Post
    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).

    Leave a comment:


  • bkor
    replied
    Originally posted by stqn View Post
    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..

    Leave a comment:


  • You-
    replied
    Originally posted by GreatEmerald View Post
    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.

    Leave a comment:


  • stqn
    replied
    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.

    Leave a comment:


  • curaga
    replied
    Originally posted by BlackStar View Post
    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.

    Leave a comment:


  • BlackStar
    replied
    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.)

    Leave a comment:


  • BlackStar
    replied
    Originally posted by ssuominen View Post
    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...)

    Leave a comment:

Working...
X