Announcement

Collapse
No announcement yet.

systemd Breached One Million Lines Of Code In 2017

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

  • #41
    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.
    Seems like you don't understand systemd or what it does or why the tools exist so you blame the tool. You need to learn how to configure it for your purpose.

    Comment


    • #42
      Originally posted by rene View Post
      did it replace the Linux kernel already and become a freestanding OS yet? ;-)
      pottering's friends at red hat have already made an attempt to slip into the kernel with their dbus implementation for kernel. Again no one ever asked for it but they thought they know the best how to implement it. Fortunately they were sent back away. Hope they never come back

      Comment


      • #43
        Originally posted by rtfazeberdee View Post

        Seems like you don't understand systemd or what it does or why the tools exist so you blame the tool. You need to learn how to configure it for your purpose.
        that's the point. People need to learn how to configure it while they don't need the tool in the first place. Ain't nobody has time to dig 1M loc

        Comment


        • #44
          Originally posted by pal666 View Post
          no one of voices in your head? nobody cares about voices in your head
          feel free to produce distro for idiots, it will surely be popular
          sorry, can't help you with a distro

          Comment


          • #45
            Originally posted by finalzone View Post

            Despite all these infos provided by even UNIX veterans, some people choose to ignore them and stick to their assumptions.
            No one gives a flying fuck about "Unix veterans". This isn't a religion or a person cult like North Korea.

            Comment


            • #46
              Originally posted by InsideJob View Post
              SystemD is an excellent office suite. It's more orderly than libreoffice and has fewer lines of code too. Why don't the haters and trolls recognize this fact? Linux rules on the desktop today because of people like Poettering.
              Try installing a Linux distribution from the early 90ies and you will realize that you couldn't be any more wrong.

              It's modern software like systemd, udev, dbus in distributions like Ubuntu which actually made Linux usable on the desktop for a large number of users.

              Comment


              • #47
                Originally posted by pjezek View Post
                Good job, but isn't it the right time to cleaning up the code? More rows of the code have not significant correlation with quality of the code.
                You do realize that your first question completely contradicts your second statement, no?

                Comment


                • #48
                  Originally posted by Luke_Wolf View Post
                  A million lines of code? Sounds about time for it to be all rewritten in Rust
                  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.

                  Comment


                  • #49
                    Originally posted by torsionbar28 View Post
                    Not sure that I agree with you there. The boot messages scroll by so fast on a modern computer that it's almost useless. Sure, on my first PC back in the early 1990's, an i486 DX 33Mhz with 8 MB of RAM, booting up Slackware took minutes and you could read each message in detail - but this doesn't work anymore on modern hardware, particularly on machines booting from SSD.

                    Run 'dmesg' if you want to see the kernel messages since bootup, and 'cat /var/log/boot.log' to see the screen output of the init system starting up the services. Between those two, you have a complete picture of the machine's boot process, without having to read at Superman speed where if you blink you've missed it.

                    FWIW I've been on Red Hat for 23 years (since 1995) and have Red Hat certification on RHEL 5, 6, and 7.
                    Instead now you can just type "journalctl" and you will get dmesg+var/log/boot.log+/var/log/syslog including logs from services that in sysv you could not even get logs from since they started before there where a filesystem.

                    Comment


                    • #50
                      Originally posted by torsionbar28 View Post
                      Not sure that I agree with you there. The boot messages scroll by so fast on a modern computer that it's almost useless. Sure, on my first PC back in the early 1990's, an i486 DX 33Mhz with 8 MB of RAM, booting up Slackware took minutes and you could read each message in detail - but this doesn't work anymore on modern hardware, particularly on machines booting from SSD.

                      Run 'dmesg' if you want to see the kernel messages since bootup, and 'cat /var/log/boot.log' to see the screen output of the init system starting up the services. Between those two, you have a complete picture of the machine's boot process, without having to read at Superman speed where if you blink you've missed it.

                      FWIW I've been on Red Hat for 23 years (since 1995) and have Red Hat certification on RHEL 5, 6, and 7.
                      It will be too fast to see something like a service failing to start. Although with color output, I can see the red "error" message fly by and know _something_ didn't start correctly. But more importantly, if there is a kernel panic or something severe enough that it halts the whole system, it's nice to have terminal text visible to see what happened.

                      Comment

                      Working...
                      X