Announcement

Collapse
No announcement yet.

systemd Breached One Million Lines Of Code In 2017

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

  • #51
    Originally posted by flux242 View Post
    yes, we are well aware that systemd is a set of tools. But in many cases no one asked for them.
    Exactly. The Debian, Fedora, Red Hat, Ubuntu, Gentoo (optionally), and Arch maintainers all said, "There's a new thing none of us asked for. What the hell, throw it in!" Right?

    Originally posted by flux242 View Post
    The only reason why such tools exist is because pottering think that he knows better how to implement it.
    Poettering wrote dozens of detailed blog posts on other articles on what he was doing and why. See http://0pointer.net/blog/archives.html and https://www.freedesktop.org/wiki/Software/systemd/

    Originally posted by flux242 View Post
    For example one of the first things that canonical so called devs broke by switching to sysytemd was power management. Lid close events were not configurable in xfce4-power-manager, neither pm-utils hooks were called any longer (i don't care if it's outdated or not, i'm still using it). Now systemd creates lots of garbage files all over the place (like binary log blobs) which makes it harder to control. For embedded systems is is crucial because of limited NAND erase cycles. How can I use a circular log buffer in memory with systemd? So currently systemd works full scale in embedded linux distributions there because nobody were able to separate so called systemd set of tools from each other for some reason. Is million loc the reason maybe? And no, I can't get rid of systemd because distr packages rely of systemd and to ditch it i'd have to package myself which would render distr useless for me.
    Wait, so the Xubuntu team shipped a bug in a release, and it's the fault of systemd?

    As others said, you can set the systemd journal not to persist. It's not hard, you just change a text file and restart the service (or restart the machine).

    The distribution maintainers picked it because they like it. You and I don't have the right to yell at the people making Debian, or Fedora, or Void, or Devuan, or any other distribution and tell them they have to use the software we want. They can do whatever they damn well please. If we don't like it, we can switch to a distribution that does what we want or make our own (systemd is optional in Gentoo and removed in Void and Devuan. I never used Devuan but Gentoo and Void are awesome. So give them a go.)

    Comment


    • #52
      Originally posted by flux242 View Post
      yes, we are well aware that systemd is a set of tools. But in many cases no one asked for them. The only reason why such tools exist is because pottering think that he knows better how to implement it. For example one of the first things that canonical so called devs broke by switching to sysytemd was power management. Lid close events were not configurable in xfce4-power-manager, neither pm-utils hooks were called any longer (i don't care if it's outdated or not, i'm still using it). Now systemd creates lots of garbage files all over the place (like binary log blobs) which makes it harder to control. For embedded systems is is crucial because of limited NAND erase cycles. How can I use a circular log buffer in memory with systemd? So currently systemd works full scale in embedded linux distributions there because nobody were able to separate so called systemd set of tools from each other for some reason. Is million loc the reason maybe? And no, I can't get rid of systemd because distr packages rely of systemd and to ditch it i'd have to package myself which would render distr useless for me.
      Make up your mind, either no one asked for these tools or no distribution started to use them. You have to choose just one of the two, they are mutually exclusive. And the tools are not used unless you specifically use them, yes a distribution can choose to install and enable them but they can also choose not to, and so too can any user (I run i.e dnsmasq instead of systemd-resolved).

      Comment


      • #53
        Originally posted by emblemparade View Post

        How dare you use facts against the raging mob! /s

        But yes, systemd is two things: 1) an init system, which is actually a tiny little service, and nothing too radical or clever, 2) a big project including not only the init system, but also rewrites of many system services in a way that would not only integrate much better with the new init system (no more "sleep 1" farces in System V init scripts), but also work more consistently with each other, having smart and configurable inter-dependencies and with a unified system log (also part of systemd).

        All in all, if all systemd components work well, it will be a huge step forward for all of us. Before systemd, other operating systems had much more robust service management than Linux. It was honestly embarrassing! To be honest, even with systemd in its current state, Windows is so much more ahead and more robust, since it has a mature init system since the days Windows NT 4. You read that right: we still have a ways to go to catch up with the year 2000 in Windows.

        And no, Linux distributions do not have to use the whole project: they can just use the init system with the older components. Indeed Linux distros tend to decide on a case-by-case basis.

        Any rewrite introduces regressions (bugs that have been already been solved), so it will take time to mature. If you're upset about these bugs, perhaps blame your Linux distribution for including these components before they have matured enough. Many people want "cutting edge" distros, but hypocritically the same people get angry about systemd bugs. If you want to be "cutting edge" you are essentially agreeing to beta test new software. Expect bugs.
        Wait, in what way do you find the System Services in Windows to be a better init system? IMHO it's way worse than even old sysv and the existing tools to control it are extremely limited (don't know if that have changed with power shell though) and coding for it is absolutely ridiculous (yes you have to add code in order to use it). The dependency systems is complicated as fuck without being advanced/complex and the only thing that I can see that it ever had over sysv was that it could automatically restart crashed services.

        Comment


        • #54
          Well that's just great! Not only has systemd destroyed "Linux as we know it (TM)", now it is going around breaching over a million additional source codes! Where will this madness stop?

          LOL, Yeah, I know, that doesn't make any sense. Neither do most of the other "systemd will eat your baby!" posts we get around here (and everywhere else). To each his own, but the anti-systemd brigade sure gets tiresome.

          Happy New Year!

          Comment


          • #55
            Originally posted by monraaf View Post

            You mean that Rust that becomes incompatible to itself with every new minor release?

            Rust is FAR from being used for anything serious besides Firefox because of that. No enterprise distribution that isn't out of their mind would use plumberland written in Rust unless the language actually becomes stable.
            I'm pretty sure that was supposed to be a joke.

            Comment


            • #56
              Originally posted by F.Ultra View Post

              Wait, in what way do you find the System Services in Windows to be a better init system? IMHO it's way worse than even old sysv and the existing tools to control it are extremely limited (don't know if that have changed with power shell though) and coding for it is absolutely ridiculous (yes you have to add code in order to use it). The dependency systems is complicated as fuck without being advanced/complex and the only thing that I can see that it ever had over sysv was that it could automatically restart crashed services.
              Like it or not System Services for Windows used properly in NT 3.5 was better than sysv init. People forget services in NT 3.5 could not open graphical windows because they were disconnected from the user session. Normal Microsoft they went for convenience over security and broke it. Even the introduction of session 0 in latter windows does not really fix it back to NT 3.5.

              Key advantages the old NT 3.5 system services and Systemd have over Sysvinit.
              1) The ability to tell if any process of a service is still running even if that process has forked off.
              2) The ability to absolutely shutdown a service including any part that had forked off.
              3) The ability that when you told system management to restart a service that it would because the system management could stop all the service then start it clean again where under sysvinit this could fail.

              NT 3.5 did not have automatic service restarting instead of crash they just stayed down and also did not have dependency boot either.

              Sysvinit was not design for the Linux kernel. Sysvinit is not design for a operating system that can recycle process id numbers what a true sysv OS did was just keep on increase PID number when it reached maximum kernel panic it was why fork bombs in them were so deadly. Linux kernel recycles process id numbers.

              Reality is sysvinit should have been got rid of years ago. BSD init in fact has proper dependency boot.

              Also the million lines of code. If you go back to 1990s Take a close look at all the part being used to init the system and provide key supporting parts you find over a million lines of code spreed over 500 projects that systemd in modern distributions replace. Next when you look at that over 500 projects you find that most were not being maintained properly where CVE bugs were left open for years to decades.

              Now those who don't like systemd I am not going to say you are wrong. There is no question making the arguement to remain on sysvinit is wrong when it technically incompatible with the kernel in usage. I take my hats off to Gentoo and TrueOS developers who are working on openrc because they don't like systemd .

              The reality is lot of the historic init systems used on Linux attempted to be operating system neutral. The result is they were all incompatible with the Linux/BSD kernel in different ways. Systemd lead developer did get that fact right. There are kernel dependant stuff that any init system need to be aware of if it not its broken.

              Really there is no clear define of a list of tests a init system/ service management has to pass to be classed as production useful. Sysvinit was a defacto standard not a standard where we all sat down and wrote what a init system/service management must do.

              Even systemd is still going the defacto standard route. At some point we will wake up and truly standardise the init and service management requirements.

              Comment


              • #57
                Not even the systemd repository reached 1,000,000 lines of code, per everyone's favourite Lennart:

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


                it reached 1,000,000 lines of *stuff*. Including documentation. It has about 342,000 lines of *code*.

                Comment


                • #58
                  I don't think Lennart has a specific goal set for lines of code in systemd. His set goal is rather that other software shall contribute no more than zero lines of code to any given Linux distribution, having been replaced with systemd. And nobody shall dare to question any of systemd's code lines, as they are a divine given that cannot possibly be wrong. And nobody should dare to ask for (even previously existing) features in those distributions, as everything that systemd does not support must be an ill-conceived, if not heretic, idea.

                  Comment


                  • #59
                    from Lennart himself in G+
                    Lennart Poettering


                    Uh, so Phoronix is being Phoronix, and reports quite misleading news. Let me quickly put a few things straight: first of all, "one million lines of code" is really misleading, as that appears to be raw lines of files managed by git. Since we carry large amount of documentation the actual lines of code are much lower. Using a tool like "sloccount" for counting lines of code reveals systemd currently carries ~342K lines of code, of which ~318K are proper C code. Which isn't actually that much. To put things into perspective, as one example wpa_supplicant alone has ~451K lines of code, of which ~351K are proper C code. I think as long as the supposedly huge systemd tree with all its components, such as resolved, networkd, timesyncd, nspawn, journald, and so on only reaches 75% of the size of the codebase of you frickin wifi subsystem, I think we are good, aren't we?

                    I mean, sure, apples, oranges and stuff, but still…

                    (and yeah, even stuff such as supposedly "lean" projects such as uclibc weigh 329K lines of code already…)
                    Last edited by Anvil; 03 January 2018, 05:28 AM.

                    Comment


                    • #60
                      Originally posted by AdamW View Post
                      Not even the systemd repository reached 1,000,000 lines of code, per everyone's favourite Lennart:

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


                      it reached 1,000,000 lines of *stuff*. Including documentation. It has about 342,000 lines of *code*.
                      I missed that point the 1990s mess was over million lines of code not documentation. Systemd is in fact smaller in lines of code than the fragmented mess that was before it.

                      Its simple to forget items like hald, consolekit.....that have disappeared out modern distributions and most of the stuff that has disappear was also very poorly documented. Systemd has in some ways accelerated some of the clean ups.

                      Comment

                      Working...
                      X