Slashdot Mirror
NeXTSTEP To Mac OS X
*no comment* writes "the folks over at OSviews have a nicely done article that explains the evolution of NeXTSTEP into Mac OS X. 'With the beginning of 1996, Apple realized that with the next generation PC's running Windows NT to be released within the decade, they would need a new, modern operating system to run on their machines. ... Amongst Apple's other options were to license Solaris from Sun, NT from Microsoft, or to purchase a small net services company called NeXT. Apple chose the latter.'" OSNews had another nice Mac-oriented look at NeXTSTEP last year; the Wikipedia entry is also worth looking through.
For awhile I was in search of the x86 version of Apple's Rhapsody DR2. Finally after speaking to a guy who created a page of screenshots, I found a beta software trading forum and grabbed an ISO of it. This guy also has screenshots of OpenStep too.. He's been running this site for years and its given me quite a nice look into the past. Its interesting never the less :)
Proceed with Format (Y/N)? Y
And of course, the choice of NeXTStep had nothing to do with Next also being owned by Steve Jobs!
"Freedom means freedom for everybody" -- Dick Cheney
Amongst Apple's other options were to license (-- --) NT from Microsoft
Ouch. The thought alone makes me vomit...
“Wait for Hurd if you want something real” –Linus
While I am a huge fan of MacOS X, I wonder what would have happened if they bought Be and used their cash to evolve it instead of ressurecting NeXT?
.02
It's true that Apple currently employs several key Be developers, but I think the Mac platform would eb even further ahead if they went with Be.
Just my
They fail to mention that NeXT was the company set up by Steve Jobs after he left apple, with the mission to produce a next-generation Mac-like workstation with an OS called NeXTstep, based on mach, BSD and display Postscript
The blurb is not quite complete. Apple decided it did not have time to develop a next-generation operating system. Copland was pretty much dead in the water.
At the time, also available was the BeOS. A lot of Mac die-hards at the time, myself included, thought that Apple purchasing Be and using that would make the most sense.
From my memory, I seem to remember that Be wanted more money than Apple was willing to spend. It could have also had something to do with the fact that the head of Be, Jean Louis Gassée, was a former Apple man and there was probably some politics there. In addition, NeXT had Steve Jobs and all the personality that went along with that.
I would be interested in reading some of the discussions that went along with passing up Be in favor of NeXT.
It would be interesting reading to see what might have developed out of a Macintosh + Be combination (as opposed to the Macintosh + NeXT we have now).
- (c) 2018 Hank Zimmerman
and found this which looked to be fairly indepth about the history of the Mac OS, including some information on what was taken from what and went into what.
BeOS was a nonstarter.
The printing was horrid.
The development environment was awful, contrasted to the robust tools available on NeXTSTEP at the time.
NeXT had real mult-user capability. BeOS was only brought in as a bargaining chip and to entice Jobs to come onboard. BeOS at the time was really impressive on a Mac, especially if you couldn't stomach MacOS... but I ran BeOS @work and NeXTSTEP @home, the choice was readily apparent to people who actually used both systems.
--- I do not moderate.
By 1996 WebObjects was pretty much all NeXT had left after sales of NeXT and NeXT systems had plummeted to vitually nil.
I first used NeXTStep in about 1989, when NeXT was still a hardware company.
NeXT made a big splash in the trade magazines by using standard UNIX industry hardware like the 680x0 processor, standard RAM, SCSI drives, etc. They did some neat stuff like having a 600M rewritable optical disk, unheard of capacity at the time. Unfortunately, no one else followed suit.
The big thing was the apps, though. Everything was done in Postscript, and there were several desktop publishing applications. As a math student at the time, Mathematica made my jaw drop. I figured out how to use it under ASCII mode via dialup, and checked all my homework that way.
The programming environment was interesting, though I never really delved into it. Underneath (or beside) the pretty GUI there was a 4.3BSD system with a Mach kernel. I was mostly interested in this compiler they had for it, gcc. They wanted you to copy it! And hunting around the ftp sites I found this new scripting language, perl, that was really great.
Too bad stuff like that will never catch on.
sigs, as if you care.
Maybe I just saw that in a style guide or something. My, this is some good crow.
Bottom line: Going NeXT saved Apple by getting Steve Jobs back and getting OS X based on Unix BSD. Steve Jobs might be a crazy man, a meglomaniac, whatever, but he has vision and taste and the drive to force others to follow his vision. The interregnum of Sculley et al was consumed with internal fighting and a zillion product teams smashing each other.
Also, the move to NeXT helped Apple acquire OS rock-solid stability and the Alpha Geek population, as O'Reilly puts it. So now, even though market share is sitting around 5%, OS X is still guaranteed lots of cool stuff.
And finally Tiger is going to start pulling in some of those BeOS metadata ideas...
Did apple *choose* Next, or did Steve Jobs simply decree it? Were apple engineers involved in this 'choice'?
Remember who Jobs was working for - NeXT. A Jobsian decree didn't mean anything at all at Apple in those days - the company was in the (in)capable hands of Gil Amelio. It wasn't until after the NeXT purchase that Jobs managed to oust Amelio, and assume the role of 'iCEO'.
And tomorrow the stock exchange will be the human race
...was that JLG kept jacking up the price. He saw that Apple was running out of time and options, and thought that Be was the only viable option for Apple at that point. I think that his attitude left Gil Amelio and the rest of the Apple board cold.
Of course, Apple spent far more to acquire NeXT, but they got Steve Jobs along with it, which was easily worth as much as the operating system.
Can you imagine JLG as Apple CEO, trying to push fruity-colored iMacs? It just wouldn't have happened...
Forgot to post the link - clicky here
And tomorrow the stock exchange will be the human race
Now that Cocoa is finally getting its just dues how long before we see replacements to these Gorillas? They didn't want to invest in Cocoa programming then, but now six years later will they have taken the time to find the talent to do it now? Hard to tell but these are my predictions.
If they don't they'll be left behind. Adobe sees it by Apple entering into the market with better products.
Macromedia sees it but lets see if they really see it.
Quark seems to be the most cautious and I'm guessing they'll hedge their bets and have invested in such talent already.
Microsoft? Never. They'll figure that Office will always guarantee them supremacy in the platform. Then again I'm sure they'll be quite pissed if Apple releases a compatible Office suite worthy of knocking off Office. Afterall, XML is the measure of compatibility on all future Office suites.
The last section is obviously just conjecture but conjecture with history.Ever since that article was linked to on Slashdot, there have been numerous vandalisms by Slashdot trolls and revisions to the previous version.
The link actually goes to a page that redirects you to the real article. When I went there, someone had vandalised the redirection page to be just blank. I was initially confused, realized that it was a vandalism, and when I went to revert it, I found that in those few seconds someone else had already done it.
So although the increased traffic is resulting in more vandalism, it's also resulting in more oversight, so it all evens out in the end.
It's amusing to look at the history and see what various vandalisms were done. There's a lot of typical Slashdot trolls, so it's obvious a lot of vandals are Slashdot users.
This is for 99% Magnesium, alloys may take a higher temp to reach point of auto-ignition
t m
http://www.jtbaker.com/msds/englishhtml/m0088.h
Fire:
Autoignition temperature: 473C (883F)
When heated in air to a temperature near its melting point, magnesium may ignite and burn. Dangerous in the form of dust or flakes, and when exposed to flame or by violent chemical reaction with oxidizing agents. Magnesium may react with moisture or acids to evolve hydrogen gas, which is a highly dangerous fire or explosion hazard.
Autoignition temperature is for Magnesium turnings or ribbon.
Explosion:
Fine dust dispersed in air in sufficient concentrations, and in the presence of an ignition source is a potential dust explosion hazard. Minimum explosible concentration 0.030 grams/liter. Water used on molten magnesium will produce hydrogen gas and may cause an explosion.
Fire Extinguishing Media:
Use metal extinguishing powders such as G-1® graphite powder, Met-L-X® powder, powdered talc, dry graphite, powdered sodium chloride, soda ash, or dry sand. Warning! Do not use foam, chlorinated products such as Halon®, carbon dioxide, or water to extinguish magnesium fires, because dangerous reactions will occur. Use of water on molten magnesium will produce hydrogen gas and may cause an explosion.
Special Information:
In the event of a fire, wear full protective clothing and NIOSH-approved self-contained breathing apparatus with full facepiece operated in the pressure demand or other positive pressure mode. Fire fighters should protect their eyes and skin from flying particles. In order to prevent eye injury, do not look directly at magnesium fires.
Wherever You Go, There You Are
For the x86 freaks, your only hope for an Apple menu on a bare metal x86
w _I n_DR2.html
They're making headway - mine runs.
http://www.rhapsody-project.tk/
A VERY cool resource.
http://www.shawcomputing.net/
Stone
http://www.stone.com/dev/StonesThrow21/Whats_Ne
~hylas
I can't let this topic go without a mention...
http://www.gnustep.org
Please take a look!
Thanks, GJC
Gregory Casamento
## Chief Maintainer for GNUstep
Woz: "Gil Amelio meets Steve Jobs. Game Over."
I am probably one of the few people who prefered NeXTStep to Mac OS X. Some of the (IMHO) reasons:
-the user interface was better
-file management was better
-Digital Webster
-no bar fixed across the top of the screen
Excited by old articles in Byte magazine, I bought a used NeXT Mono-Station from Sam Goldberger, who ran a company called Spherical Solutions. It ran great and I loved it. But when I wanted to buy a copy of Openstep 4 for my PC, NeXT wanted somewhere in the neighborhood of $900.00 for it. I think that had a lot to do with NeXT's inability to compete in the PC market.
Today, I run a PowerMac G4 with Mac OS X 1.3.6.
It wasn't Jobs' decision. It was Gil Amelio's decision. Jobs was running NeXT, and came as a free pack-in with the company.
You think Gassee could have revolutionized Apple? No chance. Period. Apple would be dead.
Why yes, I AM a rocket scientist!
Yeah, I think my Mac'd really be improved by not being able to print, run multi-user, or have a working TCP/IP stack. Be was never even close to technically polished enough to be a realistic replacement for Copland.
To spur "enterprise Linux," Big Bang, the distributed two-phase commit.
You mean like this? Or perhaps maybe more like this?
Knowledge is power. Knowledge shared is power multiplied.
For info about the evolution of NextStep to OS X, the Mac OS X history article is also worth reading.
http://alternatives.rzero.com/
I was Gassee's fault that the deal didn't go through anyways. He asked for WAY too much money. Apple priced Be at about $200 million, even though they were worth much less, but Gassee was asked half a billion. His pride ended up shooting him in the foot.
'With the beginning of 1996, Apple realized that with the next generation PC's running Windows NT to be released within the decade, they would need a new, modern operating system ...
They should have realized this back in the late 80's. 1996 was far too late. Apple was already relegated to a niche market by then.
the person who posted that didn't make his homeworks too, so it's redundant in a recursive way...
I'm a chainsmokin' alcoholic sociopath, so-ci-o-path
Red was basically anything too advanced for pink.
The only thing that was really physical that you could call red was 'Raptor', a future Mac OS that was being developed to run on any hardware on the planet. Not to be confused with "Star Trek" which was an attempted port of Mac OS to x86 architecture (which did quite well given the circumstances).
I think they were going to merge the two and just use some of the Star Trek codebase to keep working on Raptor but the dino bit the dust sometime in the 90's. Probably some whining about 'exorbitant costs' and the company 'bleeding red ink everywhere' - pfft! Weaklings!
The CEO of Apple then was Gil Amelio. The decision was made by him not by Jobs. Jobs sure persuaded Amelio to buy NeXT, but he was not a part of Apple at that time. Jobs was brought to Apple as a part of the deal.
A little off topic, but related nonetheless. Does anyone have any links to pictures and perhaps even step by steps of a complete teardown of one of these? I've seen the TurboStations .... they are very similar to a same year model Sun Pizza box. Layout and all of my SparcStation 5 is very close (not cookie cutter mind you, but still you can see that the inspiration was there)
These cubes are so huge ... 12" by 12" ... compared to a similar Pizza box. In fact it looks like you could have two Mainboards in a Cube? How many drives did this thing hold? What's the internal chassis look like? I'm curious to know, but don't have a lot money (shipping a computer that size/weight is enormous) to spend to just strip the thing with no intention of ever actually using it. (I have 6 various Sparc machines, none Ultra, that just sit around already)
Thanks in advance for any info.
"Genius may shine aloof and alone, like a star, but goodness is social, and it takes two men and God to make a Brother."
It was designed and prototyped shortly before they stopped making hardware (in 1993), so it never shipped.
The head designer was Jon Rubenstein, who left NeXT at that point. He (and, I think, others from the hardware group) went on designing dual-processor PPC systems. First they had a company called FirePower. That was bought by Motorola, I think.
When Apple bought NeXT, Rubenstein came on board to run hardware. Because he'd kept working on dual-processor systems after leaving NeXT, his SMP-fu wasn't stale.
So, basically, on the hardware side, NeXT vs. Be was a wash.
NT's underlying kernel and architecture is considered one of the most advanced and stable out there. If you hate the crap on top of it, fine. But VMS and its descendent NT are arguably better kernels than Linux has turned out to be (so far).
But I guess whatever it takes to get you karma on Slashdot.
Its amazingly fast, crisp, clean. I run two OPENSTEP Athlon machines and a NeXTstation TurboColor mainly for printing PostScript. NeXT printers run the paper straight through rather than around rollers making it possible to print on heavy paper, cardboard and even plastic sheets.
I do a lot of graphics work using WetPaint and Virtuoso. For some reason I'm always able to get a lot more work done each day on OPENSTEP than on a Windows machine which unforuntaly I still need to run for certain tasks.
Windows XP is a sloppy, bloated cluttered POS OS, can't even hold a candle to an 11 year old OS from NeXT!
As Much as I would love to purchase your Cube, I am no where near CO, but in IN and the shipping would be most prohibitive. However:
Black Hole, Incorporated
3007 Conestoga Ct.
Fort Collins, CO 80526
970-223-9976 Phone
970-223-9975 Fax
President: Rob Blessin
Black Hole is a company located in CO that deals with NeXT equipment and acts as a reseller of used machines and other NeXT items including printers.
Note: This post in no way is meant as an advertisement for Black Hole, Inc. I am not affiliated, nor have I ever actually had business dealing with, the mentioned company.
Just thought the info might come in handy. Though, if you don't think the shipping would be *too* bad, or if you happen to have any *dead* cubes. I'd be interested in an email.
"Genius may shine aloof and alone, like a star, but goodness is social, and it takes two men and God to make a Brother."
If the Copland project (aka the real Mac OS 8) hadn't floundered like a beached whale, it wouldn't have left Apple in the desperate position of needing to buy a new OS foundation.
That means, they wouldn't have had to buy either Be or NeXT, which would have meant no Mr Steve Jobs. Even the non-fanboy audience here wouldn't question that it was his vision guiding Apple into an undisputed innovator in the "OS-with-power-AND-style" and "digital lifestyle" arenas (despite having negligible marketshare) that has truly saved Apple from extinction (for the moment).
If Copland HAD worked out, Apple might have kicked around for a few years as a viable alternative to Windows 95/98/NT for loyal Apple supporters, but ultimately the onset of very cheap PC hardware and a genuinely superior NT-based OS would have pummeled them into powder.
(BTW, hold the flames: I'm saying NT was superior to the nuKernel of Copland, not to modern Mac OS X, which I'm sure hands NT's ass to it on a plate when it comes to things like multitasking.)So... as I see it, Copland's failure saved Apple!
NeXT built Dell's first web store for them (for the princely sum of $100,000 I believe, though now I doubt Michael Dell would even buy a car worth less than that).
Of course, once NeXT was subsumed by Apple, the WebObjects store had to be replaced for political reasons, at a much higher cost.
I think the biggest reason why Apple's Copland project failed was that it was essentially re-inventing the wheel of the type of memory management UNIX and Windows NT did.
(By the way, people forget that Dave Cutler--who spearheaded the Windows NT project back in the late 1980's and early 1990's--essentially used a lot of the stuff he did at DEC in writing Windows NT.)
But MacOS X was different: it essentially put the Macintosh interface on top of the BSD Unix kernel--probably a lot of stuff borrowed from NeXTSTEP. As such, MacOS X (for the most part) has the memory stability and multitasking/multithreading functionality of BSD Unix.
We considered a lot of other OSes. We looked at NT, but it looked like it would never be practical to port to a big-endian processor.
I was reading with great interest 'till I got here. Just to make sure I hadn't gone mad, I grabbed my NT4 cd from the bookshelf. I hadn't. I scanned the CD for this comment.
So, either you're putting us on, had an excusable brain-fart, or we're talking Apples and Oranges. Pick a card any card.
Assuming you're just getting old like the rest of us, perhaps you can shed some light as to whether the mkLinux's Mach microkernel was considered either a proof-of-concept or an enabling technology when it came to porting OpenStep to Macintosh.
My God, it's Full of Source!
OUTSIDE_IP=$(dig +short my.ip @outsideip.net)
WebObjects is still alive and kicking, at my company we use it for all manner of things. It has become a real workhorse and continues to evolve capability-wise and mature in terms of stability. As a J2EE certified platform (last time I checked), the thing that I find most overlooked about the package is its built-in GUI a la Dreamweaver, it is, however, much more effective at visualizing/previewing dynamic pages with active data than the Macromedia product. If you are developing database-tied web sites with Java you owe it to yourself to check out Apple WebObjects. (It is not strictly tied to the Apple platform BTW) Of all the J2EE APIs I have used it is by far the most friendly, due to a code-quality pedigree inherited from NeXT and extensively re-factored ObjectiveC MVC structures. thanks Steve, et. al. (the built-in multi-schema load-balancer is a nice finishing touch ;) /*
Can you tell your JVM controller to re-start (and pass off extant sessions to other instances) your application instances to account for what could (at any time) be(come) a buggy JVM by clicking on a check-box on an HTML config page? A non-elegant but eminently practical solution for inexplicable java memory leaks is built in to this package. I call Nice. Check it out.
*/
TTFN.
Why the Darwin kernel? Why not the Linux kernel -- it's got the best hardware support. What about the L4 microkernel that has incredibly fast messaging rates?
Linux best hardware support my ass.
There have been 4 major releases of OS X on the market. Along that time I'm sure changes to the kernel have been made, possibly during security or x.x.1 point revisions also.
If Mac OS X was based off Linux. That's a shitload of clueless people recompiling their drivers.....or asking "which one of these 4 drivers (multiplied by version releases) are we are supposed to install?" just because kernel modules on Linux arn't portable.
I think it's borderline pain in the ass already and I use Gentoo. If I were using Fedora, and didn't already install Gentoo to learn all that compile stuff, I'd never get this working right (without months wasted).
You call that hardware support?
Support doesn't mean "oh, tech support phone guy will walk me through a kernel source install, driver compile, and copying modules around on my system."
Support means that "oh, I plugged it in, ran old ass installer CD from 3 versions ago dug out of the rotting box, and *poof* whatever the hell it is suddenly works."
And it's not like this is all that hard to put into the Linux kernel. IT'S BECAUSE LINUS AND THE KERNEL DEVELOPERS WANT IT THE WAY IT IS NOW. Having Apple back Linux won't change that one bit. Would you really want them to fork it instead?
Want an example of it done right (relatively)? Look at printing on OSX.
There's cupsd. Not exactly the easiest user friendly of all printing systems. (I mean, grandma isn't going to know what http://localhost:631 is supposed to mean) But nice and powerful. There's also the pre-cupsd OSX printing system there, which wasn't so hot because while it was uniform to code drivers for, it just didn't have any to begin with. And then there's the UI wrapper that combines both of them behind some UI.
Now, I'm using a Epson 480SXU. It's a printer so cheap that it doesn't even have a power button. It cost me less including cartridges, than it would if I just bought ONE of the two cartridges alone.
It also only has Windows drivers. Lucky for me, my Powerbook has cups, which has mild support for it. And with my unix knowledge, I got my printer working.
Now..... if I had a hypothetical deskjet 9999 or whatever the heck they're on, there's no CUPS support yet cuz it starting shipping 3 hours ago. But they were nice enough to include OSX drivers......tested for 10.1..... you know, before cups came on OSX......you know, like 2 years older than OSX 10.3. (this situation actually happened with a DJ1152 or some number in that range)
Sure, they chose not to open source their drivers to protect whatever patented dithering system they might have coded in. But lucky for me! The old school printing API on OSX is solid enough to let me run some crappy driver with unoptimized code. Sure it might suck as a v1 driver, but it was easy to install and any moron could do it.
And you can't do that with Linux right now. All because of the lame kernel modules API. The lesson learned? Somebody ought to make a new Linux API specifically for hardware support so we can actually pass around binary drivers.
And then...for REAL plug & play, make it possible to embed these drivers on the device themselves [serial EEPROM] so that if there's no newer driver on the system, it'll load the old one that came on release of the hardware. That is the kind of hardware support we should look at. Afterall, there's already an EEPROM that just holds the PCI ID anyways, might as well fill it up.
Instead of paying too much for Be, the tactic them seem to have used is hire good people from Be and have them work on parts of OSX. Thus you get things like the former BeOS file system designer creating Spotlight.
"There is more worth loving than we have strength to love." - Brian Jay Stanley
OPENSTEP is basically the implementation of the OpenStep API + extras, which is a reinvention of the NeXTSTEP APIs so they were platform independent. OPENSTEP ran on Mach, much in the same vein as NeXTSTEP, but also on other operating systems and architectures, even Windows NT, so code could be very easily ported from architecture to architecture.
I worked on Copland. The failure of Copland was not really a failure of technology but a failure of management. There were a number of management failures that brought the project down.
In the winter of 1995 we got a mandate that the first Copland beta would be made available for the May 1996 World Wide Developers' Conference.
That winter two of the major tasks that were being handled were to bring in the new file system and the new I/O system, replacing the original Copland, hastily built, prototype systems. For the purposes of that build, Copland could be split into 4 major pieces: file system, I/O subsystem, kernel and higher level functionality.
We produced set of glue code such that either file system or I/O subsystem could be used together, allowing the new I/O subsystem to be tested without alterations to the rest of the system and the new file system to be tested with the old I/O subsystem.
In January of 1996, as we were approaching the end of that build cycle, the kernel team decided that they really, really, needed to change a bunch of API's that would break just about everything. At this point, a strong management decision would have been "WAIT - those changes can go into the next build, AFTER the I/O subsystem and file system have been tested". Instead, the kernel changes were allowed to proceed. At this point everything in the system was broken. Upgrading the old I/O subsystem to work with the new kernel API's was a huge amount of work so the ability to test the new file system against the old I/O subsystem was lost. Now, the entire system had to be tested together with every component in flux. Needless to say, the integration process for this build took forever and was probably the first death blow for the project.
As WWDC approached, we expected that pressure would be brought from management to make the deadline. Instead, as the time for all-nighters with free pizza came up in about March management looked at the schedule and decided that it could not be met. Having told everyone previously if this deadline was missed the company would be in deep doo-doo, management credibility went out the window. The number of late nighters (already not enough for a project so far behind schedule) dropped precipitously. This was the second death blow to the project.
Over the summer of 1996 we were very close to having the developer release ready. A senior engineer and tech lead had been on sabbatical and doing some serious thinking and came back with a paper that cast serious doubts on the approach that Copland was taking to emulating the Mac OS System 7 environment.
Classic Mac OS is more of a library than an operating system in that all of the operating system's data structures are in the same address as applications. Copland's approach to Classic Mac OS compatibility was to emulate EVERYTHING, including internal data structures that applications might use. For example, in Classic Mac OS there is a linked list (can't remember the name of the damned thing right now) of data structures for all of the open files. Applications would walk this list to find out who else had files open. In the Copland emulation environment the Copland file system would generate events for the emulation layer so that the emulation layer could keep this list current!
This approach was causing serious problems. The mandate from marketing was that 99% of applications had to run, warts and all and this was proving to be strictly impossible. The emphasis on providing an emulation layer had bushwhacked the "new api" such that there really wasn't much available to write apps that took advantage of the multi-tasking and memory protection that the OS provided. The paper written seriously critiqued this approach.
Unfortunately as this paper made its way up the management chain to people who did not really understand what it was talking about, the entire project began to be regarded as failed.
Copland had a number of technical failings, one of its
Yes, we had all of these discussions. But as you doubtless know, it was not acutally possible to switch the processor between big endian and little endian mode quickly enough to run both kinds of apps in separate processes at anything like decent speeds The kernel was going to have to run either big endian or little endian, and one class of apps was going to suffer hugely on performance. That meant one thing, given that we already had a huge base of big-endian compiled apps we needed to run at close to full speed. We were going to have to shift the endianness of the NT kernel and all the apps to get decent speed.
Remember, I said practical. It was clearly possible, but business-wise it made next to no sense given the technological constraints we had to work with.
I think the biggest reason why Apple's Copland project failed was that it was essentially re-inventing the wheel of the type of memory management UNIX and Windows NT did.
Actually they were trying to invent the steel-belted radial. The Copland swap system, for instance was a strange beast, using 256 swap files (for some reason) and performed better than unix or NT swap systems.
Don't forget, we got alpha seeds of Copland - you can run it today if you have the right hardware. They just hadn't finished backwards compatibility (yes, that old song again) when it was "too late" and they went shopping for something else.
We're better off today for it, I'm sure, but it's disingenuous to represent that they didn't get memory management working.
My God, it's Full of Source!
OUTSIDE_IP=$(dig +short my.ip @outsideip.net)
Well, it's been about 7 years since I worked there, but my guess would be no. Not that they have any serious objection to other OSs for the hardware, but they have an OS and it serves them fairly well.
I'd really prefer they move away from Mach and towards Linux as a kernel, but there are some fairly serious changes to their graphics system that would need to be made in order to have a decent performance level atop Linux. They depend pretty heavily on Mach IPC constructs and have optimized the crap out of that path to make the OS X window server work.
i applaud anyone who would like to bring the user interface of NeXTstep back to the x86 platform on modern hardware. but i'm wondering if there's an alternate route.
........... kris
i've been spending considerable time of late conceptualizing building a new distro based solely on GNUstep and its associated apps. in my opinion, there is a critical mass of GNUstep-powered apps that run on Linux to create a user experience that rivals that of NeXTstep. it's low-hanging fruit that IMHO no one is reaching out to grab. i would like to grab it.
you might not understand the sheer power NeXTstep affords its users to appreciate why I would want to build something like this--i encourage you to find an old NeXTstep box and see for yourself why I would be excited about NeXTstep years after its demise.
i'm sure some believe KDE/GNOME already provide ease-of-use for end users, but having had the power of NeXTstep under my fingers for years, and having been a Linux user since 1995, I'm not sold. I'm currently working with a small Linux distro vendor to explore the possibility of building such an environment. We're trying to figure out if it would have any commercial promise. So far, well, it looks promising, but we might do it anyway for the sheer fun of having NeXTstep back on top of Linux. (Scratching an itch, in other words.) Although I believe KDE and GNOME have come a long way, IMHO they still lack the sheer ease-of-use that NeXTstep provided back in the day. I think the time might be right for an alternative to KDE/GNOME that is based on the NeXTstep experience.
I'm interested in readers' thoughts on this matter. Email me if this sounds interesting.
"I thought I could organize freedom. How Scandinavian of me."
The end result was that Mac OS X was not shipped until 2001, nearly 3 years behind what was promised.
You're leaving out some rather crucial parts of the story, here. In Spring of 1999, Apple shipped Mac OS X Server 1.0. In many respects, this is what was promised: Nextstep/Rhapsody on PowerPC hardware. It's a far cry from what we have in Mac OS X today, but that's because the requirements changed.
First, the original Next acquisition strategy was to require everyone to rewrite their apps in NextStep APIs (predecessor to Cocoa). Companies like Adobe didn't like this prospect, so Apple went back and started working on Carbon, which was a significant undertaking. In addition, Quartz was created to replace Display PostScript. And that's really just scratching the surface.
Nonetheless, Apple went from having about 10% of the desktop market when I started in 1995 to less than 4% today
Windows 95 combined with Apple management issues certainly had a significant impact. But to be fair, not all of this is due to Apple losing customers. Today, market share includes $168 PCs from Walmart, but this is a much different type of experience offered to a much different type of customer than what we typically think of as computer users.
So, if Copland had succeeded would Apple have been sunk? I don't think so. The fact that OS X has a Unix underpinning has had very little effect on the number of applications available for it. OS X's windowing system is most emphatically NOT X Windows so a port of any interesting application from Unix or Windows is major work.
This is misleading in several senses. Not only does come with a X11 server but a lot of significant Unix software (Apache, MySQL, etc) is faceless. In terms of consumer desktop application, what the Unix side brings is basic infrastructure for a multi-user system.
But one of the most significant advantages that Next brought to the table was the development environment. Not only for third party developers but Apple itself. The speed at which one can write high quality applications is a huge asset.
Objective-C has become the language of choice for Mac applications which again makes your applications totally non-portable.
The language is essentially irrelevant. The difference is in the frameworks. Unless you're using cross-platform toolkits, the language issue is a moot point. And cross-platform apps generally don't serve the platform or users as much as the developer.
Your best bet is to write the core engine in something like C, and write the higher level UI stuff in whatever the platform prefers.
Had Apple had strong enough managemnt to rein in engineering and force the product to ship it would have been successful and a strong contender to Windows NT on the desktop.
We clearly have different opinions on this, but I have a rather hard time seeing your parallel universe comparing favorably to one with Jobs, Cocoa, iMac, iPod/iTunes, iMovie, iPhoto, Final Cut Pro, etc. That's just my gut feeling.
- Scott
Scott Stevenson
Tree House Ideas
I came across this excerpt from Apple Confidential that someone (above or below) linked to here. I found the following paragraph very interesting.
It's not offtopic, dumbass. It's orthogonal.
And what a killer-app. Dell was using WebObjects until Apple purchased NeXT. Rumor has it that it took Microsoft a lot of effort to replace WebObjects.
Mac OS X has less code in common with NEXTSTEP than commonly assumed; it also lacked large swaths of current functionality, and much of what it had was rewritten. The XNU kernel, including networking, is a fresh implementation of the same architecture. Printing was redone to work with the new driver and display models, then scrapped and replaced with CUPS just two years ago. Developers balked when told that the only way to get their apps running natively on Rhapsody would be to rewrite them in Java or some crazy moon language, so Apple had to go write Carbon.
Unlike the grandparent, I'm not convinced that 'Plan Be' would have worked out better than what we have now, but reusable lines of code and time to market weren't the NeXT advantages Apple thought they would be.