Apple Secretly Maintaining x86 Port Of Mac OS X 736
Earlybird writes "According to this eWeek article, Apple has ported the whole of Mac OS X to the x86 architecture and is maintaining it in parallel with the PowerPC builds. Dubbed Marklar, the project is perceived as a fall-back plan, and, quoth the article, 'has apparently gained strategic relevance in recent months, as Apple's relationship with Motorola has grown strained and Apple looks to alternative chip makers.'" Believe what you will ...
Stick with PPC (Score:3, Insightful)
It's one thing to go from 68k to a more powerful PPC architecture. It's another issue altogether to move from a PPC to an Intel or AMD cpu. The emulation speed would be a hell of a performance hit.
Why Mac OS X on PC platform makes sense (long) (Score:4, Insightful)
As we all know, with Linux we have the best free (as in beer) operating system in the market. It's fast, it's stable, it's well-supported, it scales, and it has a GUI environment that although very acceptable to the Linux community, it really is not up to par to the elegance and simplicity of the Mac OS/X GUI (and god spare me some flames, even the Windows XP interface feels better than the "stock" KDE or GNOME shipped with Linux).
On the other hand, we have Mac OS/X, the most amazing GUI out today for any platform. It certainly makes our friend Bill G. jelaous. It also has an amazing rendering engine by sporting PDF under the hood. However, even though it has a great backbone in the form of an open BSD system, the truth is that it is doubtfull the apple folks will get the steam, hype, and generally market support that Linux is constantly getting lately in all media, corporations, and geeks alike. Add to that the fact that Mac OS/X runs only on the PowerPC platform (at least officially), and you get a lot of potential market away from Apple.
So how about this, why not have Apple port it's whole Mac OS/X upper layers to the x86 platform, publish some specs for Linux vendors to "plug under", and run it on top of such Linux-based (as opposed BSD-based) systems???
With this we'd get the great support Linux enjoys in the enterprise (even when I'm first to recognize that BSD is just as good technical-wise, but this is a market-driven world folks), it'd also get the support from the millions of geeks who own a x86 machine, it'd get the support of all the OEMs who would almost inmmediatelly start providing hardware/software products for the platform, and just as important it would get the support of the common user thanks to its simple, elegant, and fast GUI system.
As a matter of fact, I'm pretty sure soon after we could start converting all Wintel users to the new platform ("Mac OS/Linux"?), since a new hardware investment would not be needed. Just a software download and a much lower price than a Windows license (say, 50 bucks?).
I know, some will argue that "what makes Macs different is the tight integration of the OS with the hardware" and blah blah blah, but heck, should this that I propose take off, I'm sure that Apple will have enough leverage to publish standards making this integration much simpler and still remain open, while benefiting everyone.
Note that since the Mac OS layer would sit on top of a MacOS-compliant Linux distro, it means that teckies will NOT be forced to use the Mac OS GUI, since they could use their Linux distro as usual, minus the Mac stuff. They could even keep using their old KDE or GNOME GUIs.
So, how does Apple make money? selling the top layer (software services and GUI), and if they want even selling slick custom-built hardware boxes like they do today with the OS pre-installed.
Now, please stop all the flames about "sotfware should be free and I shouldn't have to pay to use the Mac OS/X layer on top of Linux" and all that. Software should be free, but people also have families to take care of, and Apple's effort should be rewarded by paying them. Case closed.
As for Linux, imagine all of a sudden a flood of trully useable applications being ported from the Mac (and even Wintel) world to the new "Mac OS/Linux". This would eliminate the barrier many have when trying to move from Wintel to Mac: "my apps don't work or I can't access my data".
Also imagine the simplicity of installing, deinstalling, and managing applications that Mac OS would bring (do not tell me how debian, RPMs, etc are great, they suck big time if you ever had to use them regularly; yes I have).
This, I think, it's what would really bring a true competitor to the Windows monopoly. I'm sure that *I* would switch inmediatelly.
And BTW, as an example let's take my own case: I do not use Linux regularly because it's just too darn hard to do anything (unless you _already_ knew how to do it). Sure once you get it working it's fine and dandy, but heck, sometimes to get it to work you have to get the sources, read the FAQs, HowTos, set some flags, find dependencies, get extra libraries, etc.
Likewise, I don't use Mac OS/X because I can't go out and afford to buy a whole new machine architecture. I already have my decent 1.2Ghz Celeron, it works fine, why should I switch and spend US$1,700 just to use a nice GUI?
However allow me to keep my machine, give me the stability and power of Linux, and the elegance and simplicity of the Mac, and you can count me in right away.
Now don't get me wrong, Linux is *awesome* for someone that knows how to use it, or has the time to learn it. I think's it's an amazing platform for Apache, mySQL, PHP, firewalling, routing, Java, Perl, etc, but it could be much more if it was easier to administer and use.
You gotta understand that the people in large corporations are afraid of getting into something they don't understand or think it's too complex, this is why Windows NT has gotten such a large market share; People very close to me admit it, they use WinNT even if they have to reboot it once every 2 weeks because it is *easy* to use. And folks, yes I agree that maybe "they're not qualified enough to have such a job", but the reality is that they are here to stay and always will be here to stay, and Microsoft is counting on them.
Add to all this the distressing fact that the Windows OS _is_ getting better all the time (ask a Win95/98/Me user how many times they rebooted WinXP lately, or check out the Windows
This is the time folks to trully all come together and trully create a second option to Wintel. Let's combine the best of what we have (a Linux foundation, X86 hardware, and Mac OS upper services and GUI layers), and trully create something we can be proud of a few years from now.
So what's the next step? Someone should send this article to Apple's Steve Jobs, and have Steve meet with the heads of the major Linux distros to define some specs that all would follow to support the Mac Layer. Rally some OEMs to make their products "Mac Linux"-ready (so that they could support the tight-integration features that makes Macs such a joy to use today), and rally the big software developer houses and let them know about this and get them excited, and let's all rally behind this effort and give them all the support the open source community is famous for. This could be the beginning of a trully beautiful relationship...
Business as usual (Score:5, Insightful)
If they release on intel hardware it will be for a finite set of manufactures to a limited set of specs, so that they can continue to deliver true plug-and-play. Expect to pay more for intel based hardware that runs Mac OS X.
And don't be too disapointed if your current system is not supported.
-b
Re:Stick with PPC (Score:1, Insightful)
Believable (Score:5, Insightful)
It is much more plausible that Apple is switching the 64-bit IBM Power4 CPU. IBM is presenting this new desktop version of the CPU at Microprocessor Forum on October 15th. The CPU has a mystery vector unit with 160+ instructions, just like AltiVec. There was a post to the gcc-patches mailing list proposing a patch to enable altivec support on the powerpc64 target, and this patch originated from Alan Modra at IBM's Linux Technology Center.
All evidence indicates that IBM will produce a desktop CPU with an AltiVec unit. Apple has hit the wall with Motorola, and are now selling overclocked G4 miracle CPUs just to stay in the game. I think Apple will switch to Power4.
Please... (Score:1, Insightful)
Let's see:
http://apple.slashdot.org/article.pl?sid=02/08/
http://apple.slashdot.org/article.pl?sid=02/04/
http://slashdot.org/article.pl?sid=02/02/17/133
http://ask.slashdot.org/article.pl?sid=01/01/27
And that's just in this last year. Give it up, people! It's not going to happen.
Recompiling (Score:3, Insightful)
Do you have any idea how long it took Apple to get everyone to recompile all their software for the 68k software for the PPC? It took years. If apple had started off telling everyone to compile FAT binaries from the time that Mac OS X was released, maybe we'd be okay. But the mac os x developer community is somewhat mature now, and there is a fairly large mac os x software library. Large enough going back and getting everyone to recompile everything would be hellish.
I'm sorry, you need an emulation layer to help people crossgrade gracefully. This isn't linux. Usually, people don't have the source code to apps they install. People expect to install by dragging a package icon from one window to another, not by typing "./configure; make install", waiting 15 minutes, and then poking through your hard drive trying to figure out where the Makefile install script put its junk.
Gee, there's a great line. "Buy mac os x for the PC! But you won't be able to run any classic mac os apps! Or any commercial apps where the CDs were pressed before april of 2003, or any shareware apps, because the shareware developers will be too lazy to configure confusing FAT binaries for an archivecture they don't use! You can run Microsoft Word, IE, and Fink, though!"
I really hope apple has some plan for dealing with this, some kind of CLR-style "partial compilation" VM thing so that one executable can contain machine code for two architectures without having to take the disgustingly inefficient fat-package route. If every single application has to come with two binaries, one for each of the two architectures, and there's PPC-only shareware apps made by lazy ppc users and x86-only shareware apps made by lazy x86 users floating around.. that's just going to be the biggest mess imaginable.
I can't even imagine what it will be like trying to explain to the average iMac owner why their new software comes with two CDs, one marked "x86" and one marked "PPC". And let's not even get into devices, or software that's been written to use Altivec.
Re:Actually, this idea isn't new... (Score:4, Insightful)
This would have been when Windows 3.1 was the best Redmond had to offer, but I'm not sure the MacOS of that era would have been much better.
Geez, are you kidding? System 7 was FAR AND AWAY better than 3.1 ever was. I remember reading a compariason of System 7 to Win 3.1 in a MacUser issue from back in '90. System 7 formed the basis of the Mac's OS for almost 10 years, and though it was showing a little bit of age as it progressed, it was still a remarkable OS.
Re:Bring it on (Score:3, Insightful)
Re:Leaked Photos of Hardware (Score:2, Insightful)
don't get all excited (Score:3, Insightful)
As such, it would suffer from all the current problems of the Apple platform: no 'cheap' (This does hold promise, though. I've been very disappointed with the GUI speed of OSX, and I'd be very interested in how much of a speedup there would be on more modern hardware.
Why Mac OS X on PC platform makes no sense (short) (Score:5, Insightful)
Apple would die the quarter that OSX became an x86 commodity. On x86 hardware, they'd be dealing with all the vendors that make things for Microsoft as competition, and dealing with unhappy traditional Mac developers that just made the switch to OS X on PPC. They'd alienate the entire Apple infrastructure just to gain a few points on hardware speed that they wouldn't even be able to sell anymore. People won't pay Apple's -slightly- higher hardware prices when they can get the exact same thing (technically) for less.
Apple makes money by selling hardware, that's where the support base they have is, and that's where the company excels. The entire user experience as a whole is what drives Apple sales.
If we do see OS X on x86, we'll see it on the same Apple hardware we see today, just with a different chip in the mix. It'll all be Apple branded, no clones, no over the counter OS sales for plain-jane x86 machines.
This is the ONLY way that an x86 port of OS X makes sense to Apple.
Personally, I'm betting that it'll be the new
Re:Business as usual (Score:5, Insightful)
Think rather, "Apple will design its own motherboards from scratch, with the only thing in common with other X86 boards being the presence of an x86-compatible chip".
They could dispense with lots of the legacy bullcrap that way--use something similar to Open Firmware, eliminate unnecessary layers of BIOS bullcrap, leave out any legacy support for ISA in the chipset, support a reasonable interrupt architecture, whatever else they want.
Plus, software like VMWare could still probably be made to run Windows on such an architecture, since these are the kinds of things that can be virtualized, and the things that aren't necessary. I doubt Windows would run out-of-the-box on such an architecture without some virtualizing mechanism to emulate missing things. But you'd still get better speed than with an X86 emulator on PPC.
I think it would be cool, actually, and even useful if VMWare were ported to it.
Something to keep in mind... (Score:3, Insightful)
Of course then the only problem is backwards compatibility, unless the x86 has a large enough margin over the PPC that it can be effectively emulated (like what Apple did when they switched from 680x0 to PPC).
Re:Stick with PPC (Score:4, Insightful)
All the developers will have to do little more than re-target and recompile. Very little work involved, relatively speaking.
Why would a Carbon app need to be significantly modified to compile on an x86? Does an app for Solaris SPARC need heavy modification to run on Solaris X86? No, it doens't, it needs, well, no modification whatsoever, it just compiles.
Same thing here.
Yes, they would need a new emulator for classic apps.. but many of these already exist for x86, they could probably purchase code if they don't want to do it themselves. it would be no harder than writing one for PPC. PPC and 68K do not have any kind of inherent compatability.
All the 'cheap hardware' idiots, save your breath. (Score:5, Insightful)
Apple sells the experience of using tightly-integrated hardware and software. They can't do that if they suddenly have to make sure their software will work with every home-built x86 whitebox on the face of the earth. What Apple does is something that Microsoft can never do, unless they start selling their own brand of computers and restrict Windows to only run on Microsoft PCs.
Even if Apple ever were to switch to making x86-based Macs (and you, the reader, are significantly more likely to bang Anna Kournikova than to see an x86-based Mac for sale), they would put something proprietary in those machines, maybe even in every component of those machines, and change the Mac OS to refuse to boot if it doesn't detect that proprietary something. That's the only way they'll be able to preserve the 'it just works' aspects that are a major part of their success.
Personally, I think Apple will,very soon, tell Motorola to go piss up a rope (and I say, it's about time!). The new IBM chip has something close enough to AltiVec, and IBM actually gives a shit about improving their products. Now that Mac OS X is truly ready for prime time with 10.2, all Apple needs is to be able to produce machines that will impress the MHz/GHz-obsessed, cock-measuring crowd.
~Philly
Re:Question for OS X users. (Score:3, Insightful)
Re:Question for OS X users. (Score:2, Insightful)
If you run a browser in full screen on one of those you are wasting a whole lot of screen real estate.
Re:Believable (Score:2, Insightful)
I find it doubtful that they even have this port, never mind if they are going to use it. If it does exist, then it has done for several years, yet it has only been leaked now (by Think Secret!)
Directly involved in the development of Marklar is 12 or so people, however the article says: "mainstream Mac OS X team is regularly asked to modify code to address bugs that crop up when compiling the OS for x86." This means that all the OS X developers know about it, as do the internal testers. I don't know the specific numbers, but that's a lot of people, and surely one of them would have let the cat out the bag before now.
Re:Ported all of Mac OS X to x86? (Score:3, Insightful)
Finder is both a Carbon application and a Cocoa application. At least the one on my Jaguar install is. Which means technically its a cocoa app (From what I can tell) but it still links in a lot of carbon code.
But then, most programs are. Its very difficult to write a cocoa application that doesn't hit carbon (Even though you don't link against it) and vice versa... for instance printing is done by carbon, even for cocoa apps.
Carbon is part of OSX and is going to stick around (much as I prefer cocoa and objective C)..
I see no reason to believe that carbon can't be (or couldn't have already been) ported to x86. Odds are most of it is C not assembly anyway.
Re:Apple's Trump Card against MS. (Score:1, Insightful)
It was killed when it became clear MS would bury them alive, mostly by enforcing licenses that at the time forbade OEMs from selling anything other than an MS OS with each box. And of course failing to support Apple with Excel and Word products.
Presumably once the remedy element of the MS trial is overwith and it is clear Apple can move they will.
My hope? They support AMDs 64 bit implementation as rapdily as possible. That would make it a killer, cheap, and pretty fun box wouldn't it?
Heck the rest of the hardware architecture has been PC compliant for years. Why not the processor? It might help lower the price of the box a bit too for that matter.
Re:Business as usual (Score:3, Insightful)
Re:All the 'cheap hardware' idiots, save your brea (Score:3, Insightful)
Now that Mac OS X is truly ready for prime time with 10.2, all Apple needs is to be able to produce machines that will impress the MHz/GHz-obsessed, cock-measuring crowd.
Actually, since Apple is so focused on the multimedia segment, they are really hurting on the hardware side. My $1000 Athlon box is out rendering $3000 G4 boxes. Why? Mainly because of Apples very slow FSB, and relatively slow chips. And no, I'm not just talking about clock speed, even Carmack admits that PPC's are slower then x86's for Doom, and that optimizations for Altivec only have significant value in a limited number of situations. This isn't to say that PPC's are awesome for certain tasks, especially where raw performance is not required. As you said, coupled with OS 10.2, Apple has a very good consumer product.
I'm not saying as a business decision that Apple should do this, but I'm saying that from a purely technical standpoint it would not affect the quality of Apple products.
Re:Nope. (Score:2, Insightful)
Re:I Doubt It (Score:4, Insightful)
Re:Believable (Score:4, Insightful)
Re:Nope.-Another reality check. (Score:1, Insightful)
You were doing fine until you got here. First a lot of the hardware that plugs into the PCI bus on an apple is little to no different than what plugs into the PCI bus on an x86 machine. On all the *standard* buses offered the *only* issue is drivers and that's because the OS it has to interface with is different, not the hardware.
Second ALL Apple has to do is what it already does. Build a *packaged* system, just like Sun, IBM, and others have been doing for years.
Third. The hardest part for Apple is going to be redesigning the *custom* mainboard it uses.
Forth and in conclusion. Ask yourself who does driver development for Apple presently, and how's that any different than what's on the x86 side?
Hint:Your argument is a red herring nothing more.
Re:Switch? Perhaps, but not to x86 (Score:1, Insightful)
You really believe a 2.5GHz P4 is 2.5x faster than the same system with an (underclocked) P4 1GHz?
Believe me (or look for the stats yourself), this isn't the case, it's *way* under this, cause the rest of the system (memory, harddrives, graphics card etc.) still keeps the same...
But you probably still won't believe me, so there are 2 figures out of the SPEC list for CPU2000, submitted by Intel, and using the same MoBo. The 1.5GHz P4 gives a value of 605, the 2.0GHz P4 a value of 702 (not 807, as to be expected by assuming linearity...)
That's only 48% of the "linearly-to-be-expected" gain, and that for exactly the same system otherwise -- and for a CPU-specific test, not real-time apps !!
And then you compare two *totally* different platforms, with testsuites compiled with different compilers, with different FSB of the CPU's, perhaps even different graphic cards etc. and you try to convince us that *there* the linear increase should be visible in real-world performance. Be reasonable!
A few corrections (Score:4, Insightful)
This is a quarter-truth. However, you're ignoring a fair number of issues:
* A port would likely be less tweaked for the architecture (run out of registers more likely, cause cache misses, whatever) for some time.
* Apple didn't port all of the MacOS to the PPC for *ages* (actually, I'm not sure the entire OS ever went native). They just ported critical chunks, and emulated less used bits. If you want to avoid emulation, you're looking at a much larger porting task in a short period of the time.
* Apple could port the OS -- but 99% of applications won't be recompiled for the x86. That means a lot of apps need to be emulated.
Furthermore, your assumption that PPC is automagically more powerful than Intel architectures is a clear indication that you are severiously under-informed.
Actually, he's right, though he simplified things a bit. The PPC has far more registers than the x86 architecture. Any emulation would involve extremely expensive swapping of registers very frequently. I'm don't remember what L1 fetch time on the x86 is, but it's at least one cycle. That means that your PPC code is going to run, at best, at half speed a fair bit of the time.
The reason the PPC could emulate the 680x0 so efficiently is because it had so many registers and didn't have to execute many instructions to handle any single 680x0 instruction. Also, the PPC was a faster chip, so running slow 680x0 code still seemed reasonably peppy to the user -- trying to port PPC code to the x86, a *competitive* line, means looking at some serious slowdown issues.
I won't go so far as to call you a newbie, but your bias suggests that you have a ways to go before you become a seasoned professional. Keep on plugging though, and try to be more open-minded. Consider doing research before forming conclusions, for example.
I think that you owe it to the parent poster to do the same yourself.