Announcement

Collapse
No announcement yet.

Lennart: The State & Future Of Systemd

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

  • #71
    Originally posted by johnc View Post
    That's a pretty good point. I should throw something together that's designed to thwart Canonical in some way and I'm sure I'd get an offer from RH the day it hits GitHub.

    Not that I would work there anyway.
    It has been said numerous times before: All you do is saying that people/companies/projects/etc are irrelevant, hurtful, etc. You're alienating pretty much everyone. As a troll, you're rather poor (you behave pretty much like people say you will). If you're not attempting to troll, then that's weak too because of all of the alienating.

    Comment


    • #72
      Originally posted by bkor View Post
      It has been said numerous times before: All you do is saying that people/companies/projects/etc are irrelevant, hurtful, etc. You're alienating pretty much everyone. As a troll, you're rather poor (you behave pretty much like people say you will). If you're not attempting to troll, then that's weak too because of all of the alienating.
      Somebody from the GNOME project feels upset about being alienated?

      Isn't this the same group that basically told its users to f off?

      Comment


      • #73
        Originally posted by johnc View Post
        Somebody from the GNOME project feels upset about being alienated?

        Isn't this the same group that basically told its users to f off?
        SO you're just trolling and alienating. Good luck with your systemd panick attacks :P

        Comment


        • #74
          Originally posted by interested View Post
          I think you other question shows you haven't read up on systemd. systemd actually integrate with third party software like ntpd, in fact that is a major point of systemd that it provides such generic layers between programs and end users
          ..
          The point is, that these systemd services and utils doesn't have any inbuilt ntp client at all, they just use whatever version of ntp the distro have installed as their canonical ntp solution. So the distro can change ntp implementation, but all command line utils and their syntax will remain the same, just like they work the same way across all systemd distros, regardless of what ntp solution they use.

          So the official systemd way of using ntp, is using third party solutions. systemd just provide a comparability layer for such third party solutions.
          Actually I have read up on systemd many times, and on NTP I was going by what Lennart wrote himself on his blogs, which gave me a disturbing impression and the guy does have a track record of taking a view, justifying it with a parody appraisal of alternatives setting up straw men.

          When he claims systemd has NTP daemon service now or DHCP, it sounds like an embrace and extend, if that's not the case, he's DOING a very poor job of explaining his features. Something along the lines of "integrates the system provided SNTP daemon" would be clear.

          The stuff about syntax is hardly impressive, the old sys V init had a standard pattern, something like /etc/init.d/<daemon> start, and package installers even had LSB hooks to set up such services correctly in a standard way.

          Perhaps you have a way round the most troubling systemd feature? That pid 1, is reliant on Dbus which is subject regularly to security updates and unfortunately rebooting appears to be the only way to unload the updated libraries from system memory/disk due to shareable libraries being held open. I would be very happy if there's a simple solution to this one

          Comment


          • #75
            Originally posted by johnc View Post
            I think at this point X.org is leaner than systemd.
            Phoronix: Systemd Continues Getting Bigger, Almost At 550k Lines Of Code
            Phoronix, Linux Hardware Reviews, Linux hardware benchmarks, Linux server benchmarks, Linux benchmarking, Desktop Linux, Linux performance, Open Source graphics, Linux How To, Ubuntu benchmarks, Ubuntu hardware, Phoronix Test Suite


            tinyX server: 136539 lines including comments and whitespace, not sure if gitstats includes those or not.

            Comment


            • #76
              Originally posted by curaga View Post
              Phoronix: Systemd Continues Getting Bigger, Almost At 550k Lines Of Code
              http://www.phoronix.com/scan.php?pag...tem&px=MTY5NjM
              In actuality systemd is closer to 240k LOC, 35k LOC of which are man pages. X.org however is over two million lines of code. Of course roughly 20k LOC is taken by udev. It also replaces syslog-ng 60k LOC or rsyslog 150k LOC, ConsoleKit 15k LOC, cronie 6k LOC, xinetd 20k LOC, potentially many networking utilities like NetworkManager 400k LOC.... and so on and so forth.

              Originally posted by rob11311
              Perhaps you have a way round the most troubling systemd feature? That pid 1, is reliant on Dbus which is subject regularly to security updates and unfortunately rebooting appears to be the only way to unload the updated libraries from system memory/disk due to shareable libraries being held open. I would be very happy if there's a simple solution to this one
              systemd PID1 has _never_ relied on dbus. In near future nothing will as they will use kdbus instead. Also systemd moved from libdbus to their own libsystemd-bus many releases ago.

              Comment


              • #77
                Originally posted by rob11311 View Post
                Actually I have read up on systemd many times, and on NTP I was going by what Lennart wrote himself on his blogs, which gave me a disturbing impression and the guy does have a track record of taking a view, justifying it with a parody appraisal of alternatives setting up straw men.
                I think the important thing here to remember is that systemd isn't a personal Poettering project, he is just a lead developer, there are at least 24 developers with commit access and +500 contributors. It is a proven fact that many high ranking Linux kernel developers and distro maintainers totally agree with Poettering's description of the problems with old script based init-systems, and that systemd actually solves many of these problems in a modern way.

                Personally Poettering strikes me as an extremely smart developer that have been able to tackle almost impossible problems like getting Linux an audio daemon without rewriting everything (it builds on ALSA), and making both a new init system and logging system that is a vast improvement over the old, while still having extremely good backwards comparability. No "flag day" problem where everything old doesn't work any more and everything new is put into production.


                Originally posted by rob11311 View Post
                When he claims systemd has NTP daemon service now or DHCP, it sounds like an embrace and extend, if that's not the case, he's DOING a very poor job of explaining his features. Something along the lines of "integrates the system provided SNTP daemon" would be clear.
                Systemd doesn't have a NTP daemon, it has a service that can turn on or off third party NTP solutions and set local time and timezones etc. That way upstream projects are guaranteed to have a consistent way off doing such basic things. Same with networking.

                The point is that it has been within the scope of systemd long before came into production, to control NTP/time/date and networking. So it is hardly feature creep that they also provide an optional SNTPv4 client, same with the networking features; they are optional and the basic functionality systemd provides upstream developers works without them. (The dhcp is even built as a library so other can use its features).

                Also, these new features solves actual real world problems that most other implementations doesn't care about. With mass deployment of 5000 OS containers within minutes, it actually do matter whether a dhcp connection for a lease takes 10 seconds or 10 milliseconds. They are not made and added just because someone thought they could.

                But systemd will expand its scope over time. It is a given fact and now also a "mission statement" that they want to track important technological changes. kdbus and "kernel capabilities" and cgroup are great example on how systemd enables end users and distro maintainers to use new and exciting kernel features in an easy way.

                I really can't see it should be a problem that Linux actually improves over time instead of stagnate into a 20th century time freeze.


                Originally posted by rob11311 View Post
                The stuff about syntax is hardly impressive, the old sys V init had a standard pattern, something like /etc/init.d/<daemon> start, and package installers even had LSB hooks to set up such services correctly in a standard way.
                You don't get it. On non-systemd systems it is utter fragmented chaos with inconsistent ways of doing even simple things as setting time and date, or enable or even checking for the existence of NTP. Some non-systemd distros doesn't use SysVinit, many doesn't follow LSB, they all use different NTP implementations. It is extremely hard for third party/upstream developers to make tools or DE's that work across non-systemd distros.

                On systemd distros, systemd provides stable API's and tools and codepaths' that enable third party developers to make tools to potentially work across all systemd distros. This is exactly why DE developers from KDE, Gnome, LXDE etc. are targeting systemd for new development.


                Originally posted by rob11311 View Post
                Perhaps you have a way round the most troubling systemd feature? That pid 1, is reliant on Dbus which is subject regularly to security updates and unfortunately rebooting appears to be the only way to unload the updated libraries from system memory/disk due to shareable libraries being held open. I would be very happy if there's a simple solution to this one
                I don't think it is an actual problem on modern Linux systems; after the shared library have been updated, the old version will be wiped out from both memory and disk the nano second after the inode/file descriptor is closed. The old library won't hang around as a ghost just because it is shared with other processes. Saw a google engineer talk about how google never reboot their servers after library security updates for the very same reason. (can't find the youtube link, sorry).

                Comment


                • #78
                  [QUOTE=interested;427609]I think the important thing here to remember is that systemd isn't a personal Poettering project, he is just a lead developer, there are at least 24 developers with commit access and +500 contributors. It is a proven fact that many high ranking Linux kernel developers and distro maintainers totally agree with Poettering's description of the problems with old script based init-systems, and that systemd actually solves many of these problems in a modern way.

                  Well, here you are wrong, it is his personal project, as stated by himself http://0pointer.de/blog/projects/systemd.html FAQ - Is this a Red Hat project?
                  No, this is my personal side project. Also, let me emphasize this: the opinions reflected here are my own. They are not the views of my employer, or Ronald McDonald, or anyone else.

                  Comment


                  • #79
                    [QUOTE=mlouis;427628]
                    Originally posted by interested View Post
                    I think the important thing here to remember is that systemd isn't a personal Poettering project, he is just a lead developer, there are at least 24 developers with commit access and +500 contributors. It is a proven fact that many high ranking Linux kernel developers and distro maintainers totally agree with Poettering's description of the problems with old script based init-systems, and that systemd actually solves many of these problems in a modern way.

                    Well, here you are wrong, it is his personal project, as stated by himself http://0pointer.de/blog/projects/systemd.html FAQ - Is this a Red Hat project?
                    No, this is my personal side project. Also, let me emphasize this: the opinions reflected here are my own. They are not the views of my employer, or Ronald McDonald, or anyone else.
                    Look at the timestamp. Systemd evolved beyond personal project since then with over 500 contributions. Linux kernel started the same way.

                    Comment


                    • #80
                      Originally posted by interested View Post
                      They do actually fix bugs and make it a high priority. Just look at the mailing list. That systemd seems to develop at speed is because so many developers are working on it. I don't think development will slow down at all over time, but continue with ever more features, though probably mostly new features to already existing components like service management, OS containers etc.
                      First they start FUD campain about upstart being bad bad bad, because it fails to unmount partitions on reboot and that systemd magically solves this problem, but they still have this bug open that is not supposed to happen with almighty systemd for almost a year now:


                      At the same time their hobby is to introduce bugs and then refuse to fix them, blaming anyone, but themselves.
                      Last edited by Stellarwind; 06 July 2014, 02:44 PM.

                      Comment

                      Working...
                      X