Announcement

Collapse
No announcement yet.

Upstart Now Available In Debian Unstable

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

  • #46
    Originally posted by LightBit View Post
    So if you put everything into one process, like COMMAND.COM, it becomes simpler?
    systemd package contains the code for many different programs (including udev). The init daemon (/usr/lib/systemd/systemd) for version 196 is 888 kB size.

    When everything is compiled you get these binaries:

    hostnamectl
    journalctl
    localectl
    loginctl
    systemctl
    systemd-analyze
    systemd-ask-password
    systemd-cat
    systemd-cgls
    systemd-cgtop
    systemd-coredumpctl
    systemd-delta
    systemd-detect-virt
    systemd-inhibit
    systemd-machine-id-setup
    systemd-notify
    systemd-nspawn
    systemd-stdio-bridge
    systemd-tmpfiles
    systemd-tty-ask-password-agent
    timedatectl
    udevadm
    udevd

    Which are normally located in the /usr/bin/ directory. So you see, systemd is not like COMMAND.COM

    Comment


    • #47
      Originally posted by LightBit View Post
      Same as systemd does't care about POSIX.
      systemd is a system and service manager for Linux, not for POSIX operating systems. If other UNIX-like operating systems want systemd, the need to port cgroups (which is in Linux since 2007).

      If you don't like it... you know... don't use it.

      Comment


      • #48
        Originally posted by siban View Post
        systemd package contains the code for many different programs (including udev).
        The init daemon (/usr/lib/systemd/systemd) for version 196 is 888 kB size.
        Is this supposed to be small?!
        init should be less than 10kB statically linked to some bloat free library.

        Originally posted by siban View Post
        When everything is compiled you get these binaries:

        hostnamectl
        journalctl
        localectl
        loginctl
        systemctl
        systemd-analyze
        systemd-ask-password
        systemd-cat
        systemd-cgls
        systemd-cgtop
        systemd-coredumpctl
        systemd-delta
        systemd-detect-virt
        systemd-inhibit
        systemd-machine-id-setup
        systemd-notify
        systemd-nspawn
        systemd-stdio-bridge
        systemd-tmpfiles
        systemd-tty-ask-password-agent
        timedatectl
        udevadm
        udevd

        Which are normally located in the /usr/bin/ directory. So you see, systemd is not like COMMAND.COM
        See what is inside core (pid 1): http://cgit.freedesktop.org/systemd/.../tree/src/core

        Comment


        • #49
          Originally posted by siban View Post
          systemd package contains the code for many different programs (including udev). The init daemon (/usr/lib/systemd/systemd) for version 196 is 888 kB size.
          ...
          So you see, systemd is not like COMMAND.COM
          888 kb !

          You're making my, and his, point for us. That is _huge_. That's 850kb of code, all unnecessary, there to increase the chance of bugs disrupting the only task init should do.

          My sysvinit is ~32kb, and that is a bit too big too.


          So yes, that is exactly like command.com despite systemd having some commands split off.

          Comment


          • #50
            Originally posted by siban View Post
            systemd is a system and service manager for Linux, not for POSIX operating systems. If other UNIX-like operating systems want systemd, the need to port cgroups (which is in Linux since 2007).
            I don't know if any other UNIX-like operating system wants systemd. Maybe FreeBSD?
            It' actually great that systemd isn't portable.

            Originally posted by siban View Post
            If you don't like it... you know... don't use it.
            No systemd, no Gnome.
            No systemd, no udev.
            ...
            No systemd, no Linux.

            Comment


            • #51
              Originally posted by LightBit View Post
              Urgh. That's really nasty. I can understand that some people insist that that's too much for PID 1 and should go into a separate service manager on top of init.

              Comment


              • #52
                Originally posted by kigurai View Post
                If sysvinit is the only really good choice to couple with OpenRC, why would I want that instead of just running sysvinit directly? Genuine question, because I haven't used gentoo in a long time, and never heard of OpenRC. But to me, it sounds a bit hypocritical to bash systemd for "unused code" while championing an init system that sits on top of another init system...
                Also, the "more code = more bugs" is a rule of thumb, not some kind of law. As you are probably aware there are some really stable pieces of hardware with milions of lines of code (Linux kernel, to take one relevant example), and lots of very small applications that are riddled with bugs.
                If systemd crashed substantially more than sysvinit I suppose you could have a point. I have not seen anything that hints about that.
                OpenRC is not an init system. It is an RC system. Linux distributions rarely make a distinction between them because the init and RC systems are integrated, but Gentoo and various *BSD operating systems keep them separate.

                The main innovations of OpenRC are the creation of named runlevels and full dependency handling. The numbered runlevels of sysvinit were an attempt at handling dependencies, but they sequentialize the boot process and are unable to handle complex dependency chains. OpenRC's calculation of the dependency graph eliminates such limitations. It is also written in C, so there is not much overhead in the calculation.

                Originally posted by funkSTAR View Post
                FSF is a non-commercial org caring deeply about software freedom.They want CA to maximize legal protection for the licensed code. Canonical is just a RH competitor seeking an advantage. They dont want CA to keep the code open and protect it. Canonical want the copyrigtht so they can do whatever skunkwork they need. This includes distrobuting closed source editions. And yes Canonical KNOWS the CAing will keep RH out of the loop. They are causing fragmentation without any regrets.

                Upstart: CA, low canonical investment, no community.
                Systemd: no CA, high RH investment, much larger community.

                Systemd is already way ahead based on technical merits. Based on metrics like keeping the source code on free license and building communities systemd is your pick.

                So in order to follow your PurgePoettering agenda you have to accept less features, less freedom and less community. Only a suffering hater can do something this stupid. I hope you will get well by time. God bless you.
                I do not believe that Canonical is worse than RedHat or the FSF. Canonical gives commit privileges to community contributors, which RedHat does not do. Both the FSF and Canonical require copyright assignment. I am also acquainted with one of the Upstart developers. He is a nice guy, which is more than I can say for those involved with systemd.

                Anyway, systemd is full of severe reliability regressions that I do not want on my system. I am currently fixing a regression that can cause udevd to enter d-state permanently. It will cripple the system boot process in certain situations. eudev inherited it from systemd. Anyone who asks me for details will be told to ask again after our first tag. I have adopted the Sun Microsystems approach to collaboration (i.e. code drops) for reliability bugs introduced by systemd in response to abuse from Lennart Poettering and Kay Sievers. You can thank them for that.
                Last edited by ryao; 12-01-2012, 06:09 PM.

                Comment


                • #53
                  Originally posted by funkSTAR View Post
                  So in order to follow your PurgePoettering agenda you have to accept less features, less freedom and less community.
                  I think you have it reversed. One faction wants to preserve choice for its users and embraces diversity (including letting users run whatever init system they wish). The other cares more about vertical integration than about choice and diversity.

                  Originally posted by ryao View Post
                  Both the FSF and Canonical require copyright assignment.
                  The FSF copyright assignment is a lot different from Canonical's or most others', in that the FSF is allowed to publish your code under free software licenses only. If the FSF publishes the code under a non-free license, then the copyright reverts to you.

                  Comment


                  • #54
                    Originally posted by siban View Post
                    systemd package contains the code for many different programs (including udev).
                    That's quite the point. In order to install and maintain systemd, I need to grasp at least the basic function and parameters of these binaries:

                    hostnamectl journalctl localectl loginctl systemctl systemd systemd-ac-power systemd-analyze systemd-ask-password
                    systemd-binfmt systemd-cat systemd-cgls systemd-cgroups-agent systemd-cgtop systemd-coredump systemd-coredumpctl
                    systemd-delta systemd-detect-virt systemd-fsck systemd-hostnamed systemd-inhibit systemd-initctl systemd-journald
                    systemd-journal-gatewayd systemd-localed systemd-logind systemd-machine-id-setup systemd-modules-load systemd-multi-seat-x
                    systemd-notify systemd-nspawn systemd-quotacheck systemd-random-seed systemd-readahead systemd-remount-fs
                    systemd-reply-password systemd-shutdown systemd-shutdownd systemd-sleep systemd-stdio-bridge systemd-sysctl
                    systemd-timedated systemd-timestamp systemd-tmpfiles systemd-tty-ask-password-agent systemd-udevd systemd-update-utmp
                    systemd-user-sessions systemd-vconsole-setup timedatectl udevadm
                    In the case of Upstart, that's

                    halt init init-checkconf initctl initctl2dot poweroff reboot reload restart runlevel shutdown start status stop telinit
                    upstart-socket-bridge upstart-udev-bridge
                    many of which are symbolic links or have traditional system V semantics. To be honest, to the Upstart set one has to add udevd and udevadm, which need to be found and ripped out of systemd's installation image (because that's the best practice that systemd maintainers envision for people who do not want to use systemd).

                    And we're talking only about the binaries, not all stuff such as support libraries and configuration files. In total, the systemd installation image touches 621 files and 93 directories. Upstart touches 44 files and 18 directories.

                    Now in all honesty, looking at the complexity of the two packages, and supposing that I don't need systemd's additional features, because I'm fine with syslog and inetd, when managing my system, am I more likely to need external help when I'm using systemd, or when I'm using upstart?

                    Oh, and since people keep making silly comparisons such as counting the number of PIDs used,

                    Code:
                    $ size init
                       text    data     bss     dec     hex filename
                     221392    1948     136  223476   368f4 init
                    Code:
                    $ size systemd
                       text    data     bss     dec     hex filename
                     884496   54692    2424  941612   e5e2c systemd

                    Comment


                    • #55
                      Originally posted by peppepz View Post
                      Oh, and since people keep making silly comparisons such as counting the number of PIDs used,

                      Code:
                      $ size init
                         text    data     bss     dec     hex filename
                       221392    1948     136  223476   368f4 init
                      Code:
                      $ size systemd
                         text    data     bss     dec     hex filename
                       884496   54692    2424  941612   e5e2c systemd
                      What has that todo with PID?

                      As I understand it systemd is a system and process manager not a init. A part of systemd, the systemd binary is the init. Upstart and systemd doesn't do the same thing so a comparison of the total code size of the project is not relevant.
                      As I understands it the last version of the old init in Arch linux is supposed to use some of the stuff in systemd without using the init systemd?

                      Comment


                      • #56
                        Originally posted by Akka View Post
                        As I understand it systemd is a system and process manager not a init. A part of systemd, the systemd binary is the init. Upstart and systemd doesn't do the same thing so a comparison of the total code size of the project is not relevant.
                        peppepz compared size of init part only.


                        Originally posted by Akka View Post
                        As I understands it the last version of the old init in Arch linux is supposed to use some of the stuff in systemd without using the init systemd?
                        Yes, udev. It was separate package before, but systemd devs "stole" it.

                        Comment


                        • #57
                          Originally posted by LightBit View Post
                          but systemd devs "stole" it.
                          How did "the systemd devs" (who?) steal it? Do you have sources for such a claim?

                          Comment


                          • #58
                            Originally posted by LightBit View Post
                            peppepz compared size of init part only.
                            Yes, but was has the size on the systemd binary todo with the processid number? And he compared the number of different systemd processes with the ones in upstart, but I forgot quote that part, so it look a little bit strange ....

                            Yes, udev. It was separate package before, but systemd devs "stole" it.
                            As I understood the news not, it was not only udev they used. At least both init system is partly configuration files compatible. But I didn't care much then, as I had switched my installation to systemd some month before.
                            .
                            Last edited by Akka; 12-02-2012, 01:53 PM.

                            Comment


                            • #59
                              Originally posted by droste View Post
                              How did "the systemd devs" (who?) steal it? Do you have sources for such a claim?
                              They didn't actually stole it. Kay Sievers is systemd dev and he was also udev maintainer. http://lwn.net/Articles/490413/

                              Comment


                              • #60
                                Originally posted by LightBit View Post
                                They didn't actually stole it. Kay Sievers is systemd dev and he was also udev maintainer. http://lwn.net/Articles/490413/
                                Sounds much better, thank you. You have to be really careful with what words you use on this topic. Some people will believe everything as soon as it's a thing they can use against systemd! And stealing definitely implies that something illegal/wrongful happened, which is not the case.

                                Comment

                                Working...
                                X