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
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.
/usr/libexec/gcc/darwin/ppc/3.1/specs
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
Thread model: posix
Apple Computer, Inc. GCC version 1161, based on gcc version 3.1 20020420 (prerelease)
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:
/proc filesystem; which not a small number of apps.
1) anything that uses the
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
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.