Live data from Hacker News

Darling – MacOS translation layer for Linux

darlinghq.org

151–160 of 274 posts

Re: Darling – MacOS translation layer for Linux

#151

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.

OS X is UNIX 03 certified. That's a formalism.

1) That's a nearly 15-year-old standard (03 == 2003). Windows was certified to the predecessor POSIX standard.

2) While certified, it's compliance in actuality is poor. macOS's certified status says more about flaws in the certification test suite and administrative process, and the OpenGroup's need for income, than it does about macOS. The manual page for pselect, for example, even admits that it's not compliant!

FreeBSD, Linux, NetBSD, OpenBSD and probably DragonflyBSD are all more compliant in a practical sense than macOS, and much more compliant to the latest specification as they implement all or most of the newly defined interfaces, while macOS implements very few.

That said, yeah, macOS is compliant enough as a practical matter, especially compared to Windows. Porting stuff to macOS is about as painful as porting to Solaris or AIX, which is to say not very painful.

The biggest headaches with macOS are the bugs. For example, last week I was adding support for sendmsg/recvmsg and IP_PKTINFO in my Lua unix module and was able to reliably crash the kernel with a single line of unprivileged code:

  https://www.irif.fr/~boutier/mac-crash.html
I was really confused at first. I had to reboot multiple times before I figured out it was my test code and not my hardware dying. After some Googling I found the above link that verified what I was seeing. This bug was only fixed, AFAIK, in macOS 10.12. (I don't have a 10.11 machine to test.) I was testing the code on 10.10, and as of the latest update a couple of days ago 10.10 is still broken AFAIK.

The most famous problem was kqueue not supporting pipes, but that was fixed eons ago. There are alot of other problems with their neworking subsystem, though. For example, shutdown() fails if the associated stream has already entered the equivalent state, either because the sender sent RSET/FIN or shutdown was alreayd called; no other implementation does that. If you send a socket descriptor to another process with sendmsg and then immediately exit the process, the receiving process will receive an unuseable file descriptor. There are lots of stupid quirks like this that make writing reliable, high-availability software for macOS very difficult. Fortunately, few people use macOS for HA server stuff, but I like porting my software to other platforms because it helps catch bugs (bugs that, for w'eve reason, stay hidden when running on Linux), and macOS provides a poor signal/noise ratio in that regard.

Re: Darling – MacOS translation layer for Linux

#152
Another similar project was Magenta OS: http://crna.cc/cat/open-source

>Magenta was my attempt at implementing a mach compatibility layer on top of the Linux kernel.

The 2012 archive.org cache of this page has some details: https://web.archive.org/web/20120619162157/http://crna.cc/ma...

Re: Darling – MacOS translation layer for Linux

#153
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.

> GTK uses CSS for themes.

GTK3 yes, and it been constantly changing between minor versions so that most of the people that liked doing GTK2 themes abandoned doing GTK3 themes.

As for /r/linux, i get the impression that their permanent residents are a mix of gamers and "devops" these days.

Re: Darling – MacOS translation layer for Linux

#155
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…

> I basically argued that HTML+JS+CSS renderers are the new X and that HTTP(S) is the new X11 protocol-- or at least that these parts occupy an analogous position in the stack to what X originally was. (They are technically quite different of course.)

While i agree from a technical POV, i disagree that this can be seen as a good thing.

Re: Darling – MacOS translation layer for Linux

#157
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…

I totally agree with you. Good example is Atom editor. Also I totally liked the idea of Firefox OS. Shame it died. IMHO it was totally Mozilla fault. They shipped FF OS with under powered hardware. When I asked them, why. Was told their focus is on emerging markets. Well focus was wrong. If they put Firefox OS on some decent hardware, I would love to buy it.

They also tried to push a open to end user modification phone firmware by partnering with carriers. And carriers are notorious for wanting to put in bloatware, and locking it in place.

The Mozilla of recent years is a massive example of the whole "busybody" problem that FOSS is having these days. Too many people with some kind of "social" angle has gotten involved on the management end to tout their own horn.

This then is draining resources and taking focus away from writing good reliable code as they are chasing the latest "social problems" to solve so that said management can add another entry to their resume of causes championed.

Re: Darling – MacOS translation layer for Linux

#158

Earlier quoted context omitted.

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…

Minor note: Sublime also runs fine on Linux and Windows.

Exactly. That's what I use.

Re: Darling – MacOS translation layer for Linux

#159
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…

I am truly sorry you caught the brunt of the toxic parts of the Linux community. It's a part of the community that has existed since I first started using Linux in the mid 90s. It sounds like you offered some thoughts about what you felt was the right thing to do, and people reacted violently to it. I personally wish we had a first class, broadly adopted Free *nix desktop option with native GUI and the like. I am not…

A major problem with the more user facing layers of Linux is that the developers involved are using those few loudmouths as an excuse to dismiss all feedback from non-devs.

End result is that they are operating inside an echo chamber of sorts, thinking they just need for sharpen the UX more to make "year of desktop Linux" happen while alienating existing desktop Linux users.

Damn it, Windows is not the leading OS because it has a sharp UX. Microsoft, besides their questionable behavior with OEMs and bundling, leaned over backwards to make sure Windows offered a stable usage environment.

Even with Windows 10 can you run a binary from the early days of Win32, as long as you use a 32-bit install. The reason it is not working on 64-bit is because the CPU modes needed are mutually exclusive.

Re: Darling – MacOS translation layer for Linux

#160
post #50

Earlier quoted context omitted.

If you're interested in porting code, many of the OSX core libraries are available as part of the GNUstep project: https://www.gnu.org/software/gnustep/ Most of "cocoa" came from the OPENSTEP specification, and GNUstep offers quite a complete implementation.

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…

> 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.

I think that GNUstep has actually been around since the mid- or late-90s — but it was never a game changer. I don't know why really (was it 'fully-baked' and 'first-class'?), although for my part I just never found a reason to use it.

Post reply on HN