4 ms·

Yes. I’m not being emotional about it, just irritated. Systemd has tangibly caused me to lose work with tmux; I appreciate there are root causes for this, but

Yes. I’m not being emotional about it, just irritated. Systemd has tangibly caused me to lose work with tmux; I appreciate there are root causes for this, but frankly, if some piece of someone’s code does that, for whatever reason that is beyond my control to immediately stop using it... ...it feels justified to be annoyed. How do you suggest an alternative meaningful response would look? Create my own distribution? What tangible and meaningful alternatives do I have other than encouraging people not to use systemd?

deno 8y ago
> Create my own distribution? > What tangible and meaningful alternatives do I have other than encouraging people not to use systemd? Sure, if you think you can actually “test every single program and make everything opt-in.” I think you will however find that making everyone happy and having new features are just simply contradictory by the very definition. At some point you will want new stuff and you’ll have to break something. The best you could do is adopt BSD’s model and fork tmux and other userland and ship outdated/patched versions. It’s a ton of work, of course. I am not actually seriously suggesting you create your own distro, after all you can probably just fix the annoying issue with systemd and move on with your life, and Systemd actually makes it easy for your by making it a configuration switch and supporting the non-default workflow. I am simply suggesting you put yourself in the position of someone that has to make those decisions and really think about it from that perspective. Everything’s always a trade off.
- inferiorhuman 8y ago
  > I am not actually seriously suggesting you create your own distro, after all you can probably just fix the annoying issue with systemd and move on with your life, and Systemd actually makes it easy for your by making it a configuration switch and supporting the non-default workflow. Given the extraordinary scope of systemd, what happens with the next major issue? Having to perpetually work around poorly designed software is infuriating. > I am simply suggesting you put yourself in the position of someone that has to make those decisions and really think about it from that perspective. Everything’s always a trade off. Why should the onus be on the end user? Perhaps the distributions should be making choices that are less antagonistic of their users (e.g. upstart instead of systemd). You're right about the tradeoffs though, and one of the tradeoffs for buying into systemd is angry users.
  - deno 8y ago
    > Given the extraordinary scope of systemd, what happens with the next major issue? Having to perpetually work around poorly designed software is infuriating. Systemd doesn’t break stuff if they just feel like it. Everything is compatible if it can be, for example you can still run /etc/init.d scripts and manage them through systemd on Debian. Lingering processes are also still supported! It’s a configuration switch that most distros decided to turn on by default, because... > Why should the onus be on the end user? Perhaps the distributions should be making choices that are less antagonistic of their users (e.g. upstart instead of systemd). ... it’s a net benefit to most users. It’s only “antagonistic” to a particular subset of powerusers perfectly capable of working around the issue but somehow more motivated to loudly complain about it on Internet. > You're right about the tradeoffs though, and one of the tradeoffs for buying into systemd is angry users. Fair deal if it helps with even 0.1% desktop market share.
    - erik_seaberg 8y ago
      > particular subset of powerusers perfectly capable of working around the issue What is the actual workaround? Is there a patch that unbreaks nohup by passing cwd and env to systemd-run --user or something?
      - deno 8y ago
        Take a look at this: https://github.com/tmux/tmux/issues/428 https://github.com/tmux/tmux/issues/428
        erik_seaberg 8y ago
        I see arguing but no consensus on what ought to be done. My use case: I run a shell pipeline that will probably take all weekend to finish. On a POSIX box I start it with nohup. What do I do on a systemd box? Does nohup need a patch that doesn't exist yet?
        inferiorhuman 8y ago

deno 8y ago

> Create my own distribution? > What tangible and meaningful alternatives do I have other than encouraging people not to use systemd? Sure, if you think you can actually “test every single program and make everything opt-in.” I think you will however find that making everyone happy and having new features are just simply contradictory by the very definition. At some point you will want new stuff and you’ll have to break something. The best you could do is adopt BSD’s model and fork tmux and other userland and ship outdated/patched versions. It’s a ton of work, of course. I am not actually seriously suggesting you create your own distro, after all you can probably just fix the annoying issue with systemd and move on with your life, and Systemd actually makes it easy for your by making it a configuration switch and supporting the non-default workflow. I am simply suggesting you put yourself in the position of someone that has to make those decisions and really think about it from that perspective. Everything’s always a trade off.

inferiorhuman 8y ago
> I am not actually seriously suggesting you create your own distro, after all you can probably just fix the annoying issue with systemd and move on with your life, and Systemd actually makes it easy for your by making it a configuration switch and supporting the non-default workflow. Given the extraordinary scope of systemd, what happens with the next major issue? Having to perpetually work around poorly designed software is infuriating. > I am simply suggesting you put yourself in the position of someone that has to make those decisions and really think about it from that perspective. Everything’s always a trade off. Why should the onus be on the end user? Perhaps the distributions should be making choices that are less antagonistic of their users (e.g. upstart instead of systemd). You're right about the tradeoffs though, and one of the tradeoffs for buying into systemd is angry users.
- deno 8y ago
  > Given the extraordinary scope of systemd, what happens with the next major issue? Having to perpetually work around poorly designed software is infuriating. Systemd doesn’t break stuff if they just feel like it. Everything is compatible if it can be, for example you can still run /etc/init.d scripts and manage them through systemd on Debian. Lingering processes are also still supported! It’s a configuration switch that most distros decided to turn on by default, because... > Why should the onus be on the end user? Perhaps the distributions should be making choices that are less antagonistic of their users (e.g. upstart instead of systemd). ... it’s a net benefit to most users. It’s only “antagonistic” to a particular subset of powerusers perfectly capable of working around the issue but somehow more motivated to loudly complain about it on Internet. > You're right about the tradeoffs though, and one of the tradeoffs for buying into systemd is angry users. Fair deal if it helps with even 0.1% desktop market share.
  - erik_seaberg 8y ago
    > particular subset of powerusers perfectly capable of working around the issue What is the actual workaround? Is there a patch that unbreaks nohup by passing cwd and env to systemd-run --user or something?
    - deno 8y ago
      Take a look at this: https://github.com/tmux/tmux/issues/428 https://github.com/tmux/tmux/issues/428
      - erik_seaberg 8y ago
        I see arguing but no consensus on what ought to be done. My use case: I run a shell pipeline that will probably take all weekend to finish. On a POSIX box I start it with nohup. What do I do on a systemd box? Does nohup need a patch that doesn't exist yet?
        inferiorhuman 8y ago