Announcement

Collapse
No announcement yet.

Lennart Poettering Takes To Battling Systemd Myths

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

  • #81
    Originally posted by peppepz View Post
    I've just installed udev from systemd-197. Thanks for at least having made Python optional on the target, this helps when bootstrapping a cross-compiled image. However, now libudev links with libsystemd-daemon, so the integration between systemd and udev apparently went a step further and now there's another piece of systemd I need to have on my system only to run udev. Ressured by you, I shut up and install the library, knowing that it won't harm me.
    Yeah, libsystemd-daemon is made so that when used on a non-systemd system its functions will be noops. Moreover, it comes with the sd_booted() function which is used like this in one place in udev:

    Code:
            /* don't muck around with ACLs when the system is not running systemd */
            if (!sd_booted())
                    return 0;
    I guess this illustrates how udev development is done: when using systemd you might get a few extra neat features (which were not possible before), but when you don't we bail out and things behave as they used to do.

    Originally posted by peppepz View Post
    It makes sense for udev users to build only udev. You say that it does not make sense upstream, so apparently there's some thing that you call "upstream" whose interests are in conflict with a portion of the downstream udev users, namely all those who use udev but not systemd. Which is what I've been ranting about all the time, with people telling me that it was not true.
    I think you are creating a conflict where there is none (at least nothing serious). The point is that udev is just another part of the systemd repos, and is not really 'special'. The systemd repos also have a lot of other pieces like udev which can be used without systemd (in Arch we shipped lots and lots of the systemd binaries in a package called systemd-tools which was used by our initscripts (which I maintained) before we switched to systemd).

    So if you want it to be possible to build udev separately, and you want the buildsystem to be uniform and 'make sense', you should also allow any of the other parts of the package which does not depend on the systemd binary to be built separately (while making sure that any parts that do depend on systemd pulls it in). Sure, it could be done, but so far the suggestions I have seen have been very invasive, much more so than simply split the package up after building it (and possibly discarding some parts you don't need).

    To be perfectly honest, while I understand why you want to build just udev, I'm not very sympathetic to the way you are framing it as an important issue. Let me make an analogy to illustrate how I see your plight:

    You are used to Santa Clause delivering your favorite toys on every Christmas morning. Now you are noticing that Santa Claus has included some toys in your gift basket that you don't really want. So you tell him that he needn't bother with those, you don't want them. No big deal. However, Santa tells you that, 'Sorry, in order for the elf factory to produce gift packages efficiently enough we can't make everything optional; the sorting process would simply take too much time. Please just throw away the gifts you don't want'. No big deal, or so one should think. On the contrary, now you panic because you are scared that one year Santa will stop providing your favorite toys and only provide the toys you don't really want. Not to worry, says Santa, 'I'll still keep giving you the toys you want as long as they make sense'. Which induces an even bigger panic attack: 'What do you mean "as long as it makes sense"?! I want it forever and ever! Promise me now! Forever!'. Obviously Santa, having been around for some time, knows that nothing is forever, so he refuses to make such a promise. For instance, a couple of hundred years ago the standard gift basket would contain riding boots. He stopped doing that, as hardly anyone goes horseback riding anymore. Sure, some do, but not enough for the elves to spend resources on that, when there are so many XBoxes to assemble. Santa thinks this is a fair deal, and is a bit confused about all the hatred he is attracting... After all, it is not like he is obliged to provide anyone anything at all...

    Originally posted by peppepz View Post
    In your previous message you told me repeatedly that I could use Linux without udev, now at least you're saying that "most clients no longer care about the non-udev usecase". So I can use Linux without udev, I'll just have to do without "most clients". Lucky me *.
    Ah, a misunderstanding: Linux is a kernel, on top of which you can put several different collections of user-space applications. Some of them include and rely upon udev, others do not. Whatever way you slice it, there is no dependency chain including udev which forces you to use systemd. Maybe other apps will force you to use systemd (GNOME, NetworkManager, PolKit? Neither do at the moment, but perhaps one day?), but you can't make the claim that it is some sort of power-play by the systemd/udev devs as they have no control over these other projects.

    Originally posted by peppepz View Post
    Since you're pointing at LFS, in all honesty, can you find on the whole LFS site another package whose installation requires such a complex and elaborate procedure every time a new release is out? One! Bonus points if it's a system package which is needed by any application to interface itself with the Linux kernel.
    I know virtually nothing about LFS, I only noticed their udev package and thought to myself that this is exactly what eudev should have done.

    Originally posted by peppepz View Post
    I hope so. I have to live in hope (so much for "nothing will change"). The biggest problem is that he should gather quite a critical mass of users in order for his implementation be tested well-enough to be a viable replacement, but well, that's true for many kinds of project.
    So you seriously worry about a day will come where all major player have agreed that systemd is the way to go, it serves all their usecases from servers, via desktops, tablets and smartphones to embedded. Moreover lots of standard user-space applications start hard-depending on systemd as they agree it is the right choice. However, it still does not serve your usecase, so you are desperately in need of some guy to fork udev? Seems more likely to me that if ever the time comes where udev starts depending on systemd it is because there is no longer a reason not to use systemd, and you will already have moved to systemd for other reasons... (unless you have some religious opposition to it, but I would never dream of accusing anyone of being that irrational ;-) ).

    Originally posted by peppepz View Post
    Also he'll need quite a dose of endurance to harsh criticism. Let's see what happens with eudev.
    Please do not confuse the harsh criticism eudev endured with criticism of the idea of a fork. The criticism was due to technical incompetence and (willful?) ignorance of how the project they were forking works (which they then keep on spreading, despite being informed of their mistakes).

    Comment


    • #82
      To be perfectly honest, while I understand why you want to build just udev, I'm not very sympathetic to the way you are framing it as an important issue. Let me make an analogy to illustrate how I see your plight:
      While I disagree with the larger part of your previous message, I only respond to the fragments that relate to me.
      There are two things wrong with your analogy:

      1) it puts words in my mouth that I have never uttered, that make me appear as a moron. "panic attack"? I've expressed my current problems and my future concerns in a precise and documented way. "hate"? I don't know what it means.
      2) it assumes that systemd is the only "modern" init suite, by depicting other solutions as old-fashioned or unreasonable, as "riding boots". This is not the case, as you certainly know. Moreover, people still ride horses, it's an activity that many people love. It's much more healthy than playing with xboxes.

      Ah, a misunderstanding: Linux is a kernel, on top of which you can put several different collections of user-space applications. Some of them include and rely upon udev, others do not.
      Did you really believe that my interest in Linux was limited to seeing the kernel boot without running applications afterwards, hence you told me that I don't need udev? No, I also like to run applications and these need udev; X, for instance.

      So you seriously worry about a day will come where all major player have agreed that systemd is the way to go, it serves all their usecases from servers, via desktops, tablets and smartphones to embedded.
      I don't worry at all about the future, Linux always fixes itself in the long run. I do worry about the teething pain.

      so you are desperately in need of some guy to fork udev?
      The day udev stops working for me, should that day ever come, I'll write a replacement myself. I have to study its source package every time a new udev release is out anyway, in order to find out about all the undocumented incompatible changes. I don't want anybody to do any work for me.

      Comment

      Working...
      X