Announcement

Collapse
No announcement yet.

Systemd 240 Released To End 2018 On A High Note

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

  • #41
    Originally posted by frank007 View Post
    Already switched over. Good luck.
    lol, you have so little luck, you should ask for it, not offer it

    Comment


    • #42
      Originally posted by frank007 View Post
      I'm just switching from systemd to a different init system. I already experienced an unbootable system (doing nothing) because of it. That's all.
      I remember Sysvinit, I remeber how easy it was to manage, I remeber everythin, so I'm just switching over.
      Come join us who run voidlinux. My slowest spinning disk systems all boot to login in 13s or less. The nvme one goes all the way to desktop in about 8s. I want an init system, not a windows/osx system clone.

      Comment


      • #43
        Originally posted by frank007 View Post
        Already switched over. Good Luck.
        I don't give a shit. Good luck to you too, good sir.

        Comment


        • #44
          Originally posted by starshipeleven View Post
          Something else failed and systemd is just what you decided to blame.
          Apart for Kernel panics (which should be visible not opaque) and hardware failures I think it's clear that a blocked boot is an init system issue. I like systemd myself, but if this happened to me I'd be contemplating a switch too.

          Comment


          • #45
            Originally posted by Almindor View Post
            Apart for Kernel panics (which should be visible not opaque) and hardware failures I think it's clear that a blocked boot is an init system issue.
            FYI: what causes these types of "failures to boot" is some service that hangs or the init script/configuration that is wrong somehow but is tagged as critical, it's not a Systemd-only thing. It's just that systemd is the newer thing.

            Most common mistake back then when it was new and people was still learning how to use it was adding a mount point in the fstab and not tagging it as "nofail". Then for some reason that drive is removed or you reformat or something, and systemd does not find that partition again on boot and blocks booting.

            I like systemd myself, but if this happened to me I'd be contemplating a switch too.
            I actually troubleshooted the issues back then when systemd was new and some breakage was expected, and I'd do that again if I got breakage.

            all the times I investigated it was 100% misconfigured crap, not a bug.

            Systemd has bugs allright, but never had it hang or break hard on its own.

            Comment


            • #46
              Originally posted by pal666 View Post
              fedora is the major distro that releases the most often. though it is downstream who synchronises with upstream and systemd doesn't do time-based releases
              Fedora has releases every 6 months, sometimes lees often. That makes it almost, but not quite, as often as Ubuntu. Which BTW is too often in my opinion.

              Comment


              • #47
                I'm back at 239. Got some d-bus error at login with 240.

                Comment


                • #48
                  Still running systemd 238.254 even though arch linux probably has 240 by now. Can't be bothered to upgrade. If it's working, why risk breaking it?

                  Comment


                  • #49
                    Originally posted by caligula View Post
                    What worries me is how systemd is adopting container tech. They're replacing the lean, lightweight, super optimized minimal docker with super bloated systemd-nspawn. Oh wait..
                    Ya almost caught me there.

                    Comment


                    • #50
                      Originally posted by lumks View Post
                      What I still wish to get, would be a more dynamic environment.d that can run scripts/scriplets to generate some env vars. So we could phase out everything in /etc/profile.d
                      Something like that would solve a ton of issues, honestly. However the semantics are not really obvious. Run scripts per unit? Or per session? Or...?
                      Things get even more messy when you throw user and graphical sessions into the mix. As it stands now, every major DM and DE does things subtly differently, disregarding resource scopes and lifetimes along the way. Ever heard about GNOME session manager pushing per-session variables like $DISPLAY into `systemd --user` and user dbus daemon? Now guess what happens when you exit the session.

                      There's no obvious clean way of solving the environment variable mess. Sometimes I think that environment variables are just not suited for passing anything subject to change. $DISPLAY, $SSH_AUTH_SOCK, I'm looking at you.

                      Comment

                      Working...
                      X