First Psystar Mac Clones Ship

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

[Apple Acolyte]

Here's the relevant EULA excerpt: "You agree not to install, use or run the Apple Software on any non-Apple-labeled computer, or to enable others to do so."

Re:Movie doesn't show anything

[nawcom]

That movie can be extremely easy to create, it's probably a fake. He films the normal PC in the back with the cable and so on, everything is fine... When the turns to the front of the screen someone takes out the VGA cable, puts it in a display switcher or something, while the monitor is still turned off, and connects a Mac laptop to that display switch. Then the dude turns on the PC, starts recording the screen, waits until the windows starts showing and the other guy switches the signal to the laptop. This was his hand with the camera remains in the same position and it's easy to cut out the transition.. especially since the eyes of the people are focused on the flash where the mac screen is shown. So the movie for me it says nothing, it can be so easily faked i could do it myself if i had a fake. The motherboard is also a Gigabyte based on the "setup-q-flash" message shown on the screen... i don't know if gigabyte would agree to make a Mac clone... Just my two cents

... and let me guess, you don't believe in the moon landing either?

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

[stoofa]

Why don't you just select 'download and keep package' from the software update menu and then just routinely burn your packages folder to CD?

Re:Operation Unsuccessful

[MBGMorden]

Except that in the MacMini, the expansion slots are needed OUT OF THE BOX if you want to do anything remotely graphics related. Your argument would carry a lot more weight if the machine wasn't so crippled in the first place.

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

[RavenChild]

The people commenting on the linked paged are idiots. This is not a typical "Hackintosh." They claim to have EFI emulated so that there is no need to hack your copy of OSX. You are able to install right from the Leopard CD. This isn't using OSx86.

Re:Meh

[grm_wnr]

Thinking about this a little, it appears you should buy a secondhand PowerMac G5. I am almost serious about this.

Re:You Don't Actually Need Software Update

[nine-times]

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

[Jimithing DMB]

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

[Jimithing DMB]

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.