Live data from Hacker News

Darling – MacOS translation layer for Linux

darlinghq.org

101–110 of 274 posts

Re: Darling – MacOS translation layer for Linux

#101
post #81
post #49

Earlier quoted context omitted.

> it lacks well designed high quality GUI applications. If porting to Linux was done easier that could change. Fundamental to most peoples complaints about desktop Linux applications is the lack of look and feel cohesion across all permutations of distro, desktop, and toolkit. Wine applications using the Windows APIs look like complete garbage and fit in nowhere. The same would be true of OSX Cocoa apps - they wouldn…

If you theme them, then they look quite a bit less terrible. There is a clearlooks theme that makes things quite a bit more bareable.

Paper (https://snwh.org/paper/theme) is a particularly great theme for the Gnome desktop (it also works with Budgie, Pantheon, and Unity, but I haven't tried it on any of those). The author's icon set is also pretty nice.

Re: Darling – MacOS translation layer for Linux

#102
post #2

Hmm. I guess many developers use just the right amount of MacOS specific tools to justify this now. The git client Tower is something I've eyed before, but most tools I use are available on Linux, and I say that as someone who uses a Mac at work.

So many awesome GUI tools for developers on Mac, I can't find on Linux. E.g. OmniGraffle is fabulous for doing diagrams. I have not found anything as well designed and functional on Linux. You got so many nice git clients: Tower, Gitup, GitX etc. There are awesome diff tools like Kaleidoscope. There are a lot of good tools for keeping all sorts of notes, programming snippets etc. My life is pretty much centered on Ul…

[deleted]

Re: Darling – MacOS translation layer for Linux

#103

Earlier quoted context omitted.

> Anyone that likes commodities of UNIX... This is an untrue generalization. I know people who have a Mac, yet do all of their actual coding within containers set up to use some flavor of Linux and never really touch the underlying OS. Macs DO have solid, reliable hardware underneath, but the insinuation that there is no reason you need to run a true POSIX compliant OS vs MacOS is definitely not a hard and fast truth…

OS X is posix-compliant. It doesn't implement certain GNUisms but depending on any vendor-specific problems is going to be a pain point.

Darwin is very much not POSIX-compliant. It may aim to be, but there are so many blatant unfixed bugs (broken poll, broken cmsg, etc.) and missing features (ptrace, etc.) that porting work is frequently necessary.

Re: Darling – MacOS translation layer for Linux

#104
post #2

Hmm. I guess many developers use just the right amount of MacOS specific tools to justify this now. The git client Tower is something I've eyed before, but most tools I use are available on Linux, and I say that as someone who uses a Mac at work.

So many awesome GUI tools for developers on Mac, I can't find on Linux. E.g. OmniGraffle is fabulous for doing diagrams. I have not found anything as well designed and functional on Linux. You got so many nice git clients: Tower, Gitup, GitX etc. There are awesome diff tools like Kaleidoscope. There are a lot of good tools for keeping all sorts of notes, programming snippets etc. My life is pretty much centered on Ul…

[deleted]

Re: Darling – MacOS translation layer for Linux

#105
post #77

Earlier quoted context omitted.

I go back and forth on whether this would truly be useful. 10-15 years ago, having a fully baked, first class, slavishly source compatible implementation of GNUstep with broad adoption throughout Linux land would have likely been a game changer. But now, it seems webified apps are king. The handful of native apps that people use are already satisfactorily implementable on Linux. In fact, a great number of native apps…

I wrote a blog post once about how the web is the new presentation layer for the desktop, that this is not necessarily a bad thing, and that a desktop OS (e.g. a Linux distro) should just fully embrace it by implementing a desktop that runs 100% via web technologies. Local and remote web apps could coexist as first class citizens, etc. I basically argued that HTML+JS+CSS renderers are the new X and that HTTP(S) is th…

Please don't allow a few toxic loudmouths to create your opinion on an entire community of people.

Re: Darling – MacOS translation layer for Linux

#106

Back in the PowerPC days, there was a thing called Mac-on-Linux [0] that allowed GUI Mac apps to run in Linux. It worked pretty well. I wonder if that code base would be helpful. [0] https://en.m.wikipedia.org/wiki/Mac-on-Linux

Mac-On-Linux ran a complete copy of Macos, so it's not really the same thing

Re: Darling – MacOS translation layer for Linux

#107

Back in the PowerPC days, there was a thing called Mac-on-Linux [0] that allowed GUI Mac apps to run in Linux. It worked pretty well. I wonder if that code base would be helpful. [0] https://en.m.wikipedia.org/wiki/Mac-on-Linux

MoL ran the entire MacOS (9 or X) in an X window or VT, making it a full virtualization layer like VMware or VirtualBox. This is a binary loader/API translation layer/reimplementation, like Wine.

Re: Darling – MacOS translation layer for Linux

#108
post #77

Earlier quoted context omitted.

I wrote a blog post once about how the web is the new presentation layer for the desktop, that this is not necessarily a bad thing, and that a desktop OS (e.g. a Linux distro) should just fully embrace it by implementing a desktop that runs 100% via web technologies. Local and remote web apps could coexist as first class citizens, etc. I basically argued that HTML+JS+CSS renderers are the new X and that HTTP(S) is th…

While I agree with your view of HTML+CSS+JS in relation to X and would even go as far as to say the shift towards "webified" apps is (mostly) a good thing, it still saddens me as a developer to see it happening. It's an ecosystem that doesn't discourage lazy practices and it makes me feel unimportant because modern computers can more or less keep up with even the most poorly-written webified apps. I think it's that s…

agree with you....

...but the embedded world is also being slowly infected with JS, java and people wanting to run interpreters on embedded devices for which they are totally inappropriate.

Oh well.

Re: Darling – MacOS translation layer for Linux

#109
post #77

Earlier quoted context omitted.

I wrote a blog post once about how the web is the new presentation layer for the desktop, that this is not necessarily a bad thing, and that a desktop OS (e.g. a Linux distro) should just fully embrace it by implementing a desktop that runs 100% via web technologies. Local and remote web apps could coexist as first class citizens, etc. I basically argued that HTML+JS+CSS renderers are the new X and that HTTP(S) is th…

Why do you need a desktop running 100% via web technologies? What's the advantage of that? BTW, IIRC KDE uses JS for some Qt stuff and GTK uses CSS for themes. How is HTTPS even close to X11 protocol? That's like saying a car engine can function as a steering wheel. BTW /r/linux is not all Linux users.

The advantage is long-term at the level of the ecosystem. You can leverage the world's largest developer pool and ride the coattails of major corporations.

Qt, GTK, and other desktop techs are "weird" little tiny niche skills to acquire, and since desktop dev in general is lower priority these days they're going to be rare. HTML5+CSS+JS with a stack based on React or Ember will draw tons of dev talent.

For consistent look and feel the environment could standardize on a single set of CSS themes (maybe a fork of bootstrap) and a "recommended" UI toolkit (I'd recommend React). Use of other CSS or other UI toolkits is okay, but if you do you're strongly recommended to hold to the style guidelines.

Those style guidelines could in turn be informed by things like Atom, Visual Studio Code, Slack's desktop app, etc.

Re: Darling – MacOS translation layer for Linux

#110
post #7

Is there anything the other way around? Running a Linux binary on MacOS? Sometimes the source isn't available so recompiling isn't an option.

Good question. Given the well documented and stable x86/x86_64 Linux ABIs, it should be at least as feasible as the Darling project. I've been watching projects like Darling and libhybris (run Android bionic libc binaries on glibc) but I haven't seen any project for running Linux ELFs on macOS specifically.

Projects like usercorn are already emulating lots of Linux syscalls on non-Linux hosts. Things are even easier if you can ignore the binary emulation and just focus on melding the two different ABIs and APIs.

I used usercorn to try and debug an Android shared lib on macOS. I got some of the SO to correctly execute (full dynamic linking wasn't working) but it did require light patching of usercorn. I would have had less issues if I was emulating a Android guest on Linux host (instead of macOS host) since you're syscall mappings are almost 1:1 then.

https://github.com/lunixbochs/usercorn

Post reply on HN