One of the problems is that for many mainframe systems, massively parallel processors are a common feature. Linux's SMP support isn't really that great. There are some massive improvements in the 2.4 kernel, but some fundamental design decisions get in the way.
For example, Linus is a big proponent of a non-preemptable kernel. A preemptable kernel is one that can allow tasks within the kernel to be preempted by other tasks. The Linux kernel does not allow tasks to be preempted by anything other than interrupts.
As an aside, interrupts in the Linux kernel typically run a small bit of code to set up some state information about the interrupt, flag a "bottom half" to run later, and then get the hell out of dodge. The bulk of the work is in the "bottom half," which is a bit of code which is enqueued to run when the kernel gets the time to get around to it. For example, the timer interrupt increments the jiffies (an internal measure of sub-second time), lost timer ticks (ticks that haven't been handled by the bottom half), and flags the bottom half for later execution. The bottom half will later update time-related statistics and service kernel timers.
Basically, though, once the "top half" of an interrupt is handled, the kernel must immediately go back to what it was doing. It is guaranteed that kernel code will not be preempted. This makes the kernel cleaner, easier to understand and maintain, and faster on uniprocessor systems or systems with few processors. However, there's a reason that the Solaris kernel is preemptable. Preemptability is a serious performance enhancer for massively parallel systems, but Linus is not budging on this. There are a number of alternative solutions that the Linux kernel is following, such as its system of "bottom halves," some of which can now be run on other processors in the 2.4 kernel (if I understand correctly). Essentially, a preemptable kernel requires that fine-grained kernel locks be scattered all over the kernel, and that more code in the kernel be considered "critical sections." This is somewhat of a hassle.
Solaris scales extremely well partially due to its kernel's preemptability and heavy use of threads. Solaris's kernel can be preempted by another task and can dispatch kernel threads to work on other processors. This keeps system call hungry processes on other processors happy and well fed. However, it does incur some overhead which isn't justifiable on desktop machines. I'm reminded of a funny quote from the 2.2 kernel mailing list I found once while looking for info on this once: "MVS spends a lot of time running OS algorithms to allow full preemption that Linux wastes on running user applications."
Basically, this is just one of a variety of wide-sweeping changes to the kernel that go many levels beyond a simple patch that "Big Iron" vendors are pushing for. Linus is against it happening in the first place. While Linus and Co. are coming up with a lot of innovative alternative solutions to the problems, "Big Iron" wants to go with proven solutions that they know will work for their systems. In addition, the changes would impact performance on desktop uniprocessor and SMP machines. In essence, these are political issues.
RTLinux has already forked the code to handle this. Basically, RTLinux runs a hard-RT capable microkernel that runs the Linux kernel as its idle process. Basically, when a RT process needs something at exactly a certain time, it will get it and all normal processes will be run under Linux when the system isn't busy doing more important things. There's also the uLinux fork to attempt to make something Linux-like on systems without hardware memory-management units, like the 286. Code forks already exist, often for good reasons.
At the time the first Final Fantasy game was released, it was an all-or-nothing prospect for the fledgling game giant SquareSoft. If Final Fantasy didn't make it, they would've been dead in the water. So, for Square, it very well could've been a "Final" Fantasy.
Fortunately, Final Fantasy did well and so did it's 8 sequels and spin-off games, and so did Square's other games, such as the Seiken Densetsu series. After Final Fantasy II, why change the name of a best-selling series?
(As an aside, Neverending Story Part Two makes a lot of sense if you think in terms of chapters.)
Actually, Photoshop for the Mac was the original. It was written in the MacApp application framework. When Adobe ported Photoshop to Windows, they actually ported MacApp to Windows to get it to work. I don't know if Photoshop is still MacApp based, but the Mac version was first.
According to this page, the 750 MHz models have a maximum power dissipation of 70W. While it does have the ability to reduce the clock speed by 1/2 to 1/32 for EnergyStar compliance, you're still looking at a possible max power consumption of 560W.
Better hold off on that fantasy until we perfect a portable micro-fusion reactor.
That's funny, because none of the stats you cited indicated that you meant for game play. You talked about CPU, RAM, and HDD. If you were really talking about that, then you should've included graphics card stats. Of course, none of that would've given us a clue since you were just talking about "blowing it out of the water."
Face facts. A Solaris machine has far more memory bandwidth, far more i/o bandwidth, far faster math calculations (especially FP), and has far more support for multi-processing, including more advanced bus-negotiation schemes than little old SMP.
What you mean to say is that your little graphics card could blow the unmentioned Solaris box's graphics card out of the water (if the unspecified machine you are spouting off about even has one). Fine. Whatever. You're just trolling and spouting nonsense when you've never actually had any experience with what a real piece of hardware can do. It's not like your little machine would have a chance against a 4-way or more Solaris box doing OpenGL in software.
Further, does UT even run on Solaris? Stupid OS...
No, stupid UT. It's not Sun's fault that it hasn't been ported to Solaris. It's the fault of Epic for realizing that people buy a Solaris box for work, not for screwing around when they should be in class learning about how real computers work.
Dude, that was sarcasm. I hate it when people can't get that without my having to use tags. I've seen Windows NT 4.0 on a 486 that some clueless techs installed on a computer at my mom's school because they were order to update the OSes on machines in the classrooms. It's hideous. Reread my response with the thick layer of criticism that I laid on it.
BTW, Windows NT won't run on a 386. I know because those idiots tried it.
Duh. Why pay when you can get the crappy x-window interface for free?
You can't run it at the same time as the Quartz graphics layer. This means you can't run Carbon, Cocoa, and Classic Mac OS X apps at the same time as X apps. You might as well dual-boot into Linux at that point. What's the point of having Mac OS X at that point?
Where, exactly, have I or anyone stated that X11 is without flaws?
"And since X is a protocol, it is neither slow, buggy or holding anything back any more than HTTP is slow, buggy or holding the web back. So can we please stop with the 'X is bad' rhetoric?"
That sounds an awful lot like you're saying X is good, which it blatantly isn't. X is bad. It's incredibly bad.
Perhaps one day a better windowing protocol (Berlin?) will supplant it like HTTP did to Gopher, but that day isn't here yet and the work continues.
What, you mean like NeWS or Display Postscript? Both lost badly to X in the days before it became a standard. Superior code does not equal inevitable domination. Just look at Windows. Just look at X. I really hope the Berlin project takes off, but don't hold your breath. X has shown an amazing ability to crush better written competitors because of its wider adoption and better availability. We'll see.
I'm sick of hearing this nonsense about American apathy from people like Jon Katz. It's time that we put a stop to this. I vote that we... that we... ah, screw it. I don't give a damn anymore.
Seriously, though, the Net isn't a hotbed of political activity. The Net is where people go to bitch about politics rather than actually do something about politics. This is why things like DMCA, stupid patents, and UCITA get gotten away with. Rather than let their frustration build until it charges them into action, most Netizens just let it all out on discussion boards and think of themselves as having "educated" someone else on-line, who probably won't do anything about it either.
Yes, there is an overhead. All X applications still have to formulate their drawing commands into X drawing commands and pipe them through the high-speed local socket. The local X server then has to read the command from the input, decode and interpret them, and then call its API calls to draw them.
The alternative is to have the application go straight to the graphics APIs and do it itself. There may be no network slowdown, but the above is a major slowdown. Even DPS had a slight slowdown on the local machine compared to straight rendering. Personally, I hope GNUStep takes off too. It would be good to see the UNIX world with a free, well written, exportable graphics layer.
Why, yes. X11 is a protocol. So is Windows' SMB protocol.
Being a protocol doesn't mean that it isn't inherently flawed. X11 and SMB are very much alike in the fact that they are a series of hacks, forced inconsistencies, and special cases for backwards compatibility. They are both dangerous to run in kernel mode because there is no clean way to implement a broken standard. You may eventually reach stability, but there will still be occasional "gotchas," and your code will never be clean and well designed.
If you don't believe me, try actually reading some of the ICCCM standard sometime.
Try reading some of the sections of the Unix-Hater's handbook dedicated to X, like this one.
If you honestly think that just because X11 is a protocol that it's not inherently flawed, then you obviously have never tried to implement someone else's protcol before. There is a major difference between implementing something clean and simple and something that is a complex mass of special cases. Yes, you still want X for a Mac, just the same as you want SAMBA for Unix boxes, but don't go thinking it's not a flawed system. X is an albatross hanging about the neck of the Unix world. It's a great example of how superior products can be crushed by flawed but free alternatives.
Or does this seem a bit silly to port Xfree86 to OS X?
XFree86 was ported to Darwin, not Mac OS X. The difference is that Darwin had no graphics layer controlling the screen, much like Linux itself has no graphics layer controlling the screen.
Tenon's solution is very different. It goes through Mac OS X's drawing APIs, while XFree86 controls the screen directly. The XFree86 port was to give people running Darwin, and not Mac OS X, a GUI (of sorts).
Geez. This is only brought up in every single discussion thread about Mac OS X or Darwin since Carmack announced his intention to port XFree86 over a year ago.
Apple did a lot of work to get their X server working...
This X server is not made by Apple. It's made by Tenon. Also, Apple's current Display PDF system is not the same as an X server, if that's what you meant.
Well, I once worked at a mission-critical transaction processing software company in tech support, and both of my managers were very good at handling support calls that got escalated to them. Neither of them started out as managers. (Neither of them seemed to be really good at managing itself, as office and customer politics were a large influence in why I left.) I now work for a GIS firm, and my boss is an ex-techie. His name is all over the entire code base, and he is a very competent programmer. So far, he seems to be an extremely effective manager as well. That, or else my new company just doesn't have office politics that touch my job.
Anyway, YMMV. Not all managers are bad. It seems to really depend on what their background was. I have little respect for people who are managers because that's what they majored in in college. In my experience, anyway, that is that major that all the people who couldn't hack something serious take, and it really doesn't teach you anything about managing people that you wouldn't know or easily learn if you had the "knack" for it already.
A revision A and revision B iMac both have two SO-DIMM sockets. Due to space constraints, one socket can take a 2" SO-DIMM, but the other one can only take a 1.5" SO-DIMM. You can get a 256 MB 2" SO-DIMM and a 128 MB 1.5" SO-DIMM to max out at 384 MB of memory in your machine. That's more than enough for Mac OS X Beta.
The guy who wrote the article is talking out of his ass. Like Colonel Klink from Hogan's Hero, he "knowz abzolutely nuttzing." The Beta system requirements are likely to be higher than those of the final version, but you can expect them to be a little high too. The main reason for this is that you need to support both the memory needed for the straight Mac OS X environment and the Classic environment. You're effectively running two seperate OSes at once. The Classic environment is a resource pig because of that.
I couldn't have said it better myself, although I've tried before.
I'm not surprised considering how much of the article was filled with FUD and uninformed nonsense.
This guy's speed claims are just so much bunk. The same guy who claims that his emulator will run at the same speed as a real Power Mac G4 claims that Windows NT runs just fine on a 486/33. Whatever. Anyone who has actually seen this tried knows what a joke it is. I'm sure, though, if you're used to emulating machines that were already slow, then you're used to sluggishness.
The reason why Apple dumped support for legacy Macs with Mac OS 8.0 was because of the continuation of attempts to scrape out all the m68k code from the OS. Mac OS 8.0 was the first version of the Mac OS to have a 100% PowerPC-native Finder. Apple had warned that when the Mac OS hit 8.0 (originally as Copland) that m68k machines would no longer be supported. Users knew that this was coming. Even though Mac OS 8.0 didn't do all that Copland promised, the timeline for m68k obsolecence was well-known in the day.
The move to cut off the clones in Mac OS 8.0 was an unfortunate necessity. The clones were devouring Apple's revenue, and the move to open up the Mac market to clones honestly should've never been made. Apple should've looked hard at just how much influence IBM has over the PC market before doing that. However, this was yet another bone-headed move from the Scully administration that Amelio and Jobs had to clean up.
I remember. I was there.
His claims about Mac OS X show just how uninformed he is. The claims of sluggish, broken emulation in the Classic layer have been refuted by many who have actually had experience with the system. (A few apps, oddly enough, act more responsively under Classic in Mac OS X than in Mac OS 9.0.4 itself!) The only real things that are broken in Classic are those that require raw access to the hardware below the system or that muck about in areas of the system that they shouldn't be.
Well, good! That's a modern OS doing its job. Those kinds of application need to be replaced with better written ones. Too much backwards compatibility for people who refuse to modernize their code is the bane of Windows and the x86 processor family.
Also he whines about memory requirements without fully considering the fact that Mac OS X Beta is Beta! It's not the trimmed and optimized final version that will be shipping. The 128 MB requirement, with 192 MB suggested, is probably not the final system requirements. Most of the reason for this huge requirement is the Classic environment. Yes, that's right. Mac OS X requires huge amounts of RAM because it runs an emulator. You didn't think that they could emulate an OS that allows unprotected access into low global system memory without allocating it its own memory space to work with, did you?
The very suggestion that Mac OS X won't run on the machines it was promised to is bull. There isn't a G3 or G4 based machine that can't get up to 128 MB of RAM today. Even the old revision A iMacs can get up to 384 MB with 2 SO-DIMM sockets. The G3 system with the least RAM expandability is the first G3 PowerBook. It can only go up to 160 MB, well within Apple's requirements. Even iBooks can get 320 MB of RAM.
"Oh, no. I don't have enough RAM in my machine. It must be obsolete! Damn Apple and their evil marketing. Now I have to buy a whole new machine." Come on! Upgrading a 3 year old machine to run Mac OS X is less than $300 for most people. That's nothing in the PC world. Try running Windows 2000 on an average machine from 3 years ago. It's not going to be very usable. Apple is making a suggestion for having a usable system. Wait, I forgot. "NT 4.0 works on a 486." Riiiight...
That brings me to his claims that no one has to upgrade their machines in the PC world. That's perfectly true. You don't have to run the latest version of Windows or Office. You don't have to run the latest games. You don't have to run anything that didn't come out within 1-2 years of your PC purchase. You might want to, but system requirements in the PC world have followed Moore's law more than CPUs themselves. It isn't until the past two years or so when most software started to only require a 233 MHz Pentium II or higher. The higher cost of PC maintenance is a well-known phenomenon. Even average home users upgrade at least 1 or 2 components of their system per year.
Finally, thank you, Slashdot, for this article. For once I can be proud, and say "This is news for nerds! This is stuff that matters!" How often does that happen? Well, not nearly enough.
This wasn't news. The only news involved is that he's pitching a hissy-fit and giving up on his product. This was just a little uniformed rant that happened to agree with your opinions. Considering the kind of articles you've griped at in the past, I'm not surprised you consider an open flame full of anti-Mac half-truths and FUD to be newsworthy.
I'm not sure I want what you're smoking. It seems to be a bad trip.
What Makefile hell are you talking about? If you're talking about the directory structure, that's easily enough fixed in the Makefiles. Personally, I think the bundle system will improve many of the problem of uninstalling software that is downloaded and 'make config; make install''ed.
What filching of Open Source are you talking about? Everything they are using that was open-source is was either under the BSD license and is now licensed under another Open Source license, or it was GPL'ed and is still GPL'ed. Charging for GPL'ed stuff is not in violation, or else people like RedHat would've been in trouble a long time ago.
Your portion of reality doesn't really seem all that rational. It just seems to be a lot of unjustified accusations. Of course, that's assuming that this isn't just some lame troll. I wouldn't be surprised since this post started at (Score: 0).
You've apparently never used a case-insensitive system, have you? Try creating 'bAR' and 'Bar' in the same directory. Try creating them in seperate directories and moving them to the same directory.
Case insensitivity creates ambiguity in file names. There is no functional reason why I should be able to create both 'MyReport.latex' and 'myreport.LaTeX'. Having both is a workflow problem in determining which is which. There can also be problems with accidentally creating new files when you meant to overwrite an existing one. A case-insensitive filesystem helps average users avoid getting themselves into such a mess.
The main reason to have a case-sensitive filesystem is to support the generation of randomly named temp files, such as 'GBVhX88r' and 'gbVHx88R'. The names carry no semantic meaning, but having a case-insensitive filesystem complicates the hashing functions generally used to create such temp files. The only real reason to support filenames like that is when for when knowing the semantic meaning of a filename is unimportant.
This is good for server systems, but the advantage in simplifying the creation of such files is outweighed by the possible confusion and ambiguity for common user-oriented tasks. This is why most consumer OSes, such as the Mac and Windows use case-insensitive file semantics. Most server OSes, where the user is not as important, are case-sensitive.
Not really. Apple is making no efforts at all to woo Open Source developers since they know that for most of them it's an all or nothing strategy. They're just trying to be nicer to their existing developers by giving them access to parts of the system they wouldn't previously have had.
Most of the people working on Darwin are Apple employees. If you really think that not being Open Source is a death knell, then you really don't understand how the market works or how common, non-techie users think at all.
Oh, great. Another "I'm not interested, so we shouldn't have this on Slashdot" post by someone who thinks that their opinions and tastes reflect that of the entire Slashdot community. Haven't we done this before, ad naseum?
Get over yourself. Some of us like to keep up to date on Microsoft's anti-competitive nature. To those of us who love to play Bungie games on non-Windows OSes, this is not a good sign. If you don't like it, don't read it. There's always the option to filter MS news items.
You think you're tired? I'm sick unto death of people like you going around discussion threads I like to read bitching about their very existance. I think I just about overdosed on it when Slashdot started carrying anime info.
Bunch of whiners. Get the point of Slashdot. It's not just about reading what you like and censoring what you don't. The whole point of the moderation system and the ability to customize your Slashboxes and home page is that you don't have to see this stuff if you don't want to, but your opinion shouldn't be able to demand that no one else can.
Heck, I can't stand Jon Katz, but guess what -- I got over it. I just don't read his articles, even when the front page excerpt is so vacuous and full of misinformation as to send my blood boiling, such as whenever he starts babbling nonsensically about role-playing games he seems to have never actually read, much less played.
Why don't you grow up and realize that many people here are interested in what MS does. Your opinion is just one amongst many, not The One.
Excuse me? You've read Heinlein's "Starship Troopers" and you think the movie was good?
That movie was a butchery. As soon as I heard that the director of "Showgirls" and "Total Recall" was adapting one of my favorite Heinlein novels, I thought I knew what I was in for. Oh, was I wrong. It was much worse than I could've expected.
"Starship Troopers" is a coming of age story. It's all about Rico learning to become a man in the military. The story is supposed to focus on him growing up, not on the Aron Spelling-esque high school "romance" that the movie foists on you as character development. The Hugo-award winning plot behind it all was essentially thrown out the window and replaced with a cheap, sleazy soap opera. Just the attitude of it made me want to take a shower afterwards. Of course, that's the effect any American Paul Verhoeven movie has on me.
Then, let's talk about the way they took all the cool action-movie elements and ruined them too. First of all, power armor. Where the hell was the power armor? This was a great opportunity for them to show off the Hollywood movie magic. I mean, these lunks of high-tech weaponry and steel lept a half-kilometer at a time, leaving mini-nukes behind at every jump. How badass is that? But, nooo...
They instead spent that special effect magic on ruining the Bugs. What happened to the cool technology that the Bugs had? We supposedly stole tech from them. Instead, the director decided to go with the biotech flavor of the year and create nonsense such as Bugs travelling via faster-than-light plasma spew (which orbiting ships could dodge, incidentally).
Let's talk about how they screwed up the military. The (unarmored) soldiers are all carrying weapons with a half-mile effective range. What do they do? Do they build trenches and begin shelling the enemy lines with artillery? Do they line up and begin slaughtering the enemy waves long before they can even get to them? No, they run up to melee range with creatures that can't hurt them from a distance, surround them so that they could potentially shoot each other, and begin firing after the thing has already gutted one of them. Of course, this is really an excuse to show the horrors of war by blanketing the battlefield with dismembered human corpses. Blech. How cheezy. I'm not going to even go into the ways in which Verhoeven mocks the society that Heinlein set up in the book.
Oh, and where were the Skinnies? One of the best badass perfect action movie moments had to be the 30-second bomb, where they rampaged through a Thinmen colony dropping bombs that delivered a warning that they could've taken them out for real at any time. Oh wait, that's right. You couldn't do that when you got rid of the power armor.
I don't feel like going into the way they raped every character from the book that showed up, including one of my favorites, Sargeant Zim. I guess that's just one side-effect of destroying the plot. I can't believe that you've read the book and still like this awful, awful movie. The only people I've ever met who liked it had never heard of Robert A. Heinlein.
I know that Apple makes their money on their hardware; it's painfully evident in their pricing. However, I think you missed what I was saying.
If Apple released MacOS X on Intel, and it was truly a good OS, then I would buy it, and try it out, and use it. Otherwise, they lose my business, because I'm not buying their proprietary, overpriced hardware, and I certainly don't support their *closed* way of doing business. If that way of doing business changed, then I would respect Apple more.
...and Apple would be out of business. Think of all the OS vendors in the world. There are only a few major types of OS vendors:
Hardware & OS vendors -- Apple, Sun, SGI, IBM, etc.
Software & OS vendors -- Microsoft.
Free OS repackagers -- Red Hat, SuSE, etc.
Non-free OS-only vendors -- Be.
The first group gets all their money from hardware. This includes Apple. The reason to develop the OS is to sell the hardware. In Apple's case, the situation is worsened by the fact that the main reason to buy the hardware is to get the OS, unlike Sun, SGI, HP, etc.
The second "group" is Microsoft. Windows is paid for in three major ways: (a) ripping off the OEMs by forcing them to buy Windows for each machine, no matter what, (b) revenue from other products, such as Office 2000, (c) forcing businesses to buy over-priced versions of their "server" OS to run other over-priced software that MS has convinced them that they need. Apple doesn't really have any way to leverage any of these.
The third group primarily makes money by making installing Linux easier and by promising support. Their software is generated for them at no cost by legions of Open Source programmers. Unfortunately, good GUI design is one of the things that the Open Source community is bad at. You need a Cathedral, not a Bazaar, for a good GUI it seems. The chaotic, feature-obsessed nature of OSS programmers always seems to fly in the face of GUI design goals such as consistency and simplicity.
Also, Apple wouldn't make any money from support since Apple's design goals in creating their OS is to avoid the need for support. The Mac is too easy to use and well-designed to generate a support-based revenue stream.
Finally, we have the fourth group -- the one NeXT used to be in. Be, Inc. makes its money off of selling a relatively cheap OS and only off of selling that OS. Unfortunately, this is not a large enough revenue stream to support the staff of developers that continue to revise and improve the Mac OS, Quicktime, and other Apple software.
Apple could, instead, go the old route of NeXT, Inc. and charge $4000 per seat of Mac OS X. Unfortunately, that would never fly. It would be pirated left and right or it would simply die in the marketplace. Heck, even at $500, it would cost more than some budget computers. Selling it on Intel would also bring about the ire of Microsoft. Cancelling Office or IE for Mac would put a serious crimp in the growth of the Mac OS. Also, vendors who still had to pay the Windows tax and who risked losing their discounts on Windows were reluctant to commit to an x86 Mac OS back in the Rhapsody days.
The fact is Apple cannot realistically sell Mac OS X on Intel. It would tank their business. You don't have to respect that. If you want to continue using an inferior OS because you're cheap, then that's your problem. Apple, quite frankly, doesn't really need your respect.
(Oh, and what's this new platform nonsense? Itanium? Puh-lease. We'll see if it ever comes out and if it can ever outperform Intel's own Pentium chips, much less AMD's Slegdehammer.)
Knowing the history between Apple and Micro$0ft Apple probably only went the *nix route to annoy Micro$0ft.
Actually, no. There's a good bit of history you might have missed if you weren't paying attention 3-4 years ago. Apple saw that the Copland project was going nowhere, so they axed it. They began to shop around for other OSes to buy and convert to Mac. BeOS was the first contender way back in the days before it even had basic things like printer support. In fact, this is what got Be the national limelight.
However, Apple saw that they were looking at a company with some really good ideas, but their current work-in-progress was very raw and unfinished. Plus, the head of Be, Inc. was an ex-Apple headknocker who left under less than amiable terms. He wanted to stick Apple with a huge bill for buying out Be.
Then Apple was pointed the way of NeXT, Inc., which was formed by Apple founder Steve Jobs. It was a product that had over a decade of maturity, and established customer base, and a series of visionary technologies that were years before their time. It also had a staff of top-notch, well recognized engineers, such as the head developer of the Mach microkernel. OPENSTEP, the cross-platform version of NeXTSTEP, was powerful, stable, and had a great interface that could be built off of. The fact that UNIX was the source of its stability wasn't a big deal. It was just another bonus.
Still, why didn't they just go all out and run Linux on it. They could cut a load of their development staff and save money if they did that.
No offense, but this one is a serious no-brainer. Mac is strong everywhere Linux is weak. The interface and ease of use is what makes Mac beloved by all its users. To move to Linux would be a slap in the face of the Mac faithful who don't like tinkering with their system because they have to to get something to work. To go from the eligance of the Mac GUI to any X-Windows based solution would be to fall behind Microsoft in terms of UI. Also, it would mean completely abandoning all of their developers who would sooner turn to Windows-only solutions than try to rewrite for Linux/X11.
Furthermore, moving to Linux as the OS would destroy Apple as a hardware company. Why pay twice as much for only slightly better performance than an Lintel system? The reason why people buy Macs is for the Mac OS. Seperating the two or destroying one half of the software/hardware marrage would destroy the entire company. Some common sense should let you see why they wouldn't move to Linux.
Slashdot Mirror
One of the problems is that for many mainframe systems, massively parallel processors are a common feature. Linux's SMP support isn't really that great. There are some massive improvements in the 2.4 kernel, but some fundamental design decisions get in the way.
For example, Linus is a big proponent of a non-preemptable kernel. A preemptable kernel is one that can allow tasks within the kernel to be preempted by other tasks. The Linux kernel does not allow tasks to be preempted by anything other than interrupts.
As an aside, interrupts in the Linux kernel typically run a small bit of code to set up some state information about the interrupt, flag a "bottom half" to run later, and then get the hell out of dodge. The bulk of the work is in the "bottom half," which is a bit of code which is enqueued to run when the kernel gets the time to get around to it. For example, the timer interrupt increments the jiffies (an internal measure of sub-second time), lost timer ticks (ticks that haven't been handled by the bottom half), and flags the bottom half for later execution. The bottom half will later update time-related statistics and service kernel timers.
Basically, though, once the "top half" of an interrupt is handled, the kernel must immediately go back to what it was doing. It is guaranteed that kernel code will not be preempted. This makes the kernel cleaner, easier to understand and maintain, and faster on uniprocessor systems or systems with few processors. However, there's a reason that the Solaris kernel is preemptable. Preemptability is a serious performance enhancer for massively parallel systems, but Linus is not budging on this. There are a number of alternative solutions that the Linux kernel is following, such as its system of "bottom halves," some of which can now be run on other processors in the 2.4 kernel (if I understand correctly). Essentially, a preemptable kernel requires that fine-grained kernel locks be scattered all over the kernel, and that more code in the kernel be considered "critical sections." This is somewhat of a hassle.
Solaris scales extremely well partially due to its kernel's preemptability and heavy use of threads. Solaris's kernel can be preempted by another task and can dispatch kernel threads to work on other processors. This keeps system call hungry processes on other processors happy and well fed. However, it does incur some overhead which isn't justifiable on desktop machines. I'm reminded of a funny quote from the 2.2 kernel mailing list I found once while looking for info on this once: "MVS spends a lot of time running OS algorithms to allow full preemption that Linux wastes on running user applications."
Basically, this is just one of a variety of wide-sweeping changes to the kernel that go many levels beyond a simple patch that "Big Iron" vendors are pushing for. Linus is against it happening in the first place. While Linus and Co. are coming up with a lot of innovative alternative solutions to the problems, "Big Iron" wants to go with proven solutions that they know will work for their systems. In addition, the changes would impact performance on desktop uniprocessor and SMP machines. In essence, these are political issues.
RTLinux has already forked the code to handle this. Basically, RTLinux runs a hard-RT capable microkernel that runs the Linux kernel as its idle process. Basically, when a RT process needs something at exactly a certain time, it will get it and all normal processes will be run under Linux when the system isn't busy doing more important things. There's also the uLinux fork to attempt to make something Linux-like on systems without hardware memory-management units, like the 286. Code forks already exist, often for good reasons.
There's a great article kernel design and impact on real-time systems here:
TradeSpeak.com - White Paper Library: Linux for Real-Time Systems: Strategies
At the time the first Final Fantasy game was released, it was an all-or-nothing prospect for the fledgling game giant SquareSoft. If Final Fantasy didn't make it, they would've been dead in the water. So, for Square, it very well could've been a "Final" Fantasy.
Fortunately, Final Fantasy did well and so did it's 8 sequels and spin-off games, and so did Square's other games, such as the Seiken Densetsu series. After Final Fantasy II, why change the name of a best-selling series?
(As an aside, Neverending Story Part Two makes a lot of sense if you think in terms of chapters.)
Actually, Photoshop for the Mac was the original. It was written in the MacApp application framework. When Adobe ported Photoshop to Windows, they actually ported MacApp to Windows to get it to work. I don't know if Photoshop is still MacApp based, but the Mac version was first.
According to this page, the 750 MHz models have a maximum power dissipation of 70W. While it does have the ability to reduce the clock speed by 1/2 to 1/32 for EnergyStar compliance, you're still looking at a possible max power consumption of 560W.
Better hold off on that fantasy until we perfect a portable micro-fusion reactor.
That's funny, because none of the stats you cited indicated that you meant for game play. You talked about CPU, RAM, and HDD. If you were really talking about that, then you should've included graphics card stats. Of course, none of that would've given us a clue since you were just talking about "blowing it out of the water."
Face facts. A Solaris machine has far more memory bandwidth, far more i/o bandwidth, far faster math calculations (especially FP), and has far more support for multi-processing, including more advanced bus-negotiation schemes than little old SMP.
What you mean to say is that your little graphics card could blow the unmentioned Solaris box's graphics card out of the water (if the unspecified machine you are spouting off about even has one). Fine. Whatever. You're just trolling and spouting nonsense when you've never actually had any experience with what a real piece of hardware can do. It's not like your little machine would have a chance against a 4-way or more Solaris box doing OpenGL in software.
Further, does UT even run on Solaris? Stupid OS...
No, stupid UT. It's not Sun's fault that it hasn't been ported to Solaris. It's the fault of Epic for realizing that people buy a Solaris box for work, not for screwing around when they should be in class learning about how real computers work.
Dude, that was sarcasm. I hate it when people can't get that without my having to use tags. I've seen Windows NT 4.0 on a 486 that some clueless techs installed on a computer at my mom's school because they were order to update the OSes on machines in the classrooms. It's hideous. Reread my response with the thick layer of criticism that I laid on it.
BTW, Windows NT won't run on a 386. I know because those idiots tried it.
Duh. Why pay when you can get the crappy x-window interface for free?
You can't run it at the same time as the Quartz graphics layer. This means you can't run Carbon, Cocoa, and Classic Mac OS X apps at the same time as X apps. You might as well dual-boot into Linux at that point. What's the point of having Mac OS X at that point?
Duh. <g>
Sure, as long as you don't want to run Mac apps and Unix apps at the same time. Might as well dual boot into Linux at that point.
Where, exactly, have I or anyone stated that X11 is without flaws?
"And since X is a protocol, it is neither slow, buggy or holding anything back any more than HTTP is slow, buggy or holding the web back. So can we please stop with the 'X is bad' rhetoric?"
That sounds an awful lot like you're saying X is good, which it blatantly isn't. X is bad. It's incredibly bad.
Perhaps one day a better windowing protocol (Berlin?) will supplant it like HTTP did to Gopher, but that day isn't here yet and the work continues.
What, you mean like NeWS or Display Postscript? Both lost badly to X in the days before it became a standard. Superior code does not equal inevitable domination. Just look at Windows. Just look at X. I really hope the Berlin project takes off, but don't hold your breath. X has shown an amazing ability to crush better written competitors because of its wider adoption and better availability. We'll see.
I'm sick of hearing this nonsense about American apathy from people like Jon Katz. It's time that we put a stop to this. I vote that we... that we... ah, screw it. I don't give a damn anymore.
Seriously, though, the Net isn't a hotbed of political activity. The Net is where people go to bitch about politics rather than actually do something about politics. This is why things like DMCA, stupid patents, and UCITA get gotten away with. Rather than let their frustration build until it charges them into action, most Netizens just let it all out on discussion boards and think of themselves as having "educated" someone else on-line, who probably won't do anything about it either.
Yes, there is an overhead. All X applications still have to formulate their drawing commands into X drawing commands and pipe them through the high-speed local socket. The local X server then has to read the command from the input, decode and interpret them, and then call its API calls to draw them.
The alternative is to have the application go straight to the graphics APIs and do it itself. There may be no network slowdown, but the above is a major slowdown. Even DPS had a slight slowdown on the local machine compared to straight rendering. Personally, I hope GNUStep takes off too. It would be good to see the UNIX world with a free, well written, exportable graphics layer.
X11 is a protocol
Why, yes. X11 is a protocol. So is Windows' SMB protocol.
Being a protocol doesn't mean that it isn't inherently flawed. X11 and SMB are very much alike in the fact that they are a series of hacks, forced inconsistencies, and special cases for backwards compatibility. They are both dangerous to run in kernel mode because there is no clean way to implement a broken standard. You may eventually reach stability, but there will still be occasional "gotchas," and your code will never be clean and well designed.
If you don't believe me, try actually reading some of the ICCCM standard sometime.
Try reading some of the sections of the Unix-Hater's handbook dedicated to X, like this one.
If you honestly think that just because X11 is a protocol that it's not inherently flawed, then you obviously have never tried to implement someone else's protcol before. There is a major difference between implementing something clean and simple and something that is a complex mass of special cases. Yes, you still want X for a Mac, just the same as you want SAMBA for Unix boxes, but don't go thinking it's not a flawed system. X is an albatross hanging about the neck of the Unix world. It's a great example of how superior products can be crushed by flawed but free alternatives.
Or does this seem a bit silly to port Xfree86 to OS X?
XFree86 was ported to Darwin, not Mac OS X. The difference is that Darwin had no graphics layer controlling the screen, much like Linux itself has no graphics layer controlling the screen.
Tenon's solution is very different. It goes through Mac OS X's drawing APIs, while XFree86 controls the screen directly. The XFree86 port was to give people running Darwin, and not Mac OS X, a GUI (of sorts).
Geez. This is only brought up in every single discussion thread about Mac OS X or Darwin since Carmack announced his intention to port XFree86 over a year ago.
Apple did a lot of work to get their X server working...
This X server is not made by Apple. It's made by Tenon. Also, Apple's current Display PDF system is not the same as an X server, if that's what you meant.
It is unforgivable that you are not aware it is Sergeant Schultz, not Colonel Klink, who knows "abzolutely nuttzing."
You are right. I will go hang my head in shame now.
Well, I once worked at a mission-critical transaction processing software company in tech support, and both of my managers were very good at handling support calls that got escalated to them. Neither of them started out as managers. (Neither of them seemed to be really good at managing itself, as office and customer politics were a large influence in why I left.) I now work for a GIS firm, and my boss is an ex-techie. His name is all over the entire code base, and he is a very competent programmer. So far, he seems to be an extremely effective manager as well. That, or else my new company just doesn't have office politics that touch my job.
Anyway, YMMV. Not all managers are bad. It seems to really depend on what their background was. I have little respect for people who are managers because that's what they majored in in college. In my experience, anyway, that is that major that all the people who couldn't hack something serious take, and it really doesn't teach you anything about managing people that you wouldn't know or easily learn if you had the "knack" for it already.
A revision A and revision B iMac both have two SO-DIMM sockets. Due to space constraints, one socket can take a 2" SO-DIMM, but the other one can only take a 1.5" SO-DIMM. You can get a 256 MB 2" SO-DIMM and a 128 MB 1.5" SO-DIMM to max out at 384 MB of memory in your machine. That's more than enough for Mac OS X Beta.
The guy who wrote the article is talking out of his ass. Like Colonel Klink from Hogan's Hero, he "knowz abzolutely nuttzing." The Beta system requirements are likely to be higher than those of the final version, but you can expect them to be a little high too. The main reason for this is that you need to support both the memory needed for the straight Mac OS X environment and the Classic environment. You're effectively running two seperate OSes at once. The Classic environment is a resource pig because of that.
I couldn't have said it better myself, although I've tried before.
I'm not surprised considering how much of the article was filled with FUD and uninformed nonsense.
This guy's speed claims are just so much bunk. The same guy who claims that his emulator will run at the same speed as a real Power Mac G4 claims that Windows NT runs just fine on a 486/33. Whatever. Anyone who has actually seen this tried knows what a joke it is. I'm sure, though, if you're used to emulating machines that were already slow, then you're used to sluggishness.
The reason why Apple dumped support for legacy Macs with Mac OS 8.0 was because of the continuation of attempts to scrape out all the m68k code from the OS. Mac OS 8.0 was the first version of the Mac OS to have a 100% PowerPC-native Finder. Apple had warned that when the Mac OS hit 8.0 (originally as Copland) that m68k machines would no longer be supported. Users knew that this was coming. Even though Mac OS 8.0 didn't do all that Copland promised, the timeline for m68k obsolecence was well-known in the day.
The move to cut off the clones in Mac OS 8.0 was an unfortunate necessity. The clones were devouring Apple's revenue, and the move to open up the Mac market to clones honestly should've never been made. Apple should've looked hard at just how much influence IBM has over the PC market before doing that. However, this was yet another bone-headed move from the Scully administration that Amelio and Jobs had to clean up.
I remember. I was there.
His claims about Mac OS X show just how uninformed he is. The claims of sluggish, broken emulation in the Classic layer have been refuted by many who have actually had experience with the system. (A few apps, oddly enough, act more responsively under Classic in Mac OS X than in Mac OS 9.0.4 itself!) The only real things that are broken in Classic are those that require raw access to the hardware below the system or that muck about in areas of the system that they shouldn't be.
Well, good! That's a modern OS doing its job. Those kinds of application need to be replaced with better written ones. Too much backwards compatibility for people who refuse to modernize their code is the bane of Windows and the x86 processor family.
Also he whines about memory requirements without fully considering the fact that Mac OS X Beta is Beta! It's not the trimmed and optimized final version that will be shipping. The 128 MB requirement, with 192 MB suggested, is probably not the final system requirements. Most of the reason for this huge requirement is the Classic environment. Yes, that's right. Mac OS X requires huge amounts of RAM because it runs an emulator. You didn't think that they could emulate an OS that allows unprotected access into low global system memory without allocating it its own memory space to work with, did you?
The very suggestion that Mac OS X won't run on the machines it was promised to is bull. There isn't a G3 or G4 based machine that can't get up to 128 MB of RAM today. Even the old revision A iMacs can get up to 384 MB with 2 SO-DIMM sockets. The G3 system with the least RAM expandability is the first G3 PowerBook. It can only go up to 160 MB, well within Apple's requirements. Even iBooks can get 320 MB of RAM.
"Oh, no. I don't have enough RAM in my machine. It must be obsolete! Damn Apple and their evil marketing. Now I have to buy a whole new machine." Come on! Upgrading a 3 year old machine to run Mac OS X is less than $300 for most people. That's nothing in the PC world. Try running Windows 2000 on an average machine from 3 years ago. It's not going to be very usable. Apple is making a suggestion for having a usable system. Wait, I forgot. "NT 4.0 works on a 486." Riiiight...
That brings me to his claims that no one has to upgrade their machines in the PC world. That's perfectly true. You don't have to run the latest version of Windows or Office. You don't have to run the latest games. You don't have to run anything that didn't come out within 1-2 years of your PC purchase. You might want to, but system requirements in the PC world have followed Moore's law more than CPUs themselves. It isn't until the past two years or so when most software started to only require a 233 MHz Pentium II or higher. The higher cost of PC maintenance is a well-known phenomenon. Even average home users upgrade at least 1 or 2 components of their system per year.
Finally, thank you, Slashdot, for this article. For once I can be proud, and say "This is news for nerds! This is stuff that matters!" How often does that happen? Well, not nearly enough.
This wasn't news. The only news involved is that he's pitching a hissy-fit and giving up on his product. This was just a little uniformed rant that happened to agree with your opinions. Considering the kind of articles you've griped at in the past, I'm not surprised you consider an open flame full of anti-Mac half-truths and FUD to be newsworthy.
I'm not sure I want what you're smoking. It seems to be a bad trip.
What Makefile hell are you talking about? If you're talking about the directory structure, that's easily enough fixed in the Makefiles. Personally, I think the bundle system will improve many of the problem of uninstalling software that is downloaded and 'make config; make install''ed.
What filching of Open Source are you talking about? Everything they are using that was open-source is was either under the BSD license and is now licensed under another Open Source license, or it was GPL'ed and is still GPL'ed. Charging for GPL'ed stuff is not in violation, or else people like RedHat would've been in trouble a long time ago.
Your portion of reality doesn't really seem all that rational. It just seems to be a lot of unjustified accusations. Of course, that's assuming that this isn't just some lame troll. I wouldn't be surprised since this post started at (Score: 0).
You've apparently never used a case-insensitive system, have you? Try creating 'bAR' and 'Bar' in the same directory. Try creating them in seperate directories and moving them to the same directory.
Case insensitivity creates ambiguity in file names. There is no functional reason why I should be able to create both 'MyReport.latex' and 'myreport.LaTeX'. Having both is a workflow problem in determining which is which. There can also be problems with accidentally creating new files when you meant to overwrite an existing one. A case-insensitive filesystem helps average users avoid getting themselves into such a mess.
The main reason to have a case-sensitive filesystem is to support the generation of randomly named temp files, such as 'GBVhX88r' and 'gbVHx88R'. The names carry no semantic meaning, but having a case-insensitive filesystem complicates the hashing functions generally used to create such temp files. The only real reason to support filenames like that is when for when knowing the semantic meaning of a filename is unimportant.
This is good for server systems, but the advantage in simplifying the creation of such files is outweighed by the possible confusion and ambiguity for common user-oriented tasks. This is why most consumer OSes, such as the Mac and Windows use case-insensitive file semantics. Most server OSes, where the user is not as important, are case-sensitive.
Turn on Graphite. That's the first thing I'm doing on my freshly installed system when the disk arrives.
Not really. Apple is making no efforts at all to woo Open Source developers since they know that for most of them it's an all or nothing strategy. They're just trying to be nicer to their existing developers by giving them access to parts of the system they wouldn't previously have had.
Most of the people working on Darwin are Apple employees. If you really think that not being Open Source is a death knell, then you really don't understand how the market works or how common, non-techie users think at all.
Oh, great. Another "I'm not interested, so we shouldn't have this on Slashdot" post by someone who thinks that their opinions and tastes reflect that of the entire Slashdot community. Haven't we done this before, ad naseum?
Get over yourself. Some of us like to keep up to date on Microsoft's anti-competitive nature. To those of us who love to play Bungie games on non-Windows OSes, this is not a good sign. If you don't like it, don't read it. There's always the option to filter MS news items.
You think you're tired? I'm sick unto death of people like you going around discussion threads I like to read bitching about their very existance. I think I just about overdosed on it when Slashdot started carrying anime info.
Bunch of whiners. Get the point of Slashdot. It's not just about reading what you like and censoring what you don't. The whole point of the moderation system and the ability to customize your Slashboxes and home page is that you don't have to see this stuff if you don't want to, but your opinion shouldn't be able to demand that no one else can.
Heck, I can't stand Jon Katz, but guess what -- I got over it. I just don't read his articles, even when the front page excerpt is so vacuous and full of misinformation as to send my blood boiling, such as whenever he starts babbling nonsensically about role-playing games he seems to have never actually read, much less played.
Why don't you grow up and realize that many people here are interested in what MS does. Your opinion is just one amongst many, not The One.
Excuse me? You've read Heinlein's "Starship Troopers" and you think the movie was good?
That movie was a butchery. As soon as I heard that the director of "Showgirls" and "Total Recall" was adapting one of my favorite Heinlein novels, I thought I knew what I was in for. Oh, was I wrong. It was much worse than I could've expected.
"Starship Troopers" is a coming of age story. It's all about Rico learning to become a man in the military. The story is supposed to focus on him growing up, not on the Aron Spelling-esque high school "romance" that the movie foists on you as character development. The Hugo-award winning plot behind it all was essentially thrown out the window and replaced with a cheap, sleazy soap opera. Just the attitude of it made me want to take a shower afterwards. Of course, that's the effect any American Paul Verhoeven movie has on me.
Then, let's talk about the way they took all the cool action-movie elements and ruined them too. First of all, power armor. Where the hell was the power armor? This was a great opportunity for them to show off the Hollywood movie magic. I mean, these lunks of high-tech weaponry and steel lept a half-kilometer at a time, leaving mini-nukes behind at every jump. How badass is that? But, nooo...
They instead spent that special effect magic on ruining the Bugs. What happened to the cool technology that the Bugs had? We supposedly stole tech from them. Instead, the director decided to go with the biotech flavor of the year and create nonsense such as Bugs travelling via faster-than-light plasma spew (which orbiting ships could dodge, incidentally).
Let's talk about how they screwed up the military. The (unarmored) soldiers are all carrying weapons with a half-mile effective range. What do they do? Do they build trenches and begin shelling the enemy lines with artillery? Do they line up and begin slaughtering the enemy waves long before they can even get to them? No, they run up to melee range with creatures that can't hurt them from a distance, surround them so that they could potentially shoot each other, and begin firing after the thing has already gutted one of them. Of course, this is really an excuse to show the horrors of war by blanketing the battlefield with dismembered human corpses. Blech. How cheezy. I'm not going to even go into the ways in which Verhoeven mocks the society that Heinlein set up in the book.
Oh, and where were the Skinnies? One of the best badass perfect action movie moments had to be the 30-second bomb, where they rampaged through a Thinmen colony dropping bombs that delivered a warning that they could've taken them out for real at any time. Oh wait, that's right. You couldn't do that when you got rid of the power armor.
I don't feel like going into the way they raped every character from the book that showed up, including one of my favorites, Sargeant Zim. I guess that's just one side-effect of destroying the plot. I can't believe that you've read the book and still like this awful, awful movie. The only people I've ever met who liked it had never heard of Robert A. Heinlein.
If Apple released MacOS X on Intel, and it was truly a good OS, then I would buy it, and try it out, and use it. Otherwise, they lose my business, because I'm not buying their proprietary, overpriced hardware, and I certainly don't support their *closed* way of doing business. If that way of doing business changed, then I would respect Apple more.
...and Apple would be out of business. Think of all the OS vendors in the world. There are only a few major types of OS vendors:
The first group gets all their money from hardware. This includes Apple. The reason to develop the OS is to sell the hardware. In Apple's case, the situation is worsened by the fact that the main reason to buy the hardware is to get the OS, unlike Sun, SGI, HP, etc.
The second "group" is Microsoft. Windows is paid for in three major ways: (a) ripping off the OEMs by forcing them to buy Windows for each machine, no matter what, (b) revenue from other products, such as Office 2000, (c) forcing businesses to buy over-priced versions of their "server" OS to run other over-priced software that MS has convinced them that they need. Apple doesn't really have any way to leverage any of these.
The third group primarily makes money by making installing Linux easier and by promising support. Their software is generated for them at no cost by legions of Open Source programmers. Unfortunately, good GUI design is one of the things that the Open Source community is bad at. You need a Cathedral, not a Bazaar, for a good GUI it seems. The chaotic, feature-obsessed nature of OSS programmers always seems to fly in the face of GUI design goals such as consistency and simplicity.
Also, Apple wouldn't make any money from support since Apple's design goals in creating their OS is to avoid the need for support. The Mac is too easy to use and well-designed to generate a support-based revenue stream.
Finally, we have the fourth group -- the one NeXT used to be in. Be, Inc. makes its money off of selling a relatively cheap OS and only off of selling that OS. Unfortunately, this is not a large enough revenue stream to support the staff of developers that continue to revise and improve the Mac OS, Quicktime, and other Apple software.
Apple could, instead, go the old route of NeXT, Inc. and charge $4000 per seat of Mac OS X. Unfortunately, that would never fly. It would be pirated left and right or it would simply die in the marketplace. Heck, even at $500, it would cost more than some budget computers. Selling it on Intel would also bring about the ire of Microsoft. Cancelling Office or IE for Mac would put a serious crimp in the growth of the Mac OS. Also, vendors who still had to pay the Windows tax and who risked losing their discounts on Windows were reluctant to commit to an x86 Mac OS back in the Rhapsody days.
The fact is Apple cannot realistically sell Mac OS X on Intel. It would tank their business. You don't have to respect that. If you want to continue using an inferior OS because you're cheap, then that's your problem. Apple, quite frankly, doesn't really need your respect.
(Oh, and what's this new platform nonsense? Itanium? Puh-lease. We'll see if it ever comes out and if it can ever outperform Intel's own Pentium chips, much less AMD's Slegdehammer.)
Knowing the history between Apple and Micro$0ft Apple probably only went the *nix route to annoy Micro$0ft.
Actually, no. There's a good bit of history you might have missed if you weren't paying attention 3-4 years ago. Apple saw that the Copland project was going nowhere, so they axed it. They began to shop around for other OSes to buy and convert to Mac. BeOS was the first contender way back in the days before it even had basic things like printer support. In fact, this is what got Be the national limelight.
However, Apple saw that they were looking at a company with some really good ideas, but their current work-in-progress was very raw and unfinished. Plus, the head of Be, Inc. was an ex-Apple headknocker who left under less than amiable terms. He wanted to stick Apple with a huge bill for buying out Be.
Then Apple was pointed the way of NeXT, Inc., which was formed by Apple founder Steve Jobs. It was a product that had over a decade of maturity, and established customer base, and a series of visionary technologies that were years before their time. It also had a staff of top-notch, well recognized engineers, such as the head developer of the Mach microkernel. OPENSTEP, the cross-platform version of NeXTSTEP, was powerful, stable, and had a great interface that could be built off of. The fact that UNIX was the source of its stability wasn't a big deal. It was just another bonus.
Still, why didn't they just go all out and run Linux on it. They could cut a load of their development staff and save money if they did that.
No offense, but this one is a serious no-brainer. Mac is strong everywhere Linux is weak. The interface and ease of use is what makes Mac beloved by all its users. To move to Linux would be a slap in the face of the Mac faithful who don't like tinkering with their system because they have to to get something to work. To go from the eligance of the Mac GUI to any X-Windows based solution would be to fall behind Microsoft in terms of UI. Also, it would mean completely abandoning all of their developers who would sooner turn to Windows-only solutions than try to rewrite for Linux/X11.
Furthermore, moving to Linux as the OS would destroy Apple as a hardware company. Why pay twice as much for only slightly better performance than an Lintel system? The reason why people buy Macs is for the Mac OS. Seperating the two or destroying one half of the software/hardware marrage would destroy the entire company. Some common sense should let you see why they wouldn't move to Linux.