Reading the article it's tempting to say sometimes it borders on ridiculousness :) .
> No one, in the Unix world, ever complained about the Unix's missed promise about file abstraction.
The whole world, sans programmers, keeps moaning on complexity of computers, and Unix, and how hard it is to learn all those arcane commands and abstractions and why things can't be just plain and simple. I'll skip rants about how it's related to file abstractions :) .
Being fully aware how the same things could look very different from different angles, I'd still maintain the "not broken - don't fix" approach has been countered then and now.
What operating systems do you have in mind? The only remaining systems (outside of academia/research) which are not based on unix seem to be windows, openvms and os/z.
Edit: thanks pjmlp. With so many name changes I forgot that IBM still had an alternative OS for small computers. I imagined that maybe there were still other mainframe systems, but I was too lazy to check...
Far as surviving ones, Burroughs MCP and GCOS are still around. BeOS is being cloned by Haiku. Amigas are still around with MorphOS being good. eComstation maintains OS/2. The THEOS OS and GEM(?) window system still exist. Plan 9 of course. GenodeOS continues microkernel-style tradition. JX continues language-style security trend. Oberon legacy last iterated as A2 Bluebottle OS.
Thanks. Apart from the mainframe systems, the ones having experienced commercial/industrial success in your list are either life-extension efforts to support niche users or are clones of the actual thing developed by hobbyists. Maybe they would suck less than unix if they had seen in the last 20 years a fraction of the development behind unix operating systems. By the way, you forgot to include FreeDOS (I don't know if DR-DOS is still alive).
Besides adopting ideas from the mainframe world in UNIX System V architecture, what improvements has UNIX had in those 20 years in what concerns modern computing architecture?
I don't know what fraction of the improvements concern modern computing architecture, but probably we all agree that there have been improvements that make it suck less in practice. I thought I was replying to the person who said that "most non-unix oses simply suck, too, and usually more." My point is that the comparison is somewhat unfair.
If by UNIX you mean *BSD or GNU/Linux derivatives then I agree the UNIX-like experience, as such has improved a lot, when comparing the BSD/GNU experience with the POSIX certified one.
However, I imagine that if I seat myself in front of a 2016's fresh installation of Aix, HP-UX, Solaris, Tru64... I will struggle to find any major difference from a 2006 installation, the last time I used any of them.
I agree, but the pace of development of those systems over the last ten years is not comparable with the previous ten years. By that time unix sucked already substantially less. For example, SunOS 5.6, 5.7, 5.8, 5.9 and 5.10 were all released in the 1997-2005 timeframe. Only 5.11 has been released since then.
DTrace, ZFS, and containers should be major differences. Serious changes in how admins' jobs work have resulted from just those three. A whole cloud platform has been built when that was added to other benefit of open-sourcing one. So, Sun's OS got transformed into a pseudo-mainframe with better debugging and possibly better filesystem. I don't recall enough details of mainframe FS's to be sure on latter.
Far as Linux, Ubuntu with its software-center, Flash, VLC, and so on are much different than my early experience with Caldera OpenLinux on a Pentium 2. Which would've looked like shit with almost no apps or features had it not bricked that machine during install. ;)
So, they're not very innovative but have had huge improvements that totally change the user-experience. I mean, certain things are similar or the same especially on terminal end. Yet, we can't pretend like UNIX has sat still. It's just still not fixing its worst issues or learning from prior work as effectively as it could.
Yeah, but that is just copying the other OSes, mostly mainframe features that are just relevant for a few selected souls.
As for the desktop, yeah the experience has improved, but still no proper GUI stack in place, all is built on top of X architecture.
Nothing compared to the work done at Xerox, DEC/Olivetti or even what Microsoft does at MSR.
I came to me thinking how similar the coding experience in Mac OS X, Android and Windows or the whole OS stack is to the way I experienced Oberon back in the day.
Yes Mac based OSes and Android have a UNIX kernel, but when using the official APIs for applications, one would hardly notice it.
That was the brilliance of NEXT: leverage momentum of UNIX in lower layers while hiding it behind a sensible upper layer. Fixed up the graphics stack, attempted to provide better organization (failure = Mach), and provided consistent, good user interface on top. Maybe better API's, maybe not... never programmed Macs.
I've been saying for a while that a group needs to do this for one of the BSD's. Not just put KDE or Gnome on one but seriously reengineer the GUI, sounds, graphics, admin controls, and package mgmt. Smooth integration with high usability and good efficiency like Macs. Closest I've seen was Mint but had to ditch it for security reasons.
nickpsecurity, I missed the link in your reply. Now I think you were listing only operating systems that sucked less than unix ("did vastly better than UNIX in all kinds of ways"). And I have just realized you are not the one claiming that most "most non-unix oses simply suck, too, and usually more."
Exactly. You got me mixed up with someone else. Now, one could easily argue they sucked in some way. Especially in interfaces for some (eg mainframes, minicomputers) given they were created before PC's were invented or computers could even do much more than batch or terminal ops. Then, due to backward compatibility, they had to maintain these warts. One might also talk supported features, speed, cost, and so on for anything on the list. LISP machines got too slow, OpenVMS was too expensive, BeOS lacked Windows ecosystem, and so on.
Yet, each contributed architectural or feature innovations that are worth considering or copying to this day. Some you still can't buy on the market: Burrough's hardware security or Genera LISP's development capabilities. Some FOSS hasn't quite caught up to: BeOS's amazing, consistent, desktop experience; OpenVMS's bulletproof clustering and other availability features [1]; OS/app security of KeyKOS or EROS; low 0-days in kernel code due to use of high-level language with extra type or memory safety. So, they still kick UNIX and Windows ass in numerous attributes. Ironically, it's Microsoft and Windows trying to copy as many techniques as possible from old systems rather than UNIX. Their quality and security levels have skyrocketed vs Dark Ages of Microsoft. UNIX (or alternatives) have plenty room to grow by using differentiators like on my list.
Note: I especially encourage you to carefully read the Genera LISP machine page. Some points are obviously old news or even laughable today ("has TCP/IP"). 8-13 for debugging down to OS level and 16 are a pretty badass combo you ain't getting with UNIX, C, and GCC. ;)
[1] Maybe Amazon Web Services would've gone down less if they, instead of UNIX, were running on VMS boxes known for individual uptime of 3-5 years and cluster uptime of up to 17 years in hands of average sysadmins. Ya think? :)
"Maybe they would suck less than unix if they had seen in the last 20 years a fraction of the development behind unix operating systems."
Essentially it. Each on my list were innovative in their capabilities with some capabilities still missing from UNIX. They just didn't have economic and social momentum behind them. Far as FreeDOS, I left it off because it wasn't really innovative or worth copying. I'd take UNIX or Oberon over DOS any day. Maybe eCOS given its innovation was being highly and easily configurable.
This reminds me of my Blue Box on NuKernel idea, the idea being to later implement the Mac OS APIs in separate processes outside the box. One interesting thing it did was to use Pascal strings.
>The whole world, sans programmers, keeps moaning on complexity of computers, and Unix, and how hard it is to learn all those arcane commands and abstractions and why things can't be just plain and simple. I'll skip rants about how it's related to file abstractions
It says "no one, in the unix world". People outside of the unix world are not in the unix world. The point is, unix became very popular despite being bad (or perhaps because of being bad). Even within unix, the worse a system is, the more popular it is in general (see a typical linux distro full of randomly tossed together junk).
OS X is not the worst UNIX. Darwin is kind of a shit kernel, but the user land is way more sensibly designed than your typical Linux distro (which is, as OP said, a random collection of junk).
Don't agree. Self contained app bundles are great. I use homebrew for some stuff and dependencies are a PITA. E.g. multiple incompatible Python versions.
That's because OS X's user land is based on BSD. BSD in general is a much more well thought out UNIX-like OS than Linux. When I made the switch a couple of years back, I was surprised at how simply everything fit together compared to my experiences in the Linux space.
> The whole world, sans programmers, keeps moaning on complexity of computers, and Unix, and how hard it is to learn all those arcane commands and abstractions and why things can't be just plain and simple. I'll skip rants about how it's related to file abstractions :) .
There are a lot of things about Plan 9 that really aren't that good in 2016. The compiler, for example, lacks a modern optimization pipeline and generates code that is unacceptably slow by modern standards. The windowing system is not a compositing window manager; it's a '90s design through and through and cannot perform as well as solutions like Wayland (that are arguably simpler). The browser doesn't support dynamic changes and would have to be rearchitected to support anything more than simple pages with acceptable performance.
None of this is meant to bash the great work that the Plan 9 team did while at Bell Labs/Lucent, mind you. With the team they had they did a really great job, and they're all top-notch developers. I only want to counter the notion that Plan 9 is all around a technically better OS than the ones we use today. It isn't.
As sad as it sounds, most complexity exists for a reason. There is a good amount of cruft that could be dropped if not for backwards compatibility, but when e.g. compilers are concerned, you depend on that complexity for performance.
> There are a lot of things about Plan 9 that really aren't that good in 2016.
Well yeah, that's because Plan 9 wasn't written in 2016 and hasn't been kept up to date. I don't think anyone claimed otherwise.
It doesn't invalidate the point that people do want a simpler OS that isn't as crazy and hodge-podgey as Unix. They just don't want it as much as they want compatibility with old software.
Think how hard a sell Windows 10 would be if it didn't run software written for Windows 7. Literally no-one would use it. That doesn't mean it isn't better.
This has devolved into a fairly pointless semantic debate. What I'm saying is that rio is not built around compositing hardware surfaces, like all modern windowing systems (DWM, Mac CGS, Wayland) are. A windowing system that is not architected this way will always have inferior performance, and retrofitting the proper design onto an existing one based on memory buffers and drawing commands is difficult to do (see all the problems with XCOMPOSITE).
>The whole world, sans programmers, keeps moaning on complexity of computers, and Unix, and how hard it is to learn all those arcane commands and abstractions and why things can't be just plain and simple.
Which is orthogonal to a broken filesystem abstraction here and there.
Besides the plan 9 userland was hardly different or better in that aspect.
If I could get texlive, a graphical browser and an rdp client running under it I could live there after I retire. Until then it remains something of a toy system for me (others may disagree). I'd be delighted to hear from those using it for actually creating stuff.
I know that [kertex](http://www.kergis.com/en/kertex.html) works on plan9, if there are parts missing between kertex and texlive, Thierry (the creator of kertex) could probably give you some pointers on getting those working too.
For me abaco(1) is generally good enough, and I used to use vnc and esd to get video and sound to my terminal from my 'browser machine.' RDP is a bit harder, but writing a client or doing a hackjob of freerdp or whatever wouldn't be too bad.
It does not seem that it was ever meant to compete with or replace commercialized operating systems. The direct output of research is not something you sell - but it does give the world better things which can be industrialized.
The actual product ended up being Inferno, and that ran into the combined Java marketing campaign and Lucent's lack of ability to market anything to developers. Well, Lucent continued a tradition that flowed from AT&T's UNIX PC[1] and all their various weird marketing once they got free of the monopoly restrictions.
By "the actual product" you mean "a completely different OS written on a virtual machine that happens to also run on Plan 9", then yes. Inferno has 9P, it has a lot of the same good stuff as Plan 9, but there's a pretty big gulf between the two and fluency in one does not translate to fluency in the other.
> It does not seem that it was ever meant to compete with or replace commercialized operating systems.
UNIX was also a research system. The following paragraph from the article would also by applicable:
"One of the major problems with Plan-9 was that AT&T and the people behind Unix, while they were incredible scientists and programmers, they were not used to create commercial software and AT&T has never been in the software business. (...) They used software and they used to produce internal software to run their high end network appliances but they never created software to be sold to someone else and it never was major source of revenue (...). This just means that they never had a sense of what could have been needed into the outside world."
If anything, this problem was relatively less important for Plan 9 given that they already had some experience in creating research systems that would become mainstream.
Edit: By the way, saying that "AT&T used software and they used to produce internal software to run their high end network appliances" seems a bit of an understatement. Quoting wikipedia: "Researchers working at Bell Labs are credited with the development of radio astronomy, the transistor, the laser, the charge-coupled device (CCD), information theory, the operating systems Unix, Plan 9, Inferno, and the programming languages C, C++, and S. Eight Nobel Prizes have been awarded for work completed at Bell Laboratories."
I'm not sure that I follow your argument. Are you saying that because a similar research project was successfully commercialized Plan-9 should be judged akin?
Even if you accept that, UNIX was not developed to what it became by AT&T. Let arguments about how they managed licensing UNIX vs how Plan-9 was licenced commense!
I'm not trying to argue with what you said, but pointing at the weakness of the article's conclusions. As another commenter just wrote "How does the author explain the huge success of the original UNIX? It violates everything he says."
> I am quite sure that you do not know what Plan-9 is and that, probably, you never have heard of it too.
Right off the bat with a failed assumption. Of course I know what Plan 9 is, I've used it lots. Why make this assumption? Just say "most people" and you've already hedged your bets.
If you already know you aren't the target for someone's writing, and you could figure out what it meant anyway, why bother complaining about it? It's a rhetorical device, not a declaration of fact. Read like a human, not a computer, and you might enjoy life a lot more.
I think hyperbole is a fine use of rhetoric. And I think "read like a human, not a computer" is not talking about a computer's lack of emotion, but its need for precision and order. In contrast to human adaptability.
That just means that you, I, and other knowledgeable people are not the target audience, and he intends for it to be read by people who do not have the context to disagree with his just-so story for why Plan 9 failed, which coincidentally includes a business principle.
And my interpretation of his thesis boils down to: Don’t scratch your own itch. Fine. I have my own explanation for why Plan 9 failed, and there are lots of reasons you can invent, based on hindsight and your own biases.
Let's say for the sake of alternatives, that Plan 9 was released to the public in 1995 under the MIT license. I think at least one of the BSDs would have used the C compiler, but I think it would have been bigger than that.
So never simplify anything? Let everything become more and more complicated with band aid fixes until no one has any idea how the hell the whole thing works or any clue why things happen. Sell people a faster horse, because that's what we've really wanted all along? Is that the moral of this?
Seems to be saying that Plan 9 introduced one thing now on most unix-like systems (/proc) and another thing now on most systems period (UTF-8). However Plan 9 was a total failure and a waste of time and teaches us not to solve problems if they aren't a big deal. ?
Yes. Those two (and a few more) good things about it that solved real problems were adopted.
Most others, including its central premise about everything actually being a file, were not (adopted or successful), and turned out they weren't a big deal.
If from one product with 1 central premise and 10 new features the world only adopts 2 of those features, I'd still call it a "total failure" market-and-adoption wise, and a waste of time for those building it.
They could have built those 2 features independently anyway.
To be fair, Inferno was a bit different with the whole Limbo and VM thing. It really didn't have a chance being targeted at the same market as Java with a whole lot less ad / industry push. Lucent just never got it together for product pushes.
1995 was Lucent, and AT&T did enter the UNIX PC market in the 80's. I got to use a 3B2 in college in 91. Sadly, that was my first UNIX computer.
Inferno isn't Plan 9. Written by the same people, yes, but it's a different OS running on a virtual machine rather than x86, different programming language, etc. The main commonality is 9P, which enables some other similarities such as Acme, synthetic filesystems, etc.
> Most others, including its central premise about everything actually being a file, were not (adopted or successful), and turned out they weren't a big deal.
Except they are, because Linux reinvented them decades later with lots of hype, but worse, in the form of user-level file systems and containers like Docker.
> They could have built those 2 features independently anyway.
Except you can't know which features will be a hit in advance, so your research prototype is only a failure if it never gets any adoption, and never inspires something better. Otherwise it was successful in exploring a design space, even if the result is negative.
Your argument is the same fallacy as the belief that publishing negative scientific results isn't important. Documenting failed experiments is just as important to growing our understanding as documenting successes.
> 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. For instance, UTF-8 is a wonderful idea and you need to do that but you can implement that in libraries or subsystems in such a way that you can use it in other operating systems more than create an operating system all around an encoding system.
I disagree 100%. The Plan9 use of Unicode and UTF8 was visionary.
Character set handling was seriously broken on all Unixen in the 1980s. One major problem was the range of character sets available on most hosts which constrained the type of character data applications could handle easily. Another was the plethora of competing, overlapping encodings like EUC-JIS and SJIS or the myriad of ISO-8859 encodings. This required constant mapping (or rather partial mapping) between different layers of the stack with attendant hits on usability, configuration problems, data corruption, etc.
Unicode with UTF-8 storage encoding almost completely solves these problems, the more so as software up and down the stack adopts the same conventions. At least on the projects I worked on then in the DBMS industry we would have gladly taken the hit to upgrade.
The article almost makes it sound like UTF-8 was a Plan9 invention.
I also don't understand why using UTF-8 was a bad idea. If I start a new OS from scratch, I would have to be brain-damaged to not use UTF-8 as the sole encoding (and other encodings being treated as second class citizens).
I can understand the issue with taking the file abstraction to perfection. If by doing that you are incompatible to most of the software there is, you're going to have a hard time getting developers to develop for your OS. This could be somewhat alleviated with a ioctl compatibility library for the time being.
It is for all but UTF-32. And even in the case of UTF-32 if you are indexing for what a user would logically consider a character then its O(n) there is well because of combining characters.
I don't think the assumption of brilliance is warranted. Plan 9 was facing an uphill battle due to the lack of conformity, sure. But it wasn't a brilliant system, it was pretty bad. If it had been brilliant, maybe it would have won that battle. But I don't think it is far to say brilliance fails without conformity based on a single example whose brilliance is very debatable.
One of the messages of the article is to identify if there is a market. I must have read this a thousand times so far in my life. It's as if so many product failures and millions of developer-hours could have been saved if we followed this advice and thought really really hard about the market. It's so simple and we're morons for not embracing this wisdom.
The problem is you just don't know. You might create a new market where none existed or completely take over a very crowded market, or (much more likely) fail regardless of what your marketing research told you.
How does the author explain the huge success of the original UNIX? It violates everything he says. Certainly Dennis Ritchie and Ken Thompson weren't thinking about the size of the market for a new OS. UNIX was incompatible was everything that existed at the time and AT&T could have used an existing OS for everything they needed done.
Facebook is another good example of you just don't know. Probably there were a thousand other equally smart Zuckerbergs trying to create a social whatever in 2004. One succeeded and 999 failed. Was it because Zuckerberg was thinking hard about the market and the others weren't? Many of the factors you don't understand, don't control, can't predict, and can't even explain more than a decade later.
I agree with this and in general think the degree of randomness in outcomes and survivorship biases aren't fully appreciated by a lot of folks examining the startup world.
With that said, I do think there is one trait that is common to successful products/projects ...they were successfully sold.
Now this might seem obvious after the fact but I think the amount of effort expended in 'selling' should be somewhat proportional to the novelty (and or perceived ineffectiveness )of the product. If you don't have an evangelist (on your team or external) that can sell the idea to customers, employees, business partners, investors ... your chances of success are greatly reduced.
And even then pure randomness and timing (you could be too early/too late ) will drive the final outcome.
Another one: Doing market research well is really hard, and not something the person/group has a lot of experience in. It also might result in finding out that there isn't really a market which means we would have to abandon or drastically change our plan, and we really don't want to do that. So, let's just not bother and assume there is a market!
Then there's the fun dynamic where if you are being really honest with yourself you don't care too much about whether there is a market or not, you just want to see the idea in your head become reality, because it would be super cool and you will feel good for having been able to do it. Which might be fine for a one-person side project, but otherwise not so much.
I'm reminded of a message from The Innovator's Dilemma by Clay Christensen. When PCs first came out, no one wanted them. When Honda motorcycles first came out, no one wanted them. When email systems first came out, no one wanted them. These things all flew in the face of the established norms, moving upmarket and eventually overtaking the market leaders. There were no markets for these things then, but these products created their own markets.
Of course, as you said, we don't know who the exact winners will be, but like the Richter scale, there are some indicators that can be helpful in determining the magnitude and general location of the next earth-shaking market movements. Christensen's framework recommends examining several of a product's consumer utility curves for exploitable inefficiencies in niche (and usually low-end) markets. E.g., laptop manufacturers value 2.5" hard drives for their form-factor and are less sensitive to price per GB. E.g., teenagers value the speed, ease, and essentialism of Snapchat and are willing to forgo access to an extended peer network on Facebook.
While we'll never know exactly what will succeed or fail, thinking about the market is almost always a productive activity that can certainly have a dramatic impact on outcomes.
>How does the author explain the huge success of the original UNIX? It violates everything he says.
The original Unix was not created as some sort of grand solve-the-world's-problems vision. It happened because some people on project like that, Multics, said, "fuck it, let's spend a month building something simple that we can actually use." Market 1: themselves.
From there, they found other people with needs and they solved them. Market 2 was another department that needed a word processor; they made one. Then more Bell Labs departments needed an OS for their shiny new computers, so that was market 3.
So yes, the history of Unix very much fits with the "find a market and solve their problems" notion. It's true that they weren't thinking strategically about long-term world domination. But that's sort of the point of the "identify a market" notion: vast, airy thoughts about strategy often lead to product that nobody uses. Whereas focusing solving very specific needs of actual users (that is, your chosen market) is frequently a path to success.
It's basically the same deal with Facebook. Facemash was just Zuckerberg fucking around. When he found that it had real resonance for people, he tried something more ambitious in the space. But he didn't say, "I'm going to totally change the way humans interact by creating a technological marvel." He didn't spend millions of dollars or years building amazing infrastructure. He made a small, basic product for a single school. Only when he had proof that he had product-market fit did he worry about scaling up. And he got that product-market fit by paying attention to the market, his fellow students.
Yes. I think both also proceeded by making major inroads into very small markets before expanding. Facebook in particular didn't get their first users by launching something adequate for a lot of people. They launched something that was a home run for a small group. Then they went school by school, dominating each as they went.
The truth is that each adopter makes their own decision; the more you can make something that's stellar for one person, the better a base you have to expand from.
An MVP IS a test for a market. If people like Facemash, maybe they'll like a Facebook. Ken Thompson implemented the first Unix in a month[1]. Neither started out huge.
One thing to remember, too, is that the original Facebook was quite different from what we have today. It focused on personal profiles, and had features of almost like a dating site. A huge use case was organizing parties (I know that because that's what we did as a group of students). Newsfeed as a timewaster is a feature that evolved only later. Messages were clunky and a non-thing.
Any product that has persisted is actually a series of products sharing same name, but each targeting a different demographic - oftentimes even actually same set of people but at different life stages. And as sibling comments point out, it is all about just trying and trying (and also, it would seem, having super convenient access to millions of people to try things on).
I'm sure the guy who thinks it's spelled "Plan-9" has some very insightful things to say. Maybe it's time for me to blog about Ruby/On/Rails, the latest web-dev hotness.
Another view is plan9 didn't become popular because it was not freely available. If it had been "freed" prior to when 386bsd was first released, history might've been different. I knew about it much before 386bsd came out and would've jumped at the chance to use it....
It was a research OS. That by itself renders the entire article moot. It's akin to someone writing an article about how Minix "lost" vs. Linux- it's apples and oranges. You can't call something a failure if it was never intended to be the thing you claim it failed at being.
Some of the people behind Plan 9 lobbied AT&T's management very hard for years to get permission to open-source it, which they obtained in 2002. (Lucent Public License 1.02 satifies the Open Source Definition and the Debian Free Software Guidelines.)
Some of the people posting to the Plan 9 mailing list at that time from plan9.bell-labs.com addresses certainly hoped that Plan 9 would catch on.
Some of the people behind Plan 9 lobbied AT&T's management very hard for years to get permission to open-source it, which they obtained in 2002. (Lucent Public License 1.02 satifies the Open Source Definition and the Debian Free Software Guidelines.)
Some of the people posting to the Plan 9 mailing list at that time from plan9.bell-labs.com addresses certainly hoped that Plan 9 would catch on.
In the 1990s Rob Pike tried to persuade one of the major browser vendors to support Plan 9.
>Moreover, in Plan-9, many of the "good old things" were removed and a lot of incompatibility was introduced in the system with respect to the other Unixes. This prevented many different companies to even start thinking of porting their applications to Plan-9.
This is fundamentally why plan9 didn't take off. It was too different and not better enough.
Platform technology marketing is being on the right side of a nuanced dichotomy:
1. You need to be different enough to be noticed and given attention
2. And better in the eye of the user (which implies familiar)
For example, OSX was a great success among hacker types for this very reason: It was different yet familiar (Most UNIX-y stuff just worked on OSX thanks to its FreeBSD lineage).
Another example is Go: It's different enough from the previous generation of server-side languages to command attention, but its syntax was very much in the C language tradition (And it articulated its "betterness" well, such as performance gain over Python/Ruby and ease of use over C/C++/Java).
Fundamentally, Plan9 was way too different from the incumbent without any clear advantage.
I find your point 1 and 2 to be very insightful. It strikes me as why react native is doing so well on it's platform technology marketing. Different enough: mostly javascript and a consistent mental model for ios, android, and perhaps web. Better in the eye of the user: More shared code, faster tooling and workflow due to compile speed improvements.
Reminds me of Dan Ariely psychology of choice. Always find a way to appear better. Bring something/someone less good so people don't question it in the current context.
Yeah. The compatability problem, or why Windows is still crazy after all these years. Build it close to right the first time: the world won't give you a second chance.
I really like Plan9's ideas, but its community gravitates to catv.org, which is full of assholes who believe that if it hasn't been blessed by Murray Hill, it has no merit, no matter what the real world has to say.
Really? Cat-v and many other sites that are fans of plan 9, as I said, seemingly refuse to believe that's happened in the UNIX world has any merit, claiming that it is either a) overly complicated, or b) useless. So I'll attempt to refute most of cat-v right now. You know, sometimes things are unnecessarily complicated (I'm looking at you, systemd), but there are REASONS for things like python and ruby.
Pthreads or and forks are necessary to build CSP-concurrency, and are in fact simpler and more unix-y than them (I'm NOT saying they're better, but they are closer to the unix spirit in many ways. You did read ALL of Lisp: The Good News, The Bad News, And How To Win Big, right?).
Bash and ZSH kind of suck, but none of the other shells are really any better, because the really problem is the f*king INSANE standard, which codifies the absolutely insane behaviors that shells are supposed to have. RC is better than most, being from plan 9, but it still has plenty of warts.
GCC and Clang may not be perfect, but they generate better code than 8c ever did, and have world-class teams working on them.
automake is TERRIBLE, but you really do need something more complex than Makefiles sometimes, so scons is probably your best option. See above about Python.
GUIs exist for a reason, and while glib sucks, you can't replace it with libc. There are other libraries, though.
Emacs is more powerful than ACME, and you can't just ask people to learn a new interface because you hate VI.
UTF-32 (UTF-16 DOES suck NOW, it didn't always) has different trade-offs from UTF-8, and is a legitimate choice sometimes.
I shouldn't have to explain why you can't just replace SQL with hierarchical databases, or non-relational databases. Maybe you can sometimes, but not in the general case, and not with good performance.
Just because you use OpenBSD doesn't mean that everybody should.
Solaris and FreeBSD have some technical advantages as well (e.x. jails). SVG, PDF, and EPUB cannot be replaced by postscript. I mean, come on, you say you want security, and then you advocate an image standard that's TURING COMPLETE, effectively giving any image the capability to crash your computer, or inject code, if there's a flaw in your postscript implementation.
I used to think that cat-v was somewhat satire, but it really didn't seem that way, once I'd read what people were saying on it. And that is really sad, IMHO.
cat-v is full of assholes, yes, and most of the Plan 9 community retains what I call "a sad devotion to an ancient religion"--anything written at Bell Labs is holy writ, anything written outside is suspect and probably tainted, must purge the heretics.
However, most of your objections down-thread are "People are used to X/Y/Z, it is literally impossible to change them now."
It's interesting to look at QNX's implemention of POSIX. In QNX, the POSIX library mostly makes calls for interprocess communication, using MsgSend and MsgRecv. That's the real underlying primitive. Not files. MsgSend works like a remote procedure call - you send data and wait for a reply. (There's a timeout mechanism available, and you can time out anything that blocks. Real-time OS, remember.)
QNX lets you make anything look like a file, by writing what QNX calls a "resource manager". This takes over a subtree of the pathname space, and the library turns create, open, close, read, write, and ioctl calls into the appropriate MsgSend calls. That's how you write a file system under QNX as a user process. But there's no reason to turn things into files unnecessarily. Displays are not files, for example.
QNX has what looks like a Berkeley sockets interface, but "send" and "recv" call the same thing as "write" and "read". You can use read and write on a socket. I think you can use "send" and "recv" on a file system, too.
If you're going to have one primitive, MsgSend and MsgRecv are a better choice than files. But it's easy to get that wrong. Mach botched it, and for decades, microkernels had a bad rep.
QnX is one of the under-appreciated gems in the OS landscape. I still hope that RIM will entirely open-source it and I'd happily contribute a good sized chunk of money towards a ransom.
It was open source for a while under Harmon, and free for non commercial use. I wish I'd downloaded it all back then. I'd like to see a QNX-like OS in Rust.
QNX is a fantastic system and one of the few microkernels that's really been done properly.
That being said though the send/recv interface on QNX gives you the same side effects that Plan 9's 9P gives you. You have a simple way for everything to talk to each other. Files are really just a way to visualize communication channels. Like displays are files, but the files are just an object you reference to send messages to the driver. Same with filesystems and everything else.
109 comments
[ 4.3 ms ] story [ 182 ms ] thread> No one, in the Unix world, ever complained about the Unix's missed promise about file abstraction.
The whole world, sans programmers, keeps moaning on complexity of computers, and Unix, and how hard it is to learn all those arcane commands and abstractions and why things can't be just plain and simple. I'll skip rants about how it's related to file abstractions :) .
Being fully aware how the same things could look very different from different angles, I'd still maintain the "not broken - don't fix" approach has been countered then and now.
And I coming from the world of Amiga and Windows, after a decade mostly spent on UNIX land, have returned mostly to Windows world in the last 6 years.
The world has gone UNIX because it was free and for free stuff, everyone is willing to live with some warts.
Had AT&T been able to sell it in first place, it probably would not have spread as it did.
Unix and C are the ultimate computer viruses. ["The Rise of Worse is Better" by Richard P. Gabriel, included in "The UNIX-HATERS Handbook"]
Edit: thanks pjmlp. With so many name changes I forgot that IBM still had an alternative OS for small computers. I imagined that maybe there were still other mainframe systems, but I was too lazy to check...
Far as surviving ones, Burroughs MCP and GCOS are still around. BeOS is being cloned by Haiku. Amigas are still around with MorphOS being good. eComstation maintains OS/2. The THEOS OS and GEM(?) window system still exist. Plan 9 of course. GenodeOS continues microkernel-style tradition. JX continues language-style security trend. Oberon legacy last iterated as A2 Bluebottle OS.
So, there's several I recall.
However, I imagine that if I seat myself in front of a 2016's fresh installation of Aix, HP-UX, Solaris, Tru64... I will struggle to find any major difference from a 2006 installation, the last time I used any of them.
Far as Linux, Ubuntu with its software-center, Flash, VLC, and so on are much different than my early experience with Caldera OpenLinux on a Pentium 2. Which would've looked like shit with almost no apps or features had it not bricked that machine during install. ;)
So, they're not very innovative but have had huge improvements that totally change the user-experience. I mean, certain things are similar or the same especially on terminal end. Yet, we can't pretend like UNIX has sat still. It's just still not fixing its worst issues or learning from prior work as effectively as it could.
As for the desktop, yeah the experience has improved, but still no proper GUI stack in place, all is built on top of X architecture.
Nothing compared to the work done at Xerox, DEC/Olivetti or even what Microsoft does at MSR.
I came to me thinking how similar the coding experience in Mac OS X, Android and Windows or the whole OS stack is to the way I experienced Oberon back in the day.
Yes Mac based OSes and Android have a UNIX kernel, but when using the official APIs for applications, one would hardly notice it.
I've been saying for a while that a group needs to do this for one of the BSD's. Not just put KDE or Gnome on one but seriously reengineer the GUI, sounds, graphics, admin controls, and package mgmt. Smooth integration with high usability and good efficiency like Macs. Closest I've seen was Mint but had to ditch it for security reasons.
Yet, each contributed architectural or feature innovations that are worth considering or copying to this day. Some you still can't buy on the market: Burrough's hardware security or Genera LISP's development capabilities. Some FOSS hasn't quite caught up to: BeOS's amazing, consistent, desktop experience; OpenVMS's bulletproof clustering and other availability features [1]; OS/app security of KeyKOS or EROS; low 0-days in kernel code due to use of high-level language with extra type or memory safety. So, they still kick UNIX and Windows ass in numerous attributes. Ironically, it's Microsoft and Windows trying to copy as many techniques as possible from old systems rather than UNIX. Their quality and security levels have skyrocketed vs Dark Ages of Microsoft. UNIX (or alternatives) have plenty room to grow by using differentiators like on my list.
Note: I especially encourage you to carefully read the Genera LISP machine page. Some points are obviously old news or even laughable today ("has TCP/IP"). 8-13 for debugging down to OS level and 16 are a pretty badass combo you ain't getting with UNIX, C, and GCC. ;)
[1] Maybe Amazon Web Services would've gone down less if they, instead of UNIX, were running on VMS boxes known for individual uptime of 3-5 years and cluster uptime of up to 17 years in hands of average sysadmins. Ya think? :)
Essentially it. Each on my list were innovative in their capabilities with some capabilities still missing from UNIX. They just didn't have economic and social momentum behind them. Far as FreeDOS, I left it off because it wasn't really innovative or worth copying. I'd take UNIX or Oberon over DOS any day. Maybe eCOS given its innovation was being highly and easily configurable.
http://ecos.sourceware.org/about.html
It says "no one, in the unix world". People outside of the unix world are not in the unix world. The point is, unix became very popular despite being bad (or perhaps because of being bad). Even within unix, the worse a system is, the more popular it is in general (see a typical linux distro full of randomly tossed together junk).
That's true of non-unixy systems too, see: Windows.
And by that same logic, OS X is the worst Unix.
A whole bunch of tools thrown together is pretty much the definition of an operating system.
There are a lot of things about Plan 9 that really aren't that good in 2016. The compiler, for example, lacks a modern optimization pipeline and generates code that is unacceptably slow by modern standards. The windowing system is not a compositing window manager; it's a '90s design through and through and cannot perform as well as solutions like Wayland (that are arguably simpler). The browser doesn't support dynamic changes and would have to be rearchitected to support anything more than simple pages with acceptable performance.
None of this is meant to bash the great work that the Plan 9 team did while at Bell Labs/Lucent, mind you. With the team they had they did a really great job, and they're all top-notch developers. I only want to counter the notion that Plan 9 is all around a technically better OS than the ones we use today. It isn't.
As sad as it sounds, most complexity exists for a reason. There is a good amount of cruft that could be dropped if not for backwards compatibility, but when e.g. compilers are concerned, you depend on that complexity for performance.
Well yeah, that's because Plan 9 wasn't written in 2016 and hasn't been kept up to date. I don't think anyone claimed otherwise.
It doesn't invalidate the point that people do want a simpler OS that isn't as crazy and hodge-podgey as Unix. They just don't want it as much as they want compatibility with old software.
Think how hard a sell Windows 10 would be if it didn't run software written for Windows 7. Literally no-one would use it. That doesn't mean it isn't better.
8½ perhaps wasn't, but Rio is a compositing window manager.
Which is orthogonal to a broken filesystem abstraction here and there.
Besides the plan 9 userland was hardly different or better in that aspect.
Just because you don't use it doesn't mean we don't. Pop by the #plan9 irc channel on Freenode some time, or lurk in #9front as see the daily commits.
If I could get texlive, a graphical browser and an rdp client running under it I could live there after I retire. Until then it remains something of a toy system for me (others may disagree). I'd be delighted to hear from those using it for actually creating stuff.
So I'll be trying to build this on a 9front install on my old Thinkpad X61 in a few weeks when the exams are over (I'm a teacher).
Which is amusing.
Opera 10 works in linuxemu
"Introduction
Plan 9 from Bell Labs is a research system..."
It does not seem that it was ever meant to compete with or replace commercialized operating systems. The direct output of research is not something you sell - but it does give the world better things which can be industrialized.
1) they did get the cover of Byte https://archive.org/details/byte-magazine-1985-05
UNIX was also a research system. The following paragraph from the article would also by applicable:
"One of the major problems with Plan-9 was that AT&T and the people behind Unix, while they were incredible scientists and programmers, they were not used to create commercial software and AT&T has never been in the software business. (...) They used software and they used to produce internal software to run their high end network appliances but they never created software to be sold to someone else and it never was major source of revenue (...). This just means that they never had a sense of what could have been needed into the outside world."
If anything, this problem was relatively less important for Plan 9 given that they already had some experience in creating research systems that would become mainstream.
Edit: By the way, saying that "AT&T used software and they used to produce internal software to run their high end network appliances" seems a bit of an understatement. Quoting wikipedia: "Researchers working at Bell Labs are credited with the development of radio astronomy, the transistor, the laser, the charge-coupled device (CCD), information theory, the operating systems Unix, Plan 9, Inferno, and the programming languages C, C++, and S. Eight Nobel Prizes have been awarded for work completed at Bell Laboratories."
Even if you accept that, UNIX was not developed to what it became by AT&T. Let arguments about how they managed licensing UNIX vs how Plan-9 was licenced commense!
Right off the bat with a failed assumption. Of course I know what Plan 9 is, I've used it lots. Why make this assumption? Just say "most people" and you've already hedged your bets.
And my interpretation of his thesis boils down to: Don’t scratch your own itch. Fine. I have my own explanation for why Plan 9 failed, and there are lots of reasons you can invent, based on hindsight and your own biases.
Most others, including its central premise about everything actually being a file, were not (adopted or successful), and turned out they weren't a big deal.
If from one product with 1 central premise and 10 new features the world only adopts 2 of those features, I'd still call it a "total failure" market-and-adoption wise, and a waste of time for those building it.
They could have built those 2 features independently anyway.
And it was only "research" because AT&T (or Lucent at the time?) couldn't sell it.
1995 was Lucent, and AT&T did enter the UNIX PC market in the 80's. I got to use a 3B2 in college in 91. Sadly, that was my first UNIX computer.
Except they are, because Linux reinvented them decades later with lots of hype, but worse, in the form of user-level file systems and containers like Docker.
> They could have built those 2 features independently anyway.
Except you can't know which features will be a hit in advance, so your research prototype is only a failure if it never gets any adoption, and never inspires something better. Otherwise it was successful in exploring a design space, even if the result is negative.
Your argument is the same fallacy as the belief that publishing negative scientific results isn't important. Documenting failed experiments is just as important to growing our understanding as documenting successes.
I disagree 100%. The Plan9 use of Unicode and UTF8 was visionary.
Character set handling was seriously broken on all Unixen in the 1980s. One major problem was the range of character sets available on most hosts which constrained the type of character data applications could handle easily. Another was the plethora of competing, overlapping encodings like EUC-JIS and SJIS or the myriad of ISO-8859 encodings. This required constant mapping (or rather partial mapping) between different layers of the stack with attendant hits on usability, configuration problems, data corruption, etc.
Unicode with UTF-8 storage encoding almost completely solves these problems, the more so as software up and down the stack adopts the same conventions. At least on the projects I worked on then in the DBMS industry we would have gladly taken the hit to upgrade.
[edit] corrected typo
I also don't understand why using UTF-8 was a bad idea. If I start a new OS from scratch, I would have to be brain-damaged to not use UTF-8 as the sole encoding (and other encodings being treated as second class citizens).
I can understand the issue with taking the file abstraction to perfection. If by doing that you are incompatible to most of the software there is, you're going to have a hard time getting developers to develop for your OS. This could be somewhat alleviated with a ioctl compatibility library for the time being.
It more or less was: https://en.wikipedia.org/wiki/UTF-8#History
But Plan9 didn't influence the design of UTF-8 only in as far as having a better character encoding than the original 2 byte UCS encoding.
And then Plan9 was used to showcase UTF-8.
The problem is you just don't know. You might create a new market where none existed or completely take over a very crowded market, or (much more likely) fail regardless of what your marketing research told you.
How does the author explain the huge success of the original UNIX? It violates everything he says. Certainly Dennis Ritchie and Ken Thompson weren't thinking about the size of the market for a new OS. UNIX was incompatible was everything that existed at the time and AT&T could have used an existing OS for everything they needed done.
Facebook is another good example of you just don't know. Probably there were a thousand other equally smart Zuckerbergs trying to create a social whatever in 2004. One succeeded and 999 failed. Was it because Zuckerberg was thinking hard about the market and the others weren't? Many of the factors you don't understand, don't control, can't predict, and can't even explain more than a decade later.
With that said, I do think there is one trait that is common to successful products/projects ...they were successfully sold.
Now this might seem obvious after the fact but I think the amount of effort expended in 'selling' should be somewhat proportional to the novelty (and or perceived ineffectiveness )of the product. If you don't have an evangelist (on your team or external) that can sell the idea to customers, employees, business partners, investors ... your chances of success are greatly reduced.
And even then pure randomness and timing (you could be too early/too late ) will drive the final outcome.
Then there's the fun dynamic where if you are being really honest with yourself you don't care too much about whether there is a market or not, you just want to see the idea in your head become reality, because it would be super cool and you will feel good for having been able to do it. Which might be fine for a one-person side project, but otherwise not so much.
Of course, as you said, we don't know who the exact winners will be, but like the Richter scale, there are some indicators that can be helpful in determining the magnitude and general location of the next earth-shaking market movements. Christensen's framework recommends examining several of a product's consumer utility curves for exploitable inefficiencies in niche (and usually low-end) markets. E.g., laptop manufacturers value 2.5" hard drives for their form-factor and are less sensitive to price per GB. E.g., teenagers value the speed, ease, and essentialism of Snapchat and are willing to forgo access to an extended peer network on Facebook.
While we'll never know exactly what will succeed or fail, thinking about the market is almost always a productive activity that can certainly have a dramatic impact on outcomes.
The original Unix was not created as some sort of grand solve-the-world's-problems vision. It happened because some people on project like that, Multics, said, "fuck it, let's spend a month building something simple that we can actually use." Market 1: themselves.
From there, they found other people with needs and they solved them. Market 2 was another department that needed a word processor; they made one. Then more Bell Labs departments needed an OS for their shiny new computers, so that was market 3.
So yes, the history of Unix very much fits with the "find a market and solve their problems" notion. It's true that they weren't thinking strategically about long-term world domination. But that's sort of the point of the "identify a market" notion: vast, airy thoughts about strategy often lead to product that nobody uses. Whereas focusing solving very specific needs of actual users (that is, your chosen market) is frequently a path to success.
It's basically the same deal with Facebook. Facemash was just Zuckerberg fucking around. When he found that it had real resonance for people, he tried something more ambitious in the space. But he didn't say, "I'm going to totally change the way humans interact by creating a technological marvel." He didn't spend millions of dollars or years building amazing infrastructure. He made a small, basic product for a single school. Only when he had proof that he had product-market fit did he worry about scaling up. And he got that product-market fit by paying attention to the market, his fellow students.
The truth is that each adopter makes their own decision; the more you can make something that's stellar for one person, the better a base you have to expand from.
[1] http://www.groklaw.net/article.php?story=20050414215646742
"...the number of UNIX installations has grown to 10, with more expected..." - Dennis Ritchie and Ken Thompson, June 1972
Any product that has persisted is actually a series of products sharing same name, but each targeting a different demographic - oftentimes even actually same set of people but at different life stages. And as sibling comments point out, it is all about just trying and trying (and also, it would seem, having super convenient access to millions of people to try things on).
Some of the people posting to the Plan 9 mailing list at that time from plan9.bell-labs.com addresses certainly hoped that Plan 9 would catch on.
Some of the people posting to the Plan 9 mailing list at that time from plan9.bell-labs.com addresses certainly hoped that Plan 9 would catch on.
In the 1990s Rob Pike tried to persuade one of the major browser vendors to support Plan 9.
This is fundamentally why plan9 didn't take off. It was too different and not better enough.
Platform technology marketing is being on the right side of a nuanced dichotomy:
1. You need to be different enough to be noticed and given attention 2. And better in the eye of the user (which implies familiar)
For example, OSX was a great success among hacker types for this very reason: It was different yet familiar (Most UNIX-y stuff just worked on OSX thanks to its FreeBSD lineage).
Another example is Go: It's different enough from the previous generation of server-side languages to command attention, but its syntax was very much in the C language tradition (And it articulated its "betterness" well, such as performance gain over Python/Ruby and ease of use over C/C++/Java).
Fundamentally, Plan9 was way too different from the incumbent without any clear advantage.
I really like Plan9's ideas, but its community gravitates to catv.org, which is full of assholes who believe that if it hasn't been blessed by Murray Hill, it has no merit, no matter what the real world has to say.
I'm going to get crucified for this, aren't I?
We're not assholes unless you come talk to us without checking your assumptions and entitlement at the door.
Probably.
Pthreads or and forks are necessary to build CSP-concurrency, and are in fact simpler and more unix-y than them (I'm NOT saying they're better, but they are closer to the unix spirit in many ways. You did read ALL of Lisp: The Good News, The Bad News, And How To Win Big, right?).
Bash and ZSH kind of suck, but none of the other shells are really any better, because the really problem is the f*king INSANE standard, which codifies the absolutely insane behaviors that shells are supposed to have. RC is better than most, being from plan 9, but it still has plenty of warts.
GCC and Clang may not be perfect, but they generate better code than 8c ever did, and have world-class teams working on them.
automake is TERRIBLE, but you really do need something more complex than Makefiles sometimes, so scons is probably your best option. See above about Python.
GUIs exist for a reason, and while glib sucks, you can't replace it with libc. There are other libraries, though.
Emacs is more powerful than ACME, and you can't just ask people to learn a new interface because you hate VI.
UTF-32 (UTF-16 DOES suck NOW, it didn't always) has different trade-offs from UTF-8, and is a legitimate choice sometimes.
I shouldn't have to explain why you can't just replace SQL with hierarchical databases, or non-relational databases. Maybe you can sometimes, but not in the general case, and not with good performance.
Just because you use OpenBSD doesn't mean that everybody should.
Solaris and FreeBSD have some technical advantages as well (e.x. jails). SVG, PDF, and EPUB cannot be replaced by postscript. I mean, come on, you say you want security, and then you advocate an image standard that's TURING COMPLETE, effectively giving any image the capability to crash your computer, or inject code, if there's a flaw in your postscript implementation.
I used to think that cat-v was somewhat satire, but it really didn't seem that way, once I'd read what people were saying on it. And that is really sad, IMHO.
However, most of your objections down-thread are "People are used to X/Y/Z, it is literally impossible to change them now."
QNX lets you make anything look like a file, by writing what QNX calls a "resource manager". This takes over a subtree of the pathname space, and the library turns create, open, close, read, write, and ioctl calls into the appropriate MsgSend calls. That's how you write a file system under QNX as a user process. But there's no reason to turn things into files unnecessarily. Displays are not files, for example.
QNX has what looks like a Berkeley sockets interface, but "send" and "recv" call the same thing as "write" and "read". You can use read and write on a socket. I think you can use "send" and "recv" on a file system, too.
If you're going to have one primitive, MsgSend and MsgRecv are a better choice than files. But it's easy to get that wrong. Mach botched it, and for decades, microkernels had a bad rep.
IIRC there were some license issues.
> I'd like to see a QNX-like OS in Rust.
Hm... now that would be an interesting 'side project'.
So it wasn't free software? It was proprietary?