I'd go further: = Everything as text - There's a fundamental problem with turning and treating everything as text: N programs having to know M parsing formats.

I'd go further: = Everything as text - There's a fundamental problem with turning and treating everything as text: N programs having to know M parsing formats. Structured data that is readily usable without de/serializing would be an improvement. - Logging - logging is broken because of the previous point, because log entries are streams of events poorly serialized to text files, log rotation and loss of structured data. - Processes - Processes should be pause-able to disk, migrate-able to other systems (as long as I/O and files can be migrated) - Indexing - there ought to be a tunable Spotlight-like system that doesn't need to constantly reindex because it indexes everything that was changed using file notifications in the background during idle (not on battery) - Caching - there ought to be a central web cache on a computer that all web browsers and web operations can share - Hypercard - we need more of this - Introspection - the system, processes and every variable should be profile-able, inspectable and queryable - Databases / files - there really shouldn't be any files or database, every program should be able to offer data types and format transformation services that the OS can use to add new functionality to all other programs and services. The notion of a file should be containers of user data that programs can use directly. IOW, a programming language should have a NoSQL/SQL-like query language built-in so there's no need for ORMs... the OS should handle how best to store and index data with the storage allocated. - Typed memory / VM - it would be much easier to accomplish all of the above if the OS were a lightweight system similar to Erlang BEAM, Pony, LLVM runtime features. - Kernel security, isolation and performance - something like seL4 but with additional transactional (N > 3)-process support to be able to make a bunch of changes, validate state and commit/rollback on failure. - Fragmentation - the problem with systems like Linux that are developed as zillions of piece-meal, semi-interchangeable parts that duplicate functionality and have many options are the mess and confusion of trying to integrate them. The BSD's have it right in terms of base system development. - Complexity - Look at how much stuff is cram-packed into the Linux kernel or OpenSSL. - Churn - Deprecating and changing APIs creates incompatibilities. An OS should pick one set of APIs for all time and make it very difficult to change them. Heck, every OS should have the same API and same VM opcode format so that there's never again an obsolete or incompatible program. There's no point to re-inventing the same thing over and over and over that doesn't work with anything else that came before.