A New Project To Run Mac OS X Binaries On Linux(phoronix.com)
phoronix.com
A New Project To Run Mac OS X Binaries On Linux
http://www.phoronix.com/scan.php?page=news_item&px=MTI0Njc
19 comments
Even if you just focused on console apps, that would be a huge milestone for many folks.
One example: being able to run XCode's command line build tools to generate iOS and Mac builds on our Linux CI boxes without a dedicated Mac build slave would be huge.
One example: being able to run XCode's command line build tools to generate iOS and Mac builds on our Linux CI boxes without a dedicated Mac build slave would be huge.
I'd suggest going after source compatibility rather than binaries. It shouldn't be that difficult to check an Xcode project for things incompatible with GNUStep and offer a way to allow ProjectCenter to build binaries on and to other platforms, provided the developer refrained to use Mac-only features. It would be a nice way to collect hard data on what should be considered more important for GNUStep to develop, generating countless other opportunities for students pursuing various degrees.
BTW, is anyone building TextMate for platforms other than OSX?
BTW, is anyone building TextMate for platforms other than OSX?
In similar vein, there is cocotron - a framework that implements Cocoa (OpenSTEP), and other things - http://www.cocotron.org
Interesting project, but probably runs afoul of a whole passel of Apple IP, and so will get nowhere useful.
Ouch. This is not going to be easy. There are some major differences in dylibs versus so's in Linux.
How lovely would it be to be able to run Adobe products on Linux? ... When Apple decided to fuck over Adobe by killing Flash I though the perfect countermove would be to release AdobeOS. They could crowd source the design from its user base, port their products to Linux and be in a very strong position to compete with OSX and Windows. Now that Apple has abandoned its old users for the mass market there's room for an open source OS for the designers, photographers and developers whose needs are not being met.
Photoshop here i come :)
It already runs on Linux, thanks to wine: http://appdb.winehq.org/objectManager.php?sClass=version&...
[deleted]
this has the potential to progress much faster, and much more completely than WINE, after all OSX is already a POSIX system, so many of the elements are already there.
Surely POSIX is the least of it. Mac apps are built on an API that has been much extended since the NeXT days and which even then was a complete wrapper over the underlying Unix OS. Think "copying QT and the whole KDE ecosystem" to get a grasp of the scale of it.
And without access to the source!
I've long suspected that having OS X compatibility for Linux would be easier and more useful than Windows compatibility for many people. Due to their similar underpinnings and less legacy stuff in OS X.
Being able to run XCode , Photoshop and Sequel Pro under Linux would certainly make my life easier.
Whether Apple wants to kill this , support it or be indifferent would I suppose depend on whether they feel threatened by Linux on the desktop.
They may even be happy to push people who are unhappy with the "iOSification" of Apple towards Linux in the future.
Being able to run XCode , Photoshop and Sequel Pro under Linux would certainly make my life easier.
Whether Apple wants to kill this , support it or be indifferent would I suppose depend on whether they feel threatened by Linux on the desktop.
They may even be happy to push people who are unhappy with the "iOSification" of Apple towards Linux in the future.
> Whether Apple wants to kill this , support it or be indifferent would I suppose depend on whether they feel threatened by Linux on the desktop.
They may even be happy to push people who are unhappy with the "iOSification" of Apple towards Linux in the future.
Given Apple's behavior in the past and in other areas, I would be very, very surprised if they were to condone (let alone promote) anything even remotely resembling OS X applications on another system.
While I don't think either outcome is likely, I'd be more willing to bet on them invoking some absurd copyright law to try and prevent this kind of work from happening (something along the lines of Oracle vs. Google).
Given Apple's behavior in the past and in other areas, I would be very, very surprised if they were to condone (let alone promote) anything even remotely resembling OS X applications on another system.
While I don't think either outcome is likely, I'd be more willing to bet on them invoking some absurd copyright law to try and prevent this kind of work from happening (something along the lines of Oracle vs. Google).
[deleted]
Less legacy, eh? Well, I guess there has been less emphasis on compatibility throughout the years, but NeXTSTEP is older than Windows NT...
While I agree with your point, I'm not sure if Windows NT is the correct comparison.
- Windows 1.0 released November 1985 [1]
- NextStep 1.0 releaed September 1988 [2]
1. http://en.wikipedia.org/wiki/Windows_1.0 2. http://en.wikipedia.org/wiki/NeXTSTEP
- Windows 1.0 released November 1985 [1]
- NextStep 1.0 releaed September 1988 [2]
1. http://en.wikipedia.org/wiki/Windows_1.0 2. http://en.wikipedia.org/wiki/NeXTSTEP
I felt NT was an apt comparison because not only is it the basis for the current Windows, it also was their first 32-bit offering, i.e. where stuff got serious. 16-bit Windows was a fairly different beast. 9x was certainly influential but (1) is now dead and (2) came after NT, borrowed lots from NT in the beginning. In light of this, drawing comparisons between 1.0 and Win8 doesn't seem all that appropriate to me.
I see where you are coming from.
I guess my hesitation was caused by the assumption that while windows before NT was all 16 bit / 32 bit hybrid; it's API's are still essentially the same which is what you would care about when re-platting an API.
However I will concede my argument like a true gentlemen, as I now realize the ABI is what we should care about. It is almost certainly different even if the API's haven't fluxed that much, and that is what a re-platt project would most care about.
I guess my hesitation was caused by the assumption that while windows before NT was all 16 bit / 32 bit hybrid; it's API's are still essentially the same which is what you would care about when re-platting an API.
However I will concede my argument like a true gentlemen, as I now realize the ABI is what we should care about. It is almost certainly different even if the API's haven't fluxed that much, and that is what a re-platt project would most care about.
Windows vista, 7 or 8 are based on Windows NT: they don't have much in common with Windows 1.0.
Just like Mac OS X is a rethinking of Mac OS based on NEXTStep and doesn't have much in common with Mac OS or even system 1.
So yeah, I think the parent's comparison is correct.
Just like Mac OS X is a rethinking of Mac OS based on NEXTStep and doesn't have much in common with Mac OS or even system 1.
So yeah, I think the parent's comparison is correct.
Wait, how can years be a stronger legacy metric than backward compatibility emphasis?
My point was the legacy is there and it's pretty large, should not be understated. Apple may not care so much about compatibility between releases or with NeXT binaries from 1987 (though I don't think Windows code from '87 works so well on NT either), but the old code is there and if your argument is that sort of thing doesn't help binary compatibility, then that's a problem. I was making my point in shorthand fashion, so I didn't even touch on Mach which is very old as well.
People have this impression that OS X is flashy and new and immune to or not experienced in code rot, and I didn't think it rings all that true.
People have this impression that OS X is flashy and new and immune to or not experienced in code rot, and I didn't think it rings all that true.
OS X apps that 'shell out' to the BSD under-pinnings could be an issue. The CLI options can differ between Linux and BSD/Darwin.
That would seem to me to be the least of the problems. Just as you can install GNU coreutils on OS X, you can compile the BSD utilities to run on Linux as well.
I wasn't saying that it was impossible to run them. I'm just commenting on an issue that was immediately apparent to me.
If a program calls '/usr/bin/nc' and expect BSD options, it's not going to get them. "Replace GNU coreutils with BSD coreutils" is an option, but not one that everyone would be ready to jump at, because now things running on your Linux system that expect GNU options won't be getting them.
If a program calls '/usr/bin/nc' and expect BSD options, it's not going to get them. "Replace GNU coreutils with BSD coreutils" is an option, but not one that everyone would be ready to jump at, because now things running on your Linux system that expect GNU options won't be getting them.
You can use chroot to solve this problem.
You can use chroot, or you can have the OS X porting layer delegate those calls to the BSD tools transparently.
chroot!
[deleted]
A shim to handle common tools and remap the options would be feasible.
I wonder if they could use anything from the Magenta project, an attempt to make an iOS-compatible Linux implementation.
Website: http://crna.cc/magenta.html + http://crna.cc/magenta_source.html
HN discussion: https://news.ycombinator.com/item?id=4087224
Website: http://crna.cc/magenta.html + http://crna.cc/magenta_source.html
HN discussion: https://news.ycombinator.com/item?id=4087224
This mostly sits at a higher level than Magenta does -- you don't need kernel support for Foundation/AppKit ABI compatibility.
Full support for Photoshop is one of the main things that keep me from being able to be fully linux
You can run Photoshop through Wine ( http://www.winehq.org/ ) quite easily.
Details here: http://appdb.winehq.org/objectManager.php?sClass=version&...
Details here: http://appdb.winehq.org/objectManager.php?sClass=version&...
An older such project, that already works for numerous use cases (such as running parts of Apple's toolchain) is maloader.
https://github.com/shinh/maloader
https://github.com/shinh/maloader
actually, darling is based on maloader. (or, at least, uses parts of its code)
Darling = darlin' = DARwin on LINux?
Yep. (The flashing cursor on the Wiki page gives it away.)
How long will this project be relevant considering that apple is planning on switching its processors from intel to some apple unique processor soon? If it is similar to the switch they made when switching to intel, nothing will be compatible.
The project will never really be relevant. If you have a serious need to run OS X probably already have OSX and a Mac.
If you need to simultaneously run Linux you install it in a VM.
This project like WINE for the most part will always be a "look what I can do" type project. It's never going to be a rosetta type system designed to bridge ecosystems as the VirtualBox / VMWare bridge already works quite well.
If you need to simultaneously run Linux you install it in a VM.
This project like WINE for the most part will always be a "look what I can do" type project. It's never going to be a rosetta type system designed to bridge ecosystems as the VirtualBox / VMWare bridge already works quite well.
Having been disgusted by security holes in Preview and the lack of viable alternatives to Preview/Adobe Reader on OS X, I installed WINE and Foxit Reader on my Macbook Pro. (And used Automator to have it launched as an OS X app.) Google Chrome is ok for a PDF reader much of the time, but there are some really annoying bugs in its PDF functionality. (Which especially impact comics.)
Just out of curiosity, which security holes in Preview are you referring to?
Google OS X PDF security holes.
Every application reports security holes,
http://www.foxitsoftware.com/Secure_PDF_Reader/security_bull...
http://www.foxitsoftware.com/Secure_PDF_Reader/security_bull...
doesn't seem a situation so dire that it warrants being disgusted to the point of installing wine to me.
http://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=apple+coregr...
no vulnerabilities in 2012, one in 2011 and two in 2010.
http://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=apple+coregr...
no vulnerabilities in 2012, one in 2011 and two in 2010.
Note that Apple doesn't discuss vulnerabilities until after they are patched. Will unpatched ones even show up there?
so you are disgusted by something that may or may not exist?
CVE is public and collects both patched and unpatched known vulnerabilities reported by vendors and independent parties.
CVE is public and collects both patched and unpatched known vulnerabilities reported by vendors and independent parties.
Why not X11 + xpdf?
Ugly but works.
Ugly but works.
I also have that set up as an Automator app. Interface isn't as good as Foxit.
After becoming somewhat disappointed with silverlight running in a win VM on linux (constant crashes, no reporting, buggy video driver usage) and being pleasantly surprised by the ease of running netflix desktop (http://www.compholio.com/netflix-desktop/) - I would say this couldn't be any farther from the truth. It's at least one instance of wine that has brought a previous inaccessible web app to the linux mainstream.
I think WINE is relevant now, after very many years of work and bugfixes (Imagine the number of quirks they have found and addressed).
It doesn't really matter, it's a research project. And second of all your statement that nothing was compatible with the Intel switch is completely false. PPC binaries worked just fine for years.
Lastly, there aren't any plans to switch Macs to ARM, it's a rumor.
Lastly, there aren't any plans to switch Macs to ARM, it's a rumor.
And even if there were, Linux runs fine on ARM, so this project could.
Is that confirmed? Last time I checked those were only faint rumors, and switching to a proprietary architecture is not gonna help their bottom line, unless they want to get rid of the PC / Laptop division.
An interesting research project, but don't hold your breath. Apple's private APIs are going to take a very long time to reverse engineer.
Remember how exercised everyone got about Window's private APIs?
Reminds me of Yellow Box (http://www.roughlydrafted.com/RD/RDM.Tech.Q1.07/4B800F78-0F7...)
[deleted]
I would draw the exact opposite conclusion.