Follow Slashdot blog updates by subscribing to our blog RSS feed

 



Forgot your password?
typodupeerror
×
OS X Apple Linux

Darling: Run Apple OS X Binaries On Linux 255

An anonymous reader writes "After having Wine to run Windows binaries on Linux, there is now the Darling Project that allows users to run unmodified Apple OS X binaries on Linux. The project builds upon GNUstep and has built the various frameworks/libraries to be binary compatible with OSX/Darwin. The project is still being worked on as part of an academic thesis but is already running basic OS X programs."
This discussion has been archived. No new comments can be posted.

Darling: Run Apple OS X Binaries On Linux

Comments Filter:
  • How long before... (Score:5, Insightful)

    by rbprbp ( 2731083 ) on Saturday December 08, 2012 @08:04PM (#42229171) Homepage
    ... Apple finds a loophole and sues this developer into oblivion?
    • ... Apple finds a loophole and sues this developer into oblivion?

      ...if only there was a similar situation we could use to predict how it might go.

    • by jimicus ( 737525 )

      Is it necessary? Wine started out life in 1993 and didn't release a stable version until 2008 - and even now requires a whacking great software compatibility list.

    • by Bogtha ( 906264 )

      I know the summary says OS X, but this is just loading Darwin binaries. You know, Darwin, the BSD-based OS that Apple voluntarily open-sourced? I know Apple have a reputation as the next evil empire, but I think suing people for doing things that they specifically enabled with an open-source release is a bit unlikely.

      • by tlhIngan ( 30335 )

        I know the summary says OS X, but this is just loading Darwin binaries. You know, Darwin, the BSD-based OS that Apple voluntarily open-sourced? I know Apple have a reputation as the next evil empire, but I think suing people for doing things that they specifically enabled with an open-source release is a bit unlikely.

        It also really depends on what Apple would sue for? I mean, if you're running an OS X binary that ships with OS X, like say, iTunes or something, OK, Apple might have a reason to sue. But if y

    • Comment removed (Score:5, Insightful)

      by account_deleted ( 4530225 ) on Saturday December 08, 2012 @09:32PM (#42229749)
      Comment removed based on user account deletion
      • I find it very improbable Apple will sue. I think they'll ignore it.

        You deserve to be mod'ed up. When a similar project [onlamp.com] passed some milestones on NetBSD, there was not even a cease and desist letter which would certainly have been seen as acknowledgement

    • by martin-boundary ( 547041 ) on Saturday December 08, 2012 @10:06PM (#42229963)

      ... Apple finds a loophole and sues this developer into oblivion?

      You leave Apple alone! They worked hard to design a rectangular LCD display for the Mac, and totally deserve their patents. If your laptop has a rectangular LCD and you're running Linux, you're just a cheapskate who's stopping progress and giving Steve Jobs an ulcer. He died because of you, you know!

    • The developer, a university student?

      It would be far cheaper to give said developer an intern job at Apple than the fee Apple's lawyers charge.

    • by Erbo ( 384 )
      If it really uses no code copied from Apple in the implementation, and the author just relied on Apple's own public documentation about their APIs, Apple wouldn't have a leg to stand on. The precedent for this was just established in Oracle v. Google, and the judge's ruling went into sufficient detail to let it be cited as precedent in any similar case.
  • by Longjmp ( 632577 ) on Saturday December 08, 2012 @08:06PM (#42229189)
    ... will I finally be able to cut & paste across applications? *ducks*
    Seriously though, if this is going anywhere near wine, we'd have the best of three worlds on one platform.
    • will I finally be able to cut & paste across applications? *ducks*

      If you're referring to some imagined deficiency of the GNU/Linux operating environment, then explain how I just copied and pasted your comment from Firefox to Leafpad [freeshell.org], composed the reply in Leafpad, and copied and pasted it back to Firefox, all on Xubuntu 12.04. Ctrl+C and Ctrl+V work just as easily to move text around between applications in GNU/Linux as in Windows.

      Seriously though, if this is going anywhere near wine, we'd have the best of three worlds on one platform.

      Cue Apple's lawyers scrambling to find a way around the ruling of API uncopyrightability in Oracle v. Google.

      • by tyrione ( 134248 )
        When GNUStep finally gets full compliance with OPENSTEP API there will be 90%+ of the way there. Chisnall knows this but he doesn't have enough talent to pull ilt off. Apple doesn't care if GNUStep and Cocoa binaries are interchangeable. That is the point of the spec.
  • by Anonymous Coward on Saturday December 08, 2012 @08:47PM (#42229447)

    This is nifty in all, but all their example application is doing is literally the graphical equivalent of "hello world".

    GNUStep still only implements maybe 30% of the Apple APIs out there. And they still don't do them 100% the same way- see NSDecimalNumber for reference (Apple has a really stupid whacked way of doing it, GNUStep's implementation is slightly more sane- but they still shouldn't be straying from what Apple does if they want a compatible API in the end). Things like Core Animation, Core Graphics, Core Image, etc... Forget about it. The GNUStep guys have barely even bothered to look at that stuff, let alone implementing it.

    Sadly, there is a lot more to a modern day Macintosh application then your standard NS/CF classes (even though Core Foundation is kinda opensource). You're not going to see Tweetbot or Cornerstone or Coda 2 running on anything other then OS X for a very, very long time. iOS might be a bit different since the majority of UIKit is very well understood (and there are various other APIs out there designed to re-implement it), so basic iOS applications could probably run with little effort- but for anything using APIs outside of UIKit (again, Core Animation, Core Graphics, Core Audio, Core MIDI, so on and so forth)- nobody has really spent any time on understanding how those work and re-implementing them elsewhere, and a lot of apps hook into this stuff to give you the nifty iOS experience that other handhelds can't.

    In other words, the biggest barrier to this project isn't running OS X binaries on Linux. That's easy. It's implementing the other 70% of the stuff that nobody has even remotely begun to poke at. The OS X API library is vast and expansive, and GNUStep has done a good job replicating what we had on NeXTSTEP in the 1990s- but they've got absolutely none of the modern OS X stuff.

  • by Anonymous Coward on Saturday December 08, 2012 @09:01PM (#42229541)

    I guess if we can run Mail.app the issue of crappy email clients on Linux is solved.

    • even more awesome, we can now run Outlook for Mac on Linux! standard at my work, it sucks even worse and harder than outlook on windows

      • by H0p313ss ( 811249 ) on Sunday December 09, 2012 @02:15AM (#42231281)

        it sucks even worse and harder than outlook on windows

        Clearly you have not had Notes inflicted on you, if you had you would cling to Outlook with all your heart and count your lucky stars.

        • by IrquiM ( 471313 )
          You obviously haven't used Notes since the 90's when outlook was non-existing. The company I work for switched from Notes to a MS-solution a couple of years ago, and I hear more and more of the users wanting to go back to it! An MS based solution with Exchange and Sharepoint might be easier to set up for the sys-admins, but for users, domino is a far better choice! It just works a lot better and the systems are more integrated with each other.
    • The only E-Mail program so far which actually is so slow it cannot keep up with my typing!

  • Actually GNUSTEP as a project works like that: FOSDEM - New Work done - SILENCE - FOSDEM - New Work Done - ... And everyone thinks: Well, why don't they go after Mac OS X emulation as a "vision" because otherwise the project lacks a good mission that inspires new contributions. Actually I thought it for the past 10 years but it always interesting to see how they start off after the annual FOSDEM meeting.
  • Steam (Score:3, Funny)

    by Tubal-Cain ( 1289912 ) on Saturday December 08, 2012 @09:20PM (#42229667) Journal
    Oh joy. Now I'll be running three versions of Steam: All Linux games on the Linux client for to encourage support for FOSS platforms, the Mac client for generic multi-platform solidarity, and the Windows client for the rest of it.
  • A few years ago I regularly built Qt-based binaries on my Linux machine, targeting PPC OS X (10.3). It was pretty slick. I tried to set up a cross-compiling environment later under 10.4 fat binary days, but that proved too difficult, sadly. As it stands now, if I could run apple's native compiler and tools under linux, outputting nice OS X app bundles for Qt apps, that would be pretty slick.

    • A few years ago I regularly built Qt-based binaries on my Linux machine, targeting PPC OS X (10.3). It was pretty slick. I tried to set up a cross-compiling environment later under 10.4 fat binary days, but that proved too difficult, sadly. As it stands now, if I could run apple's native compiler and tools under linux, outputting nice OS X app bundles for Qt apps, that would be pretty slick.

      Start here [apple.com].

  • While I understand it's possible to get Wine working on 64-bit Linux, it's my experience that it's not really supported on a pure-64 bit system... at least not on Slackbuilds.org [slackbuilds.org]
    • It works properly for me on Ubuntu 12.10. I can run Steam, even (Well, I'm not in the beta... and since I had HL2 anyway I went ahead and picked up the THQ bundle, for basically nothing. I gave some money to charity and to the bundlers for administration.)

      It was all bad in 12.04, I couldn't install it and lsb-base at the same time

  • by manu0601 ( 2221348 ) on Saturday December 08, 2012 @10:42PM (#42230129)

    There was a similar [slashdot.org]attempt [onlamp.com]in NetBSD almost 10 years ago. .

    That prehistoric project implemented Mach-O loader, Mach system calls, and has been able to start OS X display server. It felt short actually displaying something useful, and died from lack of user interest.

  • Dine (Score:5, Funny)

    by static0verdrive ( 776495 ) on Saturday December 08, 2012 @11:42PM (#42230481) Homepage Journal
    They should have named it Dine.
  • by JDG1980 ( 2438906 ) on Sunday December 09, 2012 @12:58AM (#42230889)

    I could be wrong, but I suspect implementing the OSX APIs in Linux might actually be easier than trying to implement Win32. Partly this is because OSX is already a *nix-based system, so you don't have to do as many weird hacks with directory mapping and so forth. But mostly I think it may be simpler because Apple has relatively clean APIs and relentlessly deprecates legacy stuff. When you implement Win32, you have to implement literally thousands (if not millions) of hacks and special cases going back to the 1980s. This is not without justification as a design goal – backward compatibility is one of the reasons why Windows has had such staying power in business – but it's difficult for even Microsoft to get the whole edifice running smoothly, much less third parties with no access to internal design documents and source code. In contrast, when Apple switched from Carbon to Cocoa, they were pretty aggressive about deprecating the old framework.

    • I could be wrong, but I suspect implementing the OSX APIs in Linux might actually be easier than trying to implement Win32. Partly this is because OSX is already a *nix-based system, so you don't have to do as many weird hacks with directory mapping and so forth

      OTOH you need to cope with Mach system calls. OS X is a bicephal kernel. There are positive system calls, which are handled by a BSD-derived kernel, and negative system calls, which are handled by the Mach microkernel.

      The Mach microkernel is central to OS X functionality as all process IPC go through Mach messages. And that stuff has nothing to do with Linux stuff

  • I would think that would make it easy to run their apps/programs in Linux.

    But as someone else said, is there anything to run?
  • including CoreData and CoreGraphics equivalents are in place. Until then, it's like watching a drunk athlete play against all-stars, when comparing GNUstep(off a cliff) versus OS X.
    • including CoreData and CoreGraphics equivalents are in place. Until then, it's like watching a drunk athlete play against all-stars, when comparing GNUstep(off a cliff) versus OS X.

      Sure you don't want to stick around and taunt them as they wail into the night then drink their tears as the sun rises over the desolation that their lives have become?

  • by thatkid_2002 ( 1529917 ) on Sunday December 09, 2012 @02:10AM (#42231261)
    If this ends up supporting Adobe Creative Suite better than Wine, then that will be a huge win as it is a very common "why I can't use Linux" excuse.
    How good is Apple's documentation compared to Microsofts? This is important for a clean-room implementation.
  • by Myopic ( 18616 ) *

    It seems like this was a missed opportunity to name the project Mace.

THEGODDESSOFTHENETHASTWISTINGFINGERSANDHERVOICEISLIKEAJAVELININTHENIGHTDUDE

Working...