[HN Gopher] Darling - run Mac apps on Linux
___________________________________________________________________
Darling - run Mac apps on Linux
Author : tomrod
Score : 291 points
Date : 2022-01-05 19:27 UTC (3 hours ago)
(HTM) web link (www.darlinghq.org)
(TXT) w3m dump (www.darlinghq.org)
| waynecochran wrote:
| I assume this is not command line only? If so, you really need
| some screenshots.
| max-ibel wrote:
| I suggest actually reading the page since it has the answer to
| your question.
|
| TL;DR: GUI almost working. I assume screenshots will be added
| when it is.
| tombert wrote:
| Not to in any way put down the developers on this, because I
| realize this is a hard problem, but it's been "almost
| working" for roughly five years. I don't think we should hold
| our breath on it, sadly.
| em500 wrote:
| Also, the fact that last update of the blog/progress report
| linked from the main page dates from 2019Q2 does not give
| much confidence.
| tombert wrote:
| The Github is still getting updates, at least as of
| November.
|
| I think part of the problem is that most software that
| you would want to run on Linux from MacOS are also on
| Windows, and Wine/Proton already exists. As a result, I
| think people don't really feel the urge to contribute to
| Darling when they could just contribute to Wine.
| waynecochran wrote:
| _Almost_ tells me they must have _some_ screenshots of _some_
| GUI app working. Otherwise I _almost_ have a million dollars
| to donate.
| gattilorenz wrote:
| > Does it support GUI apps?
|
| > Almost! This took us a lot of time and effort, but we finally
| have basic experimental support for running simple graphical
| applications.
|
| So, I guess for now it makes sense there are no screenshots
| ithkuil wrote:
| https://github.com/darlinghq/darling/issues/657
| stuaxo wrote:
| There's still a long way to go, especially if you want GUI apps.
|
| If you want to contribute there is an active community on
| Discord.
| awill wrote:
| isn't packaging/selling going to be a problem here? Some of the
| apps I rely on (on my MBP) are only in the Mac AppStore.
| hitpointdrew wrote:
| Oh man, if we can have iTerm2 on Linux I will be pumped.
| jldugger wrote:
| Are you familiar with Terminator? https://terminator-
| gtk3.readthedocs.io/en/latest/
| hitpointdrew wrote:
| I don't see a password manager listed in the features, which
| is about 70% of what I think makes iTerm2 so useful.
| freedomben wrote:
| Just thought it may be worth mentioning if there are devs from
| the project here, but Darling is one of the efforts that I would
| sponsor/donate to (just small amounts for now as I haven't made
| my millions yet ;-) if there were a more defined road map with
| milestones/goals.
|
| This is an amazing and important goal! Thank you so much for
| dedicating your time and efforts to this!
| mastazi wrote:
| This project needs more contributions! I hope being on the HN
| home page will help
| miller_joe wrote:
| Can it run Messages.app? This is the one thing that constantly
| gives me pause on the linux-desktop switching
|
| EDIT: It says "some" GUI apps are working / experimental, so
| probably Messages is not there yet, just curious if anyone has
| tried.
| divbzero wrote:
| Or Preview.app? That is the other macOS app that I use all the
| time.
| monocasa wrote:
| Does this still require a kernel driver to intercept syscalls?
|
| It'd be nice to have a gvisor/UML like option that would let it
| run entirely in user space.
| andjd wrote:
| Related unrelated comment. Is there any effort to make Darwin
| itself user friendly? Everything I've heard anecdotally is that
| Darwin is a world of hurt unless you really, really know what
| you're doing. It seems like that might be a slightly easier path
| towards having an open-source OS that can run mac apps than
| building a whole compatibility layer over Linux.
| aflag wrote:
| That sounds more difficult, actually. Because then you need to
| be able to run everything. Whereas, with linux, you can
| leverage most of linux's library and only use darling for the
| couple apps that you need that only run on Mac OS.
| mkdirp wrote:
| Lots of questions around GUI apps. As someone pointed out, GUI
| apps have been "almost" working for years. Darling looks great
| but it hasn't gotten near as much love as Wine has gotten.
|
| I've been keeping an eye on it, and will continue to keep an eye
| it, and I've noticed the development is very slow. At the rate
| it's going, it'll be years before it'll be a viable solution like
| Wine is. I hope visibility for it will increase so that the
| current devs get some more help on this.
|
| I'd still like to give thanks to the devs as this is a very
| ambitious project. I'm sure people used to say "it'll be years
| before it'll be a viable solution" when Wine was in its infancy.
|
| Having Linux run iOS, macOS, Android, and Windows applications
| running would be nothing less than mind-boggling, and would
| finally get people to stop yelling that nothing runs on Linux.
| freedomben wrote:
| > _Having Linux run iOS, macOS, Android, and Windows
| applications running would be nothing less than mind-boggling,
| and would finally get people to stop yelling that nothing runs
| on Linux_
|
| Nothing will stop those people from yelling that, because it
| hasn't been true in a _very_ long time and that doesn 't stop
| them. These are the same people who say they don't want to run
| Linux because they don't want to compile their sound card
| drivers. They are already way outside of rational territory and
| deep into religious territory. In their minds Linux hasn't
| changed a bit since 1999, even though if you were to compare
| mac os from that time period against modern linux, they would
| become enraged at the unfairness and injustice.
| 2muchcoffeeman wrote:
| Google all the sound problems people had and the solutions
| for the 2020 Dell XPS 17. People have that attitude because
| it still happens from time to time. It's much rarer. But it
| still happens.
| dmitriid wrote:
| While Linux has changed, the rest of the world changed, too.
|
| So yes, on the one hand people will want things like Sketch
| and Logic Pro, and on the other they will want good trackpads
| and reliable hibernation.
| aspaceman wrote:
| > They are already way outside of rational territory and deep
| into religious territory. In their minds Linux hasn't changed
| a bit since 1999, even though if you were to compare mac os
| from that time period against modern linux, they would become
| enraged at the unfairness and injustice.
|
| I agree that this is part of it. But I also just see plain
| antagonism against Linux because people recommend it. Just
| pure contrarianism.
|
| But a lot of the recommendations for Proton are also "memey".
| It's a bad fit if you need Anti-Cheat or proper injection
| protection. And that's just the nature of the beast. A proper
| Anti-Cheat _shouldn't_ approve of the injection necessary to
| get Proton working
|
| So I do have to keep a Windows installation myself. But
| Proton represents a really cool technical milestone. Weird
| the way people talk about tech in games.
| txdv wrote:
| Been playing a lot of steam games with proton, it is mind
| bogling how valve expanded from support for linux for the
| source engine to support 70% of the games.
| code_biologist wrote:
| 70% of games _big asterisk_
|
| The giant youtube channel Linus Tech Tips has done a recent
| series of videos on gaming on linux. On Jan 1 they
| published a 15 min summary video that covers that 70% claim
| in a much more nuanced way: https://youtu.be/Rlg4K16ujFw
|
| Punchline: it's kinda true, but there's plenty of struggle
| for new and multiplayer games still.
| donio wrote:
| I am sure it heavily depends on the kind games we play
| but I've had a 100% success rate over the past couple of
| years. I have to keep reminding myself to check protondb
| just in case. There are even a few games with native
| ports that I run through proton to avoid bugs in the
| native versions.
| smoldesu wrote:
| It may be true, but it really depends on how new the
| games you want to play are. I don't consider myself a
| hardcore player, but I'm perfectly happy with the games
| I've got on Linux; Overwatch, Diablo 2/3, Warframe, Risk
| of Rain 2, the Fallout series... they all work fine. It's
| certainly no Mac when it comes to game compatibility.
| Really, the only time a game _doesn 't_ work on Linux is
| when the developers go out of their way to ensure you
| aren't running Linux; with the prevalence of anti-cheat
| that has indeed seen a bit of a fork in the road. But
| developers can also whitelist Linux users, and now that
| the Steam Deck is getting ready to ship to hundreds of
| thousands of future owners, those devs have an incentive
| to get their games on Linux.
|
| I think "asterisk" is warranted, since there are still
| show-stopper games that won't run without their precious
| kernel-level anti-cheat (sorry professional Valorant
| players), but the asterisk is shrinking, not growing.
| It's a fairly small caviat at this point, especially for
| more casual audiences, and I kinda wonder why it was such
| a sticking point for Linus. Wine is not a panacea, but if
| you look at the landscape and see _the majority_ of
| Windows software running, I think there 's hope in that.
| hn8788 wrote:
| There are even bigger caveats to that number than what
| they mentioned in the video. Since all the ratings are
| based on user reports, there is no standard for what is
| considered a working game. You can look through pretty
| much any game and find positive reports that mention
| frequent crashes, performance issues, missing textures,
| requires a custom proton version, etc., but since it
| launches, they gave it a thumbs up. I've tried platinum
| rated games that are completely unplayable, ProtonDB
| ratings are a general guide at best.
|
| ProtonDB also considers a game as "working" if even a
| single person gave it a thumbs up, so the big "17,984
| games work" on the home page is very misleading.
| als0 wrote:
| I can already envisage some poor Valve employee who's
| going through each ProtonDB entry to make individual
| workarounds for the Steam Deck release.
| Legion wrote:
| That's what's making the Steam Deck possible. And the
| release of the Steam Deck is only going to bring more
| attention to Proton and accelerate further development.
| twblalock wrote:
| > These are the same people who say they don't want to run
| Linux because they don't want to compile their sound card
| drivers. They are already way outside of rational territory
| and deep into religious territory.
|
| It's rational for me to want my sound card to work without
| having to compile code. No other operating system would make
| me compile code to fulfill such a rudimentary and basic
| expectation. That's not religion, that's usability.
|
| I can't imagine trying to walk my parents through compiling a
| kernel driver to get their hardware working, and that's why
| I've never tried to get them to use Linux. If you want normal
| people to use Linux you should never, ever, ever ask them to
| even use a terminal, much less a compiler.
|
| I've used Linux on the desktop, on and off, for over 20 years
| -- in fact, since the year 1999 as you mentioned. It still
| sucks. Every time I come back to it I have at least one
| driver problem. It's not ok, and it's not defensible. Instead
| of defending it and blaming critics for being "religious,"
| admit that it has faults. Things only get better when we
| recognize the deficiencies and fix them, as Valve has been
| trying to do with Proton.
| ogogmad wrote:
| The parent commenter's point is that while you may have had
| to compile drivers back in 1999's Linux, you don't have to
| in today's Linux. This is the apparent misconception which
| he was pointing out, and which you yourself have displayed
| in your response.
|
| This is not WorksForMe(TM). It's you misinterpreting
| (wilfully?) what the parent commenter meant. If you
| disagree with him, you should argue that indeed you do need
| to compile drivers, or do something similarly complex, in
| today's Linux. Instead you're pretending that he meant that
| compiling device drivers is absolutely wonderful, and
| everybody should do it in 2022. But I don't think you
| should carry on, because none of your responses have been
| in good faith.
| beepbooptheory wrote:
| Ive only got ten years under my belt, but I don't think I
| have ever had to compile a driver! perhaps a few times in
| Arch, although it would be an AUR thing and hardly and
| intensive manual process. But certainly not in debian-based
| stuff. I dont even understand what it would be like to have
| the bad experiences people do with it.
|
| I can only assume its hardware disparity. I never have much
| money so I always get older cheaper hardware I can afford,
| where support has most likely had time to mature. Perhaps
| people with these negative impressions of Linux are trying
| to install distros on newer, bleeding edge stuff?
| colordrops wrote:
| You missed the point. You typically don't have to compile
| anything for your sound card, assuming you even have one
| anyone considering that motherboards have had integrated
| sound forever now.
| twblalock wrote:
| littlestymaar wrote:
| This comment is really fascinating: not only the author
| completely missed the point of the original comment they
| are responding to (which is: "having to compile your
| drivers was the state of Linux in 99, but it' hasn't been
| anymore for at least 15 years, so complain that Linux
| doesn't work using this argument just shows you're out of
| date by two decades at this point") but the author just
| refused to even attempt to understand when other people
| tried to warn them and instead went completely mad.
| tragictrash wrote:
| You missed the point. I have never had to compile drivers
| for my Linux machines.
|
| Furthermore I'm sick of people like you spouting this
| nonsensical BS about what everyone else expects. You are
| wrong.
|
| You want to know what I see? A great amount of progress
| in a short time.
|
| 1999 called they want you back.
| wlesieutre wrote:
| If you ever got in a situation where your sound card
| wasn't supported on macOS, instead of "you can compile a
| driver" the answer you'll get is "throw away your sound
| card and buy supported hardware."
|
| You could apply the same fix to a Linux computer and
| purchase known working hardware, but because you have the
| option of fixing the software yourself that makes it a
| worse operating system?
| saghm wrote:
| I've used Linux for around 8.5 years now, and I've never
| once had to compile a sound card driver to get my sound
| working. On the half dozen or so laptops I've installed
| it on since then, every one of them just had sound
| working without needing to compile anything.
|
| >Every time Linux on the desktop is discussed, the
| reaction of the Linux desktop community is predictable:
| defending Linux and its problems, and downplaying the
| difficulty that many users have. A ton of people say "it
| works for me on my hardware" or "I didn't need to compile
| any drivers" or "the games that I want to play work
| fine". In fact, this comment thread has good examples of
| this type of reaction. So what? Until it works for
| everyone it's just not good enough.
|
| I'm a bit confused; have you actually had this experience
| when you had to compile your sound card driver in the
| past ten years? It would be totally reasonable for you to
| be unhappy if you had, but given how much you're
| criticizing, I have to assume that if you had this
| experience you would have mentioned it. Given that, it
| sounds like the only criticism is that someone could
| theoretically happen to need to do this, but that's not
| really any different from any other operating system; the
| difference is that if your sound card doesn't work on
| Windows, you don't have the option to compile it at all.
| I'm not sure how often people have driver issues on
| Windows these days, having not used it much since before
| I swapped to Linux, but I'm not going to prematurely get
| angry about the idea that people _could_ be having driver
| issues but not have the option to compile their own if I
| don't actually hear about anyone having these issues.
| danachow wrote:
| >> They are already way outside of rational territory and
| deep into religious territory
|
| > Until it works for everyone it's just not good enough.
|
| You are pretty well proving the GP point. There is no
| system that works for _everyone_. Windows can be very
| challenging to get up and running on hardware setups that
| are not the most common.
|
| > Windows and MacOS don't make people do that
|
| False. And it's funny that this is about sound drivers. I
| have a piece of older but perfectly working Roland
| audio/MIDI equipment that uses USB drivers that are no
| longer supported on modern MacOS. How did I get it
| working? By compiling a fucking driver the other day.
| (And yes it works perfectly out of the box on any Linux
| kernel for the past 20 years).
|
| Now go ahead and move the goalposts about older hardware
| not mattering or some nonsense. This hasn't been the only
| frustration with MacOS. It took these clowns the better
| part of a year to fix VLAN configuration in the network
| setup window. The only way to configure them for a lot of
| hardware was to drop down to the command line - so much
| for working for _everyone_.
| coder543 wrote:
| Windows doesn't work for everybody either, and I do mean
| actual problems with Windows not working, even pre-
| installed from the factory.
|
| I don't even have to look outside the circle of people I
| know in person to have seen this. Googling for Windows
| not working with $X specific laptop instantly reveals
| quite a treasure trove beyond the people I know, where $X
| can be pretty much any Windows laptop. Everything from
| fingerprint readers no longer working to even simple
| things like the function key hotkeys no longer working.
|
| Issues with sound drivers not working are far from
| unheard of on Windows laptops.
|
| You definitely seem to have missed their point, and, in
| my opinion, you're being unnecessarily antagonistic.
| freedomben wrote:
| Agreed, you definitely missed my point, but in your
| defense the point was implied rather than explicitly
| stated so I'll take the fault for not being clear.
|
| I don't mind building my own drivers (in fact I maintain
| one[1]), but I would never expect the average person to
| have to do that. It would be entirely unreasonable.
|
| But, the _vast_ majority of linux users don 't have to
| compile any drivers. Unless you have some obscure piece
| of hardware or one that is so new that the driver isn't
| mainlined yet, you don't have to worry about it.
|
| You say you've been using linux for 20 years. which
| driver(s) in the last 5 or so years have you had to
| compile yourself?
|
| [1]: https://github.com/FreedomBen/rtl8188ce-linux-driver
| threatofrain wrote:
| The "religious" part is about saying the the world froze
| for over 20 years, and the point is that people _don 't_
| have to compile their drivers.
| kaba0 wrote:
| On most machines I tried, linux had every conceivable
| driver ready out of the box without any configuration.
|
| This is absolutely not something one can say about
| windows (though at least nowadays it will try to fetch
| drivers from God knows where and often succeed). And Mac
| supports like 2 hardware devices all together, both of
| them manufactured by them -- comparing an OS that
| exclusively run on specific hardware is just stupid and
| not made in good faith.
| torstenvl wrote:
| Interesting. I have had to compile drivers for every
| Linux install I've done in the past three years. Ubuntu,
| Xubuntu, elementaryOS, Pop!_OS, etc. Maybe we can all
| accept that people have different experiences?
|
| And of course, you're under no obligation to listen to
| any of us whine, but if, on the off chance, you happen to
| _want_ more people to like Linux, it seems like taking
| people 's experiences seriously would be a good starting
| point.
| kaba0 wrote:
| I didn't say that the contrary can't happen - but wildly
| inaccurate, bad-faith claims that the account made I
| replied to are not ok either. Linux did come a long long
| way, and often used hardware will indeed just work out of
| the box most of the time - I think it is absolutely fair
| to point that out because it was not this way always --
| there was a time when the majority of hardware needed
| some tinkering.
|
| May I ask you what hardware did you install linux on?
| squarefoot wrote:
| > Windows and MacOS don't make people do that
|
| They don't make people compile their own drivers because
| their respective corporations spend some good money to
| pay their developers to work on company provided
| hardware, or harware manufacturers to make their drivers
| first, and sometimes only their drivers. Linux developers
| otoh are often forced to reverse engineer closed source
| drivers on hardware they purchased themselves, so Linux
| support usually comes later.
|
| The upside is that nearly all Linux drivers are FOSS,
| which makes a _huge_ difference as there 's no such thing
| as planned obsolescence among FOSS. Never seen a
| perfectly good peripheral being supported by Windows
| until version x, so that you install Windows 10 and that
| card that worked fantastic under Windows 7 or 8 isn't
| supported anymore? No drivers, no party. Sometimes the
| price to pay for running an OS that doesn't allow you
| compile your drivers is the purchase of new hardware
| along with system upgrades; that represents one of the
| hidden costs of closed source software that should be
| stressed more often.
|
| Edit: ...and btw, it's like 15 years I don't have to
| compile my kernels anymore. A couple things or so have
| changed since 1997.
| Osiris wrote:
| To get my bluetooth adapter to work I had to find a third-
| party driver, compile it, and manually setup DKMS so it'll
| update whenever a new kernel gets installed.
|
| That's a much more complicated process that either macOS or
| Windows.
| colordrops wrote:
| How long ago was this and what was the make and model? I
| haven't had Bluetooth driver problems for a while.
| pessimizer wrote:
| > That's a much more complicated process that either macOS
| or Windows.
|
| Especially when the process on macOS or Windows is that
| they do not support that bluetooth adapter, they will never
| support it, and you should just buy a different one.
|
| I do my hardware compatibility checking _before_ I buy. If
| I 'm going to have to track down and compile drivers, it's
| my punishment for wanting a bleeding edge thing, and I
| always know what I'm getting into.
| jorvi wrote:
| For macOS to use a USB <> Ethernet adapter I had to hunt
| down some obscure driver, and after a certain macOS update
| it kept putting it in a folder on the desktop after each
| update despite it working if I just reinstalled it.
|
| I absolutely used to love macOS and thought that they must
| have the cleanest nicest code in the world because they
| have such a well-developed UI+UX, but in the end, the core
| code below it has the same wrinkles as any software
| project. They're just paved over. Plus, Apple loves to let
| stuff fail silently.
| jandrese wrote:
| On the flipside I have an older but functional scanner[1]
| that doesn't have a driver for modern Windows (Latest
| version is for Windows 7 32-bit) or Mac (Latest version
| 10.6), but still works perfectly fine in Linux.
|
| [1] https://www.usa.canon.com/internet/portal/us/home/sup
| port/de...
| freedomben wrote:
| I don't doubt that happened to you, but I've had almost a
| dozen bluetooth devices and I've only had one not work
| OOTB. I'm using OnePlus Buds Pro with my linux laptop right
| now and it paired flawlessly.
|
| Generally speaking, bluetooth is a complicated and
| proprietary mess though and many (especially cheaper
| vendors) don't bother testing at all. I'm actually amazed
| that bluetooth works as well as it does on linux. Taking a
| few minutes before a hardware purchase to check
| compatibility is a really good idea.
| chana_masala wrote:
| > because they don't want to compile their sound card drivers
|
| I literally had to do this to get my sound card working on a
| new laptop recently. I know it is partially my fault for
| choosing such a new laptop and expecting Linux to work on it,
| but still... it's not an unreasonable expectation to have in
| 2022.
| pessimizer wrote:
| Nothing's special about 2022. The reason Linux doesn't work
| out of the box with things that aren't in a lot of
| developers' hands yet hasn't changed. What's reasonable
| about thinking that the year matters?
| lelanthran wrote:
| > I'm sure people used to say "it'll be years before it'll be a
| viable solution" when Wine was in its infancy.
|
| I don't think so. Wine was viable for me, playing Starcraft
| Brood Wars in 2000.
|
| Other than games, in 2000 it was running a significant number
| of minor applications for me.
| bww wrote:
| Wine was originally released in 1993. You're talking about a
| period 7 years into it's development.
|
| https://en.wikipedia.org/wiki/Wine_(software)
| gh123man wrote:
| Has anyone been able to use darling for iOS CI jobs yet?
| Admittedly I haven't researched this in a while, but one of the
| biggest hurdles in large scale iOS development is sane DevOps
| infrastructure. I know due to Apple's TOS that you will never be
| able to build, sign, and distribute your app on non-Apple
| hardware. But i'd love to use darling to run unit tests/CI jobs
| on commodity cloud infrastructure.
|
| Even if you do get dedicated mac instances, managing them is a
| bit of a nightmare since MacOS isn't designed to be headless.
| 999900000999 wrote:
| This is for Unity specifically, but people are building IOS
| apps on Windows.
|
| https://assetstore.unity.com/packages/tools/utilities/ios-pr...
|
| I doubt any employer would let you do this though. And I have
| my Mac Mini for recording music and building IOS apps. But it
| is neat to see it's possible
| stuaxo wrote:
| There are plenty of much smaller companies and some of them
| would do definitely do it.
| saurik wrote:
| I was doing this--using Darling to run the various tools from
| Xcode on Linux so I could build one of my macOS projects--five
| years ago and it worked great, but I haven't done it much since
| as at some point I started using MacStadium to rent Mac Minis.
| (I want to start using Darling again though, on the assumption
| that it is still working for running more GUI-oriented build
| tools--stuff like ibtool and actool, which I have sadly started
| to need, and now particularly the actual xcodebuild stuff, as
| Flutter is forcing me into that world due to its usage of
| CocoaPods... I hate it :/--from newer versions of Xcode.)
| SmileyKeith wrote:
| For bazel users there is also this project[0] which runs the
| tools natively on Linux without requiring this layer. Although
| you lose tools like ibtool / actool which don't have open
| source re-implementations.
|
| [0]: https://github.com/apple-cross-toolchain/rules_applecross
| yjftsjthsd-h wrote:
| For unit tests, can you "just" build on Linux natively? I'm
| pretty sure Swift and Objective C are supposed to both work on
| Linux, although I assume library/API surface limits that.
| SmileyKeith wrote:
| This does generally work, but it requires a lot of manual
| effort to setup the environment correctly with Xcode's SDKs
| to satisfy the compiler / linker.
| saagarjha wrote:
| Plus, I've found that most iOS codebases, tend to rely on
| parts of Foundation and the Objective-C runtime that are
| not implemented on Linux, even if the code doesn't touch
| UIKit at all.
| teilo wrote:
| Good luck with supporting Mac GUIs. It's a constantly shifting
| target. Carbon is gone, but now Cocoa isn't always Cocoa because
| you also have to support SwiftUI, which is itself a moving
| target.
| Uehreka wrote:
| I thought SwiftUI was an abstraction layer on top of Cocoa,
| Cocoa Touch, etc. so you could reuse code between executables.
| Is that not the case?
| tomrod wrote:
| Excited to see this. Hopefully this resolves the application
| portability issue for Linux (e.g. Microsoft Office native apps)
| danieldk wrote:
| If you want to run apps like Microsoft Office, Wine is probably
| a far better bet. I'd be surprised if Darling runs complex
| Cocoa apps anytime soon.
| xattt wrote:
| There is no possible way to run current versions of Office
| 365 on Linux at present.
| marcodiego wrote:
| I run it with Wine. It is slow and buggy but it works.
| OnlyMortal wrote:
| I'd guess doing the C APIs for CoreGraphics and using those
| under AppKit would be a way.
|
| CoreFoundation already (partly) exists for FoundationKit
| support though I'd probably grab the GNUStep code for that.
|
| Any old Carbon APIs might be a hassle.
|
| Compositing is where it'd get tricky even with Ghostscript.
| It'd be slow without hardware support.
|
| Impressed they can load dyld though. That's a tricky thing to
| do.
| OnlyMortal wrote:
| Interesting. I expect the display postscript (now PDF) would be
| tricky with its compositing in particular.
|
| I doubt Ghostscript would be up to it performance wise as much of
| the DPS is backed by hardware nowadays.
|
| Anyway, good luck!
| mikkelam wrote:
| See also:
|
| https://news.ycombinator.com/item?id=12854895 [nov, 2016]
|
| https://news.ycombinator.com/item?id=19772322 [apr, 2019]
|
| https://news.ycombinator.com/item?id=22700365 [mar, 2020]
|
| https://news.ycombinator.com/item?id=24683669 [oct, 2020]
| bifrost wrote:
| This is cool, would love to be able to use this on FreeBSD as
| well.
| dvirsky wrote:
| Looks like an incredible project, but if GUI is not working, what
| is the current use case for it? Command line apps are usually
| open source and can be compiled in either system. What are people
| using this for in day to day work?
| stuaxo wrote:
| GUI will come eventually.
|
| Some Dev commandline tools and compilers are starting to work,
| so these kind of environments will probably come first which
| will provide better performance than running under virtual
| machines.
| ivolimmen wrote:
| > Some Dev commandline tools and compilers are starting to
| work, so these kind of environments will probably come first
| which will provide better performance than running under
| virtual machines.
|
| Then it's not useful as the only thing interesting on macOs
| are the GUI applications. All the tools I used on macOs for
| the command line where already available on Linux.
| marcodiego wrote:
| Considering POSIX/UNIX heritage of both Max and Linux,
| disregarding user space libs, I'd estimate this to be a much
| smaller effort than Wine. So, besides GNUStep, Is there any
| project to reimplement open-source portable MacOS user space
| libs?
| PaulDavisThe1st wrote:
| > disregarding user space libs
|
| most macOS software uses the APIs offered by userspace libs
| almost exclusively. They represent a huge and vast
| interconnected set of libraries, developed over decades. Maybe
| not quite as large as the entire Windows API, but similar in
| scope.
| VTimofeenko wrote:
| Asking out of inexperience with Mac command line tools ecosystem:
| outside of CI mentioned in the neighboring comments - are there
| any tools that could be useful on a desktop Linux?
| jedisct1 wrote:
| Zig has out of the box support for Darling, in order to directly
| run cross-compiled macOS apps on Linux.
___________________________________________________________________
(page generated 2022-01-05 23:00 UTC)