Announcement

Collapse
No announcement yet.

New Group Calls For Boycotting Systemd

Collapse
This topic is closed.
X
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • That page has been there for at least a month or two. And being a static page I'm not really feeling it as a movement. I'm not really a fan of systemd or the design decisions behind it but I don't think reacting to it in that way is productive.

    I was originally very interested in trying out systemd. Then I started to learn about the approach it seemed to be taking. A replacement init system sounds like it could be interesting and good to play with and get to know. A replacement init system and assorted friends is much, much less welcome. I keep seeing in this thread that these extras are optional but which ones? If the core is actually tiny and just a replacement init daemon then which part has the hard dependencies in Gnome and other places? Whether you're for or against it a nod towards the creeping dependencies in common graphical environments is probably the more honest way to talk about it (unless I've missed or misinterpreted something).

    From what I've heard so far systemd began as a replacement init. Then the extras popped up and after other projects became dependent on them we're now at a third stage where Lennart is talking about his real goal which isn't anything to do with init, it's to basically do away with distros. This makes the whole thing look like a long con leading up to a political move. It's a bait and switch and that's not the sort of behavior you want to see from people who want to rewrite your authentication system. To be clear, I don't have a problem with any of the devs working on both init and other daemons and trying to make a standardized environment. But it would look distinctly less shady if they were different projects.

    Because as noted above the system standardization is part of the same project, I don't necessarily know what's going on when I see systemd has been added to a distro. And with most of the discussion about it being people frothing at the mouth in one direction or another (yes, pro-systemd people rant too as you can see in this thread), it gets significantly more difficult to track down useful information about it online. This sets the bar for working with this significantly higher because the only way I would ever accept the radical sorts of changes systemd intends to introduce to my systems is if I understood the logic behind the decisions made. "It's new and popular" makes for an exceptionally bad justification in this case.

    Comment


    • Originally posted by lanir View Post
      That page has been there for at least a month or two. And being a static page I'm not really feeling it as a movement. I'm not really a fan of systemd or the design decisions behind it but I don't think reacting to it in that way is productive.
      Actually I'm pretty sure it's been over a year by this point, maybe 2 since I first saw it being linked.

      Originally posted by lanir View Post
      I was originally very interested in trying out systemd. Then I started to learn about the approach it seemed to be taking. A replacement init system sounds like it could be interesting and good to play with and get to know. A replacement init system and assorted friends is much, much less welcome. I keep seeing in this thread that these extras are optional but which ones? If the core is actually tiny and just a replacement init daemon then which part has the hard dependencies in Gnome and other places? Whether you're for or against it a nod towards the creeping dependencies in common graphical environments is probably the more honest way to talk about it (unless I've missed or misinterpreted something).

      From what I've heard so far systemd began as a replacement init. Then the extras popped up and after other projects became dependent on them we're now at a third stage where Lennart is talking about his real goal which isn't anything to do with init, it's to basically do away with distros. This makes the whole thing look like a long con leading up to a political move. It's a bait and switch and that's not the sort of behavior you want to see from people who want to rewrite your authentication system. To be clear, I don't have a problem with any of the devs working on both init and other daemons and trying to make a standardized environment. But it would look distinctly less shady if they were different projects.

      Because as noted above the system standardization is part of the same project, I don't necessarily know what's going on when I see systemd has been added to a distro. And with most of the discussion about it being people frothing at the mouth in one direction or another (yes, pro-systemd people rant too as you can see in this thread), it gets significantly more difficult to track down useful information about it online. This sets the bar for working with this significantly higher because the only way I would ever accept the radical sorts of changes systemd intends to introduce to my systems is if I understood the logic behind the decisions made. "It's new and popular" makes for an exceptionally bad justification in this case.
      If you want to learn about systemd there's only two authoritative sources of information:

      and
      Posts and writings by Lennart Poettering


      Lennart doesn't even belong to these forums as far as I know, and you really shouldn't expect anything more than punditry on this or any other controversial topic (pulseaudio, wayland, etc) in this forum.

      Comment


      • Originally posted by interested View Post
        So I stand by my point ...

        /sbin is a relict from the old days of doing computing, same with having a separate /usr. The reason why Linux are changing the OS FS layout with regular intervals, is because the old layout doesn't fit the new way of doing things. Same with systemd replacing SysVinit really.
        It is good to stand by one's point, but I hope you got mine, too.

        But, no, if Linux actually had a good concept for a file system layout then it would not need to change it repeatedly. This explains itself. It is the continuous, but often short-sighted evolution of distros where each is trying to do something better, but each then only ends up doing it differently, where some distros now dump all binaries into one directory for example. /sbin is losing its meaning, because static linking has been abandoned for obscure reasons, leading to a huge increase in dependencies for the packages, making a standardization of distros insanely difficult and instead of fixing the original problem together is everyone only creating their own, new problems.

        Comment


        • RedHat story with systemd is not any different from Canonical with Mir. People hate them for exactly same reason. Just like Canonical needs unified desktop/mobile display server they control and don't care much about the rest, RH needs unified init/base system they can rely upon for their enterprise stack and simply don't give a fuck about anything else. Lennart, Sievers & co don't care about different glibc, portability or running without cgroups, so they can't be arsed to implement, test and fix bugs with it - not what they are paid for,*Redhat has no use for it. Resolving as WONTFIX is much easier.

          Comment


          • Originally posted by nslay View Post
            And tell me, what would you do with your desktop environment? Open a terminal and run the same commands you would in single user mode? Spare me. There's nothing obsolete about single user mode, just ignorance about its existence and use.
            Remember that single-user mode only had that very minimal set of binaries, the barest set of tools that could be used for doing repairs? That's the difference... on a bootable image, I've got access to *everything*... if it's not on the image, I can install it.

            Comment


            • There was some talk about how much code is needed...
              All numbers per Dave Wheeler's "sloccount".
              systemd is 228,830 loc, glib is 422,080 loc, dbus is 98,355 loc, libidn is 91,570 loc, kmod is 24,856 loc, pam is 45,788 loc.

              OpenRC is 11,200 loc.
              Busybox is 206,755 loc (including kconfig, vi, two shells, runit, init, cron, dhcp client/server, coreutils, a print server, modutils, mailutils, coreutils, and a whole lot more; much of it you will never use)
              busybox-initscripts (alpine openrc scripts) plus the packaging are 196 lines.

              sysvinit is 7094 loc.

              toybox (includes init and a fair portion of a CLI system) is 37,858 loc.
              To round it out I used openbsd ksh (I actually used loksh) @ 20,941 loc; netbsd sed @ 1860 loc; and openbsd awk @ 9367 loc for a total of 70,026 loc.

              bash is 115,715 loc
              mksh is 26,922 loc
              (debian) dash is 14,167 loc
              (Does anyone see why people complain about bash being bloated?)
              coreutils is 206,654 loc
              util-linux is 118,982 loc

              So sysvinit with busybox and openrc is smaller than systemd alone (even though sysvinit is not needed that way...).
              toybox with openrc would be less than half the size.
              But if it's fair to count the shell against sysvinit, it's fair to count glib, dbus, PAM, etc. against systemd; even glib alone would nearly triple the lines of code.

              coreutils + dash + sysvinit is almost exactly the same size as systemd alone, and adding util-linux (for getty/login) makes it half again as large; but glib makes systemd far larger when including dependencies.

              Comment


              • Originally posted by Delgarde View Post
                Remember that single-user mode only had that very minimal set of binaries, the barest set of tools that could be used for doing repairs? That's the difference... on a bootable image, I've got access to *everything*... if it's not on the image, I can install it.
                But if you know what you're doing, single user works even if you don't have a flash drive or CD handy.
                Yes, that does happen.

                Comment


                • Originally posted by sdack View Post
                  It is good to stand by one's point, but I hope you got mine, too.
                  I think I understand what you were saying, and I could probably agree with some of it, I was merely trying to keep the discussion on the specific topic, instead of meandering off in a tangent about system administration.

                  Originally posted by sdack View Post
                  But, no, if Linux actually had a good concept for a file system layout then it would not need to change it repeatedly. This explains itself. It is the continuous, but often short-sighted evolution of distros where each is trying to do something better, but each then only ends up doing it differently, where some distros now dump all binaries into one directory for example. /sbin is losing its meaning, because static linking has been abandoned for obscure reasons, leading to a huge increase in dependencies for the packages, making a standardization of distros insanely difficult and instead of fixing the original problem together is everyone only creating their own, new problems.
                  Sure, a well designed OS file system layout (FHS) ought to last a long time, but it should also change when needed. It shouldn't be a religious dogma that can't be changed. The Linux FHS have actually changed somewhat over the years. You could call it minor tweaks, but it certainly have changed. There is of course distro variations, and the new FHS 3.0 standard seems only to move very slowly forward, so there is a lot of fragmentation on this at the moment.

                  I think it is natural that the Linux FHS changes with the times, simply because the demands are changing. Once people would connect to a Linux box with telnet to a shell account and compose and send their email from there. Not really a common scenario any more. These days it is all about virtualization, OS containers, massive scaling, rapid deployment, and everything should be automatic.

                  The better Linux can fulfil the modern demands, the more it will be utilised, the more money and job opportunities will it generate. If Linux can't deal with the modern way of doing computing and what people want, then it will wither away like so many other good OS's who stagnated and disappeared.

                  Linux is changing a lot these days, and mostly for the better IMHO. Most of the changes like replacing SysVinit and X.org, and making Linux stateless have been lurking in the background for a decade or more, but due to distro infighting, fragmentation and lack of any centralised Linux development, progress was slow and uneven. I think X11 served well for many years, but it has needed a replacement for a decade or more, so I welcome Wayland and predict that X will become strictly legacy only within a very short timespan.

                  Sure, all these changes means that Linux gradually will look and behave less and less like a 1990 Unix, but I have absolutely no problem with that since Linux is all about solving real world problems, not a to be a historic Unix exhibition.

                  Linux have always been changing with times (this is why it is so successful). A modern day distro is futuristically better than than a 1995 Yggdrasil Linux.

                  Comment


                  • Originally posted by Paul Frederick View Post
                    Me being the user I have to take my own side on this issue. The hardware does not seem to be having a difficult time of handling things on its end either. All of this being the case I fail to understand why we need compiled binaries in the process. That to me is just an extra layer of obfuscation that serves no useful purpose. You're also overlooking the fact that systemd is 10 times larger than the current init system in terms of lines of code. So I'm not seeing how something 10 times larger is, a hell of a lot simpler, as you put it. Quite the opposite seems to be the actual case to me.

                    But if you just keep on saying things enough times they'll come true eventually right?
                    The argument that less code means simpler is malarky for example this perl code snippet:
                    Code:
                    $stringy = "yourname"; foreach $chary (split //, $stringy) { print "$chary\n";}
                    is the exact same as this python snippet

                    Code:
                    stringy = “yourname”
                    for chary in string:
                    print(chary)
                    Pythons looks larger and seems to have more code but that perl snippet is more complex than that python snippet. if i can show that in a couple lines of code that can easily scale upward to a larger project. systemd is larger for good reason it has increased functionality and is safer than the mess that is sysvinit.

                    Comment


                    • Originally posted by Ibidem View Post
                      But if you know what you're doing, single user works even if you don't have a flash drive or CD handy.
                      Yes, that does happen.
                      But does it make sense to build the entire system around that contingency - that the admin doesn't have a bootable USB stick already sitting on his desk, doesn't have the ability to download one on-demand, *and* can repair the system using nothing but the minimal tools in /{s,}bin (assuming those haven't been hosed along with the rest of the system)? This seems a very niche use-case...

                      Comment

                      Working...
                      X