Wrong link, should specifically be https://pydissem.rgoswami.me/python_scripts.html

OP here, I guess things have changed? AFAIK there was no pricing when I set it up... I just put the image with the link, certainly wouldn't pay for it :D

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

I see, thanks for the clarification

I think the concept of slow is relative here, for a no configuration start (from a fresh install) alacritty is slower by a factor of 4 https://news.ycombinator.com/item?id=40559084

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        |

That's a valid point. It might be more about using the right tool for the task. For example, using tmux for persistent terminal windows can help. A setup where the main compilation terminal (subFloat) and smaller terminal instances for chat/irssi/nmpc (mS) run within a tmux session ensures persistence even if foot crashes (or is killed for applying configuration updates) as noted in the post ^_^

btop might be measuring the wrong thing here, but alacritty on my box shows 93M using the same interface. I remember benchmarking foot and alacritty (also kitty) pretty extensively a few years ago, and settled on foot.

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 true

timing footclient -e true is not actually measuring what you think its measuring. It's measuring the time it takes to open a socket and write a few bytes to it. Not the time it takes to run true in a new window and then close it. And just FYI both alacritty and kitty have server/client modes too. foot without server client mode does indeed startup faster than any GPU based terminal emulator because GPU based terminal emulators have to probe the GPU card(s) ont he system for their capabilities which is approx 100ms of unavoidable delay until someone convinces the kernel developers to cache this data.

In client server mode all of foot/alacritty/kitty/urxvt will open windows in a few ms.

Good point, however, window creation times aside, the official project org has some benchmarks (https://codeberg.org/dnkl/foot/src/branch/master/doc/benchma...) demonstrating speed-ups in most / all user metrics (a more nuanced discussion is on the performance page: https://codeberg.org/dnkl/foot/wiki/Performance)

Yup, I switched a few years ago from i3 (X11) to sway (Wayland) and use it to replace urxvt.

I should point out that this has been posted [1], but not for the past half decade, long enough to need another PSA :)

[1] https://hn.algolia.com/?q=https%3A%2F%2Fagner.org%2Foptimize...

Wrong sorting. It gets posted much more often; for example: https://news.ycombinator.com/item?id=36905443

It is the framework used by meson which was how I came across it. It's different, for short API documentation the yaml structure probably works better.

This is a major PITA. Also quite concerning for the entire R ecosystem. No packages can be installed or submitted, all CI runs will fail as a result.