3 ms·

That isn't so true anymore, given their focus on home directory management and killing all user processes on logout (desktop-focused and doesn't work well with

That isn't so true anymore, given their focus on home directory management and killing all user processes on logout (desktop-focused and doesn't work well with tmux or ssh)

otabdeveloper4 4y ago
> killing all user processes on logout This is a good default for the server use-case, to prevent developers and sysadmins launching stealth long-running jobs. (Especially if they steal resources.) The idea is you'd run batch jobs and services explicitly via systemd-run.
- effie 4y ago
  Why is systemd developers preventing sysadmins/developers from something they want to do on their own/assigned machines a "good default"? Why is their systemd-run idea valid and decades of established unix practice is not? This is really bonkers, don't invent or repeat "rationale" from the vendorthat obviously is anti-user and makes no sense.
  - otabdeveloper4 4y ago
    Security by default is usually a good default, yes. systemd-run exists because a) you can use it to limit resources, b) it registers long-running processes under systemctl so you can interact with them under another session, and c) logs go into a central place. Established Unix practice doesn't give you any of that unless you write a mountain of very opinionated shell scripts, which at that point why not just use the standard systemd instead?
    - effie 4y ago
      Security is a spectrum, and too much security means less freedom and shitty life experience. I don't have a problem with a new tool such as systemd-run. I do have a problem with breaking well established workflows in the name of security/efficiency/ideology, when users didn't ask for it. That is a policy question with different answers on different systems. Anybody who cares about that kind of restrictions has to think and implement policies on their systems on their own. Relying on systemd to do the right policy thing for everybody is unrealistic, naive and warped idea of what users need.

That isn't so true anymore, given their focus on home directory management and killing all user processes on logout (desktop-focused and doesn't work well with tmux or ssh)

otabdeveloper4 4y ago

> killing all user processes on logout This is a good default for the server use-case, to prevent developers and sysadmins launching stealth long-running jobs. (Especially if they steal resources.) The idea is you'd run batch jobs and services explicitly via systemd-run.

effie 4y ago
Why is systemd developers preventing sysadmins/developers from something they want to do on their own/assigned machines a "good default"? Why is their systemd-run idea valid and decades of established unix practice is not? This is really bonkers, don't invent or repeat "rationale" from the vendorthat obviously is anti-user and makes no sense.
- otabdeveloper4 4y ago
  Security by default is usually a good default, yes. systemd-run exists because a) you can use it to limit resources, b) it registers long-running processes under systemctl so you can interact with them under another session, and c) logs go into a central place. Established Unix practice doesn't give you any of that unless you write a mountain of very opinionated shell scripts, which at that point why not just use the standard systemd instead?
  - effie 4y ago
    Security is a spectrum, and too much security means less freedom and shitty life experience. I don't have a problem with a new tool such as systemd-run. I do have a problem with breaking well established workflows in the name of security/efficiency/ideology, when users didn't ask for it. That is a policy question with different answers on different systems. Anybody who cares about that kind of restrictions has to think and implement policies on their systems on their own. Relying on systemd to do the right policy thing for everybody is unrealistic, naive and warped idea of what users need.