Slashdot Mirror
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?
← Back to Stories (view on slashdot.org)
← Back to Stories (view on slashdot.org)
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.
Thoughts on tech, Software Engineering, and stuff
Taken from their User Guide:
What it will save you is having to by a second Mac or reboot each time you want to go into either Linux or Mac OS [X].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.
you mean Open Firmware? =]
"I would say that 99 per cent of what my father has written about his own life is false." - L. Ron Hubbard Jr.
MOL is almost completely free of hardware emulation. For instance, a custom device driver is used instead of emulating the IDE controller.
:-).
In fact, one could say that it is MacOS X that has been ported to run on MOL
The only thing that is emulated is privileged aspects of the CPU.