Slashdot Mirror
Mac OS X x86 Put To The Test
stivi writes "ZDNet has tested Mac OS X x86 on a Toshiba laptop. The article discusses installation process, performance and power consumption comparison and has a thorough photo gallery as well." From the article: "Mac OS X will not be available on any old x86 PC, though, as Apple wants to retain control over its hardware platform. From the company's point of view, this is an understandable position, as the margins on Apple-branded computers are much higher than is usual for standard x86 PCs. Were Apple to put the x86 version of its operating system on general release, Dell would begin to manufacture Apple clones. This would put enormous pressure on the price of Apple's own computers -- something the company is naturally keen to avoid."
Lexus makes a great car, with a ton of room for third party add-ons and third party service. But their smooth engine and user friendly console won't fit in a Hyundai. Are Hyundai drivers mad?
The engines won't fit in a Hyundai, but they fit in Toyotas and are often found (with trivial modifications) in Toyotas at much lower price points. Another example are Hondas and Accuras. My neighbor owns a 2000 3.2TL Sedan and I have an Accord V6 sedan of the same year. The car is almost identical, with a few more bells and whistles on the Accura. The big difference is the nameplate, not the car.
//No producer of high quality goods should listen to cheapskate NewEgg buyers who don't care for quality and future development.//
... you're painting all newegg customers/products as cheap and/or craptastic. Simply not true.
Not all products on newegg.com are cheap and poorly made.
I put together a very nice system (for gaming) for under $800, all with quality parts from newegg.com. It's been running for four months, with not one problem.
Ok, one problem: Fedora Core 4 won't recognize my wireless PCI card.
Anyway
Frammin' on the jim-jam, frippin' at the krotz!
Everyone else seems to be harping over how Apple will lock out unapporved hardware. I'm interested in the opposite. Will Apple companies to make hardware that Apple has approved but also works for other x86 platforms? This is interesting because I can forsee "Apple Approved" being a quality standard for x86 hardware. That could potentially be a very good thing regardless of your OS or computer manufacturer.
I'll preface this by saying I'm not an Apple pundit, and while my current machine is a Powerbook, my last dozen were all PCs (of the AMD kind).
Why do people get all worked up about OS X being hardware locked? If it were my OS, I'd do the same thing -- not just to secure my profits (though they are entitled, it is THEIR operating system), but to actually standardize on a reference platform that can be supported.
How much of any OS developer's time is wasted trying to account for instabilities in your cheap ass, five dollar, no name, Korean sweat shop motherboard? I don't care if Intel just botched a huge batch of boards, it happens, but trying to accomodate a hundred different chipsets and video cards and ram types and people messing with voltage...
We complain about how this industry has been around for so long, and how computers still aren't that stable? It's because there are N! possible combinations of hardware and software to try and get working together nicely, which is a lofty goal at best.
Call me crazy, but I'm at an age where I just want it to work, and my Powerbook at home always does, and my Powerbook at work always does. Part of that is the quality of the OS, and that's reflected in the (relative, not concrete) stability of the reference platform it's built on.
"All I ever wanted was to see Larry Wall give Bill Gates a Perl necklace."
http://www.eisenschmidt.org/jweisen
Try to add a static network mount. Just drop it in fstab, and it'll all be there, right? . Sorry yet?.
/etc/sysconfig/network, doesn't work on slackware though...
:) And I can assure you from experience, getting your unix app to run on other varients of unix is not usually a piece of cake either.
... with a spiked hammer.
... but yet, Mac OS X is one of the harder common platforms to test on due to the need for special hardware and the lack of developer / "lite" OS versions.
:)
You create static network mounts by editing the fstab? Er...
BTW, mac os x can be configured to use the same files as any other unix, by default it's just set up to check netinfo first. You can modify the lookupd configuration to change this. Yeah, apple does things differently. But hey, different unix systems do to. I mean, I'm used to editing my
Now look at the syntax in `ld' for linking "framework" libraries, and hell, the fact that "framework" libraries exist. If you haven't worked on build systems, you won't understand the horror of that one.
This is a product of apple's development environment. They provide and promote their own dev environment that is not unix based. Well, sort of but not really unix based. Frameworks to me are a better solution than libraries, because they are far more flexible. Your framework can include multiple libraries for different platforms (say, um, x86 and PPC), it can include translations for multiple languages, it can include graphics and help files, etc all in one neat little package. How do you do this with unix systems? You end up with files spread all over the place, requiring installers and multiple archives for different platforms. I can easily delete everything associated with a framework. Deleting everything installed by a library is not so simple.
And of course mac os x supports plain old shared libraries as well.
If you haven't given up yet, try starting a GUI app from the console. Tip: You have to use the special "open" command, just executing it isn't enough.
Not true, you can start an app from the console just like you would on a unix system. Hint: the actual binary is not the yourapp.app folder, it resides inside there.
It goes on, and on. None of these things are all that bad (well, except for the retard who chose to ignore all compatibility and use "-framework name" instead of "-framework,name" in the linker options) but they're all very frustrating for someone developing for UNIX.
They're much less frustrating than getting your unix app running on windows
They're also good reasons to inform any Mac user who claims that "Mac OS X is just UNIX on the inside" just how wrong they are
Depends on what you consider unix... I mean, os x is unix on the inside. However, like many unix vendors and linux distros, they have their own way of doing certain things. At the core though, you have a unix kernel. That doesn't mean that your linux app will just compile and work (although many do just fine if you have the right libraries installed and use X11 for display). Now if you want your unix app to use apple's GUI components and other tools, well then, you're going to have to do more work, as you're leaving the compliant unix layer and using apple's own additions.
All these sorts of issues make it crucial to test on Mac OS X
I'd agree with that, but really it shouldn't be that hard to test. A mac mini costs less than $500. There are also a large number of mac os x hosting companies, not sure but I would think that someone out there probably offers some sort of full account where you could do VNC or something. Maybe... It'd be a good idea at least
I think that a lite version of OSX would not be worth apple's time though, I mean the resources to maintain a sepearate crippled release probably wouldn't benefit apple any. And if they just offered a developer version that is fully featured but runs on cheap x86 boxes, well, I think that would be abused pretty quickly.
It is not the fact that it is beta software. It is just that iTunes is absolutely the worst application that they could have tested.
First, iTunes is the one application in the developer build that comes as a PowerPC application. That means, it hasn't been compiled for a Pentium, but for a PowerPC, and has to be translated to Pentium code by Rosetta. Every other application would have been absolutely on par with its Windows counterpart. I first thought they might have used iTunes deliberately, but it is of course the only one where a Windows version exists, so they had to use this.
Second, iTunes music encoding (which is what was measured) is about the most highly optimised code that you can find. It takes advantage of Altivec on PowerPC, it uses SSE2 and SSE3 on Pentium, and on an elderly G3 it falls back to plain floating-point code, using all the 32 floating-point registers that the G3 has.
Guess what. Rosetta doesn't handle Altivec code. For two reasons: It is an absolute pain to translate to Pentium code, and if an application needs handcoded Altivec optimisations on a PowerPC, then you surely want handcoded optimisation using SSE on the Pentium. Because Altivec is not handled, the G3 version is translated, which is much less optimised. So we are now comparing the translation of plain floating-point code with hand-optimised SSE code. But that floating-point code uses all 32 floating point registers - and Pentium has only eight! So the translated code spends lots of time storing and loading registers, which the Pentium code doesn't. An AAC or MP3 encoder written for Pentium just wouldn't do that; it would try to use fewer variables.
3. iTunes encoding is incredibly processing intensive, while other applications are memory intensive. Memory has the same speed, whether you run original Pentium code or translated PowerPC code. Memory intensive applications tend to use the same time, whether Pentium code or Rosetta-translated code is used. If you copy 100MB of memory, the speed will be exactly the same, whether you use Pentium code or translated PPC code. With compute-intensive code, Rosetta falls behind.
4. iTunes encoding doesn't use any operating system functions. Most apps use the OS a lot, for drawing, user interface, disk access and so on. All OS routines run at full speed, with no translation penalty. Rosetta apps with lots of operating system calls will tend to be quite close to native speed, those without any OS calls will be relatively slower.
So here we have the absolutely worst case for any application: A compute-intensive application, heavily relying on Altivec code, where the much inferior G3 version gets translated to Pentium 4 code. Compared to hand-optimised SSE2 code. Exactly the kind of application where developers would create a native version as quick as possible.
(Note that with a shipping product, iTunes encoding on Windows and on MacOS X 86 will use exactly the same source code and run at exactly the same speed, because Apple will use exactly the same hand-optimised SSE code for both versions.)