Oh yeah if it was running in kernel level (or analogue) I wouldn’t be here posting the video. Pretty sure what I got was a segmentation fault or similar stuff caused by code with a "Should be unreachable" comment.
BTW, that VM+image is Pharo which isn’t exactly “true old Smalltalk”, but I find it close enough to not have to bother compiling old VMs myself when I want to play with Smalltalk-esque stuff.
A lot of my operating system ideas aren’t focused around the design of the kernel itself, but rather the design of the userspace and user interface.
One particular idea I’ve been thinking about is how we handle command-line interfaces. Currently, commandline interfaces live in the terminal, an imitation of the ancient VT100 dumbterminals that would plug into a mainframe. To control a VT100, you would use escape codes to move around the cursor and change colours and formatting. This design is frankly awful. First of all, it’s bound to the idea of characters, and is thusly very alphabetcentric - not every language has a distinct idea of characters. The terminal, to support every language, first must force those languages into a monospace, separated form, and then it has to be hyperaware of the size of every single character to render them correctly. Needless to say, this causes issues! Fun! Yay!
For instance, on some terminals with Unicode support, like Urxvt, the terminal does exactly this. However, if you install a custom icon font, the font size detection goes completely hogwild, and urxvt cannot render those characters whatsoever. Sometimes, it fails to render normal unicode characters, too. I’ve had this happen on other terminals, but Urxvt is the most notable because THE PATCHES DONT FUCKING WORK.
So, onto the issues with the terminal as a model of UI itself, unicode handling aside. Interfacing with the terminal is just horrible, both OS-side and user side. Ncurses and equivalent libraries are just… messy. Colour handling is damn impossible to get right, because so many programs use literal colour-codes rather than the terminal colour scheme. SSH can be incredibly laggy because it is literally sending every escape code at once rather than doing something sensible. Terminals are shit at nesting - many programs reinvent terminal window managers, and any internal terminal has to reimplement the entire terminal from scratch! See vim’s vterm, the entirety of ssh, etc. Termcap is a mess. Stderr and stdout are really hard to handle in a way that’s consistent. Every shell program has to be pipe-aware if it wants to look reasonably pleasant and include colours and formatting.
I won’t go much more into why the terminal sucks, but know that the implementation of a terminal that is commonly regarded to be the most simple is about 21k lines of C, and it doesn’t include scrolling, barely includes unicode support, or actual features. Scrolling is broken in most terminals, actually - I’ve not found a single terminal that handles my nano correctly. Also, the way special characters get inputted is frankly… terrifying? I’ve also not found a single terminal or settings combination that correctly recognises the difference between Ctrl-Backspace, Backspace and Ctrl-H. More in depth critiques of the terminal are available over at the Arcan (UI focused) website.
SO, where does this leave us? I think we need a new ‘model’ for Command Line Interfaces that goes beyond the frankly unfixable design of VT100s and Xterms. And, while we ditch the old design and model, why not try and make things more user accessible? What’s something almost every person in developed countries uses on an almost daily basis? Chat apps! SMS, Discord, Whatsapp, Telegram, etc. A fun little trend in some of these chat apps is the use of assistant bots. You use them when moderating, you use them to play music, install stickers, etc. Isn’t that a commandline interface? Why not base a new ‘terminal’ off these chat bots which any Discord user picks up use of in minutes?
So, my big revolutionary idea for fixing the VT100 is to replace it with a (of course custom) chat client! Hear me out. So, a big issue terminals have is separation - all input and output and formatting goes into the same buffer, which is text only. There’s no stdout, stdin, stderr separation. Well, a chat app has no problems with that! Every input is distinct, because theyre all in their own messages. Similarly, every output is also distinct - you can seperate out stderr into it’s own field, you could display them together, you can do whatever! Chatapps tend to be capable of displaying fancy formatting, too, so why not give that ability to the shell programs? You could have tables, markdown, images, etc. Another big thing that chat apps have is the ability to reference messages. You can reference a message by replying to it, which adds a whole new world of programmability and userinterface design.
Let me walk you through a hypothetical workflow here, with editing images. You ever used imagemagick? It’s a right pain if you’re wanting to constantly do small adjustments. You can edit the image in place, you can come up with lots of tiny variations on a filename, and you need to have an image viewer and a manual open at all times, because who the fuck knows how to use imagemagick?
What if we added the ability to attach images? Now, your constant edits and tweaks can be ephemeral! You attach an image into the chat with the imagemagick command, and type in a colourshift command. The command replies, and you get the image with the colourshift done. Now, get this. You reply to the original message that has the unedited image, with another, different command. The bot replies, with the corresponding image attached! Both of them coexist at once, and you haven’t had to fumble around with renaming files, moving around image parameters. Want to keep applying edits to an image? Just keep replying! Since the image is displayed inline, there’s no issues with opening a gallery. What’s more, is imagemagick could provide inline help, too - just a help command away! (I’m going to let you into a secret here; I’m pretty sure this actually exists as a discord bot, with the reply thing I described and everything.)
Call me crazy, but I think this is both more useful, cleaner, and more approachable than a traditional shell+VT100 combo. It does require some rethink of the way we handle terminal programs on a fundamental level, however. I think that that is very possible to do, and where it’s impossible, it would be easy enough to just fall back to the standard model with a quick and easy adapter (of course, you wouldn’t be running Vim in there.)
commonly regarded to be the most simple is about 21k lines of C
12k* if you meant suckless’ st. To add to problems with it, it doesn’t support colour fonts (like emojis) at all, it was enough for me to cat a file with an emoji in it and the entire terminal crashed lmao.
I kinda like your whole idea of this “new shell” but it has to be all or nothing I think or it will forever remain a hobbyist thing. (Sorry if I sound too pessimistic.) There is so much stuff relying on terminals that you’d have to reimplement a loot of tools to run in the better UI or delivering some xterm emulation layer. And, if most of the soft goes through a shitty emulation layer it doesn’t exactly help sell your “API” unless you’re Apple and just made it mandatory.
All aside, that’s an interesting description of GNU Emacs (in an OS thread, nonetheless) /s
This is a super interesting idea and I do think I like it better than the traditional UNIX Shell.
I kinda like your whole idea of this “new shell” but it has to be all or nothing I think or it will forever remain a hobbyist thing.
not a new shell, new terminal. old shell could plug right in.
here is so much stuff relying on terminals that you’d have to reimplement a loot of tools to run in the better UI or delivering some
xtermemulation layer.
not really actually! the entire design is still focused on textual interchange. it’s intended to let you use stuff like imagemagick, dd, repls, other tools that are commandlines (not tuis!)
of course, there is a purposeful break with TUIs. i have no interest in supporting them; theyre an overload into a space where they shouldnt exist
the main bulk of work for the new commandline model would be designing the adapters that make this kind of thing useful, and thats just boring busywork
Arcan actually has a blogpost that I can’t find right now which focuses on replacing the TUI with a better system that’s still backwards compatible to an extent.
This chat app console would exist in the context of Arcan, Oil Shell, etc which are projects that intend to liberate themselves from the VT100s
not a new shell, new terminal. old shell could plug right in.
Right-o, that was just a terrible choice of words on my side.
Thanks for all the other clarifications as well
So, interesting OS ideas. First off, lets start with one which has been near and dear to my heart for quite a while.
Back in the late 80s, when the home computer scene started really finding its footing in Europe, there were a couple of game programmers in Britain, right? They developed macro packages for their assemblers so they could more efficiently code their games for their target platforms (mostly the Amiga then, as it happens). One of them eventually came upon a flash of brilliance when he thought “hey, wait a second, since memory is a primary constraint for speed of execution and not all assembly languages for processors are created equal, why don’t I make a virtual assembly language and a runtime which does binary translation in real time to run it on commodity hardware?” So he did that, starting from his macro package, and from there it sort of spiralled out of control to eventually become a full preemptively multitasking operating system called TAOS with (this was in the early 90s mind): a compositing UI, network transparency across multiple architectures and systems (including but not limited to i386, ARM, SPARC, Alpha, MIPS, Transputer, who even knows what else). In more ways than one, it feels like a sort of anti-Unix, and eventually, even though it gained a vaguely passable POSIX and gcc implementation much later down the line (branded intent or elate), it still kept its essential uniqueness (although one of the later marketing thrusts for the platform was using it to run Java programs, as everyone and their dog was wont to do at the time).
If any of the above sounds interesting to you or you want to try it out, I’ll leave a link below to my personal web presence and some copies I’ve managed to scrape together over the past… almost a decade now. It was definitely one of my white whales for better or worse and I’d be very happy if my efforts in finding and disseminating it would be of use to anyone else. I’ll also leave some other links to people commenting on other sites, since their explanations are more in-depth and probably would do better at actually conveying the inherent coolness of the system.
/otk/comp/os/taos (downloads)
Hello --- ex-Tao employee here! So Tao was my first startup. And then it was my ... | Hacker News (david-given’s overview)
TAOS was tiny; but it had no features. It had the VP1 loader, memory allocator, ... | Hacker News (additional context)
GitHub - vygr/ChrysaLisp: Parallel OS, with GUI, Terminal, OO Assembler, Class libraries, C-Script compiler, Lisp interpreter and more... (one of the original programmers reimplementing something much alike to it, currently on hiatus for reasons)