Being a programmable environment is one of the good benefits of UNIX, and piping programs together is also a good benefit of UNIX. "Write programs that do one

Being a programmable environment is one of the good benefits of UNIX, and piping programs together is also a good benefit of UNIX. "Write programs that do one thing and do it well" and "Write programs to work together" are good ideas, too (unfortunately many programs don't). I think that using a text stream for everything is not the best idea though. In many cases binary formats will do better. I think XML and JSON are not that good either. I think "cache your compiler output to disk so you wouldn't have to do a costly compile step each time you ran a program" is a good idea, although this should not be required; REPL and other stuff they mention there is also very helpful. They say the file system is also old. My idea is a transactional hypertext file system. It doesn't have metadata (or even file names), but a file can contain multiple numbered forks and you can store extra data in there. (Transactional file system is something that I think is useful and that UNIX doesn't do.) They are also right about the terminal is old, although some of the newer things that some people had tried to do have different sets of problems. They also say another unfortunate thing is layering, and I agree that this layering is excessive. Interoperating without needing FFI is also helpful (and see below what I mention about typed initial messages, too). About the stuff listed in "Text streams, evolved", my idea of the operating system design, involves the "Common Data Format" (which is a binary format, somewhat like ASN.1 BER but different), and most data, including the command shell and most files, would use it; this also allows for common operations. I agree with "a program which displays all of the thumbnails of the files listed on stdin would be much more useful to me than a mouse-oriented file browser", and I do not have a GUI file browser anyways. I do use command-line programs for most things, even though I have X Windows to run some GUI programs and to be able to have multiple xterms at once (I often have many xterms at once). However, it could be improved as I describe above, too. They mention the shell. I agree that it could be greatly improved, and I think that it would go with the other improvements above. My operating system design effectively requires "programs as pure functions over streams of data" (although it is functions over "capabilities", and not necessarily "streams of data") due to the way that the capability-based security is working, and the way the linking and capability passing is working also allows working like higher-order functions and transformations and all of that stuff. Even, my idea also involves message passing (all I/O is done by passing messages between capabilities), too. I had also considered programs that require types. One of the forks (like I mentioned above) of a executable file can specify the expected type of the initial message, and the command shell can use this to effectively make them like functions that have types. Something they don't mention is security. That can also be improved; the capability-based security that I mention above, if you have proxy capabilities too, will improve it. There is also the possibility that users can use the command shell and write other programs to make up your own proxy capabilities, and this allows programs to be used to do things that they were not necessarily designed to do, in addition to improving security. Instead of merely a user account, it might e.g. allow to write to only one file, or allow connecting to only one remote computer (without the program knowing which one it is, and perhaps even with data compression that the application program is unaware of), etc. I still think that, even if you have powerful computers, you should still program it efficiently anyways. The new one won't be UNIX; it will be something else.