* applications run in a sandbox (preemptive multitasking/protected memory)
* interprocess communication is well implemented (copy on write, pipes, stdin/stdout/stderr)
* everything is a file (so many data structures and APIs become superfluous once you realize this)
* atomicity is for the most part robust which allows scaling (mutexes, semaphores, file locking)
* open nature of code lends itself to better security, size and performance
Bad points:
* Hierarchical filesystems are a dead end (the future is all about metadata, hashes, diffs and relationships)
* Too much emphasis on brevity, while size becomes less important over time (acronyms, abbreviations, regular expressions, bash, perl, etc)
* Human-oriented concepts, ironically, don't work well for the use cases humans want (permissions, process priority, executable bit)
* Basing everything on source code instead of binaries needlessly increases everyone's workload
* Dependency hell
Honestly I could come up with 10 times as many examples as these. Especially for the bad points, seriously, it's worth keeping an open mind about what could be possible if we thought about how the world is moving towards treating data as essentially infinite. I think computers of the future will work more like how Google does things with map reduce and Go. It just kills me every time I can't find something on my hard drive when I KNOW so much about it, what I was thinking at the time I made it, and not so much its name or contents. Or when I lose hours, or even days, trying to make the simplest command work in the shell, or set up a config file (for BIND etc). I think UNIX reached a pinnacle with Mac OS X but now it will enter a long period of slow decline as multiprocessing and higher level languages begin to replace all of the things that we used to do by hand. Especially with regard to how we develop software today, so much of it (makefiles, even compiled code), while not necessarily UNIX-centric, is going to go the way of the dodo. I find anymore that the vast majority of my time, perhaps as high as 90%, goes to learning curves, getting anything to work at all, and fumbling in the dark without being able to see where a problem comes from. The operating systems of the future, whatever form they take, are going to solve these problems in ways that I think would be difficult with a command prompt mindset.
Hierarchical filesystems are a dead end (the future is all about metadata, hashes, diffs and relationships)
What's the case against hierarchical file systems? I've never really had any issues with them that i've noticed but admittedly i've never encountered any radical alternatives. It's a model that seems to work.
Good comment, though I think there's an obvious distinction in that systems can/could be Unix-derived without necessarily surfacing any of the traditional tools/philosophy to application developers or users.
The figure of 50 years in the OP's question is a bit silly. That far out is wild speculation for anyone!
I don't know if basing things on source is necessarily a negative. Perhaps better binary distribution mechanisms would be worthwhile, but maintaining the source-basis is a good way to ensure we're less susceptible to falling into a pit of proprietariness.
In terms of IPC, I like Singularity's model a lot. You don't do any (slow) hardware boxing, only software-enforced isolation, so you're already in the same address space, which means sending data between apps is a lot faster.
Actually come to think of it, I like everything in the Singularity paper. We should do way more software-based enforcement and utilize compile-time and install-time verification to do things like avoid DLL-hell, etc.
Comments
You know, I sure hope not.
Good points:
* applications run in a sandbox (preemptive multitasking/protected memory)
* interprocess communication is well implemented (copy on write, pipes, stdin/stdout/stderr)
* everything is a file (so many data structures and APIs become superfluous once you realize this)
* atomicity is for the most part robust which allows scaling (mutexes, semaphores, file locking)
* open nature of code lends itself to better security, size and performance
Bad points:
* Hierarchical filesystems are a dead end (the future is all about metadata, hashes, diffs and relationships)
* Too much emphasis on brevity, while size becomes less important over time (acronyms, abbreviations, regular expressions, bash, perl, etc)
* Human-oriented concepts, ironically, don't work well for the use cases humans want (permissions, process priority, executable bit)
* Basing everything on source code instead of binaries needlessly increases everyone's workload
* Dependency hell
Honestly I could come up with 10 times as many examples as these. Especially for the bad points, seriously, it's worth keeping an open mind about what could be possible if we thought about how the world is moving towards treating data as essentially infinite. I think computers of the future will work more like how Google does things with map reduce and Go. It just kills me every time I can't find something on my hard drive when I KNOW so much about it, what I was thinking at the time I made it, and not so much its name or contents. Or when I lose hours, or even days, trying to make the simplest command work in the shell, or set up a config file (for BIND etc). I think UNIX reached a pinnacle with Mac OS X but now it will enter a long period of slow decline as multiprocessing and higher level languages begin to replace all of the things that we used to do by hand. Especially with regard to how we develop software today, so much of it (makefiles, even compiled code), while not necessarily UNIX-centric, is going to go the way of the dodo. I find anymore that the vast majority of my time, perhaps as high as 90%, goes to learning curves, getting anything to work at all, and fumbling in the dark without being able to see where a problem comes from. The operating systems of the future, whatever form they take, are going to solve these problems in ways that I think would be difficult with a command prompt mindset.
What's the case against hierarchical file systems? I've never really had any issues with them that i've noticed but admittedly i've never encountered any radical alternatives. It's a model that seems to work.
Good comment, though I think there's an obvious distinction in that systems can/could be Unix-derived without necessarily surfacing any of the traditional tools/philosophy to application developers or users.
The figure of 50 years in the OP's question is a bit silly. That far out is wild speculation for anyone!
I don't know if basing things on source is necessarily a negative. Perhaps better binary distribution mechanisms would be worthwhile, but maintaining the source-basis is a good way to ensure we're less susceptible to falling into a pit of proprietariness.
In terms of IPC, I like Singularity's model a lot. You don't do any (slow) hardware boxing, only software-enforced isolation, so you're already in the same address space, which means sending data between apps is a lot faster.
Actually come to think of it, I like everything in the Singularity paper. We should do way more software-based enforcement and utilize compile-time and install-time verification to do things like avoid DLL-hell, etc.