Why did Apple's Copland fail when so many 90s OS succeed, dominate world today(liam-on-linux.livejournal.com)
liam-on-linux.livejournal.com
Why did Apple's Copland fail when so many 90s OS succeed, dominate world today
https://liam-on-linux.livejournal.com/60604.html
151 comments
Is the premise correct? Almost all 1990s OS projects ultimately failed. Cairo, Taligent, Copland, BeOS. The projects that survived were 1970's/1980's technology: NeXT Step (OS X), Linux, Windows NT.
Don't forget Symbian, probably the last successful operating system designed from scratch.
It started life as EPOC32, the operating system for "palmtop" devices made by UK-based Psion in the mid-90s; then Nokia and Ericsson decided they needed a smartphone OS that isn't Microsoft and bought into EPOC creating Symbian sometime around 1998. It took a while for Symbian to get off the ground because the hardware wasn't there yet and the partners kept bickering, but by 2006 it was shipping on a hundred million devices and was perceived as very successful against Microsoft's Windows Mobile. A few years later, Symbian would be trounced to oblivion by iOS and Android.
The interesting thing about Symbian was that it had a rich native framework but wasn't even close to POSIX or Windows. You didn't even get the C standard library; instead the system was built on an idiosyncratic embedded-centric dialect of '90s C++. This focus on optimization at expense of programmer convenience turned out to be a total dead-end once PC-style operating systems became viable on phones — but at least it made for a distinctive development experience.
It started life as EPOC32, the operating system for "palmtop" devices made by UK-based Psion in the mid-90s; then Nokia and Ericsson decided they needed a smartphone OS that isn't Microsoft and bought into EPOC creating Symbian sometime around 1998. It took a while for Symbian to get off the ground because the hardware wasn't there yet and the partners kept bickering, but by 2006 it was shipping on a hundred million devices and was perceived as very successful against Microsoft's Windows Mobile. A few years later, Symbian would be trounced to oblivion by iOS and Android.
The interesting thing about Symbian was that it had a rich native framework but wasn't even close to POSIX or Windows. You didn't even get the C standard library; instead the system was built on an idiosyncratic embedded-centric dialect of '90s C++. This focus on optimization at expense of programmer convenience turned out to be a total dead-end once PC-style operating systems became viable on phones — but at least it made for a distinctive development experience.
And of course finally it went FOSS: https://github.com/SymbianSource
I'm surprised nobody has even attempted to pick it up, AFAICT. A very good OS in its day.
I'm surprised nobody has even attempted to pick it up, AFAICT. A very good OS in its day.
[deleted]
I miss WebOS
It's open-source on an OpenEmbedded base, shipping in LG TVs.
http://webosose.org/develop/architecture/
http://webosose.org/develop/architecture/
Webos is just linux with specific wm.
The story of GEOS is quote interesting too. From 8bit OS for c64 in mid 80ies to powering Nokia Communicator and a bunch of random Japanese products in mid/2nd half 90ies.
No, it's not on multiple fronts. Copland failed internally before it ever hit the market (i.e. it was never generally released.) Sure, the NeXT acquisition was the final nail in the coffin for it, but it had failed long before that. Part of the reason for the NeXT acquisition was that Copland was such a mess. It could be argued whether NeXT or Be was the better option, but Apple desperately needed to buy an OS... because Apple didn't have something that was going to ship.
>It could be argued whether NeXT or Be was the better option,
I think a lot of people start mashing years together when it comes to BeOS. Apple announced the NeXT acquisition in December 1996.
In December 1996, BeOS was still a developer preview with the first "real" release still about two years away. NeXTStep was already 8 years old.
In 1996 BeOS was at a completely different state of readiness and maturity than it was with R5 (which everyone remembers fondly).
USENET is full of posts, 96-98, of individual developers announcing with triumph the porting of UNIX core utilities to the BeOS developer release versions-- utilities that were already present and mature in NeXT/Openstep.
Mac OS X Server 1.0 was released about two years after the deal was finalized and I imagine it would have taken about two years of really hard work just to make BeOS multiuser, nevermind porting all of the core utilities.
It took a couple more years (it was a somewhat jerky transition for many users) before a "usable" OS X was released but from the beginning there was an wide variety of software available for it that was easily ported from NS/OS, and features like Display Postscript, Objective-C, a mature set of APIs, and most importantly of all Project Builder were there from the beginning.
The software scene on BeOS in 1996 was... sparse.
I think a lot of people start mashing years together when it comes to BeOS. Apple announced the NeXT acquisition in December 1996.
In December 1996, BeOS was still a developer preview with the first "real" release still about two years away. NeXTStep was already 8 years old.
In 1996 BeOS was at a completely different state of readiness and maturity than it was with R5 (which everyone remembers fondly).
USENET is full of posts, 96-98, of individual developers announcing with triumph the porting of UNIX core utilities to the BeOS developer release versions-- utilities that were already present and mature in NeXT/Openstep.
Mac OS X Server 1.0 was released about two years after the deal was finalized and I imagine it would have taken about two years of really hard work just to make BeOS multiuser, nevermind porting all of the core utilities.
It took a couple more years (it was a somewhat jerky transition for many users) before a "usable" OS X was released but from the beginning there was an wide variety of software available for it that was easily ported from NS/OS, and features like Display Postscript, Objective-C, a mature set of APIs, and most importantly of all Project Builder were there from the beginning.
The software scene on BeOS in 1996 was... sparse.
In 1996 Mac users were far more familiar with BeOS than NeXTSTEP. Even though it was a developer release, Be was marketing heavily to Mac users (like giving away free CDs) and BeOS could run on Macs so Mac users could try it side-by-side with MacOS and form firsthand impressions. (I was triple-booting MacOS, BeOS, and Linux on my Power Mac with a bunch of Jaz carts.) Meanwhile NeXTSTEP was expensive and ran on expensive non-Mac hardware.
BeOS was also optimized (probably over-optimized) for first impressions; the immaturity and architectural mistakes were hidden behind a facade of "OMG it's so fast and pretty". The BeOS GUI with its cartoony 32x32 icons was also a lot closer to MacOS than NeXTSTEP with it's huge high-DPI GUI, so BeOS looked like "Mac done right" while NeXT was a foreign culture.
So yeah, NeXT was better but most Mac users had no way of knowing that at the time.
BeOS was also optimized (probably over-optimized) for first impressions; the immaturity and architectural mistakes were hidden behind a facade of "OMG it's so fast and pretty". The BeOS GUI with its cartoony 32x32 icons was also a lot closer to MacOS than NeXTSTEP with it's huge high-DPI GUI, so BeOS looked like "Mac done right" while NeXT was a foreign culture.
So yeah, NeXT was better but most Mac users had no way of knowing that at the time.
Agree with everything you said and NeXT was the right call (even sans Jobs). Apple needed mature ecosystem, libraries, etc, not just a base OS.
However, BeOS was far more stable/mature than its 'developer release' status implied. I remember how blown away people were at the dev release in 1996 by how solid it was, not just by how forward thinking its features were.
I don't think multiuser would have been a showstopper for release if BeOS was acquired by Apple. They could have put out 2-3 versions of a single user OS and few would have cared.
However, BeOS was far more stable/mature than its 'developer release' status implied. I remember how blown away people were at the dev release in 1996 by how solid it was, not just by how forward thinking its features were.
I don't think multiuser would have been a showstopper for release if BeOS was acquired by Apple. They could have put out 2-3 versions of a single user OS and few would have cared.
something I have been wondering about for years, having been around: was Be actually acquisition bait from day one for Apple? I am convinced that NeXT wasn't; they just didn't build something that was designed for acquisition.
But Be, Inc. and BeOS really strike me as the kind of design, company, compromises, focus and leadership/team that I've come to associate with startups that are actually designed to be acquired by the executive's former employer after some time.
I would love to know if this is true, though in my experience, that is usually only known to the founders and executives except in the really obvious cases.
But Be, Inc. and BeOS really strike me as the kind of design, company, compromises, focus and leadership/team that I've come to associate with startups that are actually designed to be acquired by the executive's former employer after some time.
I would love to know if this is true, though in my experience, that is usually only known to the founders and executives except in the really obvious cases.
It was started by a former apple executive Jean-Louis Gassee [1]. At apple he said he wanted a kernel on macOS[2]. When he started BE they did develop their own hardware (BE Box). They eventually decided to port it other hardware (hardware is expensive). Microsoft had a strangle hold on most PC manufacturers and the BEbox was power PC so it made sense to try to get Mac clones to use it (There was a brief period in the 90s where apple clones existed.). I got a disk and tried it on a "Power computing" mac clone. It was kinda amazing compared to macos8. But the lack of software made it hard day to day.
[1]https://en.wikipedia.org/wiki/Jean-Louis_Gassée
[2] https://mondaynote.com/50-years-in-tech-part-11-getting-the-...
https://en.wikipedia.org/wiki/BeBox
[1]https://en.wikipedia.org/wiki/Jean-Louis_Gassée
[2] https://mondaynote.com/50-years-in-tech-part-11-getting-the-...
https://en.wikipedia.org/wiki/BeBox
I'm aware of all that history. The part I'm asking about is whether his exit plan was Apple and when that exit plan went with the other option the company was not viable.
This is very common for "startups" founded by executives who come from a company they know is failing to execute on something critical.
Be smells like this.
This is very common for "startups" founded by executives who come from a company they know is failing to execute on something critical.
Be smells like this.
One wonders, what if someone else had bought Be?
Someone did: PalmSource (the software spinoff from Palm). It was to be the basis for their Palm OS “Cobalt”, which was eventually abandoned.
Or by “someone else”, did you mean someone other than PalmSource?
Let’s be honest, though: most new OSes don’t enjoy much success or longevity. The only successful new arrival I can remember recently was Android, and it had the backing of Google, and was aimed at a relatively new market. It also borrowed heavily from established tech: Linux kernel, JDK and JVM.
I doubt there’s more than a handful companies that could have turned BeOS into something big, and of those, Apple was probably their best bet.
Or by “someone else”, did you mean someone other than PalmSource?
Let’s be honest, though: most new OSes don’t enjoy much success or longevity. The only successful new arrival I can remember recently was Android, and it had the backing of Google, and was aimed at a relatively new market. It also borrowed heavily from established tech: Linux kernel, JDK and JVM.
I doubt there’s more than a handful companies that could have turned BeOS into something big, and of those, Apple was probably their best bet.
Someone who actually had a chance to do something with BeOS, and of sticking around for longer than a few years.
Minor notes:
* BeOS was evaluated by Apple as a Copland replacement (along with Solaris, NT, and NeXTSTEP).
* MacOS X discarded DPS for Quartz so it didn't turn out to be much of a feature. But very few applications touched that directly so it wasn't much of a porting issue.
* There was more UNIX and AppKit-based software available for NeXTSTEP than for BeOS but nobody in the Mac world cared about that. Quark were the only company that really blew the transition, but they blew it badly.
* BeOS was evaluated by Apple as a Copland replacement (along with Solaris, NT, and NeXTSTEP).
* MacOS X discarded DPS for Quartz so it didn't turn out to be much of a feature. But very few applications touched that directly so it wasn't much of a porting issue.
* There was more UNIX and AppKit-based software available for NeXTSTEP than for BeOS but nobody in the Mac world cared about that. Quark were the only company that really blew the transition, but they blew it badly.
Preceded by Apple's late-80s failure with the "Pink" OS:
http://lowendmac.com/2014/pink-apples-first-stab-at-a-modern...
http://lowendmac.com/2014/pink-apples-first-stab-at-a-modern...
It wasn't actually proceeded by Pink. Copland and Pink were going on in parallel, and the competition between them (and the original MacOS folks as well) was intense. Pink was the first to lose that battle, and got spun out as a result.
Source: I worked on Pink/Taligent for six years. Prior to that I supported A/UX and MPW in MacDTS.
Source: I worked on Pink/Taligent for six years. Prior to that I supported A/UX and MPW in MacDTS.
The most amazing story of the 90s was the incredible ball of failure that was Taligent. It's almost impossible to even describe to people the situation around it and get them to understand how crazy the world went for a time. Taligent (and OO, to an extent) was the industry's equivalent to the satanic ritual abuse panic - it dominated the conversation for a brief time but was then solidly forgotten, no one really mentions it, and when you try to tell people born later they don't really believe you.
I agree that the OO hype at the time was crazy, and I was extremely guilty of that mania at the time. But from my POV (as a Pink/Taligent employee) the failures of Taligent had little to do with that. It was much more a problem of constantly moving goalposts (we're an OS! Now we're an OS and a layer on top of AIX! Now we're going to be an optional window manager for AIX!) and vicious politics.
I think that, if we're talking about Taligent itself, that's probably true. I've talked to other Taligenters and they say the last bit in particular.
But the books, the books were straight up crazy and people reacted to them in the same unfortunate way that they reacted to "Design Patterns."
Another of the crazy OS companies that deserves mention on the list of failures is both the Newton and Magic Cap.
But the books, the books were straight up crazy and people reacted to them in the same unfortunate way that they reacted to "Design Patterns."
Another of the crazy OS companies that deserves mention on the list of failures is both the Newton and Magic Cap.
Also, even though Taligent was a monumental disaster, it wasn't all bad. There is a lot of stuff you use every day that came directly out of Taligent's work. For instance, the i18n libraries for Java and ICU (http://site.icu-project.org/design/cpp) were early important work. A lot of unicode came from Taligent's work (but not all of it), and the President of the Unicode Consortium, Mark Davis, did a lot of the formative work at Taligent. So at the end of the day you can thank (or blame) Taligent for emojis.
Taligent also had quite a bit of influence on the field of unit testing, which I'm proud to have had a hand in. I've written about this in the past: https://shebanator.com/2007/08/21/a-brief-history-of-test-fr...
Taligent also had quite a bit of influence on the field of unit testing, which I'm proud to have had a hand in. I've written about this in the past: https://shebanator.com/2007/08/21/a-brief-history-of-test-fr...
It is true that many good things come out of failures. There's a lot of value in trying and _not_ succeeding.
I'm a bit of a student of failure. If we want to really dive into deep failure, someone mentioned Workplace OS, which was not just a terrible project but a terrible idea (in the same way that NT's original concept of multiple-OS-personalities was wrt: OS/2 16 bit, for example, and POSIX, just taken to an entirely more crazy level).
For truly fun crazy, one has to step away from OS projects to things like graphics (for example, Fahrenheit and Talisman).
I'm a bit of a student of failure. If we want to really dive into deep failure, someone mentioned Workplace OS, which was not just a terrible project but a terrible idea (in the same way that NT's original concept of multiple-OS-personalities was wrt: OS/2 16 bit, for example, and POSIX, just taken to an entirely more crazy level).
For truly fun crazy, one has to step away from OS projects to things like graphics (for example, Fahrenheit and Talisman).
I wrote one of those books, specifically "The Power of Frameworks". Like I said, I was definitely deep in the hype cycle at the time.
https://www.amazon.com/Power-Frameworks-Windows-Os/dp/020148...
https://www.amazon.com/Power-Frameworks-Windows-Os/dp/020148...
Taligent and OO frameworks in general had a massive impact of hype/unreality across the industry that spread to other other desktop or networked OO technologies, such as OpenDoc, CORBA, and WS-*. COM/DCOM/COM+ and OLE got caught in this and mostly succeeded in its niche but remained terrible complicated.
There was also IBM's SOM (System Object Model), used extensively in OS/2. SOM/DSOM was inspired by CORBA, just like COM. All of them uses an IDL and are based on querying for supported interfaces, which is a very powerful mechanism.
They all died except COM, which remains the basis for most APIs that Microsoft release these days (even after a brief stumble with .NET where they, if I remember correctly, they tried to kill COM). It's a great technology, and it's a shame that Microsoft didn't open it up and turn it into a truly cross-platform technology.
What didn't take over the world was this notion of object-oriented documents, which was what OpenDoc and Taligent were all about. This idea that content came with behaviour; you could embed an object from one app into another, e.g. a piece of an Excel table into a Word document, and the table would be live-updateable within Word, with all your interactions basically going between processes as COM calls, with the OO behaviour following the embedded content as it moved around, even when copy-pasted between documents. Very powerful, but super brittle. I used embedding a lot in the 1990s, trying to achieve what the PR told me should be feasible and easy, but it invariably ended with app crashes.
They all died except COM, which remains the basis for most APIs that Microsoft release these days (even after a brief stumble with .NET where they, if I remember correctly, they tried to kill COM). It's a great technology, and it's a shame that Microsoft didn't open it up and turn it into a truly cross-platform technology.
What didn't take over the world was this notion of object-oriented documents, which was what OpenDoc and Taligent were all about. This idea that content came with behaviour; you could embed an object from one app into another, e.g. a piece of an Excel table into a Word document, and the table would be live-updateable within Word, with all your interactions basically going between processes as COM calls, with the OO behaviour following the embedded content as it moved around, even when copy-pasted between documents. Very powerful, but super brittle. I used embedding a lot in the 1990s, trying to achieve what the PR told me should be feasible and easy, but it invariably ended with app crashes.
It turns out that hyperlinking / embedding shouldn’t involve you giving your memory address space to someone else - who knew :)
And really, the web/REST wound up being the object oriented document framework we were all looking for. It was terribly inefficient at first (and is still) but was architecturally simpler. The main issue is no one thought it would be possible to replace Windows with a cross platform GUI, and no one thought hypertext/hypermedia - a mostly academic concept at the time beyond HyperCard - would be that GUI.
https://www.slideshare.net/StuC/oopsla-2007-the-web-distribu...
And really, the web/REST wound up being the object oriented document framework we were all looking for. It was terribly inefficient at first (and is still) but was architecturally simpler. The main issue is no one thought it would be possible to replace Windows with a cross platform GUI, and no one thought hypertext/hypermedia - a mostly academic concept at the time beyond HyperCard - would be that GUI.
https://www.slideshare.net/StuC/oopsla-2007-the-web-distribu...
Right — as I remember, if you embedded an Excel object into Word, the Excel part was implemented in a DLL that loaded directly into the Word process space. This would have been so much more stable if it instead started a headless Excel server process. With DCOM, this kind of cross-process COM worked great, but that came much later. OLE 1.0 preceded COM by several years.
They didn’t die. CFPlugin in Core Foundation that runs on every iPhone and Mac is an implementation of COM
"They all died except COM".
And I would argue they CFPlugin is only really inspired by COM, it's not the real thing. It's just IUnknown and the same class layout:
> The CFPlugIn model is compatible with the basics of Microsoft's COM architecture. What this means is that CFPlugIn Interfaces are laid out according to the COM guidelines and that all Interfaces must inherit from COM's IUnknown Interface. These are the only things that CFPlugIn shares with COM. Other COM concepts such as the IClassFactory Interface, aggregation, out-of-process servers, the Windows registry, etc... are not mapped.
http://mirror.informatimago.com/next/developer.apple.com/doc...
And I would argue they CFPlugin is only really inspired by COM, it's not the real thing. It's just IUnknown and the same class layout:
> The CFPlugIn model is compatible with the basics of Microsoft's COM architecture. What this means is that CFPlugIn Interfaces are laid out according to the COM guidelines and that all Interfaces must inherit from COM's IUnknown Interface. These are the only things that CFPlugIn shares with COM. Other COM concepts such as the IClassFactory Interface, aggregation, out-of-process servers, the Windows registry, etc... are not mapped.
http://mirror.informatimago.com/next/developer.apple.com/doc...
It isn't fair to blame Taligent for that hype. Several of these systems existed before Pink/Taligent project was ever discussed publicly. Heck, we used to talk about how our stuff was better than COM and CORBA all the time.
And OpenDoc was developed more or less simultaneously with Pink IIRC. But its been a long time and I never worked on OpenDoc so I might have the timing off a bit on this one.
And OpenDoc was developed more or less simultaneously with Pink IIRC. But its been a long time and I never worked on OpenDoc so I might have the timing off a bit on this one.
That is a great metaphor for how important things like Taligent seemed at the time, which is hard to imagine now. Does anyone remember the Newton OS? It was very strange and still kind of visionary. There were all these bold ideas for operating systems and we kind of settled on Unix with a GUI layer or VAX with a GUI layer. That was good enough.
Add one onto the early-'90s failure list: IBM Workplace OS. Rarely mentioned these days for some reason, but a hugely hyped and super-expensive complete failure.
From the Wikipedia page https://en.wikipedia.org/wiki/Workplace_OS: A University of California case study described the Workplace OS project as "one of the most significant operating systems software investments of all time" and "one of the largest operating system failures in modern times".
From the Wikipedia page https://en.wikipedia.org/wiki/Workplace_OS: A University of California case study described the Workplace OS project as "one of the most significant operating systems software investments of all time" and "one of the largest operating system failures in modern times".
Linux was started in 1991, so it really belongs in the BeOS era. But Linux isn't an apples-to-apples comparison. It's success followed the rise of the internet, and the resulting huge demand for a free server OS. No commercial vendors were providing that.
The other OS's you mentioned are all Desktop OS's, and that market was already buttoned up by the 90s, as it largely still is today. They were up against much steeper odds.
The other OS's you mentioned are all Desktop OS's, and that market was already buttoned up by the 90s, as it largely still is today. They were up against much steeper odds.
Linux is a kernel though, not an operating system. I don’t care at all for the GNU/Linux debate but it is of course important not to take the start of one part as the start of the whole thing.
It was built on solid foundations however.
The OS part, the GNU userland, was written before the 90s. The kernel was just the missing piece that made it all work on a 386 desktop that were rising in popularity at the time.
It's interesting how the gnu project narrative of "we did all the work, the kernel was 'just the missing piece'" has propagated.
The gnu project worked on a kernel - Hurd. It has been "in active development" since 1990. It's "just the missing piece."
The gnu project worked on a kernel - Hurd. It has been "in active development" since 1990. It's "just the missing piece."
Hurd was a microkernel that was a genuine attempt at something new. Linux’s monolithic design was very safe, very 70’s/80’s, and was criticized by everyone for not being a serious 90’s microkernel design.
This was covered extensively over 25 years ago, including the classic comment by Linus that "In fact the /whole/ linux kernel is much smaller than the 386-dependent
things in [the existing microkernel] mach". https://www.oreilly.com/openbook/opensources/book/appa.html
Mach and Hurd were existing microkernels/projects before Linux development began.
Linux dominated because it (partly) worked and was accessible and a community formed around it. Hurd had none of those. It's the canonical proof of Richard Gabriel's prescient "Worse is Better (1991)"
Mach and Hurd were existing microkernels/projects before Linux development began.
Linux dominated because it (partly) worked and was accessible and a community formed around it. Hurd had none of those. It's the canonical proof of Richard Gabriel's prescient "Worse is Better (1991)"