💾 Archived View for mediocregopher.com › posts › my-ideal-os.gmi captured on 2024-08-25 at 00:02:00. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2024-08-18)
-=-=-=-=-=-=-
It's not Linux.
For a bit of fun, I'm going to describe my ideal OS from first principles.
The function of an OS, in the way that I use one daily, is to coordinate the sharing of resources with various programs running in parallel. I use some programs directly, like this web browser, while others just kinda run in the background, like this blog server. This holds true regardless of what kind of device I'm using (phone, tablet, desktop).
These programs should run independently of each other, and in general should not access the resources (cpu, memory, network, disk) being used by other programs. There are very specific circumstances where they may, but these should require explicit configuration by the user. The UX for this should make it very clear to the user, at a bird's eye view, which resources are being shared between the various programs on the OS.
And, obviously, an ideal OS must be open-source and give the user root access.
To dive into how shared access of resources would work from the user's perspective, I'm going to focus on one particular resource: disk space.
The way I would like to see disk sharing working is two-fold. First, users should be able to set aside buckets of arbitrary disk space, each labeled separately. Secondly, programs should be able to request, at installation time, a set amount of private disk space that they need to run. This private disk space gets set aside from whatever space is not being used by user buckets, and is not considered a bucket itself. During installation programs may also request any number of user buckets to attach to, and these should be selected by the user. Data stored in a user bucket can be accessed by multiple programs, as long as each has been configured to attach to that bucket.
In this system it would not really be necessary to manage user permissions on an individual file level, a la `chmod` or `setfcl`. Rather, permissions can be managed on the bucket level. A user might have permission to attach a bucket to a program with either read-only or read-write permissions. A program only has access to the contents of a bucket if it has been attached to it explicitly.
This system of sharing can be extended to other resource types. Consider sound devices. A program should request access to a sound device during installation, and the user should be able to select which of the available ones it may use, if any. Programs may share a single device, but only in combinations which have been explicitly blessed by the user. Even resources like graphics cards and network interfaces can be divvied out in a fine-grained manner. Going even further, programs can be allowed to provide new resources based on existing ones, such as a VPN program providing a new network interface.
In all these cases the resources in question retain the same basic properties. Access to them by programs is explicitly managed by users through a clean and unified interface provided by the OS. Everything else is of secondary importance to me, as everything else can cleanly fit within this framework.
-----
Published 2022-06-01