Announcement

Collapse
No announcement yet.

Upstart Now Available In Debian Unstable

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

  • #16
    Originally posted by AdamW View Post
    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.
    And the test should include a system loaded with services (typical desktop, typical server) instead of only a base system.
    It would be fair if the starting services include both systemd and upstart files, as explained in the article most things lack systemd and perhaps none has upstart (in Debian).

    I think Debian should go with upstart, because systemd is very intrusive and the linux requirement is a big negative (there is kFreebsd, hurd, etc). Of course systemd might actually address those things with time.

    Its a fact that upstart is the more mature choice.

    Here is Canonical clearly contributing a project developed by them back to the parent distro, so its about time people stop complaining about the "not giving back" excuse, and support this and encourage them to continue.
    Last edited by Artemis3; 11-28-2012, 11:45 AM.

    Comment


    • #17
      Originally posted by AdamW View Post
      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 hope that I did not contribute to this perception. udev is far from perfect and there are better ways of doing things. However, many packages now depend on udev and moving away from it would be a burden on maintainers, so we appear to be stuck with it.

      With that said, there have been suggestions that FreeBSD's devd be ported as an alternative. If udev were not so well established, porting devd would probably work extremely well.

      Comment


      • #18
        Originally posted by Artemis3 View Post
        I think Debian should go with upstart, because systemd is very intrusive and the linux requirement is a big negative (there is kFreebsd, hurd, etc).
        The planned addition of support for user sessions in Upstart states that:

        By making use of a Linux-specific prctl(2) call, we effectively tie Upstart to systems running with a Linux kernel. This is a major restriction, but porting to other systems is already complicated by the fact that even the BSDs do not provide a full POSIX environment (missing "waitid(2)" for example).
        So it seems that Upstart isn't properly portable even now and in the future it's even less. It's clearly not any priority either.

        Originally posted by Artemis3 View Post
        Its a fact that upstart is the more mature choice.
        It's also a project developed by single company without really any community participation and that has very little developement activity. It's no longer widely used out side of Ubuntu either. It's developed under contributor licence agreement using Bazaar in Launchpad. It seems very Ubuntu/Canonical specific project to me whereas systemd is developed by various companies (Red Hat, Intel, ProFusion, SUSE...) and communites like Arch Linux. It also doesn't have CLA is developed by using git in freedesktop.org. It seems that RHEL7 (Oracle Linux, CentOS, Scientific Linux...) and SLES12 will also be using it.

        Originally posted by Artemis3 View Post
        Here is Canonical clearly contributing a project developed by them back to the parent distro, so its about time people stop complaining about the "not giving back" excuse, and support this and encourage them to continue.
        Well they are also doing a lot more harm than good by fragmenting the Linux userspace by using their techically inferior solution.

        Comment


        • #19
          Originally posted by Teho View Post
          It's also a project developed by single company without really any community participation and that has very little developement activity. It's no longer widely used out side of Ubuntu either.
          Upstart is also part of ChromeOS and used in a number of embedded devices.

          (And there is activity in some development branches at least.)

          Comment


          • #20
            Originally posted by peppepz View Post
            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. 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 extremely unfair, as another responder pointed out. systemd is documented through its man pages, as is conventional. There is also considerable 'bonus' documentation consisting of user-friendly guides to various actions, a FAQ page with background detail, and so on and so on. The manpages alone constitute sufficient conventional documentation. I could just have referred to those, but I wanted to make the point that the systemd developers go above and beyond to provide useful and extensive supplementary documentation and guidance. It seems mean in the extreme to spin this as a bad thing.

            Originally posted by peppepz View Post
            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.
            The boundaries and functions of systemd, udevd and journald are all perfectly well defined and documented. You can perfectly well obtain complete knowledge of this chain, foresee its behaviour, and debug it. The boundaries and behaviour are different from sysv, but they certainly meet your conditions.

            Originally posted by peppepz View Post
            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.
            I have to say I tend to read this line of argument as 'I took the time to learn how the old way worked, and now I don't want to do it again'. Learning new stuff is a pain, yeah, but describing it as 'voodoo' is unwarranted. The 'fully automatic' way that devfs worked was just as much 'voodoo' to someone who was used to the previous method as udev's method is to you. More than anything, your perspective on what is perfectly comprehensible and sensible code and what is 'voodoo' depends on when you came in...

            Originally posted by peppepz View Post
            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.
            This is a fairly inaccurate description of that whole kerfuffle. There was a bug, developers took potshots at each other as F/OSS developers always do and always have since the beginning of time (proprietary ones too, it just happens in private where you can't see it), Linus blew off steam with a ridiculously over-the-top rant as Linus is prone to do from time to time, then everyone settled down and fixed things. It's fun to read developers yelling at each other, but it doesn't really tell you anything substantive. If we all stopped using every F/OSS project whose developers had been involved in a shouting match with Linus at some point we'd be in some trouble.

            Originally posted by peppepz View Post
            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.
            So you hit a bug. Presumably it got fixed. I can't really discuss it in any more detail since I don't know anything about that specific case. But bugs happen...

            Originally posted by peppepz View Post
            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.
            They're not 'being modified to respond to systemd's automatic activation rules'. They're being modified to *use* systemd's socket activation, because socket activation is an awesome feature and lots of developers want their software to take advantage of it. The whole point of systemd - and upstart - is to provide new capabilities for service initialization and management, capabilities sysv doesn't have. If they didn't do this there'd be no point in their existence. Projects converting to native systemd services in order to take advantage of the features it provides is a *positive* indicator for systemd, not a negative one. They didn't have to do that, after all - they could have just stuck with their sysv scripts.

            Originally posted by peppepz View Post
            Do the same search for upstart and see which of the two init systems is more invasive.
            See above. The fact that projects are not buying into upstart is not a *good* thing for upstart, it indicates that they don't have confidence enough in that project to take advantage of the capabilities it offers. Why is it a good thing for upstart if upstart offers a native service format that provides extended capabilities, but few projects want to take advantage of that?

            Originally posted by peppepz View Post
            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.
            Again, it is not about 'match[ing] the behaviour' of systemd. It is about taking advantage of useful capabilities that systemd makes available. socket activation is a feature systemd offers for services, not a mandatory requirement. You don't have to make your service socket activated. The fact that developers are doing so is a clear statement that they consider it a beneficial and desirable feature which systemd is providing them.

            Comment


            • #21
              Originally posted by Artemis3 View Post
              Here is Canonical clearly contributing a project developed by them back to the parent distro, so its about time people stop complaining about the "not giving back" excuse, and support this and encourage them to continue.
              Canonical giving back? No. For a distro to fully embrace upstart you also need to develop it. Canonicals way of doing open source is by applying a big FUCK YOU OPEN SOURCE FREAKS clause to any contributions.

              And after you sign this idiotic anti open source agreement you are allowed to contribute to an inferior init system soon to be capable to do session management for the sole purpose of vendor lockin. 'Yes thats right; We will end with a bunch of apps developed for "Ubuntu Linux" not Linux. and they will use upstart session. Pretty smart tactics by Canonical to do away with "the competition". There is a major risk of a damaging fragmentation coming to the linux desktop and people think it is funny because they can mock some systemd developers who work in the open without skunkwork agendas.

              Anyone who will accept a deal going: "Give us your copyright and we will grant you a less capable init and session system guaranteed to create further fragmentation" is a bunch of neckbeards. This is gonna be years of "fun" if people really accept Canonicals crap.

              Comment


              • #22
                Originally posted by funkSTAR View Post
                And after you sign this idiotic anti open source agreement you are allowed to contribute to an inferior init system soon to be capable to do session management for the sole purpose of vendor lockin. 'Yes thats right; We will end with a bunch of apps developed for "Ubuntu Linux" not Linux. and they will use upstart session. Pretty smart tactics by Canonical to do away with "the competition". There is a major risk of a damaging fragmentation coming to the linux desktop and people think it is funny because they can mock some systemd developers who work in the open without skunkwork agendas.
                That seems to be their strategy. And noone can blame them in a way.

                Comment


                • #23
                  Originally posted by 89c51 View Post
                  That seems to be their strategy. And noone can blame them in a way.
                  Serving shit is bad. Eating shit is much worse. Linux users have to judge by them self. Do we really put up with skunkwork which will lead to fragmentation? Saying no to systemd (like it or not) is like saying yes to years of fragmentation which will pull everyone down. The only thing Canonical will loose by adopting systemd is skunkwork capabilities.

                  Comment


                  • #24
                    Originally posted by AdamW View Post
                    They're not 'being modified to respond to systemd's automatic activation rules'. They're being modified to *use* systemd's socket activation, because socket activation is an awesome feature and lots of developers want their software to take advantage of it. The whole point of systemd - and upstart - is to provide new capabilities for service initialization and management, capabilities sysv doesn't have. If they didn't do this there'd be no point in their existence. Projects converting to native systemd services in order to take advantage of the features it provides is a *positive* indicator for systemd, not a negative one. They didn't have to do that, after all - they could have just stuck with their sysv scripts.
                    I think you are forgetting about OpenRC, which many distributions use. OpenRC is designed to run on top of any init system to provide proper dependency management and other things, such as cgroups (Linux-only). As a consequence, the use of sysvinit does not imply that you are using sysvinit scripts.

                    OpenRC scripts are similar enough to Upstart jobs that modification of Upstart to support OpenRC scripts was proposed for the Google Summer of Code.

                    Originally posted by AdamW View Post
                    See above. The fact that projects are not buying into upstart is not a *good* thing for upstart, it indicates that they don't have confidence enough in that project to take advantage of the capabilities it offers. Why is it a good thing for upstart if upstart offers a native service format that provides extended capabilities, but few projects want to take advantage of that?
                    Google Chrome OS, RHEL6, and Ubuntu and their derivatives use Upstart. RedHat used Upstart in Fedora until they decided to start from scratch instead of trying to work with Canonical on improvements.

                    Originally posted by AdamW View Post
                    Again, it is not about 'match[ing] the behaviour' of systemd. It is about taking advantage of useful capabilities that systemd makes available. socket activation is a feature systemd offers for services, not a mandatory requirement. You don't have to make your service socket activated. The fact that developers are doing so is a clear statement that they consider it a beneficial and desirable feature which systemd is providing them.
                    What prevented Redhat from implementing this in Upstart?

                    Originally posted by funkSTAR View Post
                    Serving shit is bad. Eating shit is much worse. Linux users have to judge by them self. Do we really put up with skunkwork which will lead to fragmentation? Saying no to systemd (like it or not) is like saying yes to years of fragmentation which will pull everyone down. The only thing Canonical will loose by adopting systemd is skunkwork capabilities.
                    http://xkcd.com/927/

                    Comment


                    • #25
                      Originally posted by JanC View Post
                      Upstart is also part of ChromeOS and used in a number of embedded devices.

                      (And there is activity in some development branches at least.)
                      Sure. Google even hired the lead developer of Upstart Scott James Remnant but since then he hasn't done any upstream developement on it (~1,5 years from last commit). Upstart has two "active" developers; Steve Langasek and James Hunt both whom are from Canonical. Altough it still used in some projects it's hardly relevant if none of them do any upstream developement.

                      Originally posted by ryao
                      I think you are forgetting about OpenRC, which many distributions use.
                      Distributions like what? All that I can find are based on Gentoo.

                      Originally posted by ryao
                      What prevented Redhat from implementing this in Upstart?
                      For one the project is/was under CLA/Copyright Assigment. Then there's the question of what kind of patches the upstream is willing to accept. Then there are the architectural, philosophical and technical differences and so on.

                      Comment


                      • #26
                        Having spent quite some tweaking time in sysv, upstart and systemd environments, I have to say that upstart felt like a small improvement over sysv init, not much more than parallelizing startup processes, and a few more lifecycle events you can hook into.

                        With systemd on the other hand I really felt I had total control over when, where and how processes were started. Yes it will take some time to learn the new semantics, but there's much much more control over the processes' lifecycle and context. Running as a certain uid/gid, control over (rt) scheduling, memory, oom, limits and multiprocessor behaviour, controlling where logging is sent to, control over failure situations, tieing a process' fate to another, it's all declaratively handled in systemd.. This is all stuff that upstart and sysv either need shell voodoo for, or isn't possbile at all.

                        This all started to work very well AFTER I disabled sysv compatibility in systemd though.

                        Comment


                        • #27
                          Originally posted by Teho View Post
                          Sure. Google even hired the lead developer of Upstart Scott James Remnant but since then he hasn't done any upstream developement on it (~1,5 years from last commit). Upstart has two "active" developers; Steve Langasek and James Hunt both whom are from Canonical. Altough it still used in some projects it's hardly relevant if none of them do any upstream developement.
                          Upstart might have reached a level of maturity where he felt that he did not need to work on it anymore. Anyway, Google uses Upstart in Google Chrome OS, which is a Gentoo Linux-derivative.

                          Originally posted by Teho View Post
                          Distributions like what? All that I can find are based on Gentoo.
                          Mostly Gentoo Linux and its derivatives, but Alpine Linux uses it too. There are likely a few others, although I am not familiar with them.

                          Comment


                          • #28
                            Originally posted by AdamW View Post
                            This is extremely unfair,
                            This is my opinion.

                            The manpages alone constitute sufficient conventional documentation.
                            Here's an example of how its manpages are self-contained, straight from systemd(1).

                            "For more information about the concepts and ideas behind systemd please refer to the Original Design Document (link).

                            Note that some but not all interfaces provided by systemd are covered by the Interface Stability Promise (link).

                            Units may be generated dynamically at boot and system manager reload time, for example based on other configuration files or parameters passed on the kernel command line. For details see the Generators Specification (link).

                            Systems which invoke systemd in a container or initrd environment should implement the Container Interface (link) or initrd Interface specifications (link), respectively."

                            The boundaries and functions of systemd, udevd and journald are all perfectly well defined and documented. You can perfectly well obtain complete knowledge of this chain, foresee its behaviour, and debug it. The boundaries and behaviour are different from sysv, but they certainly meet your conditions.
                            Let's inspect the boundaries between systemd and udev for instance. udevd used to be separated from systemd. Then it got merged within it, with the authors promising that "nothing would change" as it was merely a matter of sharing code. Then it turned out that things would actually change, as udev would lose its build infrastructure and one would have to use systemd's one. Then it became apparent that one had to compile and install the whole systemd (and its gazillion dependencies, some of which not cleanly cross-compilable), then manually rip the udev binary from the resulting installation (binary which had in the meantime been renamed as systemd-udevd, an undocumented compatibility break). But the developers promised that running udev without systemd would always be possible. When somebody complained that having to rip a working executable image out of systemd wasn't exactly a nice solution, they were awarded with friendly responses such as:

                            "do what source distro's do best."

                            "pick mdev" or "stay on udev-182."

                            "Another option I'm hoping Gentoo uses is to standardize on systemd instead of dozen of half backed utilities to do the same things."

                            Then some time passed, and in case there was some doubt about the real intentions of the systemd+udev maintainers about "defining the boundaries" between the two, systemd developers reveal their true intentions:

                            "(Yes, udev on non-systemd systems is in our eyes a dead end, in case you haven't noticed it yet. I am looking forward to the day when we can drop that support entirely.)"

                            So much for the well-definedness of the boundaries and functions of udevd and systemd. But I actually was talking more generally about the big picture: I appreciate the difference between "a server that starts and stops processes" versus "a server that manages mount points, listens on sockets, writes the syslog, handles dbus, starts recurring processes, handles hardware devices". In particular, I like the former approach because I can study and understand most of it and its interactions with my system, whereas my limited intelligence has much more difficulty in doing the same for a complex and continuosly changing coalition of subsystems such as systemd. So for me and those like me, upstart is better.

                            I have to say I tend to read this line of argument as 'I took the time to learn how the old way worked, and now I don't want to do it again'. Learning new stuff is a pain, yeah, but describing it as 'voodoo' is unwarranted. The 'fully automatic' way that devfs worked was just as much 'voodoo' to someone who was used to the previous method as udev's method is to you. More than anything, your perspective on what is perfectly comprehensible and sensible code and what is 'voodoo' depends on when you came in...
                            The "fully automatic" way that devfs worked was no voodoo. It wasn't more complex than the previous method. The previous method involved populating a directory on the root filesystem with all the device nodes one might think he would ever need. The devfs mothod required nothing: as the directory appeared just there, and that was it. It's not a matter of learning new things. It's a matter of changing from a model which required learning a few concepts to a model which requires learning ten times more concepts, is more cumbersome to use, and is less flexible in the end.

                            The primary source of workforce for OSS software is made up by grassroots users. Replacing simple systems with complex ones for no reason will create barriers to entry for those people. Making Linux workable only by distribution professionals will turn it into another OpenSolaris in the long run.

                            This is a fairly inaccurate description of that whole kerfuffle.
                            Which point is inaccurate? Am I lying? Where exactly?

                            So you hit a bug. Presumably it got fixed. I can't really discuss it in any more detail since I don't know anything about that specific case. But bugs happen...
                            Nobody is questioning the fact that bugs happen. I was just saying that if a software is released without even being compile-tested, a user might consider alternatives to it if they are available.

                            The fact that projects are not buying into upstart is not a *good* thing for upstart, it indicates that they don't have confidence enough in that project to take advantage of the capabilities it offers. Why is it a good thing for upstart if upstart offers a native service format that provides extended capabilities, but few projects want to take advantage of that?
                            Because upstart requires writing "recipes" to manage services, so services don't have to be modified to take advantage of it. And I can't feel any difference in boot time when I run an upstart-based distribution versus a systemd-based one. Except that in the second one, the servers have become init-system specific, and it's more difficult to maintain.

                            Comment


                            • #29
                              Originally posted by AdamW View Post
                              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.
                              You're thinking of wrong things. It's not that perfect design was achieved in 1970. It's the fact that the very definition of both "secure" and "stable" software is "does exactly what it should, and nothing more". All eggs in one basket is terrible design.

                              The only things init on a linux system should do is stay alive and reap zombies.


                              Anything more, anything at all, be it socket activation, integrated logging, or latest whizzbang 4566, increase the risk of bugs, thus decreasing the software's stability and security. From here it clearly follows that sysvinit is much superior to systemd; and BSD init to sysv.

                              The 1970 guys were completely correct in their philosophy of "do one thing, and do it well". It has been proven time and time again.

                              Comment


                              • #30
                                Originally posted by ryao View Post
                                I think you are forgetting about OpenRC, which many distributions use. OpenRC is designed to run on top of any init system to provide proper dependency management and other things, such as cgroups (Linux-only). As a consequence, the use of sysvinit does not imply that you are using sysvinit scripts.
                                I honestly don't see how this paragraph has anything at all to do with the paragraph you quoted, which was about socket activation.

                                Originally posted by ryao View Post
                                Google Chrome OS, RHEL6, and Ubuntu and their derivatives use Upstart. RedHat used Upstart in Fedora until they decided to start from scratch instead of trying to work with Canonical on improvements.

                                What prevented Redhat from implementing this in Upstart?
                                To simplify massively, the systemd and upstart developers could not agree on a design, and so could not work on the same project. This is touched upon in http://0pointer.de/blog/projects/systemd.html "On Upstart". It's probably also significant that RH staff are in general not allowed by corporate policy to sign the Ubuntu CLA as our legal department is not happy with it.

                                Comment

                                Working...
                                X