5/17/2025 at 3:58:55 PM
I think we shouldn't[1] be making Operating Systems, per se, but something like Operating Environments.An Operating Environment (OE) would be a new interface, maybe shell and APIs to access file systems, devices, libraries and such -- possibly one that can be just launched as an application in your host OS. That way you can reuse all facilities provided by the host OS and present them in new, maybe more convenient ways. I guess Emacs is a sort of Operating Environment, as browsers as well. 'Fantasy computers' are also Operating Environments, like pico-8, mini micro[2], uxn, etc..
Of course, if you really have great a low-level reason to reinvent the way things are done (maybe to improve security, efficiency, DX, or all of that), then go ahead :)
The main reasons is the difficulty in developing robust low-level systems like file systems, the large number of processors you may want to support, and also creating or porting a huge number of device drivers. At this point Linux for example supports a huge number of devices (of course you could use some sort of compatibility layer). Also, developing a new UX is very different from developing a new low-level architecture (and you can just plug the UX into existing OSes).
In most cases an OS shell (and an OE), from the user point of view, is "just" a good way of finding and launching applications. Maybe a way of finding and managing files if you count the file manager in. It shouldn't get too much in the way and be the center of attention, I guess. (This contrasts with its low level design, which has a large number functions, APIs, etc.). But also it should probably be (in different contexts) cozy, comfortable, beautiful, etc. (because why not?). A nice advanced feature is the ability to automate things and run commands programmatically, which command shells tend to have by default but are more lacking in graphical shells. And I'm sure there is still a lot to explore in OS UX...
[1] I mean, unless you really have a reason with all caveats in mind of course.
by gnramires
5/17/2025 at 5:26:52 PM
I think there's value in exploring operating systems and environments. And, it's very useful to note that you don't need to do both at the same time. This strikes me as an unneccessary worry though:> The main reasons is the difficulty in developing robust low-level systems like file systems, the large number of processors you may want to support, and also creating or porting a huge number of device drivers. At this point Linux for example supports a huge number of devices (of course you could use some sort of compatibility layer).
As a start, you simply don't need to support all of this, and you don't even need to aspire to support it all. Support virtio versions of the relevant hardware class and try to run on reasonable hypervisors. Support one or two physical devices of the relevant hardware class to run on a real machine.
If you can plugin to an existing driver abstraction and pull in external drivers, great. NDIS is one option there.
If your OS is interesting, you can figure our the driver situation, and the cpu architecture situation. It would sure be neat to run on a raspberry pi, but only running on x86 isn't a big limitation.
by toast0
5/17/2025 at 8:49:05 PM
> I think there's value in exploring operating systems and environments. And, it's very useful to note that you don't need to do both at the same time.Although they can be done separately, I think there is also a value in doing both together, since the design can be made to work with both together better. Furthermore, they can be designed together with the hardware as well, to work together all three better.
by zzo38computer
5/18/2025 at 2:25:57 AM
Your idea reminds me of VitaNuova’s Inferno.The original link seems to be dead now, here’s the Wikipedia article: https://en.wikipedia.org/wiki/Inferno_(operating_system)
by rcorrear
5/18/2025 at 7:56:29 AM
Indeed vitanuova.com is down (although company appears still active) but has been mirrored for many years in https://www.inferno-os.org (can be considered an official site since is linked by their GitHub org).by forgotpwd16
5/17/2025 at 8:57:58 PM
Sorry, is "operating environment" a known and used term?Completely agree with the sentiment here, but have not seen this term used to describe what should almost certainly be distinguished as its own concept to facilitate these kinds of conversations. OE is great terminology.
by friendofafriend
5/18/2025 at 4:12:21 PM
This very much reminds me of Alexander Obenauer's Lab Notes[1] and OLLOS[2]. They're both great, recommend reading them.[1] https://alexanderobenauer.com/labnotes/000/ [2] https://alexanderobenauer.com/ollos/
by e-topy
5/17/2025 at 5:48:27 PM
Some of these are operating systems in the most literal sense. Some are environments that aren't concerned with starting processes or reading disk blocks.by rbanffy
5/17/2025 at 8:44:31 PM
I think there are benefits of operating systems and of operating environments. There is more than finding and launching applications; there is ways of applications interacting with the system and with each other, as well as with the operator. Both low-level and high-level design are relevant, and should be made to work better together. There is also the computer hardware design; some ideas and functions of an operating system should work better when the hardware design and operating system work better with each other.My ideas involve avoiding many of the features of modern systems.
Mine does not use: ambient authority, Unicode, file names, environment variables, command-line arguments (although there is an "initial message" which has a similar use), USB, spyware, worthless excessive animations (some animations are useful (but should still be possible to adjust the speed and disable them entirely), such as objects moving around so that you can more easily see where they went to), etc.
However, as important as what to be avoided, also are things which it would include, such as:
- Separate Command and Control key (like Macintosh has). There are other differences of the keyboard as well, and also differences in the working of the keyboard manager program. The application can request the application keyboard mode, which can be TRON code, or a specialized 8-bit character set (e.g. APL), or command mode, or game mode, or hybrid mode.
- Deterministic execution. A program's execution with the exception of messages sent/received by I/O is deterministic (and the I/O can always be overridden, so if the input is recorded and replayed, the output will also be the same, even if you run it on a different computer).
- Capability-based security with proxy capabilities. All I/O must use capabilities (a program that no longer has any usable capabilities is automatically terminated (unless a debugger is attached); this is one of the two "normal" ways to terminate a program, the other being to do an uninterruptible wait for any one of an empty set of objects). All messages between capabilities consist of bytes and/or capabilities, and when a program starts it receives an initial message, which should contain some capabilities (since if it doesn't, the program is immediately terminated unless a debugger is attached). A program can also create its own "proxy capabilities" and give those instead of the original one; the receiver cannot tell the difference.
- Deterministic execution and proxy capabilities are also useful for such things as: software testing, resist fingerprinting, etc.
- File system with forks. The forks are identified by 32-bit numbers, and the 16-bit numbers have a common meaning while higher numbers have meanings specific to the files. The file management functions of the system allow accessing and dealing with all of the forks. One of these forks is used for specifying the expected type of the initial message (this is like having typed command-line arguments instead of being untyped, but it is also used to provide capabilities for I/O, and other stuff).
- Transactions and locks on multiple objects at once (including objects in the file system, but also remote objects).
- Hypertext file system. Files can contain links to other files. There are no directory structures; you can use hyperlinks instead.
- Versioned file system. A link to a file can also optionally be for a specific version of the file. This means that one of the forks can be used to make a chain of the versions of the file.
- Extended TRON character code.
- A common data format used for most files as well as for a lot of the data being communicated between programs. This is a type/length/value format, a bit like DER but with many differences. This can allow potentially any files to contain potentially any kinds of data, and has a common representation for many types which can then be extended by the use of extension types. It also allows formatted text (rather than only plain text) to be used in many more parts of the system, and allows data to more easily be transferred between programs on the system. In addition, this allows the system to work more consistently.
- Tagged data and extensions. The common format would also allow such things like tagged data, e.g. that a number is some value according to a unit of measurement (that you can then do things with it e.g. automatically convert them to other units of measurement). Extensions are also possible.
- "Reveal Codes". If the file can contain formatted text, then revealing and dealing with the formatting codes directly is necessary during editing, even if the formatted text can also be displayed without revealing the codes. WYSIWYG without reveal codes is no good; and, actually, it would not quite be WYSIWYG anyways (since the formatting does not necessarily appear the same everywhere and is not intended to do so) (although there can be print preview as well, in case you actually do want to preview exactly what it looks like, to be more WYSIWYG).
- Command, Automation, and Query Language. This is a programming language which is also used for the command shell, and the common type/length/value format can be queried and manipulated with this. It can also be used to create proxy capabilities, and for communication between programs. Many kinds of mathematical and scientific functions are also available (for example, it supports big integers and big rationals, as well as matrices, etc). Functions from other programs can also be copied and automated, e.g. a data table displayed by another program can be queried, the function of a command button can be placed inside of a loop with other commands (delays, conditions, etc), etc.
- Better i18n, m17n, l10n, a11y, etc. Paper size settings do not belong in the locale setting (they belong in the printer driver configuration instead). Date/time formats do belong with the locale setting but should not be identified by language; instead an application program can call the i18n functions to format the date/time without needing an identifier. Telephone number formats do not belong with the locale setting either; this information is a combination of the data being handled and the modem configuration. There are many other improvements to be made as well; simply translating text, date/time, etc, is not good enough. Furthermore, accessibility features can be useful for everyone, and are not only for blind people etc.
- Space-age time keeping.
- Window indicators, which are associated with the capabilities of that window and can be used to monitor and control them. Some might also be usable for arranging windows, making tabbed windows and separating them, etc. This means that the application programs do not need to do many of these things, which makes the system working more consistently as well as not requiring application programmers to add all of the functions (and those that will be added can often be easier to do).
- Improvements of the C programming language.
- All functions can be used by the command shell and most also can be used by GUI, so both are available. Command shell and GUI also can be used together in a way that works much better than most other systems do, because you can easily move and copy data between them (see above about Command, Automation, and Query Language).
- If a new version of the CPU is available with new instructions, the new version of the operating system can emulate those instructions.
- Don't try to hide stuff from the operator; allow the operator to decide what kind of security they want and to program what the operation of the computer should do. Everything must be documented, and the core system must be FOSS as well, that it can also be examined, understood, altered, etc. The system also can be customized according to your use (including colours, fonts, font sizes, window management, keyboard layouts, substitutions of various things (including proxy capabilities), etc).
- And even more things than just this, too.
by zzo38computer
5/17/2025 at 5:36:34 PM
It sounds to me like you are describing Linux desktops.by johnsmth
5/17/2025 at 5:50:01 PM
Or Windows up to Windows ME.I believe confusing UI with OS is a mistake Windows users are still paying to this day. Thanks to NeXT, Mac users don't have this torment since MacOS 9.
by rbanffy
5/17/2025 at 6:38:19 PM
I'm assuming something more like Qubes, with proper isolation between groups of processes.by sparkie
5/17/2025 at 7:05:41 PM
It's an interesting idea, I've never tried it. It could also be a simple VM running a given OS (with reduced need for hardware support), or an application running interpreted code with the environment UI.Generally the idea is to expand UX in more interesting/fun directions without incurring significant hurdles associated with an OS (where everything needs to run reliably and be secure).
I've found this quite interesting related discussion: "Classical "Single user computers" were a flawed or at least limited idea" https://utcc.utoronto.ca/~cks/space/blog/tech/SingleUserComp... (discussion on lobste.rs: https://lobste.rs/s/plkdy5/classical_single_user_computers_w...)
by gnramires