Announcement

Collapse
No announcement yet.

Using Udev Without Systemd Is Going To Become Harder

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

  • Originally posted by Vim_User View Post
    Apparently, a long time is for him a little more than two years, and apparently compatibility is not key anymore.
    Yes. The change hasn't been done yet and won't be done for quite awhile... and I would argue that three years is a long time in open source software world. Also it says nothing about breaking compatibility. The libudev library doesn't need to break the API even if the transport changes.

    Originally posted by Vim_User View Post
    Seriously, a sentence from Poettering like "Gentoo folks, this is your wakeup call." in reality comes down to: "The Gentoo people are actually the only ones of the non-systemd distros that have the manpower to handle this change in a proactive way, all other non-systemd distros better bow to us or keep using outdated udev forever. Now that Debian and Ubuntu have decided to change to our side we can show our real intentions and start with the small distros that can't handle the changes due to lack of manpower. Resistance is futile!"
    It has probably a lot more to do with Samuli being a Gentoo developer, some Gentoo folks having been particularly whiny and the previous history with projects like eudev.

    Comment


    • Originally posted by tomegun View Post
      See: https://dvdhrm.wordpress.com/2014/06/10/memfd_create2/



      Correct. As all of kdbus will be isolated in a kernel module, and there is not even plans of a dbus parser in the kernel yet, there will be no way to use kdbus for talking with the kernel (unless someone does a lot of work to make it happen of course, but I don't know about anyone who is seriously interested in that).



      The bandwith is not a problem, the latency is (or rather, kdbus is much better than netlink from a latency POV, but both are probably good enough for most uses).

      The way rtnetlink works is that your sendmsg() call will only return after the message has been fully processed (i.e., not only parsed, but the kernel will have finished changing your mac addresses or configuring your routing table before sendmsg() returns). If you only ever want to send one synchronous message, that is fine, but if you (as I do) want to send lots of unrelated asynchronous messages from a single-threaded application, it sort of sucks.
      thx, will check later
      i just use /dev/shm/ for now, would be great if shm_open() would take paths and make dir's dynamically

      good dbus won't be used for in kernel stuff

      you can put the MSG_DONTWAIT flag for non-blocking mode with sendmsg(), then just spam
      or can't you in this case ? (dk, don't see no reason why not)
      Last edited by gens; 08 July 2014, 06:44 AM.

      Comment


      • Originally posted by gens View Post
        you can put the MSG_DONTWAIT flag for non-blocking mode with sendmsg(), then just spam
        or can't you in this case ? (dk, don't see no reason why not)
        Wolud be nice, but no, you can't.

        Comment


        • Originally posted by tomegun View Post
          Wolud be nice, but no, you can't.
          any case i doubt a buffered protocol would help you much since the kernel would have to validate every instruction in order
          it would help that you could do something else, but you can do that by forking (since fork is very little overhead; and check with waitpid(*,*,WNOHANG))

          (guessing) same problem as with opengl

          Comment


          • Originally posted by Vim_User View Post
            Indeed, it is Sievers that is working on udev. The same Sievers that said this:http://lwn.net/Articles/490413/
            Apparently, a long time is for him a little more than two years, and apparently compatibility is not key anymore.
            This is a good point. Make me wonder what we can expect 2 years ahead.

            Seriously, a sentence from Poettering like "Gentoo folks, this is your wakeup call." in reality comes down to: "The Gentoo people are actually the only ones of the non-systemd distros that have the manpower to handle this change in a proactive way, all other non-systemd distros better bow to us or keep using outdated udev forever. Now that Debian and Ubuntu have decided to change to our side we can show our real intentions and start with the small distros that can't handle the changes due to lack of manpower. Resistance is futile!"
            Gentoo has always been about choice. you mix and match with the compontents your way. What systemd devs wants to do is remove those choices, those "pointless differences" for people. They are basically saying, the goal if Gentoo is pointless.

            Now, if you remove those "pointless differences" in distros, the question is: what point is it to have different distros if they are basically the same anyway? What if they in 2 years say: "we don't want those various pointless distributions".

            Don't get me wrong, I actually like systemd and its concepts, but it is its developers attitudes and actions like this that prevent me from using it.
            Same here. Systemd does many things good (not all), but I really don't like the narcissistic management style.

            Comment


            • At the end of the day he is right though. He wants to advance his project, its not his fault there is no competition for his project eliminating choice for the enduser.

              If you go on like this i swear the man is gonna snap and create a spinoff from systemd called dmetsys under the alias Pennart Loettering just to troll you guys.

              I mean he isn't taking anything away from you, its not like he is going to remote login to your system and uninstall the udev version your currently running. It will be there for you, forever and ever. Just like you can use ext2 and ext3 even today. But what you want is progress, you want there to be new versions of the software your running now(udev, consolekit, logind whatever), but without inconvinient changes to you. Its not his fault thats not going to happen(actually its your fault). You are the ones wanting an alternative. You don't get to decide what code people like Sievers, Poettering or Kroah-Hartman write in their time. Thats up to them, and maybe up to their company if they do it at work. They create, bringing new things to linux, they are not the ones taking old things away, thats just due to bitrot and neglect of people that should care.

              P.S.: Linux isn't about choice. Linux is about people writing code, and about other people liking that code and contributing to it. The rest is just background noise and ego.

              Comment


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

                Comment


                • Originally posted by Luke_Wolf View Post
                  If you're doing interfaces right that shouldn't happen, let's say that we've got an interface IFoo which has a method MemberA and we want to add a MemberB method to it, the correct response is not to directly add MemberB to IFoo but to create IBar which inherits IFoo, now if someone else comes up with a function of the same name MemberB but that has a completely different purpose they shouldn't use IBar but instead should Create IBaz which inherits from IFoo
                  so we have:
                  <clipped>
                  and then you cast to the expected behavior.

                  Ideally yes you wouldn't have that redundancy but an interface is a promise, and if they're doing incompatible things they're not the same interface.
                  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.

                  Comment


                  • Originally posted by ncopa View Post
                    This is a good point. Make me wonder what we can expect 2 years ahead.
                    Change. That's the one thing you should always count on. The world doesn't stand still, just because some people like things the way they are.

                    And I don't mean that as a slight against the anti-systemd crowd - simply as an observation that change happens, and you're better off trying to ride it than to stand in the way.

                    Comment


                    • Originally posted by Delgarde View Post
                      Change. That's the one thing you should always count on. The world doesn't stand still, just because some people like things the way they are.

                      And I don't mean that as a slight against the anti-systemd crowd - simply as an observation that change happens, and you're better off trying to ride it than to stand in the way.
                      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?

                      Change happens, but that doesn't mean that you don't have to evaluate if it is a good change or a bad change, and that also doesn't mean that you don't have to try your best to avoid it if you think that it is not a good change.

                      Comment

                      Working...
                      X