My terminal is the only user-friendly way to interact with a variety of system resources on linux (generally, implicitly because of the filesystem API). I don't go to view where named pipes are in vscode, I go to the terminal and understand the problem structure there, especially when autogenerated pipelines come into the mix. If I need to look at daemons or tune perf, I also reach for the terminal.
Any solution has to address this use case first, IMO. There are some design constraints here, like:
- I don't care about video game levels of graphics
- I generally want things to feel local, as opposed to say some cloud GUI
- byte stream model: probably bad? But how would I do better?
as just a few examples I thought of in 10 seconds; there's probably way more.
I've thought about the author's exact complaints for months, as an avid tmux/neovim user, but the ability to interact with system primitives on a machine that I own and understand is important.
But hey, those statements are design constraints too - modern machines are tied somewhat to unix, but not really. Sysadmin stuff? Got standardized into things like systemd, so maybe it's a bit easier.
So it's not just a cynical mess of "everything is shit, so let's stick to terminals!" but I'd like to see more of actually considering the underlying systems you are operating on, fundamentally, rather than immidiately jumping to sort of, "how do we design the best terminal" (effectively UI)? The actual workflow of being a systems plumber happens to be aided very well by tmux and vim :)
(And to be fair, I only make this critique because I had this vague feeling for a while about this design space, but couldn't formalize it until I read this article).