Announcement

Collapse
No announcement yet.

Devuan: Debian Without Systemd

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

  • #61
    Originally posted by omer666 View Post
    I don't get why everyone's still arguing on this point in the Phoronix forums, as this has long been forgotten in the many other places I visit on the internet. I still don't understand what's so bad about systemd compared to sysvinit, apart from its being "too monolithic". Isn't the Linux kernel very monolithic too?
    Kernel provides a low level hardware abstraction. This is much easier said than done so in reality kernels are very complex but they still serve just this one purpose - being a low level hardware abstraction provider. Monolithic kernel has all its subsystems operating in kernel space (vs. user space) but a microkernel OS has the same (or very similar) subsystems except most of them are operating in user space.

    Systemd on the other hand doesn't do one thing. It tries to be everything, including (at this point) a webserver. It also ends up being a dependency for e.g. desktop environments (via logind) which locks them in the Linux ecosystem which limits their portability to other *NIX systems.

    Originally posted by omer666 View Post
    I'm an end user, which, if I understand correctly, means that I'm an inexperienced moron.
    Nobody said that. But imagine yourself discussing heart surgery with someone who has actually been doing it for 20 years. How much of good advice you'd be able to offer?
    Last edited by prodigy_; 29 November 2014, 08:29 AM.

    Comment


    • #62
      Watching the systemd fiasco continue to unfold from my perfect FreeBSD Unix workstation.

      systemd - it's funny because it's not happening to me.

      Comment


      • #63
        Originally posted by ryao View Post
        It (OpenRC /ermo) actually has some traction, but you make a valid point about documentation. The project simply does not have enough people writing documentation. This is something that I will forward.
        Apropos documentation:

        The Gentoo-maintained OpenRC page at http://www.gentoo.org/proj/en/base/openrc/ states that "You can also find the source code in the OpenRC git tree."

        Now, I've tried to reach the Gentoo OpenRC git tree via the above link (http://git.overlays.gentoo.org/gitwe...roj/openrc.git) a couple of times during the past month without success. Is the documentation out of date? Is the link invalid? Is there another link that I should be using? FWIW, OpenRC seems to be available on github -- is this the canonical way to reach the Gentoo OpenRC git repository via the web?

        For reference, the systemd project page on the freedesktop.org wiki includes valid a link to a web-accessible git tree and the systemd git tree on github is clearly marked as being a mirror of said git tree.


        Thanks.

        Comment


        • #64
          Originally posted by prodigy_ View Post
          Kernel provides a low level hardware abstraction. This is much easier said than done so in reality kernels are very complex but they still serve just this one purpose - being a low level hardware abstraction provider. Monolithic kernel has all its subsystems operating in kernel space (vs. user space) but a microkernel OS has the same (or very similar) subsystems except most of them are operating in user space.

          Systemd on the other hand doesn't do one thing. It tries to be everything, including (at this point) a webserver. It also ends up being a dependency for e.g. desktop environments (via logind) which locks them in the Linux ecosystem which limits their portability to other *NIX systems.
          systemd does not try to be a webserver. There is an optional service, which is built by default, but disabled unless explicitly enabled, that allows getting access to the journal logs over HTTP/JSON. It can be useful for debugging. If you don't like it, don't enable it?

          Comment


          • #65
            You little Linux kiddies realize that the rest of the computing world is laughing at you...right?

            You were dumb enough to let some incompetent clown trash the very foundation of your OS with his POS pet project.

            One would think that the massive damage done in the past by similar incompetent clowns in the past like Miguel de Icaza that you Linux kiddies would have said to yourself "Never Again."

            Comment


            • #66
              Originally posted by jonnor View Post
              systemd does not try to be a webserver. There is an optional service, which is built by default, but disabled unless explicitly enabled, that allows getting access to the journal logs over HTTP/JSON. It can be useful for debugging. If you don't like it, don't enable it?
              Should we also start complaining about the even bigger umbrella project GNU next?

              Comment


              • #67
                "lock-in promoted by systemd"

                20 years of sysvinit lock-in gave all linux distributions a huge technology boost...

                Comment


                • #68
                  Originally posted by ryao View Post
                  From my perspective, the systemd camp is mostly comprised of an end users who are vulnerable to hype and less experienced developers while the sysvinit camp is mostly compromised of system administrators and veteran developers.
                  What makes you think that? So far the adoption of systemd has been driven by distribution developers (who decide to ship/default to sytemd) and other upstream developers (who decide to make use of / depend on systemd). Notice that of all the major (i.e., all the ones big enough that I know their name) distributions that changed init systems since systemd was introduced, every single one changed to systemd, and whilst a lot of projects now come with upstream systemd integration, the same is not the case for alternative init systems.

                  Unless you want to claim that the vast majority of distribution and upstream developers are "less experienced", I don't understand how this claim makes any sense.

                  He makes some fairly good points about backward compatibility and pluggability. These are things that the systemd camp could easily implement while achieving their goals, but so far, refuse to implement.
                  I disagree. This would come at significant cost. However, my opinion is not important. If it is so easy to do, then it would also be easy to keep a downstream patchset until upstream has been convinced.

                  In addition, Ted T'so, another Debian developer and the Linux ext4 subsystem maintainer, made a fairly detailed blog post criticizing systemd's design from the aspect of debugging:

                  Note:  This blog post outlines upcoming changes to Google Currents for Workspace users. For information on the previous deprecation of Googl...


                  These are all valid points that unfortunately are being ignored.
                  He made precisely one claim related to systemd (the rest wast about polkit/NetworkManager/Gnome/...): "I do find it very difficult sometimes to figure out why a particular systemd service gets started". This was _not_ ignored, but discussed at great length in the comments (also by yours truly). Several suggestions were made there, but patches are certainly welcome if things can be improved further.

                  More worrisome is that systemd proponents are typically end users or rookie developers who do not understand what they are discussing.
                  Where do you get this idea from?

                  The original method of booting Linux systems involved two components called sysvinit and sysvrc. The scripts exist solely in sysvrc and can be easily be replaced with alternatives, such as OpenRC. Similarly, sysvinit can be replaced with BSD init on both Gentoo FreeBSD and Debian GNU/kFreeBSD. In systemd, there is no distinction.
                  I think this distinction is clear to most people who take part in these discussions (at least that's my impression).

                  Proponents of systemd consistently prescribe weaknesses of sysvrc to sysvinit and consider systemd is the only way of solving them. Many of the "firsts" prescribed to systemd were solved by Gentoo's OpenRC before systemd existed. Some examples are fine grained dependencies, named run levels, the elimination of `sleep` and disabling services by default (a weakness of upstart where everything is started by default). Consequently, it is absurd to say that sysinit was the problem when replacing sysvrc with OpenRC solves these issues.
                  I think this is really missing the point of systemd. Much more important are things like race-free dbus/socket/time/path/device activation, and hence moving from explicit to implicit dependencies. Until OpenRC addresses these basic things it is just a minor improvement over sysvinit+sysvrc.

                  As to the split between sysvint and sysvrc, this is, I belive, entirely due to sysvinit's deficiencies. In principle you don't need sysvrc at all, as sysvinit's inittab file allows you to define how/when to start/stop/restart services. However, inittab is not powerful enough to manage more than a very basic system, so therefore things like OpenRC/sysvrc had to be bolted on top (rendering sysvinit essentially useless as its most prominent feature is largely unused).

                  What systemd essentially did was to beef up the inittab format (each inittab line corresponds to a .service file) to the extent that things like sysvrc/OpenRC are redundant.

                  That said, systemd's socket-based activaton is a good idea that systemd had first.
                  Nope, systemd did not have that idea first. The most obvious predecessor is launchd, but even inetd, dbus and other projects had similar concepts.

                  systemd's ability to capitalize on that is hamstrung by its inability to place nicely with others.
                  How are we not "playing nice with others"? Sure there is a very vocal minority who simply don't want to use systemd, but apart from "going away", there is nothing we can do to placate them. We do however, have great collaborations with all the other upstream projects that we interact with (yes, even the kernel, despite the occasionall flamefest), and also with the various downsrteam distributions. I believe all the major distributions have committ access to the systemd git repositor, we have open hack-fests several times a year that anyone may join (and lots of people do), and we have a very friendly and open mailinglist where all contributions are welcome, and most are merged (but obviously not all).

                  If the systemd developers were open to addressing issues such as pluggability, they would have *much* better success than they are having now
                  Hm, in what way could we be more successful? It seems that in all the ways that matter, we are achieving what we set out to do (and more)...

                  and could compete on technical merit, rather than hype.
                  Where do you get this from? It is quite a strong claim to make that all the distros and upstream who default to/integrate with systemd did so merely based on hype, and not on technical merit. Just see the very detailed analysis done by the Debian technical committee. All the peolpe involved there obviously did their homework very well, and whatever they voted and however they acted, it certainly did not have the appearance of anything being motivated by 'hype'. The same holds (but less publicly) for the other distributions, and in particular in the case of Arch Linux (where I was involved with moving to systemd) we also studied OpenRC before making the decision (in addition to our own initscripts which I was the maintainer of).

                  Also, being open does not mean claiming to accept patches and then rejecting them when someone is foolish enough to believe them (as I once was), but actively pursuing it themselves.
                  Not every patch is accepted. However, you hopefully got a detailed explanation as to why your patch was not accepted (I could not find your patch in the ML archives, but I see that you have had at least one patch accepted). There are a few design decisions that preclude a certain type of patches, but what this applies to should be pretty obvious if you follow the development for some time. Even if your patch is not accepted, you could always keep it locally/downstream if you believe in it strongly (I mean that is what these crazy uselessd/eudev people should be doing rather than hacking the codebase to pieces before they even get started, just keep a minimal patch-set with the things they could not get accepted upstream).

                  In addition, it is likely possible to implement socket-based activation in script-based init systems. If that and other ideas in systemd had been done in this manner, there would have likely been no controversy.
                  Doing socket-activation in pure shell does not seem all that easy, but you could probably hack something together using systemd-activate as a wrapper. Not something I would consider pretty, but it certainly should be possible.

                  Lastly, the emphasis on unification by certain parties is so great that it is essentially bullying and this likely has lead to counter bullying. This is counter to the principles of free and open source software, where people are supposed to be able to take, modify and redistribute software for any purpose. Spreading the idea that they cannot be different is to convene the license terms. This is something done exclusively by systemd proponents. However, it would make sense to think that the systemd proponents feel similarly coerced by he idea that things be pluggable. The idea that everyone must use the same software is no different than the idea that everyone must wear the same clothes, eat the same food and have the same number of possessions.
                  I do not believe your interpretation of the principles of free software is a commonly accepted one. That said, systemd is not about coercing anyone to do anything, so any unification that we achieved was not done by force. It was done by collaboration and technical pursuation (playing well with others).

                  Diversity and competition can be good. But meaningless diversity is not. I.e., if you have two isomorphic ways of doing the same thing that are different for no purpose (i.e., in what file you store your hostname, or your locale settings, ...) it is simply a waste of time. Moreover, competition where one part is vastly superior to the other is not helpful to anyone and also I would claim a waste of time (as there is nothing to learn from eachother). Early upstart was an interesting 'competitor' to systemd, SMF is interesting, launchd is interesting, Lennart is very excited about procd (but I haven't looked myself). sysvinit is not interesting, nor is OpenRC.

                  Comment


                  • #69
                    Originally posted by michal View Post
                    "lock-in promoted by systemd"

                    20 years of sysvinit lock-in gave all linux distributions a huge technology boost...
                    Another example of a very long vendor lock-in would be gcc. We have separate gnu89, gnu99 etc language standards that are default for gcc so developers end up writing unportable code if they don't know better. Now with LLVM they tried to be innovative with compiler stack which resulted in clang having to implement large amounts of gcc peculiarities because otherwise code doesn't compile. Lock-in's looking harmless is pretty much an illusion that breaks when you find out you *want* to replace it

                    Comment


                    • #70
                      Originally posted by nanonyme View Post
                      Another example of a very long vendor lock-in would be gcc. We have separate gnu89, gnu99 etc language standards that are default for gcc so developers end up writing unportable code if they don't know better. Now with LLVM they tried to be innovative with compiler stack which resulted in clang having to implement large amounts of gcc peculiarities because otherwise code doesn't compile. Lock-in's looking harmless is pretty much an illusion that breaks when you find out you *want* to replace it
                      That's an argument for systemd. It's the equivalent to the newcomers in this space, like llvm.

                      Comment

                      Working...
                      X