Linked by Thom Holwerda on Mon 18th Aug 2008 23:33 UTC, submitted by Charles Wilson
Thread beginning with comment 327306
To view parent comment, click here.
To read all comments associated with this story, please click here.
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE[4]: Inertia and stupidity
by Thom_Holwerda on Tue 19th Aug 2008 10:25
in reply to "RE[3]: Inertia and stupidity"
It implements namespaces per proccess and bind commands that make actual file hierarchies look like something of the past. You can install different versions of the same program and more, for example: just run the yesterday command and you will be back to your system from the previous day.
And the reason these abilities work so well is because it was factored into the design from the get-go. You can't keep on building on a system that was designed for mainframes and then hope it will still be up-to-date and capable 40 years later.
RE[5]: Inertia and stupidity
by kaiwai on Tue 19th Aug 2008 11:36
in reply to "RE[4]: Inertia and stupidity"
It implements namespaces per proccess and bind commands that make actual file hierarchies look like something of the past. You can install different versions of the same program and more, for example: just run the yesterday command and you will be back to your system from the previous day.
And the reason these abilities work so well is because it was factored into the design from the get-go. You can't keep on building on a system that was designed for mainframes and then hope it will still be up-to-date and capable 40 years later.
And the reason these abilities work so well is because it was factored into the design from the get-go. You can't keep on building on a system that was designed for mainframes and then hope it will still be up-to-date and capable 40 years later.
You're right - which is why I think it is a silly effort to try and retrofit these ideas to an existing operating system - when ever it is tried, it'll be a compromised version with limitations that take away from what it promised.
Linux is repeating the same mistake of UNIX - MacOS X broke free, but I have a feeling that we're going to revisit these issues again in 10 years time when MacOS X becomes long in the tooth. Same thing can be said for Linux as well.
I gave Plan 9 as an example, but I'm sure there are other ways to go about solving problems. We already have numerous clones of *NIX - what there needs to be is an easy to use operating system which is unrestrained from decisions made two decades ago.
One where the lessons from other operating systems can be learned. An operating system which is documented and well maintained from day one rather than something get grows into an out of control beast which ends up causing problems for the programmers at a later date.





Member since:
2006-02-27
Plan9 has been absolutely free for a long time.
It implements namespaces per proccess and bind commands that make actual file hierarchies look like something of the past. You can install different versions of the same program and more, for example: just run the yesterday command and you will be back to your system from the previous day.
And plan9 really follows its conventions.