Announcement

Collapse
No announcement yet.

Using Udev Without Systemd Is Going To Become Harder

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

  • #51
    Originally posted by Drago View Post
    Gentoo used the wrong kernel then. They should have used something way more modular, like some micro-kernel, which they can chop off as they want. And Instead they are using that monolitic bloat - Linux.
    Let's clarify a bit...

    Gentoo doesn't use any specific kernel. Gentoo Linux is only one part of Gentoo. Gentoo is a meta-distribution, where meta- means pretty much that you can build your own kind of system from nearly scratch, and the Gentoo FreeBSD project for example allows you to run Gentoo with FreeBSD kernel on a GNU userland. Gentoo Prefix project allows you to install Gentoo Portage to eg. Darwin (MacOSX), Solaris, AIX, HP-UX, and much more.

    So, it would be relatively easy to port Gentoo to whatever micro-kernel, if there was enough demand for something like that. The Package Manager, Portage, allows you to do exactly that.

    Comment


    • #52
      Reading the complete systemd discussion related to Drop the udev firmware loader patch gives more accurate explaination than the sensasionalism seems to imply just because one of the repliers is Poettering.
      The point was about obsolete kernels being unsupported to the newest version of systemd which impacts distributions like Gentoo and Debian. Given tthe latest stable kernel release i.e. 3.15 and longterm support i.e. 3.14, both can simply
      switch to them should they want to support the latest features of systemd. In this case, Gentoo and Debian are downstream, it is their job to keep up with upstream.
      As usual, most systemd detractors spent their times posting here about their personal vendetta whie doing nothing by at least contribute to alternative during the five years after systemd came out amd propose them to upstream. It becomes clean who are the real opponents slowing down the evolution of Linux as a complete operating system.

      Comment


      • #53
        Originally posted by bkor View Post
        Can you give arguments other than "yes it is"? This feels like kindergarten!
        yes
        and saying that it isn't without an argument also is

        choice is in the design
        almost everything in the kernel is optional (CK's BFS scheduler pushes that even further)
        you can have a network without a filesystem
        you can have a filesystem without the network stack

        actually there is not that much in the core kernel
        scheduler, mm are mandatory (for obvious reasons)
        everything else, including the thousands of drivers, is optional

        and the kernel will never fail because you have a different desktop environment or init system or anything
        kernel will be happy if you run only one program on it and will do the same if you run a thousand programs with hundreds of users from all around the world and many users with mice and keyboards over a usb hub and multiple monitors
        and you don't even need a hdd to do that as you can boot from a network or a usb stick (you can even remove it then)

        so ye, the kernel is awesome
        it can do anything because of the simple design

        Comment


        • #54
          Originally posted by gens View Post
          dbus instead of netlink for loading firmware is not "forward"
          netlink is newer and less idiotic (and made for this kind of things)

          just stop with the "future" crap
          it's the people writing the drivers for devices and people writing graphics and input protocols that drive linux forward, not one "visionary"
          i think it's not as you say. dbus will probably be used to request/load firmware from service exposing that interface. with dbus as it is slowdowns are a bit unpredictable, with kdbus... not. it will probably be more or less the same service as it was, just requests and responses will be better and easier to control.

          dbus it self is nothing but ipc, you can't make it do load firmware. service that exposes interface with methods like load... dbus only shows that interface as POI and has features like API introspection, security...

          and one of weak points on linux always was lack of some high speed full featured ipc. well, more or less every os on this planet has the same problem. they have better or worse system ipc, but each lacks one or another feature. and as far as i used ipc on various oses dbus is by far best to implement. this has to be said here, dbus implementation in vala simply rocks.

          Comment


          • #55
            Originally posted by JustADirtyLurker View Post
            If systemd is finally widespread this could also lead to, finally, have some standardization at the base OS level. Quite frankly, I'm tired of all the "choice" we have.
            If you want a standardized OS controlled by a single company then go pick up what Microsoft or Apple are offering.

            And when they drop a turd on your plate you will have no choice but to eat it.

            Comment


            • #56
              Originally posted by teresaejunior View Post
              I hate Lennart's attitude, he acts just as a annoying spoiled kid. You either love and praise him, or be ridiculed.
              Considering how much hate he constantly gets from within Gentoo, he shows incredible restraint.

              Just look how he's been referred to as cancer here.
              But that's probably the kind of people you get when they have to kill time all day while compiling their operating system every week

              Comment


              • #57
                Originally posted by erendorn View Post
                Modular makes designing and building harder, but maintenance easier.
                you should ask xorg how that went for them

                you don't need just "make it modular", you have to make it the right way

                Comment


                • #58
                  Originally posted by johnc View Post
                  If you want a standardized OS controlled by a single company then go pick up what Microsoft or Apple are offering.

                  And when they drop a turd on your plate you will have no choice but to eat it.


                  Bullshit. First of all I never said something like that. I don't want a standardized OS, the user will be still free to use KDE over Gnome, Wayland over Mir, distribution X over distribution Y.

                  The kernel seems pretty much the lone offer of its kind, isn't it? it's not that anyone can't fork it if they want. Nonetheless, it's there all alone. Why? because there's no need.
                  It will be the same with systemd as core os component. live with it.

                  But hey, if you can't, fork the project and good luck.

                  Comment


                  • #59
                    Originally posted by justmy2cents View Post
                    i think it's not as you say. dbus will probably be used to request/load firmware from service exposing that interface. with dbus as it is slowdowns are a bit unpredictable, with kdbus... not. it will probably be more or less the same service as it was, just requests and responses will be better and easier to control.

                    dbus it self is nothing but ipc, you can't make it do load firmware. service that exposes interface with methods like load... dbus only shows that interface as POI and has features like API introspection, security...

                    and one of weak points on linux always was lack of some high speed full featured ipc. well, more or less every os on this planet has the same problem. they have better or worse system ipc, but each lacks one or another feature. and as far as i used ipc on various oses dbus is by far best to implement. this has to be said here, dbus implementation in vala simply rocks.
                    again, check out the protocols
                    netlink IS simpler and since it is not buffered it is, theoretically, lower overhead (and since it is not buffered it supports "mmaped" IPC, and there is no faster IPC then direct memory sharing)

                    firmware is just a bunch of bytes that the kernel sends to a device
                    how you get it to the kernel is another topic (in most cases the kernel gets it itself and that's why firmware is in /lib/firmware/, a path hardcoded in the kernel)
                    if you ask me there is nothing wrong with sending it over netlink
                    further more netlink is the standard to talk low level to device drivers
                    if i am wrong feel free to tell me why (and no "future" please, i like science more)
                    Last edited by gens; 07 July 2014, 01:25 PM.

                    Comment


                    • #60
                      Originally posted by gens View Post
                      how is netlink not secure ?

                      dbus is way more complicated then netlink, and netlink can be waaaaaay faster then even kdbus
                      so what are you talking about, what code
                      would you mind pointing me to that code ?

                      PS i was talking about dbus as a protocol, it is called that
                      well 2 things first that i see people get confused about this

                      1.) Regular firmwares already in the kernel tree are normally handled in the kernel from a long ago
                      2.) this is more for ondemand firmwares like HP printers, certain USB devices, certain WiFi cards, etc. that today are horrible to use in linux

                      1.) how is netlink not secure? this is not about security like hackeable but interprocess de/marshalling, i didn't meant it as this make defective but it wasn't designed for IPC in CGroup and container ages
                      2.) dbus is way more complicated then netlink, and netlink can be waaaaaay faster then even kdbus!! no necessarily since KDBUS (require an additional patch) don't pass data around like netlink, KDBUS pass only fd's and handle de/marshaling(infrastructure) and other advantages from dbus for free without reach userspace unless is really needed.

                      So when you need to for example load an HP printer firmware but only from CUPS base process in the main host, KDBUS can be much faster in the whole process even so netlink can pass raw data faster because you chop the bigger time killer -> userspace de/marshalling,cgroups querying, etc.

                      don't take this religiously, is a very very simplified explanation but i think the generic idea is there. Additionally remember this changes are theoretical at this stage so benchmarks aren't even possible yet, so any actual comparison will have to wait until the code is complete

                      Comment

                      Working...
                      X