Darling: macOS Translation Layer for Linux
darlinghq.org
darlinghq.org
Apple needs to force developers to use their hardware or it won't have a native/refined feeling and developers will stick to Windows/Linux without the extra step of Apple.
Or Apple stops making as much money in hardware sales and might actually have to lower their prices?
>developers will stick to Windows/Linux without the extra step of Apple.
Doesn't that mean Apple is already superfluous and only exists because of arbitrary restrictions created by Apple making the entire ecosystem artifical?
That already was a threat, in 2018 they removed their total unit sales numbers for a reason. The number was falling. Now they only report total revenue which they are boosting by cutting corners where they can.
And they are still clamping down in the walled garden to further cement their position.
Blocking xcode from running in darling is just a question of when.
Same way Tcl isn't tickle, PNG isn't ping, and LaTeX only grumplingly and with quite some self discipline on our side manages to remain la TECH. These jokes were marginally entertaining 30 years ago, tired by the turn of the century, and way past expiry today.
They can hardly be marginally entertaining to someone 30 years ago if the person in question wasn't even born then! :)
But they can most certainly be marginally entertaining to this person today!
https://en.wikipedia.org/wiki/William_Houstoun_(lawyer)
So, no joke involved in that case.
Does your circle call it "S Q L" or "sequel"?
squeal, obviously.
the "correct" pronunciation is whatever the community decides, despite what we may individually think of it.
As such "jif" is decidedly _not_ the "correct" pronunciation because essentially the entire community says "gif"
"jif" would be the "archaic" pronunciation. Technically valid, but not used by anyone except for hold-outs and people who refuse to accept modern pronunciation standards.
But, everyone pronounced it with a short 'i' and now they've adopted that in adverts - 'Every little [lidl] helps' - doesn't work if you pronounce it Lie-del!
If they wanted it pronounced Lie-del - they should have spelt it like that - Lidle!
Just to drive the point home: Language is fluid, English has no organisation setting any rules and we the people get to decide how we pronounce things. And we've pretty clearly decided on what way we want to pronounce gif.
I feel like I heard about it a number of years ago and then it never went anywhere.
The copyright at the bottom says 2012-2019, which makes me think it's the same project.
https://github.com/darlinghq/darling/commits/feature/arm-sup...
I suppose that could be a gate to prevent people from installing on more machines than the license allows if done at scale. But doesn't lock out legit reinstalls from paying customers. For a cost to MS, to employ that staff.
This is what makes a big difference with doing business with Google and having to deal with bots instead.
I’m still regularly hit with “Activate your account” when I run my windows partition from parallels because the “hardware” has changed!
Does that make it a Mac still? You could literally replace almost every component in a Mac except for the motherboard and have it still be a Mac, but shouldn't the converse be true as well? If I used the original case, hard drive/SSD, video card, keyboard & mouse, even the CPU, but replaced just the logic board (swapping the ROM/EFI/SMC somehow), it seems to me it would still be considered a Mac. Particularly if in the process the original logic board was rendered inoperative to head off any claims of duplicate license use.
> Does it violate Apple's EULA? > > No! We only directly use those parts of Darwin that are released as fully free software.
How can it be permissible to buy software and not be allowed to use it on whatever you own? You own both. It's like DRM without the actual protection.
> You are expressly prohibited from separately using the Apple SDKs or attempting to run any part of the Apple Software on non-Apple-branded hardware.
Better be running linux on a Mac mini somewhere.
Statically linking the library might be preventable because it involves spreading Apple's code, but if you run a legally obtained program that generates code not containing any libraries on your own computer, I doubt there's anything that the EULA can prevent you from developing that way.
(Analogy: You buy a music CD; You do not need a specific license to listen to it, and you're not violating anything even if it has a sticker that says "by opening this sticker, you hereby agree to never play this using a Sony CD player, and to never play it at faster than 1.25x on any non-Sony CD player)
At least we could use Docker!
..and get actually reproducible builds...
I haven't checked, though I'm fairly sure the license says you're lot allowed to, though.
In my experience developing cross platform open source software, doing builds isn't the biggest problem. The situations when you need to debug platform specific behaviour, integration with OS and verifying that your software is properly packaged for macOS is when you might want direct access to a real machine.
Basically apple forces everyone to only run MacOS on it's own hardware and it's own hardware is unsuitable for the usecase.
(And yes I know about the imgix mac pro cluster)
I've tried this myself and failed.
But I genuinely wonder, why you think this is illegal. I mean, do you think that Apple's T&C are laws? I can't think of anything else that activity would be in violation of.
Does this matter if you never signed a contract with Apple in the first place?
I failed at it too, but then some bright spark wrote this script that works like a charm. Bear in mind that the VM might be too slow for normal use.
They better figure this out and release some good VM support because I have very little interest in buying all of their stuff just so I can run my build.
I did get the VM to work eventually and have been experimenting with builds on that. The VM is slow so I'm starting to lose interest in doing any more grunt work for an extra 10% of revenue. Ah, who am I kidding. I'll do it because I'm just as greedy as they are.
I have a GDI laser printer that comes with Mac drivers. I really want them to work on Linux.
More generally, it doesn't offer much of practical value to use the Darwin kernel which is at this point pretty tied to Apple hardware that comes with OS X anyway. You can still Hackintosh but it just adds a lot of additional complexity that you won't have to deal with on Linux.
upd: googling "OpenDarwin" bings up two first results that are news of it closing, in 2006
That said at this point I don't see anything inherently easier or beneficial about this than creating some other project around an alternative paradigm than PC derived desktop systems on top of some existing better supported kernel.
That said contrary to what the previous poster implied I don't think either OpenDarwin or PureDarwin aimed at reproducing the proprietary bits—they were/are essentially quirky, buggy, poorly documented BSDs just as reliant on the floss ecosystem as much better supported stacks.
Why? Where does this logic come from? And apparently it's common, because PureDarwin mentioned in another comment does just that for some reason.
IMO, the right thing to do would be to replicate Apple's proprietary stack as closely as possible. Like, literally take the real macOS and start replacing essential proprietary frameworks like Cocoa and Quartz and core apps like Finder and Dock with fully API-compatible open-source ones. You'll eventually end up with a fully open-source operating system capable of running macOS apps.
There's also some hairiness legally about working from within the official Mac OS system outwards AFAIK.
That's the point. ReactOS doesn't use any of the Linux parts, and it's reimplementing everything from scratch because there are no open-source components in Windows afaik.
To some degree it is. On the other hand this is also why I prefer to use Ubuntu or Debian over any other distribution. They are highly integrated and opinionated in the sense that they keep the packages as unmodified as possible.
* https://reactos.org/wiki/ReactOS_FAQ
I found this disappointing at the time that ReactOS was announced, as I recall, because there were a few things that were architected better in Windows NT 6.
Which is not completely dead, but also not that active.
Turns out there is a big effort difference between “why don’t they just”ing on forums and actually doing it! :)
What compromises does Ubuntu have vs MacOS? It has orders of magnitude better gaming support thanks to Wine + Steam Proton.
Besides that, Linux desktop is this loosely stacked pile of different components that sometimes falls apart. No one wants to spend 50% of their time writing config files and setting up drivers instead of actually doing something useful.
I don't understand how you can make sweeping generalizations about every desktop environment that runs on Linux. Every DE is an afterthought? Just the fact you call them "Linux GUIs" makes me question how much you have even used any DE with Linux.
I spend no time writing system config files. Drivers are part of the kernel, so I also spend zero time on that. Brand-new laptop hardware sometimes takes a while to get support, but it is really easy to check before you buy.
It is perfectly OK to prefer a padded, walled garden. Just like it is OK to prefer a modular OSS Linux environment where everything is knowable. Nobody needs to be "right", and nobody needs to bash the other with unsubstantiated claims.
I don't like walled gardens — I despise Apple's service ecosystem and the app store. I just prefer things to work sensibly out of the box. The only reason I made an Apple ID is because it won't let me download Xcode without one.
- Why do you think are there so many different DEs, window managers and UI frameworks out there?
- How would you go about introducing one singular UI and UX across all of Linux?
- How would you foster competition and innovation in that space?
- Why do you think Apple is able to define and (somewhat) enforce their standards?
[1]https://corpcons.nz/images/thumbs/0062343_pascall-deltas-jet...
Does anyone else have any Mac apps on their "run-on-linux" wishlist?
One example out of many: https://unix.stackexchange.com/q/313865/5132
Alacritty is way faster in my experience.
That leaves me out as Linux user from our pair-programming-sessions (Jitsi and Google meet with screensharing does solve some). Not sure if this is a blessing or if I'm really missing out.
The home page of Darling specifies "experimental support for running simple" GUI. Does anyone have any idea whether Metal support (which Sketch uses) is out of the question?
1. Apple hardware 2. Bare-metal linux OS 3. Emulation/shims to run MacOS software on top
Sure, it seems like a horrific Frankenstein's Monster of a setup, but since I can't have the best commercial applications, running on the (IMHO) best OS, running on (IMHO) the best hardware, this is a pill I would be willing to swallow.
But unless you have the capability of running the GUI, it's hard to justify (is there a killer cmdline only app for Mac OS? I don't think so)
https://ubuntuforums.org/showthread.php?t=2091148&page=2&p=1...
> A: Almost! This took us a lot of time and effort, but we finally have basic experimental support for running simple graphical applications. It requires some special setup for now though, so do not expect it to work out of the box just yet.
GUI support seems not to be ready yet, but when it is, it looks like they're using cocotron, so it'll look something like any of the examples you see on this page: http://www.cocotron.org/Examples/
Or has anyone figured out another way to do that?
If this goes beyond just the "window dressing", it may cause UI issues
But that's not necessary. There is open source code at the base of macOS and iOS, and it's only that being used currently. Even to go further and create a full clone of iOS would be fine, if (and only if) a "clean room" implementation were made.
They denied the original appeal over copyrightable APIs. There was a second trial over Google's fair use argument and the jury ruled for Google. Oracle appealed and the Federal Circuit ruled against Google again. That decision was appealed to SCOTUS on January 24, 2019. Google's petition challenged both decisions by the Federal Circuit: APIs are copyrightable and Google's use of the Java API wasn't fair use. Certiorari was granted November 15, 2019 and arguments were planned for October 7, 2020.
Traditionally emulators are distributed without any infringing code; it's up to the user to extract what they want to emulate from devices they own. For example, 3DS emulators don't ship with a copy of Nintendo's system software, they instead require you to buy a 3DS, hack it, and use some GodMode9 scripts to extract the relevant files. Similarly, one could have developed an iPhone emulator that requires the user buy and jailbreak a phone, and dump the relevant OS files (or extract it from an IPSW available from Apple, etc). This would have most likely been legal.
Projects like Darling are a step removed from even that. Instead of providing a tool that lets the user run Apple's OS in emulation, you instead write your own OS that provides all of the relevant APIs/ABIs necessary to allow software dependent on Apple's OS to run. This tool can then be distributed entirely freely with zero Apple ownership involved. This approach is entirely legal, at least for another week or two, depending on if the Supreme Court understands what an "API" is better than the Federal Circuit.