First Psystar Mac Clones Ship 466
An anonymous reader writes "According to Gizmodo, Psystar has begun shipping its Macintosh clones, thus proving that the company is not a hoax. Initial impressions seem to be positive, though Software Update does not work."
Re:So.. shall the bets begine (Score:5, Informative)
Re:Movie doesn't show anything (Score:2, Informative)
Installing OS X on PCs is old news. Certain Gigabyte motherboards come with hardware that OS X has driver pre-installed for, and everything else is community supported.
Here's a "fake" forum if you are lookiung for more info: http://www.insanelymac.com/ [insanelymac.com]
Re:You Don't Actually Need Software Update (Score:2, Informative)
Re:Operation Unsuccessful (Score:4, Informative)
The sad truth is that if you want a Macintosh with upgradeable graphics hardware, it's going to cost your $2200+. I can upgrade the graphics card on virtually any $199 Wal-mart PC. There's a problem here.
Me personally, I've put almost as much money into my homebrew Mac as a Mac Mini would have cost. I have a slightly bigger hard drive (160gb) and more ram than the base (2gb), but those are both options that could be accomodated. The difference is that my system is running an 8600GTS video card. You can't get that out of a Mac Mini at all.
Idiots (Score:1, Informative)
Re:Meh (Score:4, Informative)
Re:You Don't Actually Need Software Update (Score:3, Informative)
I don't think the problem is just that Apple's "Software Update" doesn't work. More likely the problem is that you can't update your OS without causing it to stop functioning. Psystar hacked the OS to run on generic hardware. If you install an update that overwrites part of that hack, your machine doesn't work anymore.
Re:Operation Unsuccessful (Score:5, Informative)
What "EFI layer"? Netkas's PC EFI is a marketing name that Netkas put on his branch of my branch of the Apple-supplied Darwin/x86 bootloader.
The only thing EFI about it is that he supplies some of the runtime services functions. I do this as well except in my version everything returns EFI_NOT_SUPPORTED. It is enough that the EFI system and runtime services tables exist and have halfway-valid information and that where a function pointer is expected that it point to some function. The implementation can be as simple as mov $EFI_NOT_SUPPORTED, %eax; ret.
Nothing bad happens when the runtime services functions do not exist. Even if the one for rebooting the system instead returns EFI_NOT_SUPPORTED the system will still reboot because Apple still has legacy code to do this without EFI runtime services.
The point of my booter is to allow Apple to focus on their own systems and to not maintain legacy code yet still continue to provide open source code that will work unmodified on non-Apple machines. The idea is that anyone can take the code they do release as Darwin and boot it unmodified on most PCs. As a side-effect anyone can also take the Apple-compiled binaries from OS X and do the same. That is, after all, the point of it.
Of course, what I provide does not enable you to run OS X. You still have to provide a decryption engine and decryption keys and I don't help with that. Nor does Netkas PC EFI since the decryption engine, as explained by Amit Singh, is in the "Dont Steal Mac OS X.kext"
None of this has anything to do with EFI. Once the kernel is going, EFI is gone except for two tables and a handful of runtime services functions.
Re:Operation Unsuccessful (Score:4, Informative)
What you don't realize is that you don't have to modify kexts on disk to modify their behavior at runtime.
The way Apple has structured the IOKit you can do everything that needs to be done purely by adding kernel extensions. It is never actually necessary to remove or modify kernel extensions but the hackintosh scene hasn't figured this out yet.
I plan to update my website in due time with the specifics of how exactly you accomplish this. Aside from the issue of the kernel simply not being able to boot unmodified on a P4 I have an otherwise completely update-proof test box with hardware that is not supported out of the box by OS X. It's no different from any other OS really. Add drivers for hardware support. Add drivers that support hardware better than the OS-supplied drivers and keep the OS-supplied drivers from loading when they would cause problems.
For example, consider a typical Windows installation. Microsoft provides a driver for basic ATA support. Once you install a more appropriate driver, it matches the hardware and drives it in lieu of the MS-supplied driver. The biggest difference is that on Windows NT (and derivatives) the plug'n'play aspect is done once when installing the driver. The system records which driver needs to load for a given piece of hardware. In OS X the plug'n'play happens upon each boot. The kernel builds up the IOCatalogue with information about available drivers and then passively matches the hardware using that information. That usually reduces it down to 1 or 2 potentials, usually just one. Then active matching occurs where each driver has a chance to probe the hardware and actively test whether or not it is able to drive it.
All of this is fully documented by Apple. Once you read the effing manual you realize that the current hackintosh methods are insanely stupid.
As an aside, this is why Windows fails to boot on a different machine to that which it was installed on. The Windows bootloader will not load drivers except those declared in the configuration control set registry hive. An OS X installation, if actually done properly, is able to boot on anything. But so far no one has really done an OS X installation properly which is why we see all these stupid machine-specific installation options in hackintosh spins.
As for the ACPI tables, I'm theorizing on that now. I think the clear answer is to write an open ACPI platform expert as such an animal is needed for Darwin to really be considered an open platform. Doing a fully open ACPI PE kext means that various ACPI hacks employed in Linux can be ported to Darwin. Not having a fully open ACPI PE means that it's somewhat questionable as to whether Darwin can be used freely, depending mostly on whether you consider the Apple-supplied kexts to be parts of OS X or parts of Darwin.