Unrelated comment, but am i the only one who gets annoyed by the "does it runs safari?" or "does it runs adobe?" questions? It seems a significant portion of "readers" can't or won't actually read, which is pretty ironic on a news site. I hate this.
I use DT almost exclusively for my photo editing since over a decade.
While it is absolutely true that you can do professional work with this you have a very steep learning curve, bad UX and feature overload.
The latter is really a core reason for the bad UX: developers love to add features. Every feature you add becomes another module or another slider.
Every slider or widget you add creates an extra dimension for the parameter vector an artist has to explore to get the result they want.
Less is more. This is contraintuitive for developers. As a developer I would say it is because of the warm, wholesome feeling that adding another feature gives you when you do. :)
Choosing what to leave out or how to combine stuff into fewer widgets is one of the hardest parts of software product development.
And this is the missing piece in so much OSS software.
Just for example, the Phase One (DT-like commercial app) HDR module (which just allows HDR compression of shadows & highlights) has two sliders that cover 95% of use cases.
DT has seven sliders & one dropdown in it's Shadows & Highlights module. Yes, they probably cover the other 5% but a what price?
That's why professional creative software still has an edge and that's why the prospect of being able to run macOS graphical software on Linux is very exciting to me.
But you can do so much in RAW alone. The retouch module alone takes it bounds above others. With the new basic adjustments, they've made many things more straightforward. You can show or hide any modules you don't want
It's hard to guess what experience is 'best'. I prefer having extra knobs.
This is correct. I would say there is still no PS alternative on Linux.
I use Natron a lot for retouching but few people will know about or consider this because it is aimed at film compositing.
But if one wanted to create something better than PS on Linux, looking at professional compositing apps (Nuke, Fusion, etc.) and their OSS clones like Natron would probably be a good starting point.
Note that this appears to require installation of xcode, I recommend reading its license terms which require being run on apple hardware. Only very old versions of the SDK lack those license terms.
Apart from the Xcode toolchain, I cannot for the life of me think of a single macOS application that both has no GUI _and_ isn't already cross-platform or a Darwin/BSD version of a tool that already exists on Linux.
I'd actually like to know what non-Xcode command line apps you (or anyone else reading this!) is using that explicitly target macOS and nothing else - I've used Macs for only about five years and primarily for dev work, so maybe there's a treasure trove of cool stuff I'm missing.
I mostly had the same thought as you, but one thing I imagine some people might want is access to Apple's own command line tools, particularly those who prefer using Linux but need to work with Apple formats for some reason.
There's osascript for executing Applescript code, plutil for working with plists, and diskutil for making DMGs. Those are just off the top of my head, there's probably others too.
Hmmm - that's all fair! Though I'm not very sure why one would want to execute Applescript on Linux - scripts are typically either so platform-integrated that they're useless on non-Mac platforms or so generic that they're trivially replicated in languages like Python or Ruby.
I'd consider diskutil and plutil vaguely part of the "Xcode toolchain" (as in, using them (especially from outside macOS) is largely geared towards app development). That's certainly a huge use case for Darling - I actually think it would be interesting if they explicitly (but maybe not very loudly?) aimed for giving people access to iOS/macOS development without Mac hardware, rather than trying to be a general-purpose emulation layer.
I've been using OS X since about 2002, if I'm remembering right -- I bought my first Mac in 2001, I'm pretty sure (one of the crazy "clamshell" iBooks with a PowerPC G3), and OS X was not really suitable as a daily driver until 10.2 "Jaguar" in August 2002.
I mention all this because even with that nearly 18 years of experience, I am really straining to think of a single non-GUI application for macOS that wasn't a Unix command line port. There are some Apple-provided system utility commands, and, fine, but probably of pretty marginal use in this context.
I think it's a great project, don't get me wrong, and I wish I had the system-programming chops to help. But it still seems to mostly be a proof of concept. I hope it keeps growing!
IINA is much more than mpv. Sure, it uses mpv underneath, but the selling point of IINA is a well thought out UI with just enough features but not too many (totally subjective, of course)
One thing you can do is to look at the programs installed by default on Ubuntu Studio. It's a nice way of discovering Linux media apps without having to browse around on the web—most programs you would need are already installed, though limited a bit to save space on the .iso.
After learning of the existence of a bunch of compatibility layers, I'm now occasionally pining for a Linux→Mac one. Because dealing with BSD software, aka ‘unknown option --help’, is a source of irritation sometimes. Plus there's actually open-source Linux software that doesn't have open-source analogs on Mac (not that I'll remember right now what it was).
But then again, Linux has /proc and a boatload of common APIs beyond kernel calls.
First thing I do on my macs is installing gnu coreutils, sed, awk, etc. I'm happy for people who enjoy the "ideological UNIX purity" of BSD tools but I like to get work done and I don't think that comparing bloat between GNU tools and BSD tools is a conversation that you can meaningfully have on any recent compiter as a full hd wallpaper likely uses more RAM than both combined.
As someone who prefers BSD, I feel right at home on the macOS command line. Although it has slowly been moving towards Linux, e.g. macOS now defaults to bash for the shell.
It is often less verbose than a man page so can be seen entirely without a pager, which is often all you need when you are looking for a reminder of that periodically used option. Certainly having both options (man page and inline help) is better than having only one option.
Nak. Help output can be more concise because it does not have to explain what the command is used for, does not have to enumerate every option for a particular flag, does not need a "See Also" or "Examples" section, etc.
It's what the SYNOPSIS section is for, at the top of the man page, so you don't need to scroll down in the pager.
In a more general sense, though, this is why BSD systems generally try to avoid bloat in the core utilities. It's not about the code size - it never was - but rather the overhead on maintainers and users.
> 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. We're working on this; stay tuned!
Safari mostly uses the open-source WebKit, except it of course sets all the Mac defines and Apple-specific feature flags, and there’s a bit of extra code sprinkled in internally. On Linux you can get something similar but not exactly the same by using one of the WebKit browsers, such as GNOME Web.
Thanks, just installed Epiphany and was able to reproduce issue with flexbox that only Safari had. Somehow I thought that Safari and WebKit browsers were using a bit different forks of WebKit. That proves me wrong.
I'm really happy with alacritty https://github.com/alacritty/alacritty/, blazingly fast and if you're happy with living inside a terminal multiplexer it's really a good experience
I found Kitty underwhelming. Used it for a while because iTerm was too slow/heavy/I used tmux anyway, but no global hotkey + terrible scrolling made me switch anyway.
It is for me. I've just tried it. As so often unfortunately the package is sufficiently out of date to make installation of the author's prebuilt binary (https://sw.kovidgoyal.net/kitty/binary.html) worthwhile.
I’ll let the website do the talking: https://iterm2.com/features.html. It’s not mentioned there, but iTerm’s has native tmux integration too: I barely know how to use it, but they show up as native tabs and windows that I can drag around and tile as I wish.
Everything else listed on iterm's site seem fairly trivial to do with tilix and other linux emulators in general.
In any event, lots of this stuff is better implemented in the shell itself (zsh and so on) much more portable that way.
Both iTerm2 and tilix are great on the desktop. Terminals are just a solved problem these days. Hell even Windows is catching up with their new terminal app (not to mention WSL(2)).
Getting LS to work in a Wine-like environment will be tricky.
I bet it works internally by exposing a separate network
device that filters traffic much like Wireshark, and the low-level abstractions for doing something like that are very OS-specific.
Perfect timing for me. Macbook Pro 2017 logic board died and can't get it in for repair due to shutdowns. So installed Linux Mint on Thinkpad T420. This will help me a lot, I'd be pleased if I could make a permanent shift from Mac.
Is this something Apple is likely to try and break constantly with software updates?
This project is nowhere near the level of Wine, if that's what you're expecting. They admit they have basic experimental support for simple GUIs. Anything command-line is highly likely on Linux anyway.
Lenovo laptops seem to be great machines to convert to Linux. My daily laptop for the past few yrs is a carbon X1 running Mint and I just converted my wife’s (different gen) carbon X1 over to Pop!_OS for her. My only gripe with either is the lack of fine-tuning available for hi-dpi settings but my understanding is that this is a Linux problem generally.
I've been wanting to get it to execute the bonjour conformance test on linux so I can do CI of Avahi against it. I didn't have any luck last time might be worth a look again.
I honestly just last monday moved from MacOS on my desktop (don't ask) to an ubuntu machine, so that I can use my nvidia card. I'm already missing a few apps, this looks really neat! I'm really hoping they work out how to get bigger apps running nicely
TLDR; "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."
Don't get your hopes up (too much) though. They will have to rely on an open source reimplementation of Cocoa (e.g. Cocotron or GNUStep) to support GUI apps. These are a long way from providing a full implementation of the macOS frameworks. You cannot just take a random Objective-C or Swift macOS app and recompile it using these open source libraries. So, binaries is even much further away. Even Wine, which has seen two decades of development (including from companies such as CrossOver), only supports a small subset of Windows applications very well.
Of course, it might be possible to re-use macOS' frameworks, but Apple would probably sue anyone who tries to offer that into oblivion.
BTW. I think this is a great project, but there are some people who seem to be rooting for using this for running Creative Suite on Linux. That won't happen anytime soon, if ever. Wine is your best shot.
On the other hand, it's a bit weird that Darling requires a kernel module. Given the name (darling-mach) I guess it's doing something to make Linux look more like XNU, but it's surprising that the Darling team has to do that within Linux itself (given that Wine is apparently able to make Linux look like NT in userspace).
Not sure it's the underlying reason, but for a long while Go would use raw syscalls on Darwin, which is something that Windows has explicitly sabotaged for ages. It's a lot easier to trap a library call from userspace than a syscall.
Their Linux kernel module does seem to be XNU based, but it feels like poor design / a rushed job to run it as a Linux kernel module instead of isolating it in userspace.
Rushed job? We've been at this for almost 8 years. We tried doing this without a kernel module for several years, but it just wasn't feasible.
You see, people think XNU is just another kernel, but it's very different from Linux or the Windows kernel. The only reason why we need a kernel module is Mach IPC. But this IPC is so critical and omni-present that a user-space process cannot even do a sleep() without using it. Even event loops in every GUI application use Mach IPC on the lowest level.
There is no way of implementing the full semantics of this IPC mechanism without a help from the kernel. For example, Mach IPC involves making direct memory copies between processes.
So even if we decided to take the "wineserver" approach, which would set us back by several years, the result would be super slow and not very compatible.
Also the userspace on macOS is quite different from other operating systems, which is why it's all taking us so long. MacOS is a bloated system with a huge number of layers sitting between the UI toolkit and the windowing server.
Imagine creating Wine from scratch. How much functionality would you need to implement to provide the correct behavior for a super-simple native GUI application? Probably just USER32, GDI32 and KERNEL32 would do. On MacOS, this is AppKit, QuartzCore, Foundation, CoreFoundation, libobjc and libSystem (which includes huge components such as libdispatch and emulating complex APIs such as kqueue).
FYI: The reason why we don't emulate raw syscalls is because this is not possible from kernel modules, unless you resort to techniques that could easily destabilize the whole system.
While I agree with your overall point (and agree that it's unfair to characterize the hard work y'all have been doing as a "rushed job")...
> How much functionality would you need to implement to provide the correct behavior for a super-simple native GUI application? Probably just USER32, GDI32 and KERNEL32 would do. On MacOS, this is AppKit, QuartzCore, Foundation, CoreFoundation, libobjc and libSystem (which includes huge components such as libdispatch and emulating complex APIs such as kqueue).
I don't think "number of APIs" is the reasonable benchmark for how difficult it might be to get a GUI application up and running. It's totally possible that macOS might more eagerly split out functionality into different systems while Windows combines that same functionality into relatively few. I don't know how true that is, but it'd be interesting to compare based on the depth of those libraries rather than just the quantity.
And from what I understand about Wine, all three of those Windows libraries are incredibly complex and convoluted, and even to this day have gaps in their Wine equivalents. Assuming macOS' greater quantity of necessary libraries add up to the same degree of API surface to be reimplemented, what y'all are doing is impressive, to say the least (and sure, Wine's more usable right now, but Wine also had a decade or two of a head start).
This software runs MacOS software in Linux. WSL2 can run Linux software on windows. This means theoretically you can use Windows to run WSL2 to run Darling to run XCode.
Take the first three letters of each name; Darwin gives you "dar" and Linux gives you "lin". Combining these, you get "darlin". Then, presumably the authors wanted a dictionary word for their name, so they chose darling.
2016: https://news.ycombinator.com/item?id=12854895