Threads for paulv

  1. 7

    I like systemd. Whenever it comes up I tend to ignore the comments because of the haters, but know that not everyone hates it.

    Bona fides: professional Linux sysadmin. ~20 year Linux user (~16 as my only desktop OS). I don’t work for Red Hat.

    1. 4

      Not an unreasonable comment, but in this thread? “Hey tmux guy, get to work and do as the nice systemd people say.”

      1. 11

        I didn’t mean for my comment to read that way, my apologies for being unclear.

        The various distribution maintainers seem to agree that systemd is the future, at least for now, which ultimately means tmux will either not work as advertised or will require some modifications. It sounds like those will ether be part of a non-standard patch bringing in a dbus dependency that the distribution ships or some sort of wrapper around tmux that invokes systemd-run, also implemented as a non-standard distribution provided patch. It’s unfortunate that the systemd developers have burned all the goodwill that other people and projects were willing to give them. But the bridges were burned, the systemd folks were jackasses, and now everyone hates them regardless of the technical merits of systemd may have.

        In conclusion: don’t be a jackass. Also, empathy.

        1. 4

          That’s fair.

      2. 2

        Edit: Misread TFA. Made silly comment. Deleted.

        1. 3

          It never was “I live as long as the box lives”. It was “I live as long as I’m not told to quit, or until the box shuts down”.

          And who tells tmux to quit? Why yes, the user (if not the admin). That is how tmux knows how long the user needs it; by the user telling it to quit when no longer needed. Now how does systemd help here again?

          This change isn’t about making a new way for the user to tell tmux to quit, it’s about making a new way for tmux to say it doesn’t want to be quit. We already have a way to do that. Don’t break that.

          1. 2

            One of the purposes of screen and tmux is to stay there after the session is disconnected and to be available for re-attachment when the user reconnects. If it weren’t its purpose, it would not ignore SIGHUP.

            1. 1

              Huh? The proposed solution is for tmux to create a lingering scope, which also lives forever. It is exactly as “wasteful” as before. The only thing that changes is how many more hundreds of lines of code are necessary to achieve this effect.