I am quite sure that you do not know what Plan-9 is and that, probably, you never have heard of it too.
I am fairly certain that I have, and for quite some time already. :)
The reason why you never heard of it is that it did not succeed.
It was never purposefully designed to succeed. It was made as a research operating system, not something to compete with the alternatives of the time.
the porting of complex application, such as X11, was impossible because “supporting it properly is too big a job”
Wait, you want to use X11? I am so sorry for you if that is the case (um…).
The first one is not to try to fix things that are not broken or better, if you want to fix them, only fix the broken pieces and do not try to fix what is clunky but it does, somehow, work as it is intended to.
Woah, there! That’s quite the severe opinion. Are you saying we shouldn’t make new programming languages, and only extend the ones that exist? Should we not attempt to fix the plentiful hacks embedded within the Linux kernel? I feel the takeaway is more along the lines of “it’s difficult to sell others on something that is better if it also reduces compatibility at the same time”. I believe that we should continue to try to redo the things that are broken, and not continue hobbling atop failing technologies.
but not at the time in which the amount of people actually opening a socket had shrunk to just a bunch of people.
People still use sockets and their numbers are far greater than just “a bunch”. Even if we use abstractions atop of sockets, some of their awkwardness manages to crawl its way through the abstraction and add complexity. Plan9 tried to solve this by thinking of a more generic abstraction, and applying it to everything it could, thereby removing any complexities that might be induced by yet another, unexpected API or abstraction being made to do something.
But, more important than everything else: are you actually solving a problem that really exists or not?
Unfortunately the problems solved by Plan9 do exist. Albeit, they’re not problems that people feel overly encumbered with, but they are mild annoyances. Not only that, but as we arrive closer and closer to The Future™ we find that a more Plan9-like system would adapt itself better to things such as multicore computers or creating a public or private “cloud”. The problems existed and exist, it just seems that almost nobody cares enough to overcome the necessity to learn something new, and prefer to stick with their known, comfortable system.
Overall, I would say this feels more like a guide on how to plan to make marketable software than anything else, with which I strongly disagree. Programming shouldn’t have to be about making something that is popular or profitable, but about making technology better overall. If only that were the world we lived in.
I don’t necessarily disagree with the principles in this article, but there’s quite a bit of path-dependent history around AT&T’s commercialization strategy that it’s glossing over, which I think limits the broad, general-purpose lessons that can be drawn from this specific example.
When Plan9 was (finally) made available in some kind of public form in 1995, a lot of what this article says is true. Unix was well established, had converged on some degree on compatibility, and Plan9 was seen by many potential adopters as gratuitously breaking this: changing too many things, some for reasons that seemed arbitrary or nitpicky, and others for reasons that might be legitimate but whose benefits were outweighed by the negatives of changing. But Plan9 wasn’t developed in a 1995 context; when it was being developed in the mid-1980s, Unix didn’t have the same dominant role, and implementations from different vendors had quite a lot of incompatibility anyway even between things considered “regular” Unix rather than experimental successors. I don’t think it was obvious at the time that a particular mash-up of System V and BSD would end up becoming the end point of Standard Unix.
Lost me at the very first sentence.
The rest of this article is complaining about how Plan 9–a research project–did not adequately cater to market whims.
I am fairly certain that I have, and for quite some time already. :)
It was never purposefully designed to succeed. It was made as a research operating system, not something to compete with the alternatives of the time.
Wait, you want to use X11? I am so sorry for you if that is the case (um…).
Woah, there! That’s quite the severe opinion. Are you saying we shouldn’t make new programming languages, and only extend the ones that exist? Should we not attempt to fix the plentiful hacks embedded within the Linux kernel? I feel the takeaway is more along the lines of “it’s difficult to sell others on something that is better if it also reduces compatibility at the same time”. I believe that we should continue to try to redo the things that are broken, and not continue hobbling atop failing technologies.
People still use sockets and their numbers are far greater than just “a bunch”. Even if we use abstractions atop of sockets, some of their awkwardness manages to crawl its way through the abstraction and add complexity. Plan9 tried to solve this by thinking of a more generic abstraction, and applying it to everything it could, thereby removing any complexities that might be induced by yet another, unexpected API or abstraction being made to do something.
Unfortunately the problems solved by Plan9 do exist. Albeit, they’re not problems that people feel overly encumbered with, but they are mild annoyances. Not only that, but as we arrive closer and closer to The Future™ we find that a more Plan9-like system would adapt itself better to things such as multicore computers or creating a public or private “cloud”. The problems existed and exist, it just seems that almost nobody cares enough to overcome the necessity to learn something new, and prefer to stick with their known, comfortable system.
Overall, I would say this feels more like a guide on how to plan to make marketable software than anything else, with which I strongly disagree. Programming shouldn’t have to be about making something that is popular or profitable, but about making technology better overall. If only that were the world we lived in.
I don’t necessarily disagree with the principles in this article, but there’s quite a bit of path-dependent history around AT&T’s commercialization strategy that it’s glossing over, which I think limits the broad, general-purpose lessons that can be drawn from this specific example.
When Plan9 was (finally) made available in some kind of public form in 1995, a lot of what this article says is true. Unix was well established, had converged on some degree on compatibility, and Plan9 was seen by many potential adopters as gratuitously breaking this: changing too many things, some for reasons that seemed arbitrary or nitpicky, and others for reasons that might be legitimate but whose benefits were outweighed by the negatives of changing. But Plan9 wasn’t developed in a 1995 context; when it was being developed in the mid-1980s, Unix didn’t have the same dominant role, and implementations from different vendors had quite a lot of incompatibility anyway even between things considered “regular” Unix rather than experimental successors. I don’t think it was obvious at the time that a particular mash-up of System V and BSD would end up becoming the end point of Standard Unix.
All of the lessons are basically wrong, and the concluding paragraph is a mismash of statements that don’t follow (and are empirically incorrect).