17 ms·

Darling – macOS Translation Layer for Linux

300 points by pcr910303 8y ago

peter_d_sherman 8y ago
Something like this is sorely needed by the open-source, not-for-profit, shoestring-resources, cross-platform development community... For example, let's say that I'm writing some cross-platform open source software. And let's say that I am developing this software on a Windows or Linux Box. Now, let's say that for whatever reason, I don't have and can't afford a Mac (a scenario like this is more common than you would think, especially in developing countries...) OK, so now how do I compile/run/test the Mac version of my software -- without having that Mac? ? That's why your software is so important. Anyway, if you can get this fully operational (GUI and everything), you'll solve that problem for that group of software developers... If you're successful, if you prevail... Apple shouldn't sue you... they should help you, because additional software for their platform ultimately benefits their platform. Also, judging by the source, you've done an amazing amount of work so far... I hope you can find the additional developers/contributors you need to take this thing to completion...
- karmakaze 8y ago
  Worth noting that outside of this bubble, macOS has less than 10% market share. Not every software needs to run everywhere. There are other working solutions, JetBrains seems to do alright with Java runtimes.
- MuffinFlavored 8y ago
  > Now, let's say that for whatever reason, I don't have and can't afford a Mac. Rely on some developer(s) spend 10,000 hours of their time for free developing a Mac emulation layer, or go on eBay and buy a $600 used Mac to test on...
  - deleted 8y ago
    [deleted]
  - asark 8y ago
    It may still be too expensive for devs in (very) developing countries or whatever, but I'm pretty sure there are (paid) remote desktop solutions for this. Also you can snag an old mac mini for well under $600, where I am. Like $200-300. It won't be good but that's probably better for testing anyway.
    - scottjg 8y ago
      I offer a service that provides you with your own macOS VM, running on real Mac hardware. https://zeromac.com https://zeromac.com It's billed by the hour, so if you just need to quickly test something, it's pretty cheap. Buying an older mac may be more economical though if you need to develop software long term.
      - MuffinFlavored 8y ago
        This is super interesting. Is it your full time job? What level of success are you having with your idea?
        scottjg 8y ago
        I run it alongside my regular consulting work, so I suppose it's not my full time job. It's also a fairly new business so I'm not too sure how successful it will be yet.
  - axaxs 8y ago
    While your point is taken... I write and contribute to free/open source tools. I can afford a Mac, but will not buy one because there's zero incentive to me. While I'm not sure this project would help, if a free or very low cost proper emulation existed, I'd use it.
  - gchamonlive 8y ago
    It may also be a matter of principle. I won't buy macs even though they are sexy and I have the money for it because I don't agree with its practices. My theoretical customers shouldn't suffer from it though
  - macdice 8y ago
    Or use one of the CI providers that will test your stuff on macOS (alongside Windows, FreeBSD, ...). Possibly for free, if your stuff is open source. I use that for Windows, which I don't personally use at all, and it finds bugs and problems all the time. I wish someone would provide free (!) CI for some rarer OSes and CPU architectures too, but I can dream.
    - viraptor 8y ago
      You can't fully test things this way. Not enough to make a serious release anyway. You can easily pass all tests while not being able to even start the app. You need at least one person with the real hardware to do testing.
      - saagarjha 8y ago
        This really depends on the tests you're running.
        viraptor 8y ago
        True. But in context of: "tests in a CI environment which costs you less than a MacBook", I don't believe anyone would go to the level that avoids those issues. It would take a lot of work and resources to replicate a "real run in clean, real environment".
        saagarjha 8y ago
        Again, this depends on the tests you’re running and how you’ve set up your CI environment.
    - faissaloo 8y ago
      Unfortunately MacOS testing is usually extremely slow due to limited numbers of machines to run tests on.
  - loeg 8y ago
    The nice thing about the former is that that cost is shared across all consumers, whereas the latter would be incurred for every user. The latter approach may still cost less for now (or forever), but it's something to keep in mind.
  - michaelmrose 8y ago
    The logical option c is just to not support mac unless your target market is one disproportionately likely to use macs like developers or artists in the US.
- zapzupnz 8y ago
  > For example, let's say that I'm writing some cross-platform open source software > OK, so now how do I compile/run/test the Mac version of my software -- without having that Mac? You don't. Darling is not a suitable replacement for testing on a real Mac in exactly the same way WINE is not a suitable replacement for testing Windows software. A developer who thinks so is misguided. Virtualising macOS would be more suitable, although the only way to do so without violating macOS' licence conditions is to run the virtualised OS on a Mac anyway. Even then, virtualised macOS lacks hardware accelerated graphics support, limiting the testing of GUI apps at least. > Apple shouldn't sue you There's no reason they would. Nothing of Apple's seems to be infringed, as the system seems only capable of running anything that Apple's open source Darwin OS can. Even if the Darling project reimplemented some of Apple's proprietary frameworks, this could be done based on Apple's open source releases of things such as Core Foundation, etc. The reimplementations of things like AppKit, when done in the future, could even possibly be based on something like GNUstep — which would give that project a well-needed shot in the arm, to say the least. > additional software for their platform ultimately benefits their platform Firstly, any well-written cross-platform software is easily ported to macOS. This is most evident with software intended for FreeBSD but is equally possible with software that originates on Linux; see Homebrew, MacPorts, etc. for the plethora of utilities that began life on Linux but have since become cross-platform, or software made by GNU that is typically cross-platform by design. Secondly, Apple has been down the cross-platform road before, and none of its developers wanted a bar of it. Apps that are developed on other systems but not tested properly on macOS are always heavily criticised by macOS users as feeling foreign and un-Mac-like. Back when Mac OS X was shiny and new, Apple offered three major platforms for developers: Cocoa, their C and Objective-C APIs inherited from NeXTSTEP; Carbon, their C and C++ APIs inherited from Classic Mac OS; and Java, a cross-platform offering to entice developers from other platforms, particularly Linux. Apple deprecated their own Java in 2010 because (A) people really disliked using Java apps, even though Apple's implementation of the JVM was performant and had native support for Cocoa-style controls and (B) nobody was using it, with major preference going to Apple's own Cocoa and Carbon APIs. Apple, and its userbase, prefer apps that are made with love and care _on_ Macs and _for_ Macs/iOS devices/Apple Watches/Apple TVs, respecting those platform conventions by being developed and tested on them.
  - 8y ago
- lostgame 8y ago
  Generally different platform builds are handled by different developers - the codebase has to be modularized to be ported from Windows, to, say, Linux, to start, same with the UI. If you're already porting to Linux, you're already dealing with a UNIX executable, which makes it at least slightly easier to port to MacOS. There are also virtualization services available where you can rent dev time, and decent and upgradeable Macs are not that expensive second hand. I dev on MacOS all the time, and have the same issue with Windows. These days I try to write everything as a PWA to start so I especially don't have to deal with extreme UI/UX pains.
- xoa 8y ago
  >I don't have and can't afford a Mac Why wouldn't you just virtualize, same as any other OS? If you're not virtualizing on Mac hardware than there are a few minor extra hoops to jump through but it's still less work compared to a hackintosh. Performance can be janky if you don't dedicate a video card to it, but something perfectly adequate like a Radeon 560 seem readily available for $60-80 now. There are a few bits of Mac specific hardware these days like the T-series chips, but not even all supported Macs have that by a long shot.
  - simcop2387 8y ago
    Doing so is not legal in most countries. the macOS T&C/EULA/etc. forbid running it on non-apple hardware. This is a large barrier to entry that a lot of people don't want to even approach.
    - qaq 8y ago
      In developing countries piracy is rampant none really cares much about EULAs
- T-A 8y ago
  >OK, so now how do I compile/run/test the Mac version of my software -- without having that Mac? Splurge on a $1/hour or $20/month account with https://www.macincloud.com/ https://www.macincloud.com/ ?
  - electroly 8y ago
    In case anyone is curious, you have to prepay $30 for the PAYG plan, and you get non-admin access to the slowest Mac Mini you've ever used in your whole life. It does technically work to build iOS and macOS apps, though.
jamesu 8y ago
Been experimenting using this to run legacy software and while it seems to work great with command line tools, as soon as you progress onto gui stuff you quickly run into missing functions and libs. Still insanely cool though.
- dehrmann 8y ago
  Especially for MacOs, where you can expect apps to stop working after a new new major OS versions, this is really nice. Meanwhile, Microsoft maintains an amazing degree of compatibility. I haven't tried, but I have a feeling Office 97 works in Windows 10.
  - earenndil 8y ago
    Traditionally, that was the case, but recently older applications have been breaking in recent versions of windows. And windows and macos both have hacks in place to fix older versions of popular applications (ms office, adobe suite, etc.).
    - Wowfunhappy 8y ago
      While Windows's backwards compatibility is sadly getting worse, it's also still pretty incredible. I can run lots of obscure Windows programs that 2+ decades old! Mac backwards compatibility isn't as bad as some people say—I have a decade-old program that still works in Mojave, for instance—but Windows is a lot better. The platform with awful backwards compatibility is iOS. And there, you don't even have the option to dual boot or downgrade. The fact that no one cares says something about how much we value mobile software...
      - earenndil 8y ago
        Honestly, the only time ios has broken backwards compatibility is with 32->64 bit. And—not to minimize that, that is quite major, but that's pretty much the only time it's happened.
lostgame 8y ago
I wish I had the time to contribute to this. Getting Logic running on linux would let me ditch the Apple hardware. It's usefulness is entirely limited to the implementation of the core library frameworks such as Core Image, Audio, MIDI, Animation, Data, etc...which will be very, very difficult, I think, while maintaining FOSS status.
- veridies 8y ago
  I wish Ardour had some of the features Logic does (most significantly flex time), as well as a nicer UI. Literally Logic is the only thing keeping me on macOS.
  - bgorman 8y ago
    Bitwig has a Linux version now.
    - jameskegel 8y ago
      It always has
  - lostgame 8y ago
    That, Final Cut, and the occasional need to use Xcode.
- swiley 8y ago
  Linux audio latency really isn't great, having another layer in between your app and the kernel probably won't help.
  - Sangeppato 8y ago
    It's actually quite good, or at the least it's better than Windows 10 on the same hardware for me, even if using wine (Apple is still the best here obviously)
  - earenndil 8y ago
linguae 8y ago
What would be amazing is if Darling could join forces with the long-running GNUstep project in order to provide access to the Cocoa APIs. This would provide a means to run Cocoa apps on Linux, which will make Linux a more attractive operating system for prospective Mac converts and may also increase the popularity of GNUstep. Also, with many Mac users expressing anxieties about the future of the Mac given Apple's business decisions under Tim Cook, a combination of Darling and GNUstep would provide Mac users an option to still use the apps they have invested in, just in case Apple neglects the Mac or makes radical decisions that would negatively impact Mac users. However, the last time I looked into this matter, GNUstep still has quite a way to catch up to macOS Mojave's version of Cocoa. At the risk of going off topic, I still don't understand why GNUstep never seemed to have reached critical mass despite all these years of development. I was just a kid during the mid-1990s, but KDE and GNOME took off around this time while GNUstep kept pressing on. Here's my thoughts: maybe in 1995 and 1996 the OpenStep API might not have been attractive to developers in a world where Windows completely dominated the desktop, but this doesn't explain the decision of the KDE developers to use Qt instead of GNUstep (as well as the decision of the GNOME developers to use GTK+). There may have also been much uncertainty in 1997 following Apple's purchase of NeXT about the future of OpenStep. Such anxieties would be alleviated sometime during 2001-2003 when Mac OS X was released and started gaining popularity, but by then KDE and GNOME (and their respective underlying GUI toolkits) were firmly established in the Linux desktop ecosystem, and to this day they remain the dominant Linux desktops, and many less popular desktops still rely on Qt or GTK.
- saagarjha 8y ago
  Has anyone tried building libobjc on Darling? I feel like that is probably something that they'd need to do first. Edit: It looks like they already have Foundation working.
- scroot 8y ago
  Every year or so I take a look at GNUStep just to see what's going on. Crazy it hasn't taken off.
  - solarkraft 8y ago
beardedwizard 8y ago
I'm puzzled, wont most console apps already cross compile without much modification? Isn't this basis of brew/etc? The GUI piece seems like the key, but without it I'm failing to understand why this is significant.
- theonemind 8y ago
  It says that it "does not yet" run GUI applications, so it seems like they plan on it. Additionally, if no one ever talked about software like this before completion, they'd have a pretty hard time getting enough developers interested to ever reach completion. As for making the front-page of HN, the HN crowd probably consists disproportionately of technology enthusiasts who find interest in technology beyond its immediate usefulness.
- apetresc 8y ago
  Well, this runs _binaries_ that were compiled for macOS. Yes, practically speaking, the only binaries worth running on macOS tend to be open-source utilities that can be compiled for Linux anyway. But it is a fundamental difference in implementation that makes this project truly exciting.
- kristianp 8y ago
  If you look at [0], you'll see that non-GUI APIs need still need to be developed as a foundation for the project to continue. Implicit is that at some point in the future a GUI may be available. [0] Also states that Apples Toolchain can be run, which is promising. Also, Darling desperately needs a re-implementation of Apple’s CoreCrypto [1]. [0] https://www.darlinghq.org/project-status/ https://www.darlinghq.org/project-status/ [1] https://www.darlinghq.org/developer-zone/low-hanging-fruit/ https://www.darlinghq.org/developer-zone/low-hanging-fruit/
- mypalmike 8y ago
  Projects usually walk before they run.
AntiRush 8y ago
Maloader[0] is a similar (smaller, easier to understand) project that runs in userland. It's a nice code base to read and there's this nice presentation about it[1]. [0] https://github.com/shinh/maloader https://github.com/shinh/maloader [1] http://shinh.skr.jp/slide/ldmac/000.html http://shinh.skr.jp/slide/ldmac/000.html
iLemming 8y ago
I really want something like Hammerspoon, but for Linux
- yacoob 8y ago
  Surely there's something equivalent...? I've used Linux on desktop exclusively ~95-07. Switched to MacOS after that. Tried out mythical "Linux on the desktop" in 2018, was amused to find that iTerm2 has grown so much, and there's hard to find a good replacement for it under Linux. Of all the things I'd expect it to handle well... 8)
  - ktpsns 8y ago
    One of the most sophisticated Linux terminal emulators I worked with is Konsole, the KDE terminal. However, I never worked long enought with iTerm2 to learn all the features. My feeling is that there is a growing crowd of Linuxers who go for "minimalism", like tiling WMs and minimal terminal emulators, and using tools like tmux or zsh to streamline their experience. Regarding Hammerspoon (which reminds me very much on what you can do with AppleScript), you certainly can do many of the examples (https://www.hammerspoon.org/go/#spoons https://www.hammerspoon.org/go/#spoons) with modern-day frameworks like xdg, dbus, libevent, inotify. My feeling is that (for instance) Python PIP has pretty comprehensive libraries which allows you to use it as a glue language for all that interfaces. I would not be surprised if that even feels slimmer and more powerful then Lua in the end, but it's a matter of taste. As always.
mikemoka 8y ago
for reference a link to the previous conversation is here: https://news.ycombinator.com/item?id=12854895 https://news.ycombinator.com/item?id=12854895
ncmncm 8y ago
The main attraction of Apple products is the certainty that, no matter what you do, they cannot be made to do what you would like. The consequence is that you feel no urge to spend time tinkering to get there, and instead adapt yourself to what it actually does. This reclaims all the time and attention that you would have spent on tinkering. Since what Apple products do has proven adequate for a large number of people, and you are no less adaptable than they are, you know you can adapt, too. Having once chosen to adapt to what Apple has chosen to offer, you find it easier each time, until it becomes wholly unconscious. Each time Apple takes away something you had used, you might momentarily balk at the "upgrade", but always acquiesce in the end. [Edit] So, the appeal of Mac emulation is very limited, because it starts out with tinkering.
- themodelplumber 8y ago
  I tried the adjustment to the Apple way from 2010 to 2018. By the end of it I realized that "tinkering" has an equivalent in the Apple world and it is called "upgrading." These two terms are almost synonymous in the pain which they will cause. By the end of my journey I had a firm "one major version upgrade per iOS device" rule and a desktop OS upgrade experience that was driving me crazy, because random CAD app wouldn't support the new OS, but another app wouldn't support the mainstream-old OS anymore. I won't say that tinkering is totally productive, but 1) personally my tinkering on Linux has led to technology development and I'm the type of guy who benefits from that anyway, and 2) I believe the pain you leave behind in lost productivity is at least offset by 25% instant upgrade-related stress for each Apple device in your household or sphere of personal work activity. Even just constrained to hardware, the horror stories about new Apple devices alone made me doubt my HW upgrade plans. By itself that was enough to make me wonder if I was about to throw away thousands. Unsurprisingly I felt like there were things Apple could do to make this all better, but like you said, they cannot be made to do what you like :-)
- vaylian 8y ago
  Thanks for putting into words what I had suspected for so long. Apple is really good at identifying what the vast majority of people (aka normal users) want to do with their computer and then they optimize these workflows. But if you want to do something more exotic you are usually out of luck. Talking to Apple enthusiasts is really tough. It's almost as you are speaking a different language. Of course, in the end of the day a computer is just a tool. They are happy with what they can do with their machine and I am happy with my machine. But they have a hard time understanding why I see their system as limiting.
volgar1x 8y ago
Will this enable Linux servers to build iOS apps?
- klohto 8y ago
  How is iOS and macOS the same thing? It's not even running on the same architecture.
  - panpanna 8y ago
    He means running xcode to produce iOS binaries
    - klohto 8y ago
      Then that's different. This won't work, xcode is heavily integrated with macOS only libraries and as far as I'm aware, it requires GUI interaction at some point to produce the iOS binary.
finchisko 8y ago
I wonder where humanity would be, if people (including me) instead of arguing on forums, actually did something useful :) Like Darling could be already polished product.
tempodox 8y ago
> At this point, does not yet run macOS application with a GUI Which makes it rather pointless, for now. Practically all non-GUI software that runs on Darwin can be made to run on Linux too and thereby even Cygwin. What I would much rather see is library support for some BSD standard functions that are missing from Linux. Trying to migrate software that uses funopen(3) to Linux gives me an ulcer.
niahmiah 8y ago
This extra layer (and wine) are always going to be garbage. If you need Mac or Windows, your best bet is not to move to Linux in the first place. If you do mostly development or scientific computing, then you’ve probably dealt with more pain on those platforms, that melts away on Linux. Best tool for job wins.
IOT_Apprentice 8y ago
The comments here sound like they are from Android users who go on about how great Android is because they can spend hours tweaking their phones and rooting them and side loading them. LOL. "made to do what you like". Dudes, just get Windows 10 and install WSL and tweak away.

300 points by pcr910303 8y ago

Something like this is sorely needed by the open-source, not-for-profit, shoestring-resources, cross-platform development community... For example, let's say that I'm writing some cross-platform open source software. And let's say that I am developing this software on a Windows or Linux Box. Now, let's say that for whatever reason, I don't have and can't afford a Mac (a scenario like this is more common than you would think, especially in developing countries...) OK, so now how do I compile/run/test the Mac version of my software -- without having that Mac? ? That's why your software is so important. Anyway, if you can get this fully operational (GUI and everything), you'll solve that problem for that group of software developers... If you're successful, if you prevail... Apple shouldn't sue you... they should help you, because additional software for their platform ultimately benefits their platform. Also, judging by the source, you've done an amazing amount of work so far... I hope you can find the additional developers/contributors you need to take this thing to completion...

karmakaze 8y ago
Worth noting that outside of this bubble, macOS has less than 10% market share. Not every software needs to run everywhere. There are other working solutions, JetBrains seems to do alright with Java runtimes.
MuffinFlavored 8y ago
> Now, let's say that for whatever reason, I don't have and can't afford a Mac. Rely on some developer(s) spend 10,000 hours of their time for free developing a Mac emulation layer, or go on eBay and buy a $600 used Mac to test on...
- deleted 8y ago
  [deleted]
- asark 8y ago
  It may still be too expensive for devs in (very) developing countries or whatever, but I'm pretty sure there are (paid) remote desktop solutions for this. Also you can snag an old mac mini for well under $600, where I am. Like $200-300. It won't be good but that's probably better for testing anyway.
  - scottjg 8y ago
    I offer a service that provides you with your own macOS VM, running on real Mac hardware. https://zeromac.com https://zeromac.com It's billed by the hour, so if you just need to quickly test something, it's pretty cheap. Buying an older mac may be more economical though if you need to develop software long term.
    - MuffinFlavored 8y ago
      This is super interesting. Is it your full time job? What level of success are you having with your idea?
      - scottjg 8y ago
        I run it alongside my regular consulting work, so I suppose it's not my full time job. It's also a fairly new business so I'm not too sure how successful it will be yet.
- axaxs 8y ago
  While your point is taken... I write and contribute to free/open source tools. I can afford a Mac, but will not buy one because there's zero incentive to me. While I'm not sure this project would help, if a free or very low cost proper emulation existed, I'd use it.
- gchamonlive 8y ago
  It may also be a matter of principle. I won't buy macs even though they are sexy and I have the money for it because I don't agree with its practices. My theoretical customers shouldn't suffer from it though
- macdice 8y ago
  Or use one of the CI providers that will test your stuff on macOS (alongside Windows, FreeBSD, ...). Possibly for free, if your stuff is open source. I use that for Windows, which I don't personally use at all, and it finds bugs and problems all the time. I wish someone would provide free (!) CI for some rarer OSes and CPU architectures too, but I can dream.
  - viraptor 8y ago
    You can't fully test things this way. Not enough to make a serious release anyway. You can easily pass all tests while not being able to even start the app. You need at least one person with the real hardware to do testing.
    - saagarjha 8y ago
      This really depends on the tests you're running.
      - viraptor 8y ago
        True. But in context of: "tests in a CI environment which costs you less than a MacBook", I don't believe anyone would go to the level that avoids those issues. It would take a lot of work and resources to replicate a "real run in clean, real environment".
        saagarjha 8y ago
        Again, this depends on the tests you’re running and how you’ve set up your CI environment.
  - faissaloo 8y ago
    Unfortunately MacOS testing is usually extremely slow due to limited numbers of machines to run tests on.
- loeg 8y ago
  The nice thing about the former is that that cost is shared across all consumers, whereas the latter would be incurred for every user. The latter approach may still cost less for now (or forever), but it's something to keep in mind.
- michaelmrose 8y ago
  The logical option c is just to not support mac unless your target market is one disproportionately likely to use macs like developers or artists in the US.
zapzupnz 8y ago
> For example, let's say that I'm writing some cross-platform open source software > OK, so now how do I compile/run/test the Mac version of my software -- without having that Mac? You don't. Darling is not a suitable replacement for testing on a real Mac in exactly the same way WINE is not a suitable replacement for testing Windows software. A developer who thinks so is misguided. Virtualising macOS would be more suitable, although the only way to do so without violating macOS' licence conditions is to run the virtualised OS on a Mac anyway. Even then, virtualised macOS lacks hardware accelerated graphics support, limiting the testing of GUI apps at least. > Apple shouldn't sue you There's no reason they would. Nothing of Apple's seems to be infringed, as the system seems only capable of running anything that Apple's open source Darwin OS can. Even if the Darling project reimplemented some of Apple's proprietary frameworks, this could be done based on Apple's open source releases of things such as Core Foundation, etc. The reimplementations of things like AppKit, when done in the future, could even possibly be based on something like GNUstep — which would give that project a well-needed shot in the arm, to say the least. > additional software for their platform ultimately benefits their platform Firstly, any well-written cross-platform software is easily ported to macOS. This is most evident with software intended for FreeBSD but is equally possible with software that originates on Linux; see Homebrew, MacPorts, etc. for the plethora of utilities that began life on Linux but have since become cross-platform, or software made by GNU that is typically cross-platform by design. Secondly, Apple has been down the cross-platform road before, and none of its developers wanted a bar of it. Apps that are developed on other systems but not tested properly on macOS are always heavily criticised by macOS users as feeling foreign and un-Mac-like. Back when Mac OS X was shiny and new, Apple offered three major platforms for developers: Cocoa, their C and Objective-C APIs inherited from NeXTSTEP; Carbon, their C and C++ APIs inherited from Classic Mac OS; and Java, a cross-platform offering to entice developers from other platforms, particularly Linux. Apple deprecated their own Java in 2010 because (A) people really disliked using Java apps, even though Apple's implementation of the JVM was performant and had native support for Cocoa-style controls and (B) nobody was using it, with major preference going to Apple's own Cocoa and Carbon APIs. Apple, and its userbase, prefer apps that are made with love and care _on_ Macs and _for_ Macs/iOS devices/Apple Watches/Apple TVs, respecting those platform conventions by being developed and tested on them.
- 8y ago
lostgame 8y ago
Generally different platform builds are handled by different developers - the codebase has to be modularized to be ported from Windows, to, say, Linux, to start, same with the UI. If you're already porting to Linux, you're already dealing with a UNIX executable, which makes it at least slightly easier to port to MacOS. There are also virtualization services available where you can rent dev time, and decent and upgradeable Macs are not that expensive second hand. I dev on MacOS all the time, and have the same issue with Windows. These days I try to write everything as a PWA to start so I especially don't have to deal with extreme UI/UX pains.
xoa 8y ago
>I don't have and can't afford a Mac Why wouldn't you just virtualize, same as any other OS? If you're not virtualizing on Mac hardware than there are a few minor extra hoops to jump through but it's still less work compared to a hackintosh. Performance can be janky if you don't dedicate a video card to it, but something perfectly adequate like a Radeon 560 seem readily available for $60-80 now. There are a few bits of Mac specific hardware these days like the T-series chips, but not even all supported Macs have that by a long shot.
- simcop2387 8y ago
  Doing so is not legal in most countries. the macOS T&C/EULA/etc. forbid running it on non-apple hardware. This is a large barrier to entry that a lot of people don't want to even approach.
  - qaq 8y ago
    In developing countries piracy is rampant none really cares much about EULAs
T-A 8y ago
>OK, so now how do I compile/run/test the Mac version of my software -- without having that Mac? Splurge on a $1/hour or $20/month account with https://www.macincloud.com/ https://www.macincloud.com/ ?
- electroly 8y ago
  In case anyone is curious, you have to prepay $30 for the PAYG plan, and you get non-admin access to the slowest Mac Mini you've ever used in your whole life. It does technically work to build iOS and macOS apps, though.

jamesu 8y ago

Been experimenting using this to run legacy software and while it seems to work great with command line tools, as soon as you progress onto gui stuff you quickly run into missing functions and libs. Still insanely cool though.

dehrmann 8y ago
Especially for MacOs, where you can expect apps to stop working after a new new major OS versions, this is really nice. Meanwhile, Microsoft maintains an amazing degree of compatibility. I haven't tried, but I have a feeling Office 97 works in Windows 10.
- earenndil 8y ago
  Traditionally, that was the case, but recently older applications have been breaking in recent versions of windows. And windows and macos both have hacks in place to fix older versions of popular applications (ms office, adobe suite, etc.).
  - Wowfunhappy 8y ago
    While Windows's backwards compatibility is sadly getting worse, it's also still pretty incredible. I can run lots of obscure Windows programs that 2+ decades old! Mac backwards compatibility isn't as bad as some people say—I have a decade-old program that still works in Mojave, for instance—but Windows is a lot better. The platform with awful backwards compatibility is iOS. And there, you don't even have the option to dual boot or downgrade. The fact that no one cares says something about how much we value mobile software...
    - earenndil 8y ago
      Honestly, the only time ios has broken backwards compatibility is with 32->64 bit. And—not to minimize that, that is quite major, but that's pretty much the only time it's happened.

lostgame 8y ago

I wish I had the time to contribute to this. Getting Logic running on linux would let me ditch the Apple hardware. It's usefulness is entirely limited to the implementation of the core library frameworks such as Core Image, Audio, MIDI, Animation, Data, etc...which will be very, very difficult, I think, while maintaining FOSS status.

veridies 8y ago
I wish Ardour had some of the features Logic does (most significantly flex time), as well as a nicer UI. Literally Logic is the only thing keeping me on macOS.
- bgorman 8y ago
  Bitwig has a Linux version now.
  - jameskegel 8y ago
    It always has
- lostgame 8y ago
  That, Final Cut, and the occasional need to use Xcode.
swiley 8y ago
Linux audio latency really isn't great, having another layer in between your app and the kernel probably won't help.
- Sangeppato 8y ago
  It's actually quite good, or at the least it's better than Windows 10 on the same hardware for me, even if using wine (Apple is still the best here obviously)
- earenndil 8y ago

linguae 8y ago

What would be amazing is if Darling could join forces with the long-running GNUstep project in order to provide access to the Cocoa APIs. This would provide a means to run Cocoa apps on Linux, which will make Linux a more attractive operating system for prospective Mac converts and may also increase the popularity of GNUstep. Also, with many Mac users expressing anxieties about the future of the Mac given Apple's business decisions under Tim Cook, a combination of Darling and GNUstep would provide Mac users an option to still use the apps they have invested in, just in case Apple neglects the Mac or makes radical decisions that would negatively impact Mac users. However, the last time I looked into this matter, GNUstep still has quite a way to catch up to macOS Mojave's version of Cocoa. At the risk of going off topic, I still don't understand why GNUstep never seemed to have reached critical mass despite all these years of development. I was just a kid during the mid-1990s, but KDE and GNOME took off around this time while GNUstep kept pressing on. Here's my thoughts: maybe in 1995 and 1996 the OpenStep API might not have been attractive to developers in a world where Windows completely dominated the desktop, but this doesn't explain the decision of the KDE developers to use Qt instead of GNUstep (as well as the decision of the GNOME developers to use GTK+). There may have also been much uncertainty in 1997 following Apple's purchase of NeXT about the future of OpenStep. Such anxieties would be alleviated sometime during 2001-2003 when Mac OS X was released and started gaining popularity, but by then KDE and GNOME (and their respective underlying GUI toolkits) were firmly established in the Linux desktop ecosystem, and to this day they remain the dominant Linux desktops, and many less popular desktops still rely on Qt or GTK.

saagarjha 8y ago
Has anyone tried building libobjc on Darling? I feel like that is probably something that they'd need to do first. Edit: It looks like they already have Foundation working.
scroot 8y ago
Every year or so I take a look at GNUStep just to see what's going on. Crazy it hasn't taken off.
- solarkraft 8y ago

beardedwizard 8y ago

I'm puzzled, wont most console apps already cross compile without much modification? Isn't this basis of brew/etc? The GUI piece seems like the key, but without it I'm failing to understand why this is significant.

theonemind 8y ago
It says that it "does not yet" run GUI applications, so it seems like they plan on it. Additionally, if no one ever talked about software like this before completion, they'd have a pretty hard time getting enough developers interested to ever reach completion. As for making the front-page of HN, the HN crowd probably consists disproportionately of technology enthusiasts who find interest in technology beyond its immediate usefulness.
apetresc 8y ago
Well, this runs _binaries_ that were compiled for macOS. Yes, practically speaking, the only binaries worth running on macOS tend to be open-source utilities that can be compiled for Linux anyway. But it is a fundamental difference in implementation that makes this project truly exciting.
kristianp 8y ago
If you look at [0], you'll see that non-GUI APIs need still need to be developed as a foundation for the project to continue. Implicit is that at some point in the future a GUI may be available. [0] Also states that Apples Toolchain can be run, which is promising. Also, Darling desperately needs a re-implementation of Apple’s CoreCrypto [1]. [0] https://www.darlinghq.org/project-status/ https://www.darlinghq.org/project-status/ [1] https://www.darlinghq.org/developer-zone/low-hanging-fruit/ https://www.darlinghq.org/developer-zone/low-hanging-fruit/
mypalmike 8y ago
Projects usually walk before they run.

AntiRush 8y ago

Maloader[0] is a similar (smaller, easier to understand) project that runs in userland. It's a nice code base to read and there's this nice presentation about it[1]. [0] https://github.com/shinh/maloader https://github.com/shinh/maloader [1] http://shinh.skr.jp/slide/ldmac/000.html http://shinh.skr.jp/slide/ldmac/000.html

iLemming 8y ago

I really want something like Hammerspoon, but for Linux

yacoob 8y ago
Surely there's something equivalent...? I've used Linux on desktop exclusively ~95-07. Switched to MacOS after that. Tried out mythical "Linux on the desktop" in 2018, was amused to find that iTerm2 has grown so much, and there's hard to find a good replacement for it under Linux. Of all the things I'd expect it to handle well... 8)
- ktpsns 8y ago
  One of the most sophisticated Linux terminal emulators I worked with is Konsole, the KDE terminal. However, I never worked long enought with iTerm2 to learn all the features. My feeling is that there is a growing crowd of Linuxers who go for "minimalism", like tiling WMs and minimal terminal emulators, and using tools like tmux or zsh to streamline their experience. Regarding Hammerspoon (which reminds me very much on what you can do with AppleScript), you certainly can do many of the examples (https://www.hammerspoon.org/go/#spoons https://www.hammerspoon.org/go/#spoons) with modern-day frameworks like xdg, dbus, libevent, inotify. My feeling is that (for instance) Python PIP has pretty comprehensive libraries which allows you to use it as a glue language for all that interfaces. I would not be surprised if that even feels slimmer and more powerful then Lua in the end, but it's a matter of taste. As always.

mikemoka 8y ago

for reference a link to the previous conversation is here: https://news.ycombinator.com/item?id=12854895 https://news.ycombinator.com/item?id=12854895

ncmncm 8y ago

The main attraction of Apple products is the certainty that, no matter what you do, they cannot be made to do what you would like. The consequence is that you feel no urge to spend time tinkering to get there, and instead adapt yourself to what it actually does. This reclaims all the time and attention that you would have spent on tinkering. Since what Apple products do has proven adequate for a large number of people, and you are no less adaptable than they are, you know you can adapt, too. Having once chosen to adapt to what Apple has chosen to offer, you find it easier each time, until it becomes wholly unconscious. Each time Apple takes away something you had used, you might momentarily balk at the "upgrade", but always acquiesce in the end. [Edit] So, the appeal of Mac emulation is very limited, because it starts out with tinkering.

themodelplumber 8y ago
I tried the adjustment to the Apple way from 2010 to 2018. By the end of it I realized that "tinkering" has an equivalent in the Apple world and it is called "upgrading." These two terms are almost synonymous in the pain which they will cause. By the end of my journey I had a firm "one major version upgrade per iOS device" rule and a desktop OS upgrade experience that was driving me crazy, because random CAD app wouldn't support the new OS, but another app wouldn't support the mainstream-old OS anymore. I won't say that tinkering is totally productive, but 1) personally my tinkering on Linux has led to technology development and I'm the type of guy who benefits from that anyway, and 2) I believe the pain you leave behind in lost productivity is at least offset by 25% instant upgrade-related stress for each Apple device in your household or sphere of personal work activity. Even just constrained to hardware, the horror stories about new Apple devices alone made me doubt my HW upgrade plans. By itself that was enough to make me wonder if I was about to throw away thousands. Unsurprisingly I felt like there were things Apple could do to make this all better, but like you said, they cannot be made to do what you like :-)
vaylian 8y ago
Thanks for putting into words what I had suspected for so long. Apple is really good at identifying what the vast majority of people (aka normal users) want to do with their computer and then they optimize these workflows. But if you want to do something more exotic you are usually out of luck. Talking to Apple enthusiasts is really tough. It's almost as you are speaking a different language. Of course, in the end of the day a computer is just a tool. They are happy with what they can do with their machine and I am happy with my machine. But they have a hard time understanding why I see their system as limiting.

volgar1x 8y ago

Will this enable Linux servers to build iOS apps?

klohto 8y ago
How is iOS and macOS the same thing? It's not even running on the same architecture.
- panpanna 8y ago
  He means running xcode to produce iOS binaries
  - klohto 8y ago
    Then that's different. This won't work, xcode is heavily integrated with macOS only libraries and as far as I'm aware, it requires GUI interaction at some point to produce the iOS binary.

finchisko 8y ago

I wonder where humanity would be, if people (including me) instead of arguing on forums, actually did something useful :) Like Darling could be already polished product.

tempodox 8y ago

> At this point, does not yet run macOS application with a GUI Which makes it rather pointless, for now. Practically all non-GUI software that runs on Darwin can be made to run on Linux too and thereby even Cygwin. What I would much rather see is library support for some BSD standard functions that are missing from Linux. Trying to migrate software that uses funopen(3) to Linux gives me an ulcer.

niahmiah 8y ago

This extra layer (and wine) are always going to be garbage. If you need Mac or Windows, your best bet is not to move to Linux in the first place. If you do mostly development or scientific computing, then you’ve probably dealt with more pain on those platforms, that melts away on Linux. Best tool for job wins.

IOT_Apprentice 8y ago

The comments here sound like they are from Android users who go on about how great Android is because they can spend hours tweaking their phones and rooting them and side loading them. LOL. "made to do what you like". Dudes, just get Windows 10 and install WSL and tweak away.