Posted by
CmdrTaco
on from the i-don't-hardly-believe-it dept.
Slashfan writes "It has been widely reported allovertheInternet that it is extremely easy to get the Intel port of Mac OS X to run on regualar PC boxes.
Some of the hackers are running the tweaked version of the operating system on their PCs natively." Pardon my skepticism ;)
Linux in on the act...
by
advocate_one
·
· Score: 5, Informative
ha ha... Linux was used to achieve the feat... basically as the midwife OS used in the copying act before kickstarting the new OSX image...
1. Download "VMWare files for patched Mac OS X Tiger Intel" from your favorite torrent site. (Hint: Use the search function).
2. Copy tiger-x86-flat.img from the archive to an external USB drive (it's 6gb)
3. Download Ubuntu Live CD (link)... be sure you get the "Live CD"!!
4. Burn the ubuntu iso, stick it in your pc, and boot it! (make sure you have your bios set to boot to CD)
5. Once ubuntu boots and the gui finally comes up, hook up the USB drive you copied the 6gb image to. A window should pop up showing the contents of the drive. Take note of where its mounted. It should be/Devices/Yourdrivesvolumename
6. Open a terminal window and cd to that directory (/Devices/Yourdrivesvolumename). Do an "ls" to make sure you are in the right place (you should see the 6gb img file.
7. In the terminal window type:
dd bs=1048576 if=./tiger-x86-flat.img of=/dev/hda
Replace hda with the correct drive! If you only have one drive, its probably hda. Thats what mine was. You are about to erase this entire drive so make sure youve got it right and make sure you want to do this! Hit enter. It takes a while... took my vaio about 9 minutes.
8. When it's done, remove the ubuntu disc and shut down the pc. Disconnect your usb drive. Thats it! When you power it back on, OS X should boot!
-- Donald 'Duck' Dunn: We had a band powerful enough to turn goat piss into gasoline.
Re:The same could be said about linux.
by
happyemoticon
·
· Score: 4, Informative
Clearly you've never done anything with drivers. We're doing some driver programming at my company, and let me tell you sir, it's a bitch. We have Dell and Gateway boxes with the same OS revision and everything, but (one particular rev of) the driver makes the Gateway box bluescreen and not the Dell. Hell, we've even had cases where two seemingly-identical Dells were tested side-by-side; one consistently bluescreened, and the other did not. It is a very tricky topic.
And moreover, since we're just talking about the OS running on Intels, it's decidedly not the kernel/processor, which is the lowest level of portability and the level at which Linux almost universally succeeds. One Genuine Intel x86 is pretty much the same as the next, a few register extensions aside. It's the devices which might be attached to it which create headaches. I could set up Slackware or Gentoo on almost any system on the face of the earth with very little difficulty. Now, getting sound to work on one of those systems is another matter entirely. Framebuffer devices will always be a pain in the neck. I'm still working on scanning properly. MacOS uses a ton of OpenGL and other chutzpah for its basic functionality; Linux basically just uses the kernel and a few core tools you'd find on the Slackware "a" diskette set.
The wireless Bluetooth mouse, Bluetooth cellphone, external Firewire HDD's, external Firewire DVD, OEM ATI Radeon video card, external USB printer, Linksys/Cisco wireless network base station, non-Apple LCD monitor, USB pen drive, etc. and EVERYTHING works perfectly with OS X (I am running 10.4.2).
Every single one of the above (except for the ATI card and perhaps the cell phone) uses generic drivers. It is a very, very different matter when you want to support every x86 chipset and SCSI controller in the world.
Darwin is a very different kernel. The interface the kernel exposes is mostly BSD, but the implementation is entirely different.
That said, they can barely port BSD drivers to other BSDs. Between BSDs that aren't as closely related (FreeBSD, OpenBSD for example) it's more a matter of using the other driver as documentation when you rewrite the driver.
Slashdot Mirror
Donald 'Duck' Dunn: We had a band powerful enough to turn goat piss into gasoline.
Clearly you've never done anything with drivers. We're doing some driver programming at my company, and let me tell you sir, it's a bitch. We have Dell and Gateway boxes with the same OS revision and everything, but (one particular rev of) the driver makes the Gateway box bluescreen and not the Dell. Hell, we've even had cases where two seemingly-identical Dells were tested side-by-side; one consistently bluescreened, and the other did not. It is a very tricky topic.
And moreover, since we're just talking about the OS running on Intels, it's decidedly not the kernel/processor, which is the lowest level of portability and the level at which Linux almost universally succeeds. One Genuine Intel x86 is pretty much the same as the next, a few register extensions aside. It's the devices which might be attached to it which create headaches. I could set up Slackware or Gentoo on almost any system on the face of the earth with very little difficulty. Now, getting sound to work on one of those systems is another matter entirely. Framebuffer devices will always be a pain in the neck. I'm still working on scanning properly. MacOS uses a ton of OpenGL and other chutzpah for its basic functionality; Linux basically just uses the kernel and a few core tools you'd find on the Slackware "a" diskette set.
it's on EVERY TORRENT SITE, EVERYWHERE.
:)
christ people, look before you open your mouth
Every single one of the above (except for the ATI card and perhaps the cell phone) uses generic drivers. It is a very, very different matter when you want to support every x86 chipset and SCSI controller in the world.
LOAD "SIG",8,1
Darwin is a very different kernel. The interface the kernel exposes is mostly BSD, but the implementation is entirely different.
That said, they can barely port BSD drivers to other BSDs. Between BSDs that aren't as closely related (FreeBSD, OpenBSD for example) it's more a matter of using the other driver as documentation when you rewrite the driver.
I rarely criticize things I don't care about.