> - Processes should be able to reserve some % of both CPU and I/O bandwidth. So you can have video players, games, etc. which remain perfectly smooth no matter what other processes are running at the same time.

It is far from the nicest interface, but I believe this can be achieved with cgroups in Linux (see `man 7 cgroups` "Cgroups version 1 subsystems").

The cpu subsystem: "Cgroups can be guaranteed a minimum number of "CPU shares" when a system is busy. This does not limit a cgroup's CPU usage if the CPUs are not busy."

The blkio subsystem offers "a proportional-weight time-based division of disk [I/O] implemented with CFQ." Though this only guarantees a proportion of I/O, not a specific bandwidth.

Okay, I found the list where I wrote these down. Here's some more:

- The ability to make changes to /proc files that only persist for the lifetime of the process that made them. (Basically, turn proc files into a stack, for cases where some program requires a particular setting, but don't want to make the change permanent.)

- globally managed weak pointers. If multiple processes are managing large amounts of cached data that can be regenerated if it's thrown away, the OS should be in charge of decided when to keep the data and when to thow it away, as it has a better view of the complete system than individual processes. (There's been some work to add this to the Linux kernel, but I don't think it's available to user space. https://lwn.net/Articles/340080/)

- let's get rid of statically-sized partition tables. There's no reason they should be a fixed size on SSDs. (It may be necessary to set a minimum and maximum size, but within those bounds they should just grow and shrink as needed.)

- A regular user should be able to create sub-user accounts with a subset of their own permissions. This could be useful to run untrusted applications in a sandbox.

- It should be easy to suspend a process to disk, migrate it to another machine, and start it back up, or to kill it and have it restart in the same state it was in when it was killed.

- It should be possible to restrict a process from opening any files that weren't passed in as arguments on the command line. (I think this has already been done. I don't remember what the project was called.)

- Package files (like rpms or debs) shouldn't have fixed file paths in them, or make any assumptions that the local filesystem will be organized in a particular way. Similarly, package files shouldn't run scripts. Ideally, only the package manager would be able to write to /usr (or whatever the administrator wants to call it on their system).

- It may be possible to do away with the user-space / kernel transition, and just run everything in a single address space. The way to do this safely is to write all software in a language that doesn't allow shenanigans (such as Rust) and only permit the OS to execute binaries that have been created by a trusted compiler. If the compiler can verify that types and memory boundaries and API conventions are always respected, then having the hardware check it again at run-time is redundant and an unnecessary drag on performance. For cases where untrusted code blocks are necessary, those would behave like kernel code; you need to be root user to tell the OS it's safe to run such code. Legacy C and C++ applications can run under an x86 emulator or inside a partitioned-off address space, but performant applications would have to be written in a safer language.