I've imagined what a perfect OS would look like in my opinion; the primary way of exchanging access is handles. Opening a file is obtaining a handle, which rep

I've imagined what a perfect OS would look like in my opinion; the primary way of exchanging access is handles. Opening a file is obtaining a handle, which represents both the file and the driver/type behind it. The file handle has some functions associated with it; write, read, flush, close. You can pass the handle to other processes, either cloned (RO or RW) or as ownership (loosing access to it entirely). A printer has a different handle and different functions. Programs can be the source of handles, so you can write a program that wraps a file behind a different set of primitives. Or that wraps the raw printer network socket and allows passing a PDF file handle into a function to print the PDF. And if the printer goes away, the printer wrapper is notified that it's gone away, so it can queue up any prints. Or exit and notify everyone owning a PDF printer handle that the handle is now invalid. Device files like on Linux wouldn't exist, you only need handles to operate on devices and you abstract over those, if you need it, you can abstract the filetree handle to provide a simulation of the /dev/lp0 file in it. The filesystem would be a database, split into various tables ("default-configuration", "system-configuration", "user-configuration", "user-homes", "executables", etc.) with some tables merged into a view ("configuration"), so you can completely forget about where a config file is. Files themselves can either be formatted as a table themselves (key-value, json/nested data, etc.) or used as text or binary files. Of course a program can choose to use the FS transactionally, including SERIALIZABLE for your backup programs, that need a very consistent view of the FS. Every interface would be malleable, a program with higher privilege can override it and change it for programs of lower privilege. Chroot becomes as simple as prepending the chroot path onto access to the filesystem functions. Going down the scheduler itself being runtime modifiable so a user can swap to a different scheduler at runtime or define a scheduler for a specific subset of programs. If everything can be used, manipulated and introspected freely, then the programmer will have to do minimal work. Why use JSON configs when there is a perfectly good database system shipped with the OS? Why bother with logging when there is an interface for the system logger that supports structured logging and can ship logs to anywhere you want in any format at any detail level? Sadly, some of these ideas aren't very efficient or hard to implement. But luckily not impossible. Just not wanted by the greybeards of the industry.