💾 Archived View for gemini.circumlunar.space › users › adiabatic › words › computing › ideal-os captured on 2024-08-18 at 20:20:16. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2024-07-09)
-=-=-=-=-=-=-
First considered in June 2024.
First published June 30, 2024.
Most recent meaningful update on July 20, 2024.
Most recent miniscule update on August 18, 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.
Originally, here I said “This is a desktop operating system” but increasingly I’m coming around to the notion that all great modern computing platforms are entire ecosystems and not just a pile of bits that one throws on commodity hardware. Because of this, I’m also specifying stock peripherals like monitors and keyboards and thinking about ways to have peripherals — like wireless headphones — shared between all your devices without an Apple Account coordinating permissions behind the scenes.
It does not assume a 1:1 correspondence between people and computers.
It won’t have bugs.
Hey, stop laughing. If I’m describing my ideal operating system, then it simply won’t have bugs in it.
The system will be thoroughly 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 experiencing the bug and ask for more information. This will happen without the bug reporter having to go through extreme measures to replicate the bug in front of someone who can do something about it — like taking it to the house of the SVP of software engineering. As you might guess, this sort of process won’t work unless you’re the SVP of something else in the organization.
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?)
There will be a couple of monitors for sale.
(I’m not sure what a good 6K size would be. The current iMac has a “4.5K Retina Display” which is 4480×2520. I’m tempted to suggest a doublewide 4.5K at 8960×2520. Not curved.)
(I’m also on the fence on offering a 4K 27″ monitor for people with bad eyesight.)
Their features:
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.
CRDTs are useful technology, although they’re by no means perfect:
Wikipedia, “Conflict-free replicated data type”
Machine-learning techniques 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:
Here’s how they’ll be laid out on a laptop-style keyboard:
⎋ 🔅 🔆 ❓ ❓ ❓ ❓ ⏪ ⏯️ ⏩ 🔇 🔉 🔊 ` 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 , . / ⇧ 🌐︎ ⎇ ⌥ ⌘ ␣ ⌘ ⌥ ←↕︎→
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 a Caps Lock key.
I don’t know what functions will be on the keys between F2 and F7. Then again, Apple changes these around every so often, so I don’t feel the least bit bad about not knowing what deserves dedicated keyboard buttons in the top middle of the keyboard. Maybe a teeny Touch Bar like MacBooks used to have.
Here’s how the different combinations of keys will shake out:
To generate this list, run the following code:
from itertools import permutations, product from pprint import pprint l = ['⌃', '⇧', '🌐', '⎇', '⌥', '⌘'] everything = set(product(l, repeat=len(l))) globs = [''.join(xs) for xs in everything] globs = [set(glob) for glob in globs] pprint(sorted(list(set([''.join(glob) for glob in globs]))))
⎇
⎇⇧
⎇⌃
⎇⌥
⎇⌃⇧
⎇⌥⇧
⎇⌥⌃
⌃⎇⌥
⌃⎇⌥⇧
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:
Shift Control Alt Option Command Globe
(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?
When Alt is part of a Command combo or a Globe combo, it does an application-level or OS-level thing.
What about when it’s pressed by itself, or in combination with other modifiers that are neither Globe nor Command?
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-primary functions, which includes both window and tab management.
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:
Adding Shift will, of course, expand the selection in that direction.
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.)
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. This will cover most of what people want out of a Compose key that they can’t get out of a macOS-style Option key.
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.
Additionally, control codes to specify colors will be able to specify both light-mode and dark-mode colors. The rationale for this is to be able to spit out terminal output, and later, when the user changes the terminal color scheme from light to dark (or vice versa), the colors used will look right for the new color scheme as opposed to something where all the foreground colors are too close to the background color to really tell what’s what.
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.
⏚
