Re: GNU Emacs now runs in foreground

From: Martin \ <et.code_at_ethome.sk>
Date: Tue, 6 Dec 2016 10:40:20 +0100

> On Thu, 1 Dec 2016 12:54:38 -0500
> Steve Litt <slitt_at_troubleshooters.com> wrote:
>
> > On Thu, 1 Dec 2016 20:48:37 +0300
> > Jean Louis <bugs_at_gnu.support> wrote:
> > I have a strange feeling that you are joking...
>
> Not at all. You know mplayer can interact via a FIFO.
>
> Seriously, I'm not joking. I'm always interested in new ways to use my
> computer.
>
> SteveT

So you claim you are not joking, heh. I hope that is not coming from sarcasm
mode still. Ok, there exists some of this stuff, but is not that common.

I am immense fan of these user-level daemons (maybe they should have some more
exact name).

First, there are two major caveats, that I noticed, being seen as
disadvantages, to this design:
 
  1 - When such daemon crashes, your whole session is taken out. For example
  all terminals die, all shell process trees go out (make), so you can loose
  quite a lot of work.

  2 - There is more moving parts in these setups, and when you are
  unawarare of supervision, it might be hard to manage these daemons
  efficiently.

Software designed for this mode of operation obviously includes emacs now.
Teams and authors behind these, usually have pretty good abilities and
experience, as obviously designing this way requires some kind of architecture.
Thus most of these packages dont suck, and are quite reliable.

I personaly use/know these:

  - super famous tmux - terminal multiplexer
    - you are probably aware of that one, handles lots of terminal sessions

  - gnu screen - terminal multiplexer
    - older and poorer cousin of tmux

  - mpd - the music player daemon - basically music player
    - when spawned as it's own service outside of/before X it can keep music
      playing even as you are tweaking you xorg.conf :)
    - can route music over fifos through network and make many amchines play
      same music

  - rxvt-unicode - uberterminal
    - this thing can operate as normal xterm-like term (process per session),
      or as daemon, when single process hosts all your terminals
    - benefits are increased new terminal startup speed (on my current box,
      this is subsecond delay - helps when you treat terms as disposable
      "surfaces"), and supposedly memory conservation, as lots of data is shared
      between the windows

  - quassel - irc client
    - irc client core runs as headless daemon, client present interface
    - requires Qt and is quite heavy

  - irccd - irc client
    - irc client, core runs as headless daemon, that can be scripted
    - i used it originally for lua, but since it went js, i use old one

There are probably few others. Excluding screen and quassel, I use them daily.

Many other things can be "adapted" to daemon, for example aria2c downloader
supports xmlrpc interface. There is slew of bittorrent clients, that can be run
this way.

I make distinction though, that proper packages of this class,
make use of unix sockets by default (many things listen on TCP/IP only)
and deamon usercase is well thought out:
  - support for foreground mode is builtin
    - this foregorund is actually daemon foreground, with messages and,
      not cli commands listener (so it's not "normal" program fake daemon)
  - there is dedicated client program to talk to daemon
  - you can configure client/server connection control points
  - the whole setup is documented and intended by author

Regarding "major" problem 1., that of crashing, rxvt-unicode is most "felt" when
it trips over. Fortunately it is incredibly stable - I have crash it maybe one
or two times in 7 years time frame, daily use. I usually have 10-100 open
terminals per xsession.

Supervisors are pretty great at taming and organizing these things.
I see you wrote articles about supervision (in post systemd world),
maybe there would be will to collect & categorise these user-level daemon tools
and provide more information on how to supervise them?

  eto
Received on Tue Dec 06 2016 - 09:40:20 UTC

This archive was generated by hypermail 2.3.0 : Sun May 09 2021 - 19:44:19 UTC