Posted by tosh 22 hours ago
- A shell is not a terminal.
- Rc it's simpler than sh.
- You can totally put shells under graphical windows as in 9front
- You can do a better Unix than Unix itself while ditching out for good the VT220 interface
- Serial terminals aren't a thing under rio(9)
Oh, wait, it is.
I'm rapidly developing grumpy old man habits about this gulf between "web" and "terminal". Imagine a world where we do `ls | grep .files.size` or something.
I mean, I get why we're here, but it feels so close to giving us all the power of html/css/etc while also having pipes and shells.
Give me a proper graphical application any day, but I recognize that it's historically been a lot more work to produce a GUI in the pre-LLM era.
But golly gee whizz if we're going to keep the command line around, can we move on from 1983?
I'm still annoyed and baffled by the fact that Ubuntu had searchable application menus 10 years ago, which were awesome and worked for just about any program, and then dropped them when they abandoned Unity. And neither KDE not Gnome thought to bring them back. In stead, many apps have since dropped application menus entirely, in favour of... some mishmash of icons and ad hoc menu buttons?
Also, even in the post-LLM era, building a decent GUI app is a lot more work than building a decent terminal app.
Between that and the level of complexity of modern GUI toolkits - and the size of their dependency trees - distribution of a GUI app is a much bigger headache than distributing a terminal app.
Super easy to use, fast, almost zero ram usage and battle tested for 2 decades.
* Ad Hoc
requirements change and terminal gives ultimate empty workbench flexibility. awesome for tasks you never new you had until that moment.
* Precision
run precisely what you want, when you want it. you are not constrained by gui UX limits.
* Pipeline
cat file.txt | perl/awk/sed/jq | tee output.result
* Equal Status
everything is text so you can combine clipboard, files, netcat output, curl output and then you can transform (above) and save. whatever you like in whatever form you like, named whatever you like.
9front copes with actual text throwing the terminal as a different tool to run legacy stuff in such as SSH or some small ANSI C tools either with the APE compat layer or NPE binding ANSI C code to Plan9 native functins.
You can resize windows with shells under 9front freely, no more SIGWINCH. No more broken cuts and pastes while running a terminal multiplexer. No control code risks executing potential malware.
My typical interface is that I have an editor open where I write package code, and then I have a julia REPL open beside it where I load the package (or includet the script or testset). Any changes I make with my editor to functions or structs in the package / script / testset are automatically reflected in my running julia session via Revise.jl.
I then execute the functions interactively from the REPL, introspect into data or generated code, debug, run benchmarks etc all from the REPL.
GUIs are great for many things, but they lack the flexibility I need for my day to day work.
Think of it like different types of programming languages. Some are more suited on different types of problems than others.
For me, my workflow is about composing and gluing different processes together rather than using a standard defined tool repeatedly in the same way as that tools UI was originally designed. So the CLI is ideally suited for me in all the areas where a GUI would be high friction.
As little as possible. Anything that can be done in a terminal can be scripted and automated, put under version control, and deployed using modern CI/CD and devops tools.
Sure, next time I'll need to quickly edit a configuration file I'll setup a complete CI/CD pipeline to run vim (or nano, or whatever) inside it.
Because that Kitty protocol seems limited in that interaction was not one of their goals.
Since this is really just a legacy system operator monk / retrocool interface, they spend years debating ancient DEC theology.
Enjoy.
Unfortunely, given that we are stuck with UNIX derived OSes, this is indeed a possible issue.
However I would argue, for fancy stuff there is the GUI right there.
Of course everything depends on exact nature of the work, but personally I would gladly leave text based interfaces behind, it's just that there's nothing better.
More so, I use the terminal as strictly necessary and nothing more.
Like, it gets taken for granted, but being able to literally grep my html file, my program source and my readme file, instead of having to open a separate gui program and using its bespoke seach menu feature, is really, really nice.
There are downsides of course, like the way we keep jamming everything into the square hole that is 1980s terminal emulators and character based displays, but frequently this is worth it.
Augmented nowadays with agent environments and tools in IDEs, which can even be voice controlled.
In some important ways, even text with hacky escape codes is more useful and more robust than a fundamentally graphical interface. Text scales up and down with display size and pixel density. Text works over high-latency links and enables simple latency compensation like in Mosh. Text gives you universal copy-paste. Text is more accessible for humans and for machines.
I use a virtual terminal daily on my phone. If we literally used rio GUIs designed around the three-button mouse and desktop pixel density, it would be a lot less ergonomic. I'd like to see a successor to the VT220 lineage, but it's easier to imagine it built on text.
What era? That is exactly the workflow of everyone using macOS and Windows around here.
Connecting to cloud environemnts is also done via a mix of RDP, VNC, Web GUI based tooling, akin to a modern X Windows replacement.
Windows is a good example of what I mean. Windows system administration has become unmistakably more text- and console-centric over time with the rise of PowerShell. Windows has started shipping an SSH service and made its graphical interface optional on the server.
The web has avoided falling into the same trap. Web UIs are, for the most part, delivered to the user as hypertext rather than rio-style pixels. They rarely hard-require a mouse and have adapted well to touchscreens. Graphics in new web UIs is usually vector (SVG).
Replicating the experience of using something like Smalltalk transcript window.
Of course Windows has SSH support, it needs to interoperate with UNIX, given that UNIX won the server room.
No need for SSH to talk with Windows Core/Nano, it can be done via Web GUI administration, or PowerShell remoting.
As far as I know from Pharo, the Smalltalk transcript logs plain text and is less capable than xterm. So what you care about is not the capabilities of the terminal but having a long-lived interactive session/REPL or a REPL integrated with an editor?
> No need for SSH to talk with Windows Core/Nano, it can be done via Web GUI administration, or PowerShell remoting.
I was thinking of the administrator connecting to Windows from their Mac or Linux/BSD machine. I don't know if that's a good idea compared to them getting a Windows VM and using Windows-to-Windows PowerShell remoting as you suggest.
Text? I do that under 9front, too. Heck, rc it's simpler there than sh itself. I can bind remote machines and use their scripts as if they were my own. I can import remote devices. I can do stuff without resorting to crude hacks with openssl and nc. C itself it's far simpler. Text, you say? No locales, and UTF8 everywhere. I can freely resize the windows and still cut and paste stuff like nothing. It's 2025. The closest workflow under Unix would be Bitlbee + any client for it, msmtp and mbsync for Email and any graphical client against the SLRN cache in order to be as usable.
Rio can use different fonts just fine, you know. There are several users using 24 px fonts on HD screens without no issues. With riow you get 'virtual desktops' a la cwm/i3 and the like.
>Three button mouse. I don't do mouse chords, but I get more universal copy and paste as I stated that the old Unix itself, with shorter and easier scripts again... than Unix.
On snarf/paste instead of the menu, modyfing rio/sam and the like for a keybinding can be something done under an afternoon. Riow can already manage windows and close then with keybings among the mentioned virtual desktops.
Oh, and BTW... for vi users... I consider the Sam regular expresions far more powerful than the vi keys themselves. I can highlight the text with the mouse and write a sam command (on acme too) which affects the selection and in an easier way than the old syntax. The best of both worlds. RSI? Well, that's a point for Unix, but with the Windows key + 1-4 the mouse usage can be reduced a lot.
And, again, the 9front API it's dumb simple; I'm pretty sure doing stuff like mapping the Windows key +j-k-l to mouse button 1-2-3 would be something relatively easy, even setting sticky menus. With that small patch tons of usability issues would go away. Meanwhile, under X.org, Wayland, evdev and the $toolkit of the day... good luck.
I see what you mean in this and the other comment. With 9front, you rely less on issuing commands to remote machines because you can directly access their resources. It's worth keeping in mind when comparing Plan 9 and Unix from a Unix user's perspective.
Being able to pick large fonts on the server isn't the same as leaving the fonts up to the client. When I use terminal emulators, SSH, and tmux, I can switch between different clients with different resolution, pixel density, and screen orientation and have the text display acceptably on each (minus text reflow for history, which is an issue).
> I consider the Sam regular expresions far more powerful than the vi keys themselves.
I agree, structural regular expressions seem like a better version of vi commands. It was reasonably easy to make some complex edits in https://github.com/martanne/vis when I tried it, and it felt like I'd only scratched the surface. I could see myself still using vis if it had tabs like Vim. (Tabs are a stated non-goal for vis.)