Announcement

Collapse
No announcement yet.

Facebook Continues Making Extensive Use Of systemd

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

  • #31
    Originally posted by cybertraveler View Post
    IDK what you are talking about with regards to OpenRC.

    Upstart works great. I still use it on one of my systems. I'll miss it when it's gone. Robust, fast, lightweight, modular.
    As I already said, to run a normal desktop or a simple server even SysV is fine. There is nothing you can realistically run at home where you actually need something like systemd.

    Upstart was supposed to be an improvement over that, for companies. But for example it didnt't really handle well the multithreaded startup thing that OpenRC and Systemd do. Which is why most distros dropped it like a hot potato when it was the time to choose between that or Systemd or OpenRC

    Comment


    • #32
      Originally posted by starshipeleven View Post
      Upstart was supposed to be an improvement over that, for companies. But for example it didnt't really handle well the multithreaded startup thing that OpenRC and Systemd do. Which is why most distros dropped it like a hot potato when it was the time to choose between that or Systemd or OpenRC
      That's not what happened.

      Firstly: Upstart has an asynchronous design. It can start jobs in parallel:

      It was necessary to outline the limitations of the SysV and dependency-based init systems to appreciate why Upstart is special...
      Upstart is revolutionary as it recognises and was designed specifically for a dynamic system. It handles asynchronicity by emitting events. This too is revolutionary.
      Upstart emits "events" which services can register an interest in. When an event -- or combination of events -- is emitted that satisfies some service's requirements, Upstart will automatically start or stop that service. If multiple jobs have the same "start on" condition, Upstart will start those jobs ''in parallel''. To be manifest: Upstart handles starting the "dependent" services itself - this is not handled by the service file itself as it is with dependency-based systems.
      source

      This parrallel execution of tasks worked great. Canonical managed to massively cut down the boot time of their Desktop OS using Upstart.

      Secondly: Mark Shuttleworth was very keen on staying with Upstart and not using Systemd. Mark and Canonical only changed their mind after their upstream OS (Debian) adopted Systemd. Before that happened Mark described systemd as

      hugely invasive and hardly justified
      source

      Comment


      • #33
        Originally posted by starshipeleven View Post

        rm -R $YourBullshit
        What about the Google fallback DNS?

        Comment


        • #34
          Originally posted by cybertraveler View Post
          Firstly: Upstart has an asynchronous design. It can start jobs in parallel:
          Yeah that's the theory. In practice it got decent at that too late.

          Comment


          • #35
            Originally posted by tildearrow View Post
            What about the Google fallback DNS?
            I disagree with that choice, on a different level (if your config is fucked up it should not work, that's the only safe way to fail in this case).

            I don't hold a grudge against Google DNS, it's not like "OpenDNS" is better (Cisco) or CloudFlare DNS is better on the privacy metric.

            Just don't use systemd-resolved. Afaik only Ubuntu uses it of the desktop distros. Don't use Ubuntu. Problem solved.

            Comment


            • #36
              Originally posted by starshipeleven View Post
              Yeah that's the theory. In practice it got decent at that too late.
              Weird that you don't acknowledge my corrections.

              Also: I don't think what you said is true.

              I think Upstart worked decently exactly when it needed to. I still have 1 old system which uses Upstart and it works perfectly. It's rock solid stable, fast to boot and service management is simple. Upstart was ready and working on time (well over 4 years ago now). Ubuntu would have continued thriving with Upstart as an init system.

              Canonical almost certainly adopted systemd because they saw other big distros adopting it and their upstream distro was adopting it so it was the path of least resistance.

              Comment


              • #37
                Originally posted by cybertraveler View Post
                Weird that you don't acknowledge my corrections.
                Corrections of what? They are both appeals to (biased?) authority.
                Not that so far I have strongly backed up what I said either, but still. This is just a chat.

                I think Upstart worked decently exactly when it needed to.
                As I already said, the whole point of a complex and powerful init system is servers where you have to start up your own application chains, if you are running mostly independent applications pre-configured by distro maintainers then it will work decently even if it's garbage, as long as the maintainers are good.

                One of the reasons I had issues with it (weird bugs notwithstanding) is that Upstart is event-based, i.e. it starts services depending on the system status or event, but does not check application dependencies per-se. This matters when you are writing the init scripts to start custom services in a server.

                So it could happen that you set up stuff and then some event triggers too soon or too late and your applications startup is fucked up. Or the service shutdown is a trainwreck (still bad as this means applications crashing and/or corrupting databases or whatever crappy applications do when they crash).

                Or you have applications that need to be started in a specific sequence at the same system state, and you have no way to do so without doing hacks or using a single init script for all of them (which kind of defies the point).

                I mean, yeah, it was doable and we could still work around stuff, but it was still kind of meh.

                Meanwhile, Systemd and OpenRC are dependency-based init systems. This means that while they still have some kind of "events" or "system states" they react to, they will start up applications in the right order because they know what depends on what.

                Canonical almost certainly adopted systemd because they saw other big distros adopting it and their upstream distro was adopting it so it was the path of least resistance.
                I can't speak for Canonical, but if basically everyone adopted either Systemd or OpenRC instead of making a fork of Upstart to sidestep the Canonical CLA, there are probably some valid technical reasons too, it's not just politics. Also TruOS (FreeBSD derivative) has adopted OpenRC.

                Comment


                • #38
                  Originally posted by msotirov View Post
                  Well, you can twist the semantics however you like, but for all intents and purposes (and definitely for the non-technical user), the session is the login.
                  non-technical user doesn't know and doesn't care what systemd is. systemd manages user session but doesn't replace login command

                  Comment


                  • #39
                    Originally posted by cybertraveler View Post
                    You should quote that variable. He may have used spaces. That command could thus go horribly wrong.
                    not if he has several pieces of bullshit separated by spaces

                    Comment


                    • #40
                      Originally posted by cybertraveler View Post
                      Robust, fast, lightweight, modular.
                      broken by design if you believe its author

                      Comment

                      Working...
                      X