5 ms·

Requiring use of systemd-specific configurations and tools is absurd. People who want to start a long-running process and check on it shouldn't even need to kno

Requiring use of systemd-specific configurations and tools is absurd. People who want to start a long-running process and check on it shouldn't even need to know the computer is running systemd. Straightforward usage of nohup, tmux, and other equally standard and/or portable tools should be the most that a system administrator who wants to kill unwanted background processes requires of end users.

madmax96 10y ago
I agree with this. This actually describes a lot of my problems with Docker as well: I __hate__ that I have to use `docker ps`, etc. This is due to a weakness in traditional UNIX architectures. I ran HURD in a virtual machine a while back and it has the solution to this problem: translators. I can't wait until they hit a 1.0 release of HURD.
gnoway 10y ago
Well I thought it was obvious, but my reply was intended to be sarcastic. For it to be taken at face value by anyone kind of highlights the problem with the systemd approach, IMO.
- JdeBP 10y ago
  > Anyway I'm sure there will be a systemd-mux soon enough where you can declaratively define your long-running post-logout processes and register them via muxctl or some other existing sd-bus client. The problem with your sarcasm is that it actually matches current reality. This is how various programs are busily being rearchitected to operate, or indeed already have been rearchitected to operate. Take gnome-terminal, for example. Nowadays, a gnome-terminal-server service runs under the per-user systemd service manager, and requests to open more terminals generated by the gnome-terminal program arrive at it over the per-user Desktop Bus. gnome-terminal is a Desktop Bus client. The gnome-terminal-server service used to be Desktop Bus activated, rather than simply run as a per-user systemd service. Ironically, given the headline on this page, this too hit a problem with a systemd release turning things on a while back. systemd version 228, in fact. All of the terminal emulator processes and the shells and login sessions that they spawned ended up sharing a single 512 maximum threads limit. * https://news.ycombinator.com/item?id=11675129 https://news.ycombinator.com/item?id=11675129 And yes, gnome-terminal-server too suffered from the kills-screen-and-tmux problem: * https://lists.freedesktop.org/archives/dbus/2015-January/016504.html https://lists.freedesktop.org/archives/dbus/2015-January/016...
  - digi_owl 10y ago
    Am i right in thinking that the client end talks to the server via dbus only? Because that brings to mind a recent project i learned about that plans to stream video via dbus...
    - JdeBP 10y ago
      Yes, since 2011. * https://github.com/GNOME/gnome-terminal/commit/e1d641726cf0dec350b33e62d78eb6df9186443e https://github.com/GNOME/gnome-terminal/commit/e1d641726cf0d...
- HelloNurse 10y ago
  I noticed the sarcasm in the bit about the hundreds of thousands of "inconvenienced" users, but the forecast about systemd-specific tools appears bitter and realistic, perfectly aligned in its defeatism with my modest hearsay knowledge of systemd from outraged news reports.

madmax96 10y ago

I agree with this. This actually describes a lot of my problems with Docker as well: I __hate__ that I have to use `docker ps`, etc. This is due to a weakness in traditional UNIX architectures. I ran HURD in a virtual machine a while back and it has the solution to this problem: translators. I can't wait until they hit a 1.0 release of HURD.

gnoway 10y ago

Well I thought it was obvious, but my reply was intended to be sarcastic. For it to be taken at face value by anyone kind of highlights the problem with the systemd approach, IMO.

JdeBP 10y ago
> Anyway I'm sure there will be a systemd-mux soon enough where you can declaratively define your long-running post-logout processes and register them via muxctl or some other existing sd-bus client. The problem with your sarcasm is that it actually matches current reality. This is how various programs are busily being rearchitected to operate, or indeed already have been rearchitected to operate. Take gnome-terminal, for example. Nowadays, a gnome-terminal-server service runs under the per-user systemd service manager, and requests to open more terminals generated by the gnome-terminal program arrive at it over the per-user Desktop Bus. gnome-terminal is a Desktop Bus client. The gnome-terminal-server service used to be Desktop Bus activated, rather than simply run as a per-user systemd service. Ironically, given the headline on this page, this too hit a problem with a systemd release turning things on a while back. systemd version 228, in fact. All of the terminal emulator processes and the shells and login sessions that they spawned ended up sharing a single 512 maximum threads limit. * https://news.ycombinator.com/item?id=11675129 https://news.ycombinator.com/item?id=11675129 And yes, gnome-terminal-server too suffered from the kills-screen-and-tmux problem: * https://lists.freedesktop.org/archives/dbus/2015-January/016504.html https://lists.freedesktop.org/archives/dbus/2015-January/016...
- digi_owl 10y ago
  Am i right in thinking that the client end talks to the server via dbus only? Because that brings to mind a recent project i learned about that plans to stream video via dbus...
  - JdeBP 10y ago
    Yes, since 2011. * https://github.com/GNOME/gnome-terminal/commit/e1d641726cf0dec350b33e62d78eb6df9186443e https://github.com/GNOME/gnome-terminal/commit/e1d641726cf0d...
HelloNurse 10y ago
I noticed the sarcasm in the bit about the hundreds of thousands of "inconvenienced" users, but the forecast about systemd-specific tools appears bitter and realistic, perfectly aligned in its defeatism with my modest hearsay knowledge of systemd from outraged news reports.