Run Mac OS X Under Linux

A user writes, "Just saw at penguinppc that Mac-On-Linux can now run Mac OS X. Nothing like having Mac OS X running on a VT to switch to and from." Cool, but ... why?

Comments

Wow

[medcalf]

So now I can run MacOS X running Virtual PC running Linux running MOL running MacOS X running a Commodore 64 emulator running M.U.L.E. What a deal!

Or just go recursive: MacOS X->VPC->Linux->MOL->(repeat forever).

Re:Wow

[Merlin42]

Uh... NO

VPC is a virtual x86 box while MOL requires a PPC. It sounds like it is very similar to VMware/plex86 except for PPC.

Re:Wow

[foobar104]

Uh... Why not?

Granted this screenshot isn't OS X, it should work there as well.

Sorry, nesthigh, I think you missed it. The OP was talking about running OS X inside a MOL instance, and in order to run MOL you have to be on PowerPC hardware. VirtualPC emulates Intel hardware, not PowerPC hardware. So you couldn't do it.

Your screen shot was obviously taken on a Mac running Linux, which was running MOL, which was running VirtualPC, but the chain ends there.

But I have to chime in with others on this one. Given that Mac OS X is superior in every stinkin' way to Linux (flame on!), why-- other than the mountain climber answer-- would you do this?

Re:Wow

[foobar104]

At this point Linux is the Unix with the most broad support and widest range of Unix apps. If you are running Unix apps Linux makes sense.

What do you want to run under Linux that you can't run under OS X? I mean, we're talking about stuff you'd want to compile from scratch, here, because this is PowerPC rather than IA-32. If it doesn't talk directly to the hardware, you should be able to compile it on OS X with only, at most, minor trouble.

Hell, it's even the same compiler:

Reading specs from /usr/libexec/gcc/darwin/ppc/3.1/specs
Thread model: posix
Apple Computer, Inc. GCC version 1161, based on gcc version 3.1 20020420 (prerelease)

Re:Wow

[jbolden]

The underlying systems are really really different. Porting to OSX can be highly non trivial. Think about all the work that went into getting XDarwin to work. A few examples of the problems:

1) anything that uses the /proc filesystem; which not a small number of apps.

2) Any program that uses an assembly subroutine anywhere

3) Any program that uses elf specific routines

4) Any program that uses a library which can't be ported

Re:Wow

[Dahan]

1) anything that uses the /proc filesystem; which not a small number of apps.

I'm not a Linux user, and I have no idea what apps use the /proc filesystem, but it seems to me that anything that does is horribly unportable. If "not a small number of apps" require /proc, I'd say that the majority of those are poorly-written.

2) Any program that uses an assembly subroutine anywhere

Why can't OSX use assembly? If a program has some x86 assembly, sure, that'd be a problem, but not a OSX-specific one. You can't use x86 assembly on LinuxPPC either. An altivec-optimized assembly routine that decrypts RC5 works just as well on OSX, LinuxPPC, NetBSD, or AIX. See the distributed.net client source code for an example.

3) Any program that uses elf specific routines

Such as...? Again, if there are a significant number of apps that even care what your object format is, I'd say the majority of them are poorly-written. Emacs' lisp undumping business is the only thing I can think of (and emacs has already been ported to OSX and even comes installed in the base system). Whose bright idea was it to intentionally make emacs dump core and try to reconstruct an executable out of the core dump anyways? Oh, that's right... RMS. (Have you seen how many undump routines there are in the emacs source? Daaaamn... but I digress...)

4) Any program that uses a library which can't be ported

Sure, but seeing that I don't buy your points 1-3, I'd say that most libraries would be pretty easy to port :)

Actually, I'd say the main barrier to porting to OSX was that it doesn't use the X Window System for its GUI. But since X has been ported to it, that barrier's gone.

A problem that still exists is accessing hardware peripherals, such as playing sound, communicating with USB devices, or the low-level DVD access needed to play DVDs.

Porting to OSX can be highly non-trivial, but most of the time, it is trivial. I think more of the problem lies with developers who learned how to program on x86 Linux not knowing how to write portable code. Even spending some time trying to compile their code on other ports of Linux would help them--I've seen a lot of 64-bit-unclean code when trying to compile stuff on an Alpha (no, you can't cast a pointer to an int... why do you even want to?), and some code that assumes little-endian byte ordering too.

Sounds like VMware for PPC

[Van Halen]

And it even says so in the FAQ, except that the author hasn't ever used VMware, so he can't be 100% sure. The first couple of screenshots look particularly similar to any PC running multiple instances of VMware...

As for the questions asking why, I suppose it's the same reason you might want to run VMware on an Intel machine: develop/test for multiple platforms without rebooting; or get capabilities only available in one or the other without a reboot. What would be much more interesting to me is MOL (or equivalent) for OS X. Just like running Linux or FreeBSD under VMware for Windows, it would allow me to run LinuxPPC or maybe even NetBSD under OS X (Classic already takes care of OS 9, and probably better than this program could). And unlike the VMware on Windows case, my host operating system would be enjoyable to use. ;-)

Why?

[eswierk]

Providing tech support for Mom is a lot easier when you have MacOS and apps running on your own box at home, even if it is slower than on Apple hardware.

Re:Ermm.. Wow.

[jbolden]

Sorry you'll also need the firmware and that is copyright Apple. Unless Apple decides to make it (unlikely IMHO) you are SOL.

Interesting

[AnalogBoy]

Linux runs on my urinary tract - front page news, 5000 comments.

MacOS runs on Linux - Apple section (? I dunno, i have everything on the FP) and the statement "but why...?"

Re:Ermm.. Wow.

[zephc]

you mean Open Firmware? =]