Announcement

Collapse
No announcement yet.

Upstart Still Has A Bright Future On Ubuntu Linux

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

  • #41
    Originally posted by nll_a
    Very reasonable. The same goes for Mir. Could everyone just chill now?
    Except that wayland and mir do not really have fundamentally different approaches on the technical side. Mir cannot be compared to upstart, one way or the other.

    Comment


    • #42
      Originally posted by AdamW View Post
      So...you reply to a couple of GNOME developers explicitly stating that this meme isn't true by...restating the meme. Sigh.
      Actually, no, they didn't explicitly state that it isn't true. They merely asserted that it wasn't true with no explanation. In fact, afterwards one of them states, ""In systemd lots of hard design decisions have been taken and therefore some design decisions get enforced on the operating system. This may not be liked by some people." This implies that there could be some truth to GNOME being somehow dependent on systemd. Of course, there is a difference between, "It can be run," and, "Everything works." Perhaps in that difference lies the answer to contradictary statements about GNOME dependency on systemd.

      These two developers also basically state that all the opposition to systemd is emotional rather than technical. I know this is not the case. There are technical reasons that people object to systemd. That's the type of thing people say to dismiss objections without answering them. It's the same tactic Mark Shuttleworth used to dismiss objections to Mir. That's also part of the reason that Lennart Poettering tends to get on people's nerves. He puts forward good technical arguments for his decisions, but he merely dismisses equally good technical objections without properly responding to them.

      I want to be clear that I haven't decided whether or not systemd is a good thing. I do think that some of the concerns raised over it are valid concerns. I couldn't care less about GNOME itself, since I have never used it as a regular thing. What happens with GTK will inevitably affect me to some extent though. The interview of these two developers at iTWire does little to put people's concerns about systemd or GNOME to rest.

      Comment


      • #43
        Originally posted by AdamW View Post
        So...you reply to a couple of GNOME developers explicitly stating that this meme isn't true by...restating the meme. Sigh.
        That they say the meme isn't true doesn't make their statement automatically true. See what the OpenBSD developer has to say about that:
        gmane.org is your first and best source for all of the information you’re looking for. From general topics to more of what you would expect to find here, gmane.org has it all. We hope you find what you are searching for!

        On OpenBSD we just dropped the features that need systemd for now. There was some talk about porting some
        systemd interfaces but the path GNOME is currently taking made us stop for now since it seems clearer each
        day that systemd will be a hard requirement at some point (not just 'some' interfaces). Even if they do not
        call it a hard requirement, you will loose 1/2 of what makes GNOME interesting which would render it
        useless to us.
        So for now it works ok enough I would say, but in the middle term, I don't see any future for !linux+systemd in
        GNOME. While some people are really opened about keeping fallback code for ConsoleKit or portability
        patches, some don't care at all or are even getting in our way on purpose.
        The features that they have dropped is power-management, so no, hibernating with Gnome 3.10 on OpenBSD will not work, because there is a dependency on systemd. Gnome developers just avoid talking about that with declaring power-management a "not essential" feature. Come on, in a world of mobile devices features like hibernation or suspend are "not essential"? They must be kidding.

        Funnily, this OpenBSD developer's effort is something that is often brought up by bkor, but every time he conveniently "forgets" to tell the rest of the story, that they don't have the intend to maintain further ports to OpenBSD, because they deem it to be not feasible, because they think that Gnome will become more and more dependent on systemd.

        So now tell me again how portability is one of Gnome's aims.

        Comment


        • #44
          Originally posted by dh04000 View Post
          ...... at the time of upstarts creation there wasn't systemd. The point of upstart was to address issues seen with sysV int. systemd was created after upstart in order to solve the similar problems seen with sysV int. Canonical was trying to fix the same problem as Red Hat was trying to solve with systemd. I don't see why you claim upstart as trying to control anything, they didn't refuse any patches from Red Hat. I don't see any evidence that Red Hat tried to work with Canonical on upstart to add features they deemed important. Nor is there any evidence that Canonical rejected attempts for others to contribute.

          If you look at what actually happened, you could easily make the same aeguement that systemd is just an attempt for Red Hat to control the int. process. Especially considering how aggressively they have been breaking the int process such that other software HAVE to use systemd components just to start up thier system, something that wasn't needed before.

          I don't see upstart breaking the int process to force other people to use components for it just to use linux.
          I don't claim upstart as trying to control init by canonical, I claim that they never will switch to systemd, not matter how much it will be superior to upstart (take a technical decision), because of the control (take a *not* tecnical decision).
          Nowdays Canonical is obsessed by project's control despite any technical disadvantage this means. So a topic that say "Canonical continues to use Upstart for their init process", to me, sounds like "2+2=4".

          Especially considering how aggressively they have been breaking the int process such that other software HAVE to use systemd components just to start up thier system, something that wasn't needed before.
          I find your statement uncorrect for several reasons.
          1) Breaking init process is just your opinion, I say "optimize" the init process.
          2) other software seem love use the systemd's work to make their life more easy, if this means utilize a feature that only systemd expose, then it is a failure of others init system don't provide it, instead of the systemd devs's shame
          3) Someone love to cut the discussion with "this is not the UNIX approach". Also here, is a matter of point of view.
          If you think the whole init process as a (ie.) three steps process, then you could think that a right unix approach should be three separate programs that make their thing good and only their thing.
          But if I think to the init process just as *one* process, that needs to be done in the best way as possible, then the unix way suggest to have just one program that manage the whole init process, optimizing all the step internally.
          4) systemd is not a fork of upstart to make happy the Lennart's NIH syndrome. The design is different, it's just a project better than upstart.
          5) The fact that RH used upstart is a proof that they look more to the technical advantages than other, the fact that Canonical doesn't switch to systemd despite the advantages is a proof of the opposite behaviour.

          Comment


          • #45
            Originally posted by Alex Sarmiento View Post
            Do you honestly believe that a company is going to keep hiring a developer whose work on a project goes against the interests and goals of the company? or do you believe otherwise?

            Maybe, Lennart is working for Redhat just because he likes to *work for* Redhat. I really doubt that his contract with RedHat is just about letting him to do whatever he wants for whatever reason , even if he works on a project of a competitor .
            "Do you honestly believe that a company is going to keep hiring a developer whose work on a project goes against the interests and goals of the company?"

            I don't see where that has anything to do with what I said. I didn't say 'Lennart can do anything he likes and we'll never fire him'. I said devs like Lennart have 'considerable freedom'. Obviously we're not going to pay them to contribute to Windows all day long, or something. But the point is that Lennart came up with the idea for systemd and started building it. If Lennart working on systemd had somehow been a huge problem for RH, then of course that would've become an issue. But there's a big difference between 'systemd is Red Hat's secret plan to control init!' and 'systemd is an idea a guy who happens to work for RH came up with and used his considerable-but-not-unlimited independence of direction to work on'.

            As it turns out, RH is pretty keen on systemd, so there's a nice harmony there. But if it was our ploy to control init, it would be hosted at redhat.com not freedesktop.org, Red Hat would control commit rights to it, and there wouldn't be a bunch of guys working on SUSE and other projects with commit rights.

            Comment


            • #46
              Originally posted by Vim_User View Post
              Really? They believe in portability? Install Gnome 3.10 on OpenBSD (or a Linux distro not running systemd) and hibernate the machine. Oh, wait, you can't. Because you need systemd for power-management.
              In fairness to GNOME, OpenBSD only got hibernation to work in the last year on i386 and its still not stable on AMD64. But on the other hand Gnome 3.x has been a pain in the ass to port to FreeBSD or NetBSD and nowhere near stable so yeah call em out on it.

              Comment


              • #47
                Originally posted by Vim_User View Post
                The features that they have dropped is power-management, so no, hibernating with Gnome 3.10 on OpenBSD will not work, because there is a dependency on systemd. Gnome developers just avoid talking about that with declaring power-management a "not essential" feature. Come on, in a world of mobile devices features like hibernation or suspend are "not essential"? They must be kidding.
                Wait, hold the phone. Systemd does power management now too? Getting to be the point where we're in the systemd ecosystem where the linux kernel is a dependency of systemd.

                Comment


                • #48
                  Originally posted by nll_a
                  Just like all the rest of the GNU/Linux distros, you mean? If anyone got any chance it's Ubuntu. Isn't that what all the Canonical hate is about?
                  I don't THINK so. I can hardly speak for others but what bothers me is that canonical is causing fragmentation in parts of the stack that are hard to deal with. Moreover, I haven't seen good reasons for their decisions. In short, I don't think whoever is making these decisions is doing so for technical reasons. That is harmful to the community.
                  However, I also don't honestly care that much b/c I think Canonical isn't going to be around much longer (unless Ubuntu Touch surprises me and becomes very popular). Shuttleworth has been dumping money into that company for a decade and seen little to no return. He can't keep doing that much longer. He doesn't have infinite resources.

                  Comment


                  • #49
                    Originally posted by nll_a
                    It's a very good read, I highly recomend it: http://smspillaz.wordpress.com/2013/...and-armchairs/
                    I read that and I struggle to find what, specficially he is referring to with regards to mir/wayland.
                    Mostly it seems to be addressing Shuttleworth's tea party comments.

                    Comment


                    • #50
                      Dear Canonical developers, please tag a new version of libnih and update the Upstart README file to list that version as required. Since a long time and at least as of v1.10, using Upstart with the currently recommended libnih version ("1.0.2 or later") causes it to choke on an assertion early on boot, and the only documentation saying that the solution is to use a certain branch of the libnih repository is to be found on a bugzilla entry over the Internet.

                      Comment

                      Working...
                      X