💾 Archived View for gemini.circumlunar.space › users › adiabatic › words › computing › ideal-os captured on 2024-07-09 at 01:10:42. Gemini links have been rewritten to link to archived content
-=-=-=-=-=-=-
First considered in June 2024.
First published June 30, 2024.
Most recent meaningful update on July 5, 2024.
Status: Repeatedly updated but by no means finished. Currently-published version is messy and possibly self-contradictory.
Anonymous 05/05/18(Sat)15:45:20 No.45166513 ▶
If only you knew how different things could be.
An underwater-basketweaving forum I’m on sometimes talks about technology topics. One question someone asked once was “What’s your ideal operating system?”.
I’ve been chewing on that for a few days.
I’ve been watching fairly alternative OSs like Haiku (the BeOS clone) and I wanted to really clear the slate and assume multiple orders of magnitude of work done just for this OS. Otherwise an operating system is just a way to run stuff that people can already run on a Linux distribution or macOS.
This is a desktop operating system.
It does not assume a 1:1 correspondence between people and computers.
It won’t have bugs. If I’m describing my ideal operating system, then it simply won’t have bugs in it. It will also be well-documented at all levels. Furthermore, anyone working on fixes to the bugs (because in order to have no bugs, one must fix bugs) will be allowed and even encouraged to contact the person having the bug and ask for more information without the bug reporter having to go through extreme measures unavailable to most people like taking it to the house of the SVP of software engineering.
Craig Federighi, the senior vice president of software engineering (at the time of this writing)
(UNIX limits files to basically a block of bytes in the name)
(Do we reimplement Git? Even just the porcelain?)
It will be largely written in a modern, performant, ergonomic, safe language like how Swift 6 is shaping up to be. The idea is to have something with Rust levels of safety yet not be quite so ugly.
Unlike Swift, the compiler will not have crashing bugs.
The compiler will support LSP use.
The Language Server Protocol (LSP)
It will be a GUI-required OS, like macOS and Windows (and unlike Linux anything).
One thing that modern users have come to expect is that there are ways to sync preferences and data between the different computers and sub-computer computing devices that a user owns.
This kind of data includes, but is by no means limited to:
iCloud performs this sort of functionality in the Apple ecosystem. Microsoft’s current operating system does something similar. It uses the term OneDrive for its file-sync functionality, whereas “iCloud” covers all sorts of different services.
My ideal OS would be able to do this between multiple computers without a central server.
While Syncthing-style relays may be useful for facilitating state syncs across the Internet, this functionality should not depend on them, and people ought to be able to disable that functionality easily if they are OK with having syncs only happen when all the computers involved are on the same LAN.
Syncthing is very good, although not perfect.
I assume that CRDTs are magic pixie dust that fix all sync issues that everyone has. This assumption is certainly false, but here we are.
Wikipedia, “Conflict-free replicated data type”
Machine-learning this-and-that can be useful, but absolutely nothing is going to be farmed out to other machines. This may mean that work is duplicated. That’s fine.
This is essentially the way Apple used these techniques before introducing what they call “Apple Intelligence”.
A proper minimal keyboard for this operating system will have:
More may be added to support languages that need it, like, say, Japanese.
(Note to self: this may be one too many.)
(We can never really totally cut off POSIX compatibility because we’ll be SSHing into POSIX systems.)
It will not have an easily-accessible Caps Lock key, if it has one at all.
There will be two main nucleus keys:
There will never be any OS- or application-defined keys that use both of these at the same time. Users, however, may create key combinations that use both at the same time.
At any rate, the canonical written order of keys is:
⌃⎇⌥⇧⌘🌐︎
Spoken aloud, Shift gets moved to the front:
⇧⌃⎇⌥🌐︎
(This section is very much a work-in-progress.)
Consider a browser.
It has these very R-ful functions:
Clearly, Reload gets ⌘R, but what about the rest?
In current OSs, people are used to Shift meaning three things:
Command will be the primary key that one uses for in-application keyboard shortcuts, like:
There will also be the same keyboard command everywhere for nerdier commands like:
Keyboard combinations with Globe will be reserved for OS-only functions, as well as window and tab management, like:
The Control key is primarily to turn letter keys into cursor-movement keys.
There are things one might want to modify cursor movement with:
The primary cursor-movement keys will be:
Unused options:
(Finding keyboard shortcuts for all these other movement/selections is an unsolved problem.)
(Not sure what to do with this key yet.)
What the Compose key does for the en-US locale
Adding a compose key in addition to, or instead of, Option sounded like a reasonable idea. However, after studying the Apple Extended layout a bit and seeing what it does with:
and the ability to place dead keys on either, I think we ought to be able to get almost everything most people would want. The Apple Extended layout is missing a couple useful characters like ≈ (something available as ⌥X on the normal layout since 1984), but it could be shuffled around a bit and still make at least as much sense as the current Apple Extended layout does now.
(Coming: adjustments to the Apple Extended keyboard layout.)
` 1 2 3 4 5 6 7 8 9 0 - = ⌫ ⇥ Q W E R T Y U I O P [ ] \ ⌃ A S D F G H J K L ; ' ⏎ ⇧ Z X C V B N M , . / ⇧ 🌐︎ ⎇ ⌥ ⌘ ␣ ⌘ ⌥ ←↕︎→
The OS will support something like Automator/Shortcuts, as well as something like Services.
It will not make it a fantastic chore to run selected text through a command-line application or the default language’s equivalent of a five-line Perl script.
The system will also provide a TextExpander-like facility to expand typed text into more/harder-to-type text.
I have not decideded whether it would be better for windows to be application-centric (like macOS) or window-centric (like everything else).
Like macOS, there will be menu bar at the top. Or maybe the bottom. There will also be a bunch of icons over on the right, and there will be good builtin utilities for managing the sort of clutter that can happen there.
The system will support both light and dark modes, as well as an automatic toggle depending on the time of day.
It will also support, for those who want them or need them:
I have not yet decided how much theming the windowing system will support. This may be disappointing if you’re looking to reimplement Windows’ Hot Dog Stand theme.
The windowing system will not support fractional pixel density (150% zoom, etc.). The macOS-style @1x, @2x (and possibly @3x, if it ever comes to that) will be the only game in town.
I may end up wanting to have the mouse cursor be like on iPadOS where the default cursor is a transparent circle and has aim assist, with the shape morphing to an I-bar where appropriate.
I’m still on the fence on the general size of click targets and whether they should be made large enough to support tap interaction.
A system is not complete without a decent pool of basic applications.
It will ship with a damn good browser not built on Blink, Gecko, or WebKit (or their companion JavaScript runtimes).
Stop laughing. We’re already in fantasyland.
It will also support Gemini and Gopher.
While we’re at it, the OS will ship with a Transmit-quality scp/sftp app.
It will have something like Panic’s Nova as a Visual Studio Code-tier do-it-all text editor.
There will be a terminal, and a default shell. It will support UTF-8.
Fair warning: I barely know how terminals and all their features are implemented. I’ve heard of ANSI escape codes and OSC (operating system command) codes, and know about some of the things they do, but I’m not an expert.
The shell will not aim for sh compatibility. At all. Nevertheless, constructs like && and || may end up being a good idea anyway to not entirely poop all over world+dog’s muscle memory.
Powershell had the right idea when it came to making formal names — that is, Verb-Noun. Maybe Noun-Verb would have been a better choice, since so many commands these days start with an ur-command, like the following:
fooctl frobnitz --softly --with="big stick"
Powershell also had the right idea when it came to operating on streams of objects instead of plain text all the time.
On the other hand, Powershell commands’ output tends to be unoptimized for the screen space given. That should be fixed somehow.
The terminal will be able to display things in whatever color. And when I say “whatever color”, I mean to include colors that are outside the sRGB range, like ones you might specify with OKLCH.
There will be one terminal-based text editor included with the system. You could describe it as “Visual Studio Code, but implemented in the system programming language with a TUI user interface instead of in TypeScript with an Electron interface”.
It will feature:
This editor will also take interface cues from Micro, Helix, and…WordStar. Micro is nano/pico on steroids. Helix supports LSPs and multiple cursors and has a decent windowing system for hints and things. WordStar pre-dates almost all common conventions for cursor movement, and therefore has “fresh” ideas. I’d consider something like (modifier) IJKL or ESDF instead of the execrable vi-style HJKL.
⏚
