There are one or two advantages over regular GUIs, but that's it.
The biggest is probably that they are lightweight since there are no GUI library dependencies (and if there are TUI ones, they are usually much lighter than their GUI sisters). This also means there are fewer (if any) dependencies to distribute compared to a GUI.
The only other advantage I can come up with is that a TUI will have to be usable by keyboard only (in almost all cases). This is not a given for regular GUI libraries.
I'm not a fan of TUIs either. I think the only one I am using regularly is `tig` (https://jonas.github.io/tig/). I guess the reason is that I don't have to remember the git revision list syntax that way and that `tig` allows for easy commit searching with `/` ...
Even 80ms seems unnecessarily slow to me. 300ms would drive me nuts ...
I'm using a tiling window manager (dwm) and interestingly the spawning time varies depending on the position that the terminal window has to be rendered to.
The fastest startup time I get on the fullscreen tiling mode.
hyperfine 'st -e true'
Benchmark 1: st -e true
Time (mean ± σ): 35.7 ms ± 10.0 ms [User: 15.4 ms, System: 4.8 ms]
Range (min … max): 17.2 ms … 78.7 ms 123 runs
The non-fullscreen one ends up at about 60ms which still seems reasonable.
You could maybe find out where the delay is by using st's Xembed support? Create a window with tabbed¹ in a tiling layout, open st in to it with "st -w <xid> -e true". If it is close to the monocle time, it is probably the other windows handling the resize event that is causing the slowdown not the layout choice.
To prove it to myself: I'm using river² and I can see a doubling-ish of startup time with foot³, iff I allow windows from heavier apps to handle the resize event immediately. If the time was a little longer(or more common) I'd be tempted to wrap the spawn along the lines of "kill -STOP <other_clients_in_tag>; <spawn & hold for map>; kill -CONT <other_clients_in_tag>" to delay the resize events until my new window was ready. That way the frames still resize, but their content resize is delayed.
Benchmark 1: st -e true
Time (mean ± σ): 35.4 ms ± 6.9 ms [User: 15.1 ms, System: 3.8 ms]
Range (min … max): 24.2 ms … 65.2 ms 114 runs
This is on awesome-wm with the window opening as the 3rd tiled window on a monitor, which means it has to redraw at least the other two windows. I'm also running xfs on top of luks/dm-crypt for my filesystem, which shouldn't matter too much on this benchmark thanks to the page cache, but is a relatively common source of performance woes on this particular system. I really ought to migrate back to unencrypted ext4 and use my SSD's encryption but I haven't wanted to muck with it.
It's the man page for the Nintendo device emulators of 9Front. 9Front is a distribution of the Plan 9 operating system (most likely the most usable because it's the most actively developed one)
The link is interesting because these emulators seem to be part of the standard distribution of 9Front. Most likely those are written from scratch, given that Plan 9 is not a POSIX system (unless they are using http://doc.cat-v.org/plan_9/4th_edition/papers/ape).
Without looking I'm going to guess that ape is A POSIX Emulator, so we have an emulator emulating an emulator.
Edit: it's A POSIX Environment, but it still contains features that are unnatural in Plan9 and could by bypassed with more work, so much like emulation.
Close. It’s ANSI/POSIX Environment. It’s been there since Plan 9 second edition. I think it was put there basically for TeX, but don’t quote me on that because I no longer remember where I read that and it isn’t in the original paper.
Which really means this is a terrible way to emulate games.
The bug list is pretty darn unacceptable for a usable emulator.
You can’t even emulate PAL region games.
It’s a nice novelty that this is built in to the OS but the Linux/Android retro handheld scene is so much more wildly sophisticated than a half-broken command line emulator. Just jump on YouTube and search for an OnionOS overview to see what I mean.
I’m pretty sure in the context of the manual it means PAL games don’t work.
Why can’t I compare them? If someone wants to emulate games they ought to compare operating systems. Like I said, cool that 9front has a built in emulator, but that doesn’t mean it’s a good use case of the OS.
Sounds about correct! I have one that I bought in 2018 but I remember it being more like 450+ € at the time.
I have had a fiber line connected during the whole time and it has served me well (I haven't done much customizing on it though, I have to admit. It's just the router for my home network).
> I only care about game feeling and mechanics. If there are cutscenes I can't cancel, I'm out in a blink. Hence, I usually play competitive online games (currently a lot of Wild Rift), because they don't come with all that baggage.
I'm in a similar boat but I am 40.
My goto since about 6 to 7 years are roguelikes and fighting games. Those are very accommodating for gameplay-focused games that can be played in short bursts and they are very enjoyable for me at least.
There are one or two advantages over regular GUIs, but that's it.
The biggest is probably that they are lightweight since there are no GUI library dependencies (and if there are TUI ones, they are usually much lighter than their GUI sisters). This also means there are fewer (if any) dependencies to distribute compared to a GUI.
The only other advantage I can come up with is that a TUI will have to be usable by keyboard only (in almost all cases). This is not a given for regular GUI libraries.
I'm not a fan of TUIs either. I think the only one I am using regularly is `tig` (https://jonas.github.io/tig/). I guess the reason is that I don't have to remember the git revision list syntax that way and that `tig` allows for easy commit searching with `/` ...
reply