7 ms·

So you think backwards compatibility is so important that we should keep old BROKEN and INSECURE behavior just for the sake of not inconveniencing few power use

by deno 8y ago

So you think backwards compatibility is so important that we should keep old BROKEN and INSECURE behavior just for the sake of not inconveniencing few power users with technical knowledge to override it? Instead those few loudest complaining should be catered to and regular users left for the wolves… I think some people sometimes lack any perspective on the topic.

wokwokwok 8y ago
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?
dooglius 8y ago
What on earth is broken or insecure about not killing processes?
- deno 8y ago
  You watch porn, log out, but mpv is somehow stuck and still playing. Broken enough?
  - dooglius 8y ago
    If I've nohup'd mpv or put it in a tmux shell, then that is the behavior I want. For instance, if I ssh into a controller for a home entertainment system to kick off a video, then this would be exactly what I want.
    - deno 8y ago
      Then you can toggle one simple configuration switch, instead of forcing confusing behavior on the other 99% of users that don’t want or need it. Take a step back and consider if say Windows did it like that, wouldn’t you agree it is broken?
      - dooglius 8y ago
        > Then you can toggle one simple configuration switch Only if I have root permissions (granted, I probably wouldn't be watching porn on a machine I wasn't admin on but that was just an example application). > instead of forcing confusing behavior on the other 99% of users that don’t want or need it Who is forcing users to run programs with nohup or tmux shells? > Take a step back and consider if say Windows did it like that, wouldn’t you agree it is broken? I'm pretty sure Windows does do it like this; if I were to remote desktop into a Windows box and start playing a video, it should keep playing even if I disconnect, reconnect, and log back in. It does this for normal applications, at least, though videos are a special enough case where it might be accelerating with the remote GPU.
        8y ago
rauhl 8y ago
SIGHUP isn’t broken & insecure: it works, and it is secure. Processes which don’t want to handle the hangup signal are terminated, and processes which want to ignore it do.
- deno 8y ago
  Tell me more about this perfect world with no bugs and nondeterministic behavior.
  - mruts 8y ago
    Well, there are some pretty severe restrictions on the type of code you can put into signal handlers. Only atomic operations are allowed. And, in my experience, almost all applications react appropriately to signals.
    - deno 8y ago
      When they work, sure. And when they don’t the user is wondering why his laptop is playing sounds when she’s logged out. Systemd’s solution is the right one from technical POV. No need to hope applications cooperate when you can just ask the kernel to make sure they do.
    - MertsA 8y ago
      >Well, there are some pretty severe restrictions on the type of code you can put into signal handlers. Err... Maybe I'm missing something but I don't believe that's the case. There's a lot of things that you shouldn't do inside of a signal handler that will exhibit undefined behavior, but it's not like the kernel puts any restrictions on what the application can do inside of a signal handler. If an application wants to make SIGHUP just call whatever existing application exit logic they already have, they can. It's a terrible idea because if the application was signalled in the middle of some library call then it's anyone's guess as to whether or not it's just going to crash but that doesn't mean that you can't do it. I think you're underestimating the difficulty of gracefully shutting down an application in a signal handler. If it's waiting for the application to finish some operation it's stuck in it'll just do the exact same thing as using nohup and there's no way to know that outside of the application.
EpicEng 8y ago
>I think some people sometimes lack any perspective on the topic. Apparently you think Linus is one of those who "lack perspective"? http://lkml.iu.edu/hypermail/linux/kernel/1711.2/01701.html http://lkml.iu.edu/hypermail/linux/kernel/1711.2/01701.html I get that systemd isn't the kernel, but it's close enough. There are many who would agree that breaking existing behavior in the name of security isn't wise. I have also not yet seen anyone point out specific security issues this solved. Unix has worked this way for a long time.
- deno 8y ago
  User launches voice chat, logs out, application stays around and listens on user/other users. Just one example. Having programs running despite being logged out is unintuitive and wrong. Most users do not know or care about going into a task manager. And if you want Linux to ever have a chance to succeed on desktop, they shouldn’t have to. As to the Linus’ post, if you want to argue that there wasn’t enough notice about this change, then that’s fine, but this isn’t what anyone here is arguing. Also it’s a configuration switch, any distribution could have decided to revert it or postpone it at their choosing.

by deno 8y ago

wokwokwok 8y ago

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?

dooglius 8y ago

What on earth is broken or insecure about not killing processes?

deno 8y ago
You watch porn, log out, but mpv is somehow stuck and still playing. Broken enough?
- dooglius 8y ago
  If I've nohup'd mpv or put it in a tmux shell, then that is the behavior I want. For instance, if I ssh into a controller for a home entertainment system to kick off a video, then this would be exactly what I want.
  - deno 8y ago
    Then you can toggle one simple configuration switch, instead of forcing confusing behavior on the other 99% of users that don’t want or need it. Take a step back and consider if say Windows did it like that, wouldn’t you agree it is broken?
    - dooglius 8y ago
      > Then you can toggle one simple configuration switch Only if I have root permissions (granted, I probably wouldn't be watching porn on a machine I wasn't admin on but that was just an example application). > instead of forcing confusing behavior on the other 99% of users that don’t want or need it Who is forcing users to run programs with nohup or tmux shells? > Take a step back and consider if say Windows did it like that, wouldn’t you agree it is broken? I'm pretty sure Windows does do it like this; if I were to remote desktop into a Windows box and start playing a video, it should keep playing even if I disconnect, reconnect, and log back in. It does this for normal applications, at least, though videos are a special enough case where it might be accelerating with the remote GPU.
      - 8y ago

rauhl 8y ago

SIGHUP isn’t broken & insecure: it works, and it is secure. Processes which don’t want to handle the hangup signal are terminated, and processes which want to ignore it do.

deno 8y ago
Tell me more about this perfect world with no bugs and nondeterministic behavior.
- mruts 8y ago
  Well, there are some pretty severe restrictions on the type of code you can put into signal handlers. Only atomic operations are allowed. And, in my experience, almost all applications react appropriately to signals.
  - deno 8y ago
    When they work, sure. And when they don’t the user is wondering why his laptop is playing sounds when she’s logged out. Systemd’s solution is the right one from technical POV. No need to hope applications cooperate when you can just ask the kernel to make sure they do.
  - MertsA 8y ago
    >Well, there are some pretty severe restrictions on the type of code you can put into signal handlers. Err... Maybe I'm missing something but I don't believe that's the case. There's a lot of things that you shouldn't do inside of a signal handler that will exhibit undefined behavior, but it's not like the kernel puts any restrictions on what the application can do inside of a signal handler. If an application wants to make SIGHUP just call whatever existing application exit logic they already have, they can. It's a terrible idea because if the application was signalled in the middle of some library call then it's anyone's guess as to whether or not it's just going to crash but that doesn't mean that you can't do it. I think you're underestimating the difficulty of gracefully shutting down an application in a signal handler. If it's waiting for the application to finish some operation it's stuck in it'll just do the exact same thing as using nohup and there's no way to know that outside of the application.

EpicEng 8y ago

>I think some people sometimes lack any perspective on the topic. Apparently you think Linus is one of those who "lack perspective"? http://lkml.iu.edu/hypermail/linux/kernel/1711.2/01701.html http://lkml.iu.edu/hypermail/linux/kernel/1711.2/01701.html I get that systemd isn't the kernel, but it's close enough. There are many who would agree that breaking existing behavior in the name of security isn't wise. I have also not yet seen anyone point out specific security issues this solved. Unix has worked this way for a long time.

deno 8y ago
User launches voice chat, logs out, application stays around and listens on user/other users. Just one example. Having programs running despite being logged out is unintuitive and wrong. Most users do not know or care about going into a task manager. And if you want Linux to ever have a chance to succeed on desktop, they shouldn’t have to. As to the Linus’ post, if you want to argue that there wasn’t enough notice about this change, then that’s fine, but this isn’t what anyone here is arguing. Also it’s a configuration switch, any distribution could have decided to revert it or postpone it at their choosing.