Not knowing that foot is a terminal emulator, I assumed that foot is some kind of improved resource manager that allows for a general lesser resource usage.
I do the same thing with URxvt as a systemd daemon, Tmux as a transient service with systemd-run from .bashrc, and a script in i3wm to run URxvtd client or hide/get the window.
The way I use to run Tmux from a transient service locally and in ssh with the same .bashrc is nice I think. Tmux will survive the terminal and even if I close my session and come back to it:
#!/usr/bin/env bash
# ~/.bashrc: sourced by bash(1) for non-login shells.
# If not running interactively, don't do anything
case $- in
*i*) ;;
*) return ;;
esac
chmod 700 ~/.bashrc.d
chmod 600 ~/.bashrc ~/.bashrc.d/*
# check if we are already in a Tmux session and not in ssh then open/attach the default one
if [[ ! "${TERM}" == "tmux"* ]] && [[ -z "${TMUX}" ]] && [[ -z "${SSH_CONNECTION}" ]] && command -v tmux 1> /dev/null; then
# attach or start the local default Tmux session
if systemctl --quiet $([[ $(id -u) != 0 ]]; echo "--user") is-active tmux-local-$(id -un).scope; then
tmux -L local-$(id -un) attach-session -t local-$(id -un) ; exit
fi
systemd-run -q --unit tmux-local-$(id -un) --scope $([[ $(id -u) != 0 ]] && echo "--user") tmux -L local-$(id -un) new-session -s local-$(id -un) ; exit
elif [[ -z "${TMUX}" ]] && [[ -n "${SSH_CONNECTION}" ]] && command -v tmux 1> /dev/null; then
# attach or start the ssh default Tmux session
if systemctl --quiet $([[ $(id -u) != 0 ]]; echo "--user") is-active tmux-ssh-$(id -un).scope; then
tmux -L ssh-$(id -un) attach-session -t ssh-$(id -un) ; exit
fi
systemd-run -q --unit tmux-ssh-$(id -un) --scope $([[ $(id -u) != 0 ]] && echo "--user") tmux -L ssh-$(id -un) new-session -s ssh-$(id -un) && exit || echo 'Tmux Systemd unit failed/exited'
fi
# if Tmux is not installed or if we are inside a Tmux session continue the sourcing
for file in ~/.bashrc.d/*.bashrc;
do
source "${file}"
done—
1: https://wiki.gentoo.org/wiki/Foot#Server_mode_configuration
Here is the project official repository: https://codeberg.org/dnkl/foot
I ended up dropping it for the same reason I dropped emacs server. There are rare edge cases which causes the server to hang and thus taking down not just one instance of your work, but all of it. Losing the resilience of multiple processes is not worth the RAM it saves, not on modern hardware.
I keep seeing comments like this popping up on HN. Do you guys have some funky esoteric configs?
In my case, where I only changed the color scheme and font, the limiting factor when starting alacritty is how fast I can move my fingers to the i3 shortcut. And I'm not running this on some exotic, fast hardware, just your standard crappy corporate HP laptop from a few years ago.
The only time there was a noticeable lag was when my zsh config was borked.
However the absolute times are still probably not noticable unless you often cold-start terminals.
| Alacritty | Foot | Foot Client |
Absolute time (ms) | 99.0 | 37.2 | 22.8 |If it was an app I opened by pressing Super and typing “terminal”, I probably wouldn’t need the speed increase. But the shortcut is easily accessible from home row, so I press it often and quickly.
> Figure 1: Snapshot of memory consumption (from btop), clients take around 10x less memory
By all means use a server/clients approach if it reduces per-process memory, but it's probably not as bad as it looks, because AFAIK the actual executable only gets loaded once and then reused. So each process has its own data in RAM, but the executable/binary only gets loaded the once.
Also, if this is a problem maybe revisit your choice of terminal? It's annoyingly hard to get a total (or more likely I just don't know how to get it), but every number I can seem to find says alacritty is only using <2MB total on my box, so your 27M max on foot looks... weird. Like, I can run a full standalone terminal in the size of your client; I appreciate that it might have features that make it worthwhile, but consider the tradeoffs?
Though of course, the memory usage on modern machines is really not a major issue, but the configuration update, along with the tmux session death was annoying..
EDIT: Some timing metrics..
foot -s &
hyperfine --warmup 8 'alacritty -e true' 'foot -e true' 'footclient -e true'
Benchmark 1: alacritty -e true
Time (mean ± σ): 99.0 ms ± 14.2 ms [User: 58.5 ms, System: 33.4 ms]
Range (min … max): 82.7 ms … 148.3 ms 32 runs
Benchmark 2: foot -e true
Time (mean ± σ): 37.2 ms ± 2.3 ms [User: 40.3 ms, System: 9.5 ms]
Range (min … max): 33.8 ms … 43.7 ms 83 runs
Benchmark 3: footclient -e true
Time (mean ± σ): 22.8 ms ± 4.3 ms [User: 0.9 ms, System: 0.8 ms]
Range (min … max): 18.2 ms … 63.6 ms 133 runs
Summary
footclient -e true ran
1.63 ± 0.32 times faster than foot -e true
4.35 ± 1.03 times faster than alacritty -e trueIn client server mode all of foot/alacritty/kitty/urxvt will open windows in a few ms.
The actual foot executable is 427kb. RAM consumption win in the server setup is the shared glyph cache, which is most of the usage at startup.
> alacritty is only using <2MB total on my box
That would be less than the image it’s drawing on screen, the glyph cache, or alacritty’s 11Mb executable. How are you measuring?
https://codeberg.org/dnkl/foot
For those out of the loop
Konsole can switch color theme with simple dbus message.
For the rest, I use tmux sessions and some scripts. When I restart computer, all terminal windows with remote ssh sessions get restored.
I do not need any modifications on server (except tmux or screen package).
EDIT: So the payment is to have a little space on their own website, which they call a "project page" e.g. https://notbyai.fyi/hi/not-by-ai/
They suggest "linking to it for verification", but it really seems both unnecessary and optional