Announcement

Collapse
No announcement yet.

Upstart Now Available In Debian Unstable

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

  • Upstart Now Available In Debian Unstable

    Phoronix: Upstart Now Available In Debian Unstable

    Steve Langasek of Canonical has pushed their latest Upstart init daemon into Debian unstable. Debian GNU/Linux can now handle either SysVinit, systemd, and Upstart to handle a head-to-head system booting battle...

    http://www.phoronix.com/vr.php?view=MTIzNjk

  • #2
    The interesting bit about Upstart is that Canonical seems to be sticking to it and also -according to LP G+- they want to use it in the user session.
    Last edited by 89c51; 11-27-2012, 12:05 PM.

    Comment


    • #3
      Originally posted by BO$$ View Post
      Canonical should really push for adoption of Upstart in order to get mindshare and make people change to it instead of that systemd. Canonical really is the lesser evil in this case.
      They can do that by providing an unbiased explanation how Upstart works and how it can manage system boot tasks better. Having an unbiased set of benchmarks can also help and not to mention that having clear and complete documentation of how to configure Upstart.

      Mucking around with init systems can be tedious and if not done right it can make system unstable or even unbootable

      Comment


      • #4
        why bother with Upstart when you have systemd? doesn the former has *any* advantage over the latter one?

        Comment


        • #5
          Originally posted by szymon_g View Post
          Why bother with Upstart when you have systemd?
          From Ubuntu's standpoint, they've invested significant time/effort to develop Upstart and it meets their needs, so there's really no reason for them to switch until Debian moves to systemd as the default. I can't think of a good reason for distros still using sysvinit to adopt Upstart instead of systemd (unless Upstart's significantly faster/lighter) if they're looking to get rid of sysvinit.

          Comment


          • #6
            Originally posted by szymon_g View Post
            why bother with Upstart when you have systemd? doesn the former has *any* advantage over the latter one?
            SystemD is Linux-only, and will likely remain like that. I don't think Upstart is.

            This is a big deal for Debian and Gentoo, who also support non-Linux kernels.

            Comment


            • #7
              Originally posted by pingufunkybeat View Post
              SystemD is Linux-only, and will likely remain like that. I don't think Upstart is.
              This is a big deal for Debian and Gentoo, who also support non-Linux kernels.
              apart from developers of, let say debian with hurd kernel, is anyone even using them?
              or is it just a toy, just to say "look! we can do it!" that keeps everything else back (same was with udev, xfce 4.10 etc etc)?


              Originally posted by DanL View Post
              From Ubuntu's standpoint, they've invested significant time/effort to develop Upstart and it meets their needs, so there's really no reason for them to switch until Debian moves to systemd as the default. I can't think of a good reason for distros still using sysvinit to adopt Upstart instead of systemd (unless Upstart's significantly faster/lighter) if they're looking to get rid of sysvinit.
              ... so, instead of stopping using their product, that has no benefits over other one, and start using systemd, they prefer using it? that's retarded.

              Comment


              • #8
                Looks like a job for... phoronix

                "it's now possible to do meaningful head-to-head comparisons of boot speed between sysvinit (with startpar), upstart, and systemd. At one time or another people have tested systemd vs. sysvinit when using bash as /bin/sh, and upstart vs. sysvinit, and systemd vs. sysvinit+startpar, and there are plenty of bootcharts floating around showing results of one init system or another on one distro or another, but I'm not aware of anyone having done a real, fair comparison of the three solutions, changing nothing but the init system."

                @Michael, looks like a job for... phoronix

                Comment


                • #9
                  Originally posted by tmpdir View Post
                  "it's now possible to do meaningful head-to-head comparisons of boot speed between sysvinit (with startpar), upstart, and systemd. At one time or another people have tested systemd vs. sysvinit when using bash as /bin/sh, and upstart vs. sysvinit, and systemd vs. sysvinit+startpar, and there are plenty of bootcharts floating around showing results of one init system or another on one distro or another, but I'm not aware of anyone having done a real, fair comparison of the three solutions, changing nothing but the init system."

                  @Michael, looks like a job for... phoronix
                  and: "Debian GNU/Linux can now handle either SysVinit, systemd, and Upstart to handle a head-to-head system booting battle."

                  Just, please, Phoronix, don't run some benchmarks and Declare a Victor. The extended capabilities of both upstart and systemd versus sysv are far more significant and interesting than any potential improvement in boot times they offer.

                  In any case, just dropping in a new init system - whether it's pinit, upstart, systemd or anything else - is not likely to result in a very significant performance difference, as most of the overhead during startup is the system doing stuff, and the init system doesn't directly change that. Both upstart and systemd potentially open up methods by which a distro could make boot more efficient, but it's still up to packagers of components that do stuff during startup to implement that, it doesn't magically happen. I doubt Debian will carry native, optimized init functions for all its packages for both systemd and upstart, and without that, a performance comparison is still fairly pointless, even using the same distro as a base.

                  Comment


                  • #10
                    Originally posted by szymon_g View Post
                    why bother with Upstart when you have systemd? doesn the former has *any* advantage over the latter one?
                    It's much simpler, and therefore maintainable, it's well documented, it does its job and only that, it compiles, it doesn't require userland to be changed to conform to its model. As a bonus, it's not developed by people who like to force everyone into using their products.

                    Comment


                    • #11
                      Originally posted by peppepz View Post
                      It's much simpler, and therefore maintainable
                      Hm.

                      Originally posted by peppepz View Post
                      , it's well documented
                      So is systemd.

                      http://www.freedesktop.org/wiki/Software/systemd
                      http://www.freedesktop.org/software/systemd/man/
                      http://www.freedesktop.org/wiki/Soft.../TipsAndTricks
                      http://www.freedesktop.org/wiki/Soft...AskedQuestions
                      http://freedesktop.org/wiki/Software/systemd/Debugging
                      http://www.freedesktop.org/wiki/Soft...ompatibilities

                      and the entire 'systemd for Administrators' and 'Documentation for Developers' sections at http://www.freedesktop.org/wiki/Software/systemd .

                      Originally posted by peppepz View Post
                      it does its job and only that
                      This is a very short-sighted perspective. It is unrealistic to assume the precise correct job descriptions for all components of a computer were perfected in the 1970s, and all it is now possible to improve is the precise implementations of each defined job. There is no stone tablet anywhere which says 'There Shalt Be An Init Daemon Which Handles Nothing But Process Creation'. It's just a design choice.

                      As gregkh perceptively pointed out in that whole eudev kerfuffle, when udev first showed up, there were plenty of people who accused it of being too complex and doing too much compared to devfs or static /dev trees (remember those?) Now udev is the paragon of virtue, I don't see too many people clamoring to be allowed to return to maintaining a static /dev tree any more.

                      Originally posted by peppepz View Post
                      it compiles
                      Er...seems to go out without saying, but so does systemd...

                      Originally posted by peppepz View Post
                      it doesn't require userland to be changed to conform to its model
                      Neither does systemd. Both upstart and systemd can function as transparent drop-in replacements for sysv if so desired. But if you want to use most of the extended features of *either*, you have to write native services - both upstart and systemd have their own native formats that are different from and incompatible with sysv.

                      Comment


                      • #12
                        Canonical should really push for adoption of Upstart in order to get mindshare and make people change to it instead of that systemd.

                        Comment


                        • #13
                          Originally posted by AdamW View Post
                          So is systemd.
                          The problem is that systemd's documentation is scattered all over many places, many of them informal or unofficial. Also, much of it is bitrotten as systemd changes the way it works quite often, pushing the burden of keeping up onto the users.

                          and the entire 'systemd for Administrators' and 'Documentation for Developers' sections at http://www.freedesktop.org/wiki/Software/systemd
                          I wouldn't call an init daemon which is documented through an unordered series of 18 blog posts by its author "well documented".

                          This is a very short-sighted perspective. It is unrealistic to assume the precise correct job descriptions for all components of a computer were perfected in the 1970s, and all it is now possible to improve is the precise implementations of each defined job. There is no stone tablet anywhere which says 'There Shalt Be An Init Daemon Which Handles Nothing But Process Creation'. It's just a design choice.
                          I never said that. Upstart, for instance, is much more recent than the 1970s. The value of a system where the boundaries and the functions of each of its components are well defined and well documented, on the other hand, has no age. An administrator can obtain complete knowledge of such a system, reasonably foresee its behaviour, and diagnose faults when things don't work as expected. A kitchen sink that leaves you with a dead console and a wall of text made up of unrelated diagnostic messages because something went wrong is the opposite of that.

                          As gregkh perceptively pointed out in that whole eudev kerfuffle, when udev first showed up, there were plenty of people who accused it of being too complex and doing too much compared to devfs or static /dev trees (remember those?) Now udev is the paragon of virtue, I don't see too many people clamoring to be allowed to return to maintaining a static /dev tree any more.
                          I remember well when udev appeared. It replaced devfs, which was a simple approach, of the kind that I like, to the problem of populating /dev. The kernel would automatically make device nodes appear when the related drivers were loaded. ( devfsd on the other hand was broken, but let's ignore that for simplicity. ) The udev design replaced that with an userspace daemon, with certain requirements of its own, which had to be invoked in a special way at a special time during the system boot process. Things that were automatic with devfs (such as booting without an initrd in all the cases where this was previously possible) became no longer directly available with udev, and the protests were quickly dismissed by the udev proponents in the usual way: "fix that in userspace". This meant that, for instance, obtaining a working early userspace changed from being fully automatic into something that required dances of pivot_root and file descriptor voodoo.

                          Recently, after going out from the door, devfs has come back through the window in the form of devtmpfs, so in the end the "simple" approach won somehow. And the attitude of systemd developers, and their propension to ignore certain problems of their users, are leading the kernel developers to kill udev altogether and have the kernel load firmware on its own again.

                          Er...seems to go out without saying, but so does systemd...
                          That's the funny thing, it should go out without saying, but it doesn't. One of the last systemd releases that I tried just didn't compile on 32 bit architectures because it contained a mismatch in a function signature between a header and the implementation. This means that systemd gets released without even checking if it compiles on x86, which I find quite unsettling when we're talking about one of the critical pieces of a Linux installation.

                          Neither does systemd. Both upstart and systemd can function as transparent drop-in replacements for sysv if so desired. But if you want to use most of the extended features of *either*, you have to write native services - both upstart and systemd have their own native formats that are different from and incompatible with sysv.
                          Just do a Google search and see for yourself how many third-party packages are being modified to respond to systemd's automatic activation rules. Do the same search for upstart and see which of the two init systems is more invasive. The fact that one should modify a server in order to match the behaviour of a superserver, of which the former shouldn't even know the existence, is a violation of the principle of separation of software components.

                          That said, in my personal experience, it is very easy to set up upstart as a replacement for sysV. Systemd - not so much. Systemd is even less a "transparent drop-in" for sysvinit than PulseAudio was for plain ALSA.

                          Comment


                          • #14
                            Originally posted by peppepz View Post
                            I wouldn't call an init daemon which is documented through an unordered series of 18 blog posts by its author "well documented".
                            Those are not so much documentation as helpful tutorials. I like how you spin extra documentation as something negative.

                            I thought that "man systemd" looked quite substantial. What is missing?

                            Comment


                            • #15
                              That said, in my personal experience, it is very easy to set up upstart as a replacement for sysV. Systemd - not so much. Systemd is even less a "transparent drop-in" for sysvinit than PulseAudio was for plain ALSA.
                              I just dropped in two systems to systemd, from Debian Wheezy, wasn't that hard. Follow the documentation. I'll have to brush up on the new way of doing things but that's expected.

                              Comment

                              Working...
                              X