I have to disagree with him on the degree of harm that would be caused to commercial development efforts by this. The market has already shown a tendancy to go with commercially supported solutions.
You're being kind.
He is basically arguing that if a failed package in a given market becomes free, it will automatically overtake the previously victorious competitor, even if it is missing features or buggy.
Unfortunately, historical fact proves exactly the opposite. StarOffice/OpenOffice hasn't made even a fractional percentage dent into Microsoft Office's sales. Interbase has taken exactly zero customers away from Oracle.
Now, it is certainly true that a pre-existing free product may discourage further development in the niche it occupies. Thus do we have the complete paucity of alternatives to GCC on the Linux and BSD platforms. But that's a very different scenario than the one Glass is addressing.
Tell that to Bungie who had to rape the original idea of what Halo was intended to be to fit Microsoft's plans and have it be yet another FPS game.
For some reason this idea that Microsoft imposed by fiat radical gameplay changes on Halo keeps coming up here. At the risk of repeating myself... there's really just not a lot of evidence for the theory. Rumors of a change from 3rd-person to 1st-person perspective in Halo predated the Microsoft buyout by at least three months, and the basic storyline and gameplay mechanics of Halo appear to be largely unchanged since the E3 2000 demos. (Inasmuch as we knew what they were even then -- Bungie was smart enough to play it very close to the hip to give themselves room to work out playability issues as development progressed.)
Obviously, internet multiplayer went out the window when Halo moved to the XBox, but Bungie apparently felt that was a reasonable sacrifice to make in return for being given several metric tons of cash and a guaranteed audience of millions for their flagship game. Can't say I blame em for that choice.
Ah, once more with the same tune: "everybody who was talking trash about Ion Storm just wishes they could have worked there!!!"
No.
I suggest that anybody who is actually interested in the reasons why Ion Storm became an industry synonym for mismanagement and failure dig up the original articles by BitchX and Flamethrower that started off the whole public meltdown. Ion Storm did not fail because people were jealous of how well John Romero treated his friends. Ion Storm failed because Romero, Porter and Hall were incompetant managers who treated their talented employees like dirt, and focussed on creating a cult of personality rather than actually completing a game.
Unfortunatly, as revisionist screeds like Divine's article prove, that cult of personality is Ion Storm Dallas' most lasting legacy, long out-living their forgettable games.
The problem is though, what happens if the company that exists today doesn't exist tomorrow?
Well, it kinda boils down to the question of whether you trust the market to have a corrective influence.
Remember, Apple's original plan right after the acquisition of NeXT was to do a five-minute port of OpenStep to the Mac hardware platform, slap a (very) thin coat of mac-ish gui paint on it, ship it on every box and tell every developer to learn ObjectiveC and OpenStep or suffer. (This plan was called "Rhapsody", although "Dissonance" might have been a better name.) Classic head-in-the-clouds Apple, but Macromedia, Microsoft and most importantly Adobe told Jobs and Amelio where they could stuff the idea, and they went back to the drawing board.
Feedback from the outside world penetrated the Infinite Loop in a pretty thorough fashion in 1998. Nothing like a near-death experience for a wake-up call.
But there are, unfortunately, no guarantees with apple, as anyone who pinned their hopes on Lisa/QuickdrawGX/OpenDoc/Copland/Be/Clones knows.
True. But then again, there are no guarantees ever. Even in the open source world. How many years late is Mozilla? How stable is Gnome? How snappy is StarOffice?
In the end, projects succeed or fail on their own merits, open source or not. A lot of the ones you call out for mention (notably GX, OpenDoc and Copland) failed not because of lack of effort by Apple, but because they just weren't adopted by ISVs (GX), were sacrificed to industry politics (OpenDoc), or were a horrible, unimplementable idea to begin with (Copland).
Committing yourself to any computing platform carries a set of risks. Some of those risks are general, some are platform-specific. You spends your money (and your time) and you takes your chances.
Marking a response to an on-going discussion as a "troll" is begging for the hammer of meta-moderation. Think carefully in the future, lest your toys be taken away.
I know that many Chinese developers are using linux and hence, the Chinese language support isn't "laugably bad."
Really? So you mean that there is a version of linux out there in which every single last configuration file in/etc has been translated into properly idiomatic Putonghua and implemented in big-5 encoding? And all of the major system daemons (init, inetd, syslogd, cron, etc) have been updated to parse big-5 input correctly? I would very much like to think that this is true, but I suspect that it is not.
Being able to display Chinese characters in GTK+ or QT windows and widgets is not the same thing as top-to-bottom localization. And "developers are using linux" is a far cry from "linux is in shape for use by the general population."
You've traveled in the asian countries, I see, but how about the rest of the world? Brazil is another country, that I know of, that has decent language support and a substantial base of linux users and developers.
I'm not sure that I'd consider Brazil to be a third-world country. In any case, the post I was responding to was predicting something much more momentous than just having a "substantial base" of linux users -- he was asserting that linux would inevitably triumph over Windows in third-world markets, something that hasn't happened in Brazil any more than in China, despite the substantially easier task of localizing linux for Portugese use than for Chinese.
Mach was never very good as a microkernel to begin with
Would you care to quantify that statement? I know that it's quite fashionable in this forum to parrot Linus Torvalds' blithe dismissal of Mach, but nobody ever seems interested in backing it up with any hard data.
and it hasn't been heavily updated in years. FreeBSD on the other hand, is very mature, just like Mach, but has had the benifet of years of massaging in the intervening years.
What an odd and incorrect statement. I don't really know where to begin. Do you really think that during the entire time that Mach was being used as the core of various incarnations of NeXTstep (on both 680x0 and ia32), MkLinux (on PPC, ia32 and PA-RISC) and MacOS X, not to mention countless other projects, that it was not "massaged" and updated significantly?
Apple really was out to lunch when it decided to use a Mach/BSD combo
You dance with who brought you. OSX is based on NeXTstep, and NeXTstep was built on the Mach/BSD core. That codebase was stable, mature, and proven to be portable. They had, and have, no sane reason to rip it out.
First, it has no real benifets, since the monolithic system server eats any potential gains in stability.
More mindless parroting of the party line. Mach/BSD is in no way unstable, and stability is not the only benefit. Think "portability, modularity, features and elegance."
Worse, it loses performance for being based on a microkernel.
So everyone keeps saying, but nobody seems willing to actually back up that assertion with anything other than vague handwaving. (Please, don't waste anybody's time by reminding us how much faster BeOS could draw windows on the screen. We know Quartz is slow. It's just not relevant to this discussion.)
hat would have made much more sense for Apple would have been to base OS-X on top of FreeBSD.
Apple had a deadline to meet for transmuting NeXTstep into OSX, and a market requirement to support their own SMP systems. Attempting to backport the entirety of OpenStep onto FreeBSD would have actively hindered both of those goals, while offering few tangible benefits in return. (Nevermind the unanswered question of just how long a port of FreeBSD to the Mac/PPC platform would take.)
Instead, they did the smart thing: they hired Jordan Hubbard, and ported many of FreeBSD's userland improvements back to the Mach/BSD codebase, and re-released that as Darwin. Everybody won.
and Apple wouldn't have to be in the core OS business.
Having done a fair bit of legging about in China, Thailand and Cambodia, I'm afraid that the facts don't square with your optimism. I have never seen a computer in an asian country that was not running Microsoft Windows. Not in government offices, not in businesses, and certainly not in the corner internet cafes. I don't imagine that the situation is much different in South America, Africa or the Middle East.
Of course, whether those copies of Windows were paid for is a different question entirely, but probably not as important as your average slashdotter would suspect -- Gates and Ballmer aren't stupid, and they know damn well that if they turn a semi-blind eye to piracy of Windows in developing countries now, they can make bank when those countries finally have the resources to pay up on what will by that time be an unshakable monopoly.
Plus, not to be blunt or anything, but linux's foreign language support is laughably bad. Microsoft's entire product line (or close to it, and certainly all of the major packages) is available localized into Mandarin, Korean, Thai, Japanese, Tagalog, Arabic, Hindi and probably more. On a good day, AbiWord might get translated into German.
The triumph of cheap commodity hardware in the third world is, yes, inevitable, but that really implies nothing about Linux's odds of success there. Linux may be "free", but profit margins on software are almost infinitely elastic: "free and in English" will not necessarily beat "really cheap and in my native tongue."
OSX's major flaw so far has been performance, because the BSD/Mach codebase it's built on it simply unwieldy without further refinement.
Gah. No. OSX has performance issues, yes, but they have zilch to do with Mach/BSD. That codebase is over 15 years old, and is quite mature and refined, thank you.
If you don't believe me on this, grab a PPC mac somewhere, install LinuxPPC and Darwin (the Mach/BSD core of OSX) on it in turn, and time some test compiles in console mode. Linux will win, but the margin will be small and consistant.
OSX's performance issues are all several layers up, in the presentation and windowing systems. Apple scrapped NeXT's old Display Postscript windowing system to build Quartz and Aqua from scratch, and that is one huge heap of immature, unoptimized, and feature-iffic code there. Additionally, a quick look at "top" on most OSX boxes will show you that an inhuman amount of memory and cpu slices are being eaten by the "TrueBlue" OS9 emulation process, aka "Classic."
The first problem will be resolved as the Quartz codebase matures and as newer video drivers start to offload the work onto the cards. The second problem will go away as people find fewer and fewer reasons to run Classic apps.
Actually, I'm kinda surprised that it took this long. Mr. Carmack had mentioned a while ago (like, 8-12 months) that the only thing holding up the Q2 source release was that they were waiting for the final two Q2-engine-license games to ship, since apparently they were legally embargoed from GPLing the code until that happened. Those two games were, natch, Anachronox and Daikatana (cue inevitable snickering here). Anox shipped several months ago, and, uh, we all know what happened to Daikatana.
Hopefully the fact that it took him so long to get around to packaging up the Q2 source for GPL release means that they've been burning the midnight oil on DOOM 3, and we'll get to see it soon.
OS X is not without its flaws; the package system stinks
Yeah, Apple's native packaging system is a nightmare. Luckily, you're not stuck with it: InstallerVISE is available for OSX Carbon/Cocoa apps, and fink just completely rocks for bsd/x11 apps.
the X server (XFree86 port actually) is a little slow
That'll change. Right now, as far as I know, XDarwin is entirely a software framebuffer -- no hardware accelleration support at all. I'd expect that to change soon for geforce-based macs, and eventually for radeon-based ones.
and porting applications can be a bit of an inconvenience
If you're just trying to compile a pre-existing autoconf-based unix package and it's being balky, there's a magic trick that will solve a good deal of your problems:
Okay, so the "Flower Power" iMac was a terrible idea, but what's your beef with the G4 towers? They a joy to work with: I wish to god that some PC case vendor would implement something similar to the "fold down" access to the motherboard that the g3/g4 towers have.
Apple had several OS projects, starting after System 6 (which was released in 1986)
Oh boy did they ever. Every once in a while, I try to amuse myself by listing all of the next-gen OS projectst that Apple started and then abandoned in one form of completion or another since the release of System 6. There were a lot of them.
Pink (spun off into Taligent; died of malign neglect)
A/UX (MacOS "shell" on top of a mutant SVR2 Unix, eerily similar in basic design to OSX. Limped along for several years with minimal support as a workgroup server product, died when Apple decided not to port it to PowerPC)
MacMach (MacOS userland server implementation on top of CMU Mach; a weird hack that seemed primarily a proof of concept)
MkLinux (Linux userland server on top of Mach 3.0 microkernel; released for PowerMac boxes and PA-RISC; never very popular itself, but jumpstarted LinuxPPC development on Mac hardware)
Copland (The ultimate exercise in feeping creaturism -- it started out as a limited attempt to give protected memory and true multitasking to a few core system services. Five years later it was going to be a full-blown next-generation OS with total GUI themeability, Windows and Unix emulation layers and god only knows what else. Mercifully killed by Ellen Hancock in what turned out to be the only smart move the Amelio/Hancock team ever made.)
Gershwin (The planned follow-on to copland that would have added user-level memory protection and multitasking. Vanished off the planet as the Copland team annexed its planned feature list.)
NetWare/PPC (Novell Netware 5.0 running on 8600-era PowerMac hardware -- finished by Novell and demoed at several MacWorld shows, but never actually shipped.)
AIX 4.2.2 (Licensed by Apple from IBM and shipped on their short-lived Apple Network Server series.)
"StarTrek" (System 7 ported to run on standard Pentium PCs. A small skunkworks team actually produced several working builds, but the project was spiked and buried.)
...and that's just off the top of my head. Any former Apple developers are welcome to chime in and add to the list.
Let me guess: you worked at IBM, circa 1993-98? Sir, you have my sympathies, but chill the fuck out.
That's crap! It was *NOT* given over to IBM.
Taligent was a separate corporation
Let's get real for a second here. Yes, Taligent was, on paper, an independent company. In reality, as you yourself point out, Apple lost interest in the project shortly afterward, and IBM was in the driver's seat for the majority of its history, and the failure of any of Pink's technology to ship on any platform until years after its irrelevance was assured can be laid largely at IBM's feet.
Apple's mistake was to spin Pink off as an external entity when they really had no interest in using an OS that they didn't completely own. The mistakes after that one were IBM's and Taligent's own.
given the challenge of taking the best OO tech from IBM and Apple and turning out a next-gen OS and cross-platform API. The Pink team was *part* of that effort.
Correct. I don't recall saying anything contradictory to this.
IBM *S H I P P E D* it for AIX and put it in beta for OS/2.
...the former being promptly ignored, and the latter, well...
I think we are largely in violent agreement here. Apple and IBM both spent a good chunk of the 90s strangling their own best technology initiatives in the cradle, while Microsoft laughed all the way to the bank. Taligent, I suspect, failed inside of IBM for the same reason that OS/2 did: because IBM is not so much a unified company as a stiched-together group of fiefdoms, and in the final analysis the portion of IBM that had no interest in challenging Microsoft seriously on the desktop was the one that got to make the critical decisions. (It's ironic that you mention CommonPoint shipping for AIX, as AIX is now undergoing the same crib-death treatment at the hands of the pro-linux/S390 crowd -- listening to IBM sales reps try to explain their unix strategy these days is alternatively hilarious and depressing.)
IBM offered and negotiated TWICE to buy out the floundering Apple and make it their consumer division! Again, Apple balked.
Sorry, but this was the right decision on Apple's part, even then. OS/2 Warp's fate made it crystal clear what Apple's destiny would be as a wholly owned subsidiary of IBM: a lot of pretty talk, followed by inevitable destruction. (See also: "Any part of Lotus other than Notes" and "AT&T buys NCR.")
Apple did NOTHING but piss away one opportunity after the next throughout the '90's. It was too egotistic to accept Copland was going NO WHERE until a certain Hancock, a former IBM exec, came in and had the testicular fortitude to end it and look for something else.
Quite. Please read my post again with your jerking knee taped down -- I said pretty much exactly the same thing about Hancock. (The phrase I used was "mercy killing.")
OS X is architected on top of Mach to keep Apple stockholders from asking why Apple paid $400 million for NeXT, bailing out Steve Jobs and his buddies.
No. OSX is architected on top of Mach because OSX is NeXTSTEP, and NeXTSTEP was always built on top of Mach. The decision to use Mach was a sound one, as proved by NeXTSTEP/OpenStep's durability and portability across many diseperate architectures over 15 years after its birth.
The argument for cancelling Copland (the original MacOS 8) was that it was going to take another year to make it work
No. The argument for cancelling Copland was that it was never going to work. Copland was a horrible idea to begin with, and rapidly became the textbook example of an out-of-control, death-ship project. By the time Hancock performed the mercy-killing, Copland was over three years behind schedule, and what little in terms of development SDKs had dribbled out of Apple had been universally panned by developers.
The MacOS really needed a new layer underneath, but UNIX/Mach wasn't a great match. I'm not suprised it took Apple almost five years to make them play together.
No. Apple had functional, usable builds of Rhapsody (OpenStep on PPC with a MacOS Classic look-and-feel, and "Blue Box" fullscreen OS8 emulation) within a year of the NeXT acquisition. I personally used such a box in early 1998; it was quite slick. This product was later released as "MacOS X Server 1.0".
The reasons that OSX "consumer" didn't ship until much later were twofold: First, Apple listened to feedback from their existing developer base, and realized that they were risking alienating a substantial amount of them by trying to force an immediate migration to the OpenStep APIs. (Adobe, in particular, dug in their heels and threatened to discontinue Photoshop development for MacOS.) In response to this, Apple had to develop the "Carbon" API layer, which was a substantial effort. Second, Apple made the decision to take the time to re-engineer the user interface and display layers ("Aqua" and "Quartz"), on the (likely) theory that the MacOS UI needed a facelift.
Apple desperately needed a new kernely, and it should have happened around 1992 or so, by which time all new Macs had enough hardware for a good protected-mode OS.
Blame IBM. Apple had a new base OS technology in 1992. It was called "Pink", and ironically was very similar in conception to OpenStep. Unfortunatly, as part of the original Apple/IBM/Motorola alliance, Pink was given over to IBM, who renamed it "Taligent" and promptly buried it.
Basically, Apple was nine years late with their new OS, which is part of why Apple tanked.
Ah. I was not aware that "tanked" could also be used to mean "wildly profitable in a year when Dell, Compaq and HP are hemmorhaging money." Fascinating.
In my experience, DLT wasn't a very good way to do backups. Maybe it was just the drive brand we had, but we had to send about 8 drives back to the manufacturer for repairs. Many times with one of our backup tapes still stuck in it.
For some reason, the DLT8000 mechanism was horribly flaky in this way for the first few production runs. You just kept RMAing the damn things until you found a solid unit, then you tried very hard not to breathe on it.
Several times I saw the tape catch miss the tape and get pulled inside without the tape. After that it was back to the manufacturer for repairs.
This is a known failure mode for DLT drives, and only an amazingly lazy tech support droid would suggest that you send the drive back for it. Next time it happens, demand that they walk you through the reset procedure -- it'll take five minutes, tops, and requires nothing more than one screwdriver and a bit of patience.
My 5200/75LC was the suckiest piece of suck ever created.
Geeze. I mean, no argument that the 5200 was pretty much Apple's low-water mark for desktop machines, but that's like complaining that you bought a Yugo. It's not like it got any good reviews ever.
Count your blessings. You could have bought an Exploding PowerBook 5300.
It evidently needs to be said again. The G4 is the G3 with Altivec and SMP. They're the same chip otherwise.
Er, no, that did not need to be said again. It didn't even need to be said in the first place, because it is completely false.
The G4 is not, in any way, shape or form, just a G3 with an AltiVec unit bolted on the side. Completely different math unit, radically different instruction pipeline, bigger caches, additional registers, SMP support (the G3 cannot be used in SMP systems), wider memory bus, more execution units... you name it, it changed -- even moreso in the 7450 and 7410 than in the 7400.
Please do someresearch before spouting "facts" liek this.
I don't suppose you'd care to back up that hysterically funny claim with any actual benchmarks, eh?
A 500Mhz G4 can, on a very good day, when the moon is in jupiter and there are no clouds, just about barely keep up with a 1GHz P-III on certain benchmarks. (Where "certain benchmarks" basically means "Photoshop Unshark Mask and nothing else.") A G3 is not getting anywhere near the 1GHz P-III, nevermind the 1.4GHz P-4.
Slashdot Mirror
I have to disagree with him on the degree of harm that would be caused to commercial development efforts by this. The market has already shown a tendancy to go with commercially supported solutions.
You're being kind.
He is basically arguing that if a failed package in a given market becomes free, it will automatically overtake the previously victorious competitor, even if it is missing features or buggy.
Unfortunately, historical fact proves exactly the opposite. StarOffice/OpenOffice hasn't made even a fractional percentage dent into Microsoft Office's sales. Interbase has taken exactly zero customers away from Oracle.
Now, it is certainly true that a pre-existing free product may discourage further development in the niche it occupies. Thus do we have the complete paucity of alternatives to GCC on the Linux and BSD platforms. But that's a very different scenario than the one Glass is addressing.
Tell that to Bungie who had to rape the original idea of what Halo was intended to be to fit Microsoft's plans and have it be yet another FPS game.
For some reason this idea that Microsoft imposed by fiat radical gameplay changes on Halo keeps coming up here. At the risk of repeating myself... there's really just not a lot of evidence for the theory. Rumors of a change from 3rd-person to 1st-person perspective in Halo predated the Microsoft buyout by at least three months, and the basic storyline and gameplay mechanics of Halo appear to be largely unchanged since the E3 2000 demos. (Inasmuch as we knew what they were even then -- Bungie was smart enough to play it very close to the hip to give themselves room to work out playability issues as development progressed.)
Obviously, internet multiplayer went out the window when Halo moved to the XBox, but Bungie apparently felt that was a reasonable sacrifice to make in return for being given several metric tons of cash and a guaranteed audience of millions for their flagship game. Can't say I blame em for that choice.
...didn't you hear? Design is law!
Ah, once more with the same tune: "everybody who was talking trash about Ion Storm just wishes they could have worked there!!!"
No.
I suggest that anybody who is actually interested in the reasons why Ion Storm became an industry synonym for mismanagement and failure dig up the original articles by BitchX and Flamethrower that started off the whole public meltdown. Ion Storm did not fail because people were jealous of how well John Romero treated his friends. Ion Storm failed because Romero, Porter and Hall were incompetant managers who treated their talented employees like dirt, and focussed on creating a cult of personality rather than actually completing a game.
Unfortunatly, as revisionist screeds like Divine's article prove, that cult of personality is Ion Storm Dallas' most lasting legacy, long out-living their forgettable games.
It's "you're ugly," not "your ugly." "Your" is possessive, "you're" is the contraction of "you are."
Examples:
Thank you, and have a happy holiday.
The problem is though, what happens if the company that exists today doesn't exist tomorrow?
Well, it kinda boils down to the question of whether you trust the market to have a corrective influence.
Remember, Apple's original plan right after the acquisition of NeXT was to do a five-minute port of OpenStep to the Mac hardware platform, slap a (very) thin coat of mac-ish gui paint on it, ship it on every box and tell every developer to learn ObjectiveC and OpenStep or suffer. (This plan was called "Rhapsody", although "Dissonance" might have been a better name.) Classic head-in-the-clouds Apple, but Macromedia, Microsoft and most importantly Adobe told Jobs and Amelio where they could stuff the idea, and they went back to the drawing board.
Feedback from the outside world penetrated the Infinite Loop in a pretty thorough fashion in 1998. Nothing like a near-death experience for a wake-up call.
But there are, unfortunately, no guarantees with apple, as anyone who pinned their hopes on Lisa/QuickdrawGX/OpenDoc/Copland/Be/Clones knows.
True. But then again, there are no guarantees ever. Even in the open source world. How many years late is Mozilla? How stable is Gnome? How snappy is StarOffice?
In the end, projects succeed or fail on their own merits, open source or not. A lot of the ones you call out for mention (notably GX, OpenDoc and Copland) failed not because of lack of effort by Apple, but because they just weren't adopted by ISVs (GX), were sacrificed to industry politics (OpenDoc), or were a horrible, unimplementable idea to begin with (Copland).
Committing yourself to any computing platform carries a set of risks. Some of those risks are general, some are platform-specific. You spends your money (and your time) and you takes your chances.
Marking a response to an on-going discussion as a "troll" is begging for the hammer of meta-moderation. Think carefully in the future, lest your toys be taken away.
You had no power to say "I want OSX to support my older Powermacs!"
Incorrect. Not only can you do just that (since the core OS code is available openly), but someone has already done it for you.
Many of your comments about Apple, while on-target, refer to a very different company than exists today.
I know that many Chinese developers are using linux and hence, the Chinese language support isn't "laugably bad."
/etc has been translated into properly idiomatic Putonghua and implemented in big-5 encoding? And all of the major system daemons (init, inetd, syslogd, cron, etc) have been updated to parse big-5 input correctly? I would very much like to think that this is true, but I suspect that it is not.
Really? So you mean that there is a version of linux out there in which every single last configuration file in
Being able to display Chinese characters in GTK+ or QT windows and widgets is not the same thing as top-to-bottom localization. And "developers are using linux" is a far cry from "linux is in shape for use by the general population."
You've traveled in the asian countries, I see, but how about the rest of the world? Brazil is another country, that I know of, that has decent language support and a substantial base of linux users and developers.
I'm not sure that I'd consider Brazil to be a third-world country. In any case, the post I was responding to was predicting something much more momentous than just having a "substantial base" of linux users -- he was asserting that linux would inevitably triumph over Windows in third-world markets, something that hasn't happened in Brazil any more than in China, despite the substantially easier task of localizing linux for Portugese use than for Chinese.
Mach was never very good as a microkernel to begin with
Would you care to quantify that statement? I know that it's quite fashionable in this forum to parrot Linus Torvalds' blithe dismissal of Mach, but nobody ever seems interested in backing it up with any hard data.
and it hasn't been heavily updated in years. FreeBSD on the other hand, is very mature, just like Mach, but has had the benifet of years of massaging in the intervening years.
What an odd and incorrect statement. I don't really know where to begin. Do you really think that during the entire time that Mach was being used as the core of various incarnations of NeXTstep (on both 680x0 and ia32), MkLinux (on PPC, ia32 and PA-RISC) and MacOS X, not to mention countless other projects, that it was not "massaged" and updated significantly?
Apple really was out to lunch when it decided to use a Mach/BSD combo
You dance with who brought you. OSX is based on NeXTstep, and NeXTstep was built on the Mach/BSD core. That codebase was stable, mature, and proven to be portable. They had, and have, no sane reason to rip it out.
First, it has no real benifets, since the monolithic system server eats any potential gains in stability.
More mindless parroting of the party line. Mach/BSD is in no way unstable, and stability is not the only benefit. Think "portability, modularity, features and elegance."
Worse, it loses performance for being based on a microkernel.
So everyone keeps saying, but nobody seems willing to actually back up that assertion with anything other than vague handwaving. (Please, don't waste anybody's time by reminding us how much faster BeOS could draw windows on the screen. We know Quartz is slow. It's just not relevant to this discussion.)
hat would have made much more sense for Apple would have been to base OS-X on top of FreeBSD.
Apple had a deadline to meet for transmuting NeXTstep into OSX, and a market requirement to support their own SMP systems. Attempting to backport the entirety of OpenStep onto FreeBSD would have actively hindered both of those goals, while offering few tangible benefits in return. (Nevermind the unanswered question of just how long a port of FreeBSD to the Mac/PPC platform would take.)
Instead, they did the smart thing: they hired Jordan Hubbard, and ported many of FreeBSD's userland improvements back to the Mach/BSD codebase, and re-released that as Darwin. Everybody won.
and Apple wouldn't have to be in the core OS business.
Why on earth wouldn't they want to be?
Having done a fair bit of legging about in China, Thailand and Cambodia, I'm afraid that the facts don't square with your optimism. I have never seen a computer in an asian country that was not running Microsoft Windows. Not in government offices, not in businesses, and certainly not in the corner internet cafes. I don't imagine that the situation is much different in South America, Africa or the Middle East.
Of course, whether those copies of Windows were paid for is a different question entirely, but probably not as important as your average slashdotter would suspect -- Gates and Ballmer aren't stupid, and they know damn well that if they turn a semi-blind eye to piracy of Windows in developing countries now, they can make bank when those countries finally have the resources to pay up on what will by that time be an unshakable monopoly.
Plus, not to be blunt or anything, but linux's foreign language support is laughably bad. Microsoft's entire product line (or close to it, and certainly all of the major packages) is available localized into Mandarin, Korean, Thai, Japanese, Tagalog, Arabic, Hindi and probably more. On a good day, AbiWord might get translated into German.
The triumph of cheap commodity hardware in the third world is, yes, inevitable, but that really implies nothing about Linux's odds of success there. Linux may be "free", but profit margins on software are almost infinitely elastic: "free and in English" will not necessarily beat "really cheap and in my native tongue."
OSX's major flaw so far has been performance, because the BSD/Mach codebase it's built on it simply unwieldy without further refinement.
Gah. No. OSX has performance issues, yes, but they have zilch to do with Mach/BSD. That codebase is over 15 years old, and is quite mature and refined, thank you.
If you don't believe me on this, grab a PPC mac somewhere, install LinuxPPC and Darwin (the Mach/BSD core of OSX) on it in turn, and time some test compiles in console mode. Linux will win, but the margin will be small and consistant.
OSX's performance issues are all several layers up, in the presentation and windowing systems. Apple scrapped NeXT's old Display Postscript windowing system to build Quartz and Aqua from scratch, and that is one huge heap of immature, unoptimized, and feature-iffic code there. Additionally, a quick look at "top" on most OSX boxes will show you that an inhuman amount of memory and cpu slices are being eaten by the "TrueBlue" OS9 emulation process, aka "Classic."
The first problem will be resolved as the Quartz codebase matures and as newer video drivers start to offload the work onto the cards. The second problem will go away as people find fewer and fewer reasons to run Classic apps.
Actually, I'm kinda surprised that it took this long. Mr. Carmack had mentioned a while ago (like, 8-12 months) that the only thing holding up the Q2 source release was that they were waiting for the final two Q2-engine-license games to ship, since apparently they were legally embargoed from GPLing the code until that happened. Those two games were, natch, Anachronox and Daikatana (cue inevitable snickering here). Anox shipped several months ago, and, uh, we all know what happened to Daikatana.
Hopefully the fact that it took him so long to get around to packaging up the Q2 source for GPL release means that they've been burning the midnight oil on DOOM 3, and we'll get to see it soon.
Just some random kibbitzing here:
/usr/libexec/config* .
OS X is not without its flaws; the package system stinks
Yeah, Apple's native packaging system is a nightmare. Luckily, you're not stuck with it: InstallerVISE is available for OSX Carbon/Cocoa apps, and fink just completely rocks for bsd/x11 apps.
the X server (XFree86 port actually) is a little slow
That'll change. Right now, as far as I know, XDarwin is entirely a software framebuffer -- no hardware accelleration support at all. I'd expect that to change soon for geforce-based macs, and eventually for radeon-based ones.
and porting applications can be a bit of an inconvenience
If you're just trying to compile a pre-existing autoconf-based unix package and it's being balky, there's a magic trick that will solve a good deal of your problems:
mv config.sub config.sub.dist
mv config.guess config.guess.dist
ln -s
If that doesn't work, the canonical answer is usually, "Check fink." Someone has probably already ported whatever it is you want.
Okay, so the "Flower Power" iMac was a terrible idea, but what's your beef with the G4 towers? They a joy to work with: I wish to god that some PC case vendor would implement something similar to the "fold down" access to the motherboard that the g3/g4 towers have.
Oh boy did they ever. Every once in a while, I try to amuse myself by listing all of the next-gen OS projectst that Apple started and then abandoned in one form of completion or another since the release of System 6. There were a lot of them.
...and that's just off the top of my head. Any former Apple developers are welcome to chime in and add to the list.
Let me guess: you worked at IBM, circa 1993-98? Sir, you have my sympathies, but chill the fuck out.
That's crap! It was *NOT* given over to IBM.
Taligent was a separate corporation
Let's get real for a second here. Yes, Taligent was, on paper, an independent company. In reality, as you yourself point out, Apple lost interest in the project shortly afterward, and IBM was in the driver's seat for the majority of its history, and the failure of any of Pink's technology to ship on any platform until years after its irrelevance was assured can be laid largely at IBM's feet.
Apple's mistake was to spin Pink off as an external entity when they really had no interest in using an OS that they didn't completely own. The mistakes after that one were IBM's and Taligent's own.
given the challenge of taking the best OO tech from IBM and Apple and turning out a next-gen OS and cross-platform API. The Pink team was *part* of that effort.
Correct. I don't recall saying anything contradictory to this.
IBM *S H I P P E D* it for AIX and put it in beta for OS/2.
...the former being promptly ignored, and the latter, well...
I think we are largely in violent agreement here. Apple and IBM both spent a good chunk of the 90s strangling their own best technology initiatives in the cradle, while Microsoft laughed all the way to the bank. Taligent, I suspect, failed inside of IBM for the same reason that OS/2 did: because IBM is not so much a unified company as a stiched-together group of fiefdoms, and in the final analysis the portion of IBM that had no interest in challenging Microsoft seriously on the desktop was the one that got to make the critical decisions. (It's ironic that you mention CommonPoint shipping for AIX, as AIX is now undergoing the same crib-death treatment at the hands of the pro-linux/S390 crowd -- listening to IBM sales reps try to explain their unix strategy these days is alternatively hilarious and depressing.)
IBM offered and negotiated TWICE to buy out the floundering Apple and make it their consumer division! Again, Apple balked.
Sorry, but this was the right decision on Apple's part, even then. OS/2 Warp's fate made it crystal clear what Apple's destiny would be as a wholly owned subsidiary of IBM: a lot of pretty talk, followed by inevitable destruction. (See also: "Any part of Lotus other than Notes" and "AT&T buys NCR.")
Apple did NOTHING but piss away one opportunity after the next throughout the '90's. It was too egotistic to accept Copland was going NO WHERE until a certain Hancock, a former IBM exec, came in and had the testicular fortitude to end it and look for something else.
Quite. Please read my post again with your jerking knee taped down -- I said pretty much exactly the same thing about Hancock. (The phrase I used was "mercy killing.")
OS X is architected on top of Mach to keep Apple stockholders from asking why Apple paid $400 million for NeXT, bailing out Steve Jobs and his buddies.
No. OSX is architected on top of Mach because OSX is NeXTSTEP, and NeXTSTEP was always built on top of Mach. The decision to use Mach was a sound one, as proved by NeXTSTEP/OpenStep's durability and portability across many diseperate architectures over 15 years after its birth.
The argument for cancelling Copland (the original MacOS 8) was that it was going to take another year to make it work
No. The argument for cancelling Copland was that it was never going to work. Copland was a horrible idea to begin with, and rapidly became the textbook example of an out-of-control, death-ship project. By the time Hancock performed the mercy-killing, Copland was over three years behind schedule, and what little in terms of development SDKs had dribbled out of Apple had been universally panned by developers.
The MacOS really needed a new layer underneath, but UNIX/Mach wasn't a great match. I'm not suprised it took Apple almost five years to make them play together.
No. Apple had functional, usable builds of Rhapsody (OpenStep on PPC with a MacOS Classic look-and-feel, and "Blue Box" fullscreen OS8 emulation) within a year of the NeXT acquisition. I personally used such a box in early 1998; it was quite slick. This product was later released as "MacOS X Server 1.0".
The reasons that OSX "consumer" didn't ship until much later were twofold: First, Apple listened to feedback from their existing developer base, and realized that they were risking alienating a substantial amount of them by trying to force an immediate migration to the OpenStep APIs. (Adobe, in particular, dug in their heels and threatened to discontinue Photoshop development for MacOS.) In response to this, Apple had to develop the "Carbon" API layer, which was a substantial effort. Second, Apple made the decision to take the time to re-engineer the user interface and display layers ("Aqua" and "Quartz"), on the (likely) theory that the MacOS UI needed a facelift.
Apple desperately needed a new kernely, and it should have happened around 1992 or so, by which time all new Macs had enough hardware for a good protected-mode OS.
Blame IBM. Apple had a new base OS technology in 1992. It was called "Pink", and ironically was very similar in conception to OpenStep. Unfortunatly, as part of the original Apple/IBM/Motorola alliance, Pink was given over to IBM, who renamed it "Taligent" and promptly buried it.
Basically, Apple was nine years late with their new OS, which is part of why Apple tanked.
Ah. I was not aware that "tanked" could also be used to mean "wildly profitable in a year when Dell, Compaq and HP are hemmorhaging money." Fascinating.
Font anti-aliasing is probably one of the major reasons that KDE is so slow for you. Try turning it off and compare again.
In my experience, DLT wasn't a very good way to do backups. Maybe it was just the drive brand we had, but we had to send about 8 drives back to the manufacturer for repairs. Many times with one of our backup tapes still stuck in it.
For some reason, the DLT8000 mechanism was horribly flaky in this way for the first few production runs. You just kept RMAing the damn things until you found a solid unit, then you tried very hard not to breathe on it.
Several times I saw the tape catch miss the tape and get pulled inside without the tape. After that it was back to the manufacturer for repairs.
This is a known failure mode for DLT drives, and only an amazingly lazy tech support droid would suggest that you send the drive back for it. Next time it happens, demand that they walk you through the reset procedure -- it'll take five minutes, tops, and requires nothing more than one screwdriver and a bit of patience.
Oh please do shut up.
My 5200/75LC was the suckiest piece of suck ever created.
Geeze. I mean, no argument that the 5200 was pretty much Apple's low-water mark for desktop machines, but that's like complaining that you bought a Yugo. It's not like it got any good reviews ever.
Count your blessings. You could have bought an Exploding PowerBook 5300.
It evidently needs to be said again. The G4 is the G3 with Altivec and SMP. They're the same chip otherwise.
Er, no, that did not need to be said again. It didn't even need to be said in the first place, because it is completely false.
The G4 is not, in any way, shape or form, just a G3 with an AltiVec unit bolted on the side. Completely different math unit, radically different instruction pipeline, bigger caches, additional registers, SMP support (the G3 cannot be used in SMP systems), wider memory bus, more execution units... you name it, it changed -- even moreso in the 7450 and 7410 than in the 7400.
Please do someresearch before spouting "facts" liek this.
the 500 MHz G3 is nearly as fast as the 1 GHz P3
I don't suppose you'd care to back up that hysterically funny claim with any actual benchmarks, eh?
A 500Mhz G 4 can, on a very good day, when the moon is in jupiter and there are no clouds, just about barely keep up with a 1GHz P-III on certain benchmarks. (Where "certain benchmarks" basically means "Photoshop Unshark Mask and nothing else.") A G 3 is not getting anywhere near the 1GHz P-III, nevermind the 1.4GHz P-4.
You, and the idiots who moderated your spew up.