I have many idea about operating system design. Some are inspired from other designs, including TRON, Plan9, Amiga, Hurd, TempleOS, BeOS, and others.<p>Here are some of my ideas (although there are a lot more that I have not listed here, but I may write about in future):<p>- Real-time capabilities (which can be ignored if not needed). Some applications have this as useful.<p>- Entirely non-Unicode. International text is supported, but it isn't based on Unicode nor requiring any unified character encoding.<p>- The system call interface proxy. This can be used for such things as providing file permissions, system call tracing, maintaining some parts of a process state, and other capabilities, rather than all of them being a part of the kernel. The definition of the system call interface is independent of the instruction set as much as possible; this way, it makes writing them simpler. (The way that the interface corresponds to actual features of the computer does depend on the instruction set, though.)<p>- Hypertext file system. Any file can contain links to other files (inherently, rather than being considered as byte sequences like other data (although of course they are still stored on disk as byte sequences)), whether a normal link (which links to whatever version is current at the time of access), or to a specific version of the file (resulting in a copy-on-write object), or to a part of a file.<p>- It has its own programming language (which can be used as REPL as well as full compiled programs), but C can also be used, and assembly language is also possible. (If using C, then partial compatibility with POSIX and TRON may also be possible.)<p>- "Objects" are "files" (they are essentially the same things), and have a "object/file descriptor" to access them. This can be used for disk files as well as for other dynamic features such as a devices, process data, dynamically translated files upon access, etc. (Devices are not a separate object type like POSIX is; they are same like anything else.) Like any file, they may contain links, which may allow you to obtain access to them.<p>- A common file format for most (although not quite all) purposes, similar to TRON Application Databus, but with many differences. This would also be used for the command-line interface, too. It is also possible for data shown in both command-line and GUI (e.g. if a data table or graph is shown, you can easily apply your own filters, import/export, etc, with any other program; if it is formatted text, you can easily use it with other programs too; if it is numbers using some units of measurement, to be able to convert them; etc).<p>- Files can have multiple streams, numbered by 32-bit numbers (which need not be consecutively assigned). Stream numbers 0 to 255 have a standardized use, and other numbers do not have a standardized use.<p>- You can run a program with any instruction set on any computer, whether or not it uses that instruction set; if it isn't, then it will be emulated. (Whether the program is x86 or ARM or RISC-V, it will run on any of them.) Also if it is mainly one instruction set but uses some extensions (of a newer version of that instruction set) that this computer does not have, then those instructions are emulated.<p>- Message bus for higher level interfaces (these can be proxied like other interfaces, too, mainly by writing your own translator). Types are required, in order that programs written using different instruction sets with differnt endianness can communicate with each other without being confused, and so that the message passing can also include links.<p>I have many more ideas than only these above things, though!!!