Darling – MacOS translation layer for Linux | Hacker News Reader

Darling – MacOS translation layer for Linux

darlinghq.org

630 pointsmikemoka265 comments

I am hoping that with cross platform Swift we can start seeing more libraries to help us port Mac apps to Linux. I am a Mac developer but I'd love to make stuff available on Linux.

I really like Linux as a backup plan, in case Apple totally drops the ball on professionals on the Mac.

The Linux desktop is getting pretty good, but it lacks well designed high quality GUI applications. If porting to Linux was done easier that could change.

> I really like Linux as a backup plan, in case Apple totally drops the ball on professionals on the Mac.

Is this a joke, referencing the new MBP releases?

Personally, I've been saying we're there already. I haven't bought a Mac in years. (employers keep giving them to me and I install Ubuntu on them.)

How well does that work? I love the hardware, but I'd love to run ubuntu on my MBP even more.

Not sure about Ubuntu, but https://antergos.com works very well on my 15" MBP out of the box.

> 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't mesh well at all, and it would be practically impossible to skin them with toolkit theming.

That, and recent efforts by Gnome and KDE have been producing tons of good new applications with modern GUI. They just aren't all the applications yet.

I suppose it's useful when almost everything works, but that one thing that you absolutely need isn't otherwise available.

This is my problem. Audio editing on Linux is a joke. For everything else I do, Linux can get me there. So I need a Mac or a PC as an audio editor? Might as well just get a Mac or a PC. I'll have to maintain it anyway, and it can do everything Linux can do, plus probably be better supported.

Would like to point out, unless you are running on non-x86 hardware or a tablet, the term pc still applies to linux based hardware.

It technically also applies to Macs -- but in practice it means Windows-based desktops and laptops.

What about video editing? I mean, I can live with Audacity for my basic needs, but I can't find anything simple as iMovie. Or should I just bite the bullet and learn Blender? Does it have preset screen transitions and stuff like that?

Have you tried openshot[1]? I haven't played much with it recently, but when it came out it was the most stable, simple video editor for linux.

[1] http://openshot.org/

No. Wow, a lot of great suggestions here. I need to test stuff now :)

I've had great success with Kdenlive. It's not as simple as iMovie, but it isn't too hard to get started.

Blender is 3d modeling and animation, vastly divergent from video editing with kdenlive / openshot / etc.

Perhaps somewhat surprisingly, Blender actually contains a non-linear video editor as well.

And it's probably one of the nicer options if/when you finally "get it". But the learning curve is tough.

It's the least bad NLE for Linux. The UI is awful, but it's stable and has a reasonable feature set.

Blender probably contains a full copy of Blender inside itself too. That program is nuts.

I was completely lost when I tried to use it. I wasn't even sure I found the NLE section of the program.

Shotcut, Kdenlive, Blender (overdrop)

Blender's Video Sequence Editor just has a couple of quirks to get past. It is not deeply mysterious.

Like: the VSE viewer and the Image viewer are similar but distinct; that can be confusing. And OpenGL acceleration on a Scene strip shows a 3D model rendition that is not (in general) the same as the rendered output of the Scene.

If you want to get fancy with the compositor + VSE, again there are just a couple of quirks but the learning curve is merely steep, not long.

There's also Flowblade from Finland: http://jliljebl.github.io/flowblade/

I'm using OpenShot, it's perfectly serviceable, particularly the new 2.x version. There's also LightWorks and many other that works really well.

Have you tried DaVinci Resolve? Last I checked it had a native Linux version. Unfortunately I don't think the Linux version is available for free (unlike the Windows and Mac versions).

What about Ardour?

I've seen a friend use it for some basic multitrack stuff - basically recording his band live whilst practising. But, it is not a patch on something like Reaper.

You're mistaken, Ardour is comparable to ProTools, Reaper and similar DAW. It's also compatible with VST plugins, etc.

It's the same with RAW image conversion software used for photography. I'd dump OSX on my MBP and never look back if Capture One or DxO Optics ran on Linux.

The open source alternatives are no where near as fast, they lag far behind supporting new cameras, their interfaces are ugly and difficult to use, etc.

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.

Quick googling "material theme gtk" returns this which looks very nice actually https://github.com/nana-4/Flat-Plat

oh no. Another "flat design" theme. A button must be distinguishable from other design elements in my opinion. I hope this fad goes away soon, it's even more annoying than the glossy look or skeuomorphs.

Nothing is more annoying than skeumorphs. :)

It should be distinguishable, not just from the theme. A good UX/UI design will make that clear regardless.

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.

That really is quite nice. Looks great in Elementary.

Wow! Definitely one of the best designs I've seen in the OSS world. Finally someone with actual design chops has risen the bar!

It lacks contrast. The fonts in particular are too thin and hard to read for my liking.

Using KDE the theme is pretty similar even for GTK apps.

I think a better way to handle this is to show people how to use the command line. That does have a cohesive look and feel and is generally very well behaved compared to nearly anything else.

Unfortunately that seems to scare people away so everyone hacks GUIs together to keep them from running and that's how we got to where we are now.

Doubtful.

I like text interfaces as much as the next nerd, but most people want to interact with a computer intuitively: see a thing and interact with that thing.

In other words, "point and click". (Or just "point" if it's a touchscreen.)

My 2 year old doesn't know the first thing about computers, but he'll jab his finger at the screen when he sees something he likes.

I don't know, language seems fairly intuitive but it's not in style. The only people who really struggle with it are illiterate. (ex: very young children) In those situations you really do need a special UI that will be frustrating for normal people.

That's a strong criticizm. There are a lot of equally valid linguistic ways to view the contents of a directory. But only one grammatical and lexical way to command the computer to do it with text.

'Open folder', 'show contents', 'see items', why does 'ls' make more sense? It certainly has nothing to do with literacy.

The same can be said for GUIs though, look at how different mobile GUIs and desktop GUIs are. It's actually a real problem that people think their GUI is intuitive, they never end up documenting it. CLI app authors know this and are forced to face reality and at least write usage text.

GUI tends to be more discoverable - in the worst case you can simply click through all the menus and see what all the available commands are. That tends not to be the case with a CLI - the man page requires a context switch and tends to go on for dozens of pages, some programs have good '--help' output but many do not.

Have fun editing HDR footage or cutting samples on the command line. Don't get me wrong, but MacOS is exactly my platform of choice because I can have a sane POSIX command line as well as a color managed display and high resolution, low latency multichannel audio on the very same computer and can switch effortlessly.

You're actually manipulating graphical data though, in that situation a GUI makes a lot of sense. Using a GUI for editing E-mail or joining a WI-FI network is silly, just like it is for most things people do with computers.

No, it's not. GUIs give amazingly good discovery, when compared to CLIs. Most people use computers as simple tools. They want it to be easy to figure out how to do what they want, not to have to look it up or work it out. CLIs are great for power users, but they suck for casual users - and "most things people do with computers" are casual usage.

Are you truly managing email through a command line interface? Or are you using something like Pine? Isn't Pine just a GUI created out of characters instead of graphics? True GUI interfaces compared to ncurses type solutions offer way more fidelity and power.

nmh FTW!

>Using a GUI for editing E-mail or joining a WI-FI network is silly, just like it is for most things people do with computers.

Englebart? Sutherland? Kay? Idiots! Fifty years of academic and industrial research into Human Computer Interaction? Arrant nonsense. Let's blow it all off and do your thing. What could possibly go wrong? [0]

[0] http://gandre.ws/blog/blog/2015/04/07/why-the-command-line-i...

I think one of the big reasons that many dev tools are command line programs is that command line interfaces are just easier to code, even if you are writing all the parsing logic from scratch. You don't have to worry about designing a layout, hooking logic up across a UI thread, wrestling with a widget library, etc.

On UNIX, the Windows, macOS culture is to provide GUIs for developer tools even if they might look a bit ugly.

> I think a better way to handle this is to show people how to use the command line. That does have a cohesive look and feel and is generally very well behaved compared to nearly anything else.

Not really. CLIs can be terribly inconsistent look and feel, even within the same tool (see git), which makes their lack of discoverability even more painful.

The "professional" market doesn't care about visual cohesion. They either use just one app anyway or have them custom written to use their nvidia quadros with whatever UI they like, But the senior execs that need the absolute monster for outlook and facebook will always be well served by the top end macs.

> The "professional" market doesn't care about visual cohesion.

That isn't true at all. I spend all day in a handful of applications and good aesthetics make my day much more enjoyable.

People will never stop complaining about look and feel. It's such a crap, it doesn't matter. How much clothes do you own? Computers are tools to do work and consume information, they don't exist for you to make a statement about your aesthetics opinions.

It's really nice that you feel that way, but I hope to hell I don't need to use software you designed. "Look and feel" and "Aesthetics" are core components of usable computer software, and consistency is the way you enable users to consistently use your software.

Setting aside the purely utilitarian aspect of being required to use a piece of software to do a task or as part of a job, consistency increases efficiency by reducing the amount of time spent understanding the deviations from expectation in the user interface.

To use your clothing analogy, consider this: what would you think if you bought a button up shirt and the buttons were not spaced equally, they were different sizes and colors, and some were on the right, some on the left. It works just as well as a shirt with standard construction, but it takes longer to put on and maybe it doesn't look very good.

There's been a great deal written about how attractive things work better. It isn't crap and it does matter.

Mad props for extending the analogy to make our point. Nice job!

Now I need to find language to complement someone without it sounding like OO programming style.

HN, may I please have a simple +1 or upvote button? Needs to be usable on my smallish screen too.

perhaps a little bit like http://www.fwrd.com/product-comme-des-garcons-shirt-asymmetr... ? haha

Most (married) people are spending more time with their computers than their spouses.

Would you marry an ugly woman? An ugly man?

Beauty is in the eye of the beholder

Beauty is created by the conniving artist. It is 'absorbed' by the user. Not necessarily all beautiful things are useful.

Beautiful software, looks good, is intuitive, doesn't complain and complements the user. Hence software is different from art.

It certainly is! That's why I choose software that I think is beautiful.

I may think a terminal window is beautiful - if I do then I will choose a terminal.

What I won't do is purposefully use user-hostile/ugly software on principle - if there is a better choice I will choose the better choice.

Look and feel is more than just what colour an icon is, it's about how an application flows. Well designed applications enable you to be more productive, they usually also have had someone really think about what the experience should be as well which can help elevate them.

Some drive a utility van. Others a custom hotrod.

This alien concept (to many engineers) of beauty is a large part of makes new apps, especially web applications and SaaS startups, win or lose. Good design elements are the norm now, and expected. Gone are the days where someone would accept an ugly piece of solid software as a MVP. If it doesn't visually look as good as others in the ecosystem, your application is toast no matter how good it is otherwise.

Who'd have thought it? People getting emotional about stuff.

When all software is designed to be consumed by other computers then we can ignore those emotional reactions, for as long as software is consumed by animals it is going to be a vitally important factor.

I think the point is that many "professional" tools have their own aesthetics independent of the rest of the OS. Things like lightroom or movie editing software. For these programs OS skins are not needed.

That's a very good point. That tool, however, should at the very least be internally consistent and pleasant to use.

I don't think that's what the person was saying that I responded to or he wouldn't have made the condescending remark about people using a pro machine to use Outlook and Facebook.

Not 'skins' per se, but even when themed, most (good) professional apps will still use native or native-behaving controls and similar design language to the host OS.

In comparison, Mac apps will look and feel different from Linux or Windows apps, and QT and GTK+ apps will look and feel different from one another or the other two.

Switching between apps, even with heavily customized UI/UX, is consistent on a given platform, and that's what's important. Taking that away will just frustrate users and complicate things overmuch.

But it's even more important than that.

People find it easier to use apps that have a familiar look and feel. That means less training, less troubleshooting, lower operating costs.

Knowing how to copy and paste or which button to click to close a window is negligible when compared to the training required to properly use an ERP or even the most unique features of, say, Excel.

Anyone capable of navigating their way in Outlook can probably navigate their way in Apple's Mail or Thunderbird or Evolution. Anyone familiar with LibreOffice can do the basic stuff in Numbers in minutes.

Now, if you want a Notepad user to become proficient in Vi, that's a whole different story. Gedit, OTOH, is pretty easy.

Vi (or gvim) is too easy by comparison. Making them use emacs would be a whole different story.

That's an apples to oranges comparison. Emacs is an operating system, not a text editor like Vi. ;-)

Visual cohesion makes my day more productive because I spend less time mentally context switching between app philosophies.

Mental context switching is just like high CPU system time, with the same results. I/O is slower, user time processing is slower and much less gets done.

    The "professional" market doesn't care about visual cohesion.

[citation needed]

I think the "visual cohesion" of Sketch[1] is a big factor in the success it is seeing. The tagline is "Professional digital design for Mac" (emphasis mine).

[1] https://www.sketchapp.com

Top end macs? Based on the latest MBP offerings, I think Apple has forgotten what that is.

Unless your senior exec is carrying around his Mac Pro from his desk. That's a nice piece of hardware--without even needing USB-C and new dongles.

+1 here.

Ubuntu or a desktop that only uses Plasma apps may fit the bill. Plasma looks great but has a limited ecosystem. Ubuntu looks ok, but has a wider ecosystem.

What's most amusing to me is that I spend a considerable amount of time with Homebrew and others trying to make my MBP more Linux-like besides running Linux under Parallels. Getting Mac GUI binaries to run on [insert god-like desktop of your choice] would be very nice for the required closed course apps I must use. Developing for iOS (because I must) in Linux would be great. Otherwise, this feels like a step backwards.

-Mr. Fully Open Source Software

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.

Is there a list of things missing ? A guide on how to contribute ?

I'd love to port my favorite OSX apps to linux (ITerm 2, I miss you so much ;_;) but that website makes it almost a point to be as useless as possible.

Also, reading through http://wiki.gnustep.org/index.php/User_Guides , why does it talk about FileSystem Layout. Is GNUStep an OS ? I thought it was just a library. The whole thing feels a bit messy :|.

why does it talk about FileSystem Layout. Is GNUStep an OS ? I thought it was just a library.

Pretty much the first thing a desktop environment has to do is establish an abstraction layer for filesystems, so that desktop-enabled applications can have a consistent way to talk about files. Both Gnome and KDE have a VFS layer (GVFS and KIO, respectively).

I really wish they wouldn't.

A good portion of what KIO and GVFS do should be done at a lower level. Instead we get this weird situation where I can "see" a file in KWrite, but I can't see it the shell or in a non-KIO-enabled program.

> ITerm 2, I miss you so much

Interesting, when I'm using Mac and I miss KDE's Konsole, which is superior IMHO.

Which features are you missing from ITerm2?

The shell integrations[1] give me this:

- Alert when current command finishes running.

- Download files with clics

- Drag-drop files to upload with scp.

- The tmux integration. Being able to use the "native" split instead of tmux splits is cool.

All those are important to me because I'm always ssh'd into a personal box, and they just make the whole terminal experience feel like I'm on my local machine.

Then there's the Marks feature, which is just friggin great, the fact that it supports a bunch of pretty useful escape codes (and they're even documented[0]), and lots of useful (but minor) features like the Caputred Output[2] that just make the whole experience pleasant.

Nowadays I'm just using i3 with urxvt. I'm hoping that one day, I'll have the time to write a tmux integration using i3's IPC, which would bring me 75% where I want.

[0]: https://www.iterm2.com/documentation-escape-codes.html

[1]: https://www.iterm2.com/documentation-shell-integration.html

[2]: https://www.iterm2.com/documentation-captured-output.html

The tmux integration is awesome. I always have a couple tmux sessions running on few remote hosts.

It's kinda odd that the best terminal app is on OSX but not in linux :(. iterm is one reason I am postponing switching to linux from osx for my work laptop.

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 are being implemented on Linux in spite of the GUI bits not being source compatible with OS X or Windows. The major holdouts (MS Office, Adobe CS) likely have more to do with business reasons that factor much more than porting costs.

Now, if GNUstep were to become a compelling alternative to XCode for developing iOS apps, I could absolutely see that tide lifting the Linux fleet.

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

The web is the OSS GUI stack with the largest, most diverse, and most active developer community, and with it you get to ride on the coattails of multi-billion dollar companies like Facebook and Google that have significant investments in the web.

I got DDOSed and threatened. I got some of the most insane all-caps slobbering and frothing at the mouth feedback I have ever seen in all my years of interacting with any developer community. You'd think I went into a conservative church and gave a talk about evidence for abortion in the Bible or something.

The vast majority of this came after the article got posted to Reddit /r/linux. Most comments there amounted to "web sucks and JS coders are weenies and next year will be the year of the Linux desktop as soon as we finish the next rewrite of (insert favorite project)." Intelligent criticism is good but the vast majority of the comments I read responded to none of the core points of my post and amounted to not much more than developer community religious bias.

I ended up taking the post down for two reasons:

(1) I got sick of getting DDOSed and it wasn't worth it to me to fight just to get an off the cuff opinion out there. I am not deeply invested in this and have better things to do.

(2) This convinced me that the "desktop Linux" community is toxic in the extreme and should be avoided. This includes avoiding providing any input whatsoever to that community. Also caused me to become a lot less loyal to Linux in general, since it's a community full of people who respond to any opinion differing from their own with absurd amounts of hate and vitriol.

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 sentiment that caused the lash-out you describe.

But hey, that's why I'm in embedded development. That field is still safe for now.

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.

IMHO the problem is that you actually do need a decent chunk of all that stuff. Not all, but a good chunk.

A UI engine is a problem on par with creating a good game engine like Unity. If you don't have a loooooooong list of capabilities and polish your UI is a toy. By the time you extend and build it out enough to make it not a toy you will have re-implemented either Aqua/Cocoa, Microsoft's UI, or the web but yours will be new and nobody will know how to code for it.

Now make it flexible and programmable and extensible enough to be future-proof and battle hardened. Now make it work remotely over the wire with good performance. Now make it fast and efficient. Now make it secure.

The web isn't perfect by any stretch but it's IMHO the best combination of:

- Complete

- Modern

- Battle tested, including security

- Maintained by professionals

- Can be made to look good

- Has a yuuuuge developer community that isn't going anywhere

Qt is the closest other contender but its dev community is less than 1% of the web's. It's also starting to... ahem... look more and more like a web stack. It's still a little lighter and faster than the web but not much, and IMHO that gap is narrowing and will narrow even more. Look into Mozilla Quantum for an example of what's coming. We're going to have aggressively multithreaded GPU-assisted HTML+CSS renderers and web assembly soon.

JS is not my favorite language but it's not bad either for what it is (IMHO) and ES6+ features make it a lot better. It's a very acceptable "BASIC for the 21st century" and is perfectly fine for driving a presentation layer, schlepping data around, and controlling stuff. JS VMs are impressively fast given the difficulty of accelerating the language, and they are not overly heavy. WASM is going to break down this barrier as well by allowing CLANG to target the web as a native platform.

Web renderers are heavy but an OS that embraces the web as its presentation layer across the board could load one instance of all that bloat instead of one instance per app.

(A web browser on this imaginary platform would be a thin wrapper around an iframe.)

You'd have to pay a lot of attention to security. You might have to fork or implement a few added things into a good web engine to make it ready for such a use case, like better security models and resource management models around iframes. But that pales in comparison to the work it would take to re-invent a stack from scratch and reach this level of capability and then to build an entire ecosystem of this size and breadth around that stack. Forget about that unless you have a billion dollars to burn.

For a web browser on this imaginary platform, see browser.html.

Regarding security, it seems like something like Servo on top of a capability system like seL4 or Robigalia could provide a lot of opportunity to enhance the client security of a web application.

Using wasm + WebGL (or whatever's in the pipeline for Vulkan) could make this easy to deploy creative applications.

Add IPFS into this mix, and we'll be able to deploy decentralized applications as easily as central-server applications.

I'd like to see better tooling for building UIs on the web before I could get fully behind this idea, but I agree that the web platform has been BY FAR the most successful GUI framework ever, and I say this as someone who works nearly exclusively on systems programming.

The Enlightenment project[1] covers a decent number of the requirements you mention and has corporate backing from Samsung.

[1]: https://enlightenment.org

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 necessarily a fan of extending the web to all parts of my computing experience. However, what you described is very much what is happening with Chromebooks--so maybe your normative statements about the Linux desktop just required the implementation and backing by a Google.

That all said, I wouldn't write off desktop Linux along with the caustic communities you've found. I did a career switch to urban planning some years ago now, and what I've discovered is that every community has a majority group of mostly reasonable, mostly disengaged people along with a smaller group of really loud, difficult people. In that sense, Linux user communities feel normal to me.

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.

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.

I don't understand all the downvotes for all of your comments. I have developed GUIs in Gtk, Qt, .Net, and Java+Swing, but I saw the writing on the wall and learned web dev. I really really hate writing GUIs in HTML (inferior tools, inferior performance), but that is where the wind is blowing.

There is plenty of money to be made in native GUIs, one just needs to search for the right customers.

I have been developing green field native applications in the last three years.

It has been a return to sanity after doing around 4 years web dev.

Any recommendations for where to look for this type of customer?

Microsoft tried this with RT, the web technology dev stack for Metro apps. Is that even still a thing?

On mobile web tech based apps are the ugly step-children compared to native apps. They've had their chance I'm afraid. I understand why they should be ruling the word in theory, but it just never works out in practice.

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

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.

A captivating tale of the birth and death of the best blog post ever.

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

Could you post your blog article? I've though a similar thing for years and have never been able to communicate it.

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

I think this is what Google is trying to achieve with Fuchsia, their new OS.

I got DDOSed and threatened. I got some of the most insane all-caps slobbering and frothing at the mouth feedback I have ever seen in all my years of interacting with any developer community. You'd think I went into a conservative church and gave a talk about evidence for abortion in the Bible or something.

Looking back over the decades and recalling my interaction with developers, I ask myself, when did we become an angry mob of anti-intellectual haters? Some of us are as cartoonishly awful as lords and ladies in French Revolution period dramas.

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

I don't think it ever reached the level of maturity of GTK/Gnome and Qt/KDE at the time.

If it did, the GNUstep desktop could have gained users (WindowMaker was very popular, me included) and developers would have got interest in it.

That didn't happen.

It'd be wonderful to have a linter that could verify if your Xcode project is compatible with GNUStep. That alone would do wonders and encourage people to either cover more APIs in GNUStep or write macOS code that's easier to port over to other platforms.

Objective-C has been crossplatform for decades. The issue isn't the programming language, it's the GUI toolkits. Probably the best way to get cross-platform apps would be to improve Qt on Mac to the point where Mac apps were willing to use it.

> Probably the best way to get cross-platform apps would be to improve Qt on Mac to the point where Mac apps were willing to use it.

I predict this won't ever happen. Whether fairly or not, Qt has a reputation for not feeling native, and this is extremely difficult to shake. And with Swift becoming the language of choice for Mac development, the use of C++ (not even standard C++: C++ with the moc preprocessor) is becoming more and more of a liability.

On the other hand, in the JavaScript world we are piling more and more transpilers/preprocessors/postprocessors. I think the use of moc won't contribute much to the liability.

Why wait for Swift? You can already do what you want with something like Lua. The only issue is that you have to be willing to build a platform around your Lua code-base, and not just have it handed to you ..

To have high quality GUI Swift is not enough. You'd need to have AppKit ported, and a bunch of Core* (CoreImage, etc.) stuff. In short—not going to happen.

FYI macbuntu: Howto make Ubuntu look like OSX

http://www.linuxandubuntu.com/home/macbuntu-transform-ubuntu...

Linux has a lot of high quality apps, e.g. Krita, LibreOffice, Lightworks, Blender. Which programs from OSX don't have their Linux counterpart? With Qt/GTK/GNUstep you can make almost any app cross-platform.

> Since the most painful area is still the missing Cocoa implementation, hackers are welcome to explore the following possibility

I wonder why they suggest trying to rebuild Cocoa on top of Qt, rather than starting with the existing GNUstep?

It'll super useful when/if it supports XCode + Mac Developer Tools for iOS development. I think that's the main thing keeping app developers on their Macs.

Believe me, it is not. All Android and WP developers I know also used Macs. :)

Interesting, the Android and WP developers I know use PCs running Linux... since the plural of "anecdote" is "statistics" I wonder how we proceed from here

The plural of anecdote is data.

Well then I guess we have 2 data.

Incorrect: The plural of anecdote is Gladwell.

I don't know anyone, and there are quite a few in this 4 floor building.

Not to mention across all company sites.

EDIT: And if you bother to listen to the Android Developers Backstage podcast, according to the Android team themselves the large majority is on Windows.

The entire Android developer team here is on Macs. And go to any Android developer conference, and I'd be willing to bet money that most laptops you'll see are Macs.

If you wish I can tell exactly which podcast where they give their numbers.

The only hesitation I have in switching away from macOS is inability to do iOS development. However, since it's just a hobby for me (and one with decreasing returns), I might give it up sooner rather than later.

That simply is not true. Most of the people that likes commodities of UNIX, nice UI and long battery life in combination with nice hardware uses Macs. Even people who do not do any iOS development. There is no such thing as Mac Dev tools, (maybe just iOS related but there aren't many that you do for that process besides Xcode). I use my Mac like I used Linux and FreeBSD, package manager check, nice terminal check, Emacs check, clang check, JetBrains' stuff check. (only two programs that are exclusive to macOS are Xcode and iTerm2, at least in my case).

Edit: OK why downvotes? Did I say something that is not true? Matter of taste, but seems like it's new trend to hate on Apple computers. Its cool now right? Why can't people just move on...

Edit2: Forgot that this is HN and that every word is meant literally. ¯\_(ツ)_/¯

OP should have said "many app developers". The implications are a bit different because it doesn't mean 'all' or 'the majority'.

Lots of people will stick with Apple hardware or the mac operating system I'm sure, but I do agree that I think a lot of people will cross over once some of these barriers are removed.

And it is okay! Different devices, different systems for different people. But what I really do not get is the amount of rage that is produced in the community, if you do not like certain device simply do not buy it, and do not bash people that do, because if there are reasons for you not to like it that doesn't mean it's same case for everyone else.

Anyway back to the story, I think that number of people that use Macs only for iOS dev is existent but not really that big. Except platform specific development (like .NET/Windows, or iOS/macOS for that matter), most of development is pretty platform agnostic (where you draw the line here is UNIX-like vs Windows OS). App developers will have to stick to Macs, unless Apple go totally insane and release dev tools for iOS on Linux (which won't happen in my opinion, because of the anatomy of both macOS and Linux). So OPs comment doesn't make sense from the beginning (both technically and economically for Apple).

No, Windows had an Unix subsystem since forever, and WSL helps switchers more than ever actually.

And that is related to which part of my post, because I do not see the connection? I didn't mention Windows. And good luck with wrestling with Windows doing UNIX things. It had it, but it was not comparable to Linux and BSDs. Now it is better situation, much better, but still I would rather spin some BSD based system in VM, than try and use Ubuntu through WSL.

SUA(SubSystem for Unix-based Applications) is litterally a BSD fork...

You mean the Unix subsystem they made just to claim POSIX compatibility, that they totally abandoned in recent Windows versions?

No, xe does not.

The subsystem that was made just to claim POSIX compatibility was the subsystem that preceded Interix. Interix was developed outwith Microsoft, and replaced the old POSIX subsystem. It was Windows NT's second POSIX subsystem, and it very much is not just a sop for the sake of checking a requirements checkbox.

It's a fairly usable POSIX environment, with a large toolset, proper terminal emulations, pseudo-terminals, interoperability with non-POSIX processes including visibility with (an enhanced) ps and the ability to send signals to Win32 processes, an actual init and inetd, and an X server.

Stephen Walli has stated that it started as a fork of 4.4BSD-Lite.

* https://news.ycombinator.com/item?id=11560510

* https://news.ycombinator.com/item?id=11416392

My Ubuntu VM hasn't been spun up since I started using WSL. I've encountered a few bugs with WSL but it works amazingly well even for GUI apps.

I didn't like Ubuntu even back then when Linux was my main workspace. Used Gentoo and Arch most of the time, Ubuntu felt like too much everything for my taste. Is it possible to use other Linux distros through WSL?

yes, an Arch port to WSL was written

> it works amazingly well even for GUI apps.

Could you elaborate on how you run GUI apps? Is it through some Xorg compiled for Windows? Can you use hardware-assisted OpenGL from WSL?

The Darling FAQ mentions it's Linux-only and that a BSD port would be plausible but a Windows version would take a lot more effort.

So I'm wondering how much of the software requires 'Linux' per se or rather just relies on a GNUserspace such as Ubuntu.

It might be an interesting test case of WSL compatibility for Canonical/MS programmers to get this working. (although wasn't MS working on some sort of iOS bridge for WP10, in the case of Darwin-based programs?)

Except neither of those work worth a damn. You can't even run stuff like MSBuild or Sublime Text from the WSL.

MSBuild/.NET Core work fine on WSL now.

Windows Services for Unix has been discontinued for a while, so "since forever" is just flat wrong.

And who in the hell ever developed for it anyway? That was a niche, forgotten product if there ever was one.

edit: maybe you should keep up with stuff more if you're going to defend it so much, it was deprecated like 7 years ago

https://en.wikipedia.org/wiki/Interix

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

So it is. I was under the impression that its microkernel approach, specifically the system calls directed to Mach, caused it to deviate from the standard. You learn something new every day.

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.

Yes, it is POSIX compliant. Its also an official UNIX.

http://stackoverflow.com/questions/5785516/is-osx-a-posix-os

https://en.wikipedia.org/wiki/Single_UNIX_Specification

Presence of bugs does not preclude you from being compliant to the spec.

...also... Linux is not officially compliant to either one.

Whether I have to do porting work in practice (which I do, a lot) matters a lot more than what a consortium from 1996 says.

The fact is, Darwin gives me trouble a lot more than Linux does when using POSIX APIs. If there were a comprehensive, up to date POSIX test suite, Darwin would fail it.

Basically just like any other UNIX during the golden days of UNIX wars.

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.

> [...] The manual page for pselect, for example, even admits that it's not compliant!

Where does it say that? I'm running 10.12.1, and the man page for pselect(2) looks like the one from FreeBSD. I could believe that pselect doesn't actually behave as documented, having run into my share of macOS bugs.

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

Agreed, though AFAIK all commercial UNIXes are buggy in one way or another, and I don't know if macOS is worse in comparison. Autoconf exists for a reason, even though few if any really like it.

  IMPLEMENTATION NOTES
    The pselect() function is implemented in the C library as a wrapper
    around select().

That means it's not actually compliant. pselect needs to _atomically_ unblock signals so that if any signal handlers are invoked pselect returns EINTR error. User code can't emulate the correct semantics because there's a race between unblocking (i.e. changing the signal mask), checking for signal arrival, and calling select. It's _impossible_ to fix this race without resort to pselect, or by use of system extensions like kqueue on BSD/macOS[1] or signalfd on Linux, which can be tricky. On Solaris you just have to use pselect, or resort to the so-called "pipe trick".

So the fact that pselect is a wrapper around select admits that it's not conformant. It's basically useless; worse, it's dangerous because application code calling pselect expecting there won't be a race.

You can see the race with this code, which on 10.10.5 still fails. What should happen is that it exits immediately with OK. What actually happens on macOS is that its pselect wrapper unblocks the signal, which is immediately delivered. But by then we've already checked that interrupted was still 0. It then calls select, which will timeout because it won't be interrupted--the signal was already delivered. On every other platform implementing pselect (which all do it correctly), pselect will always return EINTR because the signal unmasking and delivery happens in the kernel _after_ entering select.

  #include <errno.h>
  #include <signal.h>
  #include <stdio.h>
  #include <sys/select.h>
  #include <unistd.h>
  #include <err.h>
  
  static int interrupted;
  
  static void
  interrupt(int signo)
  {
    interrupted = signo;
  }
  
  int
  main(void)
  {
    struct timespec timeout = { 3, 0 };
    sigset_t empty, block;
    int n;
  
    sigemptyset(&empty);
    sigemptyset(&block);
  
    sigaddset(&block, SIGHUP);
    sigprocmask(SIG_BLOCK, &block, NULL);
  
    signal(SIGHUP, &interrupt);
    raise(SIGHUP);
  
    while (!interrupted) {
      /*
       * If pselect does not atomically unblock signals, pselect
       * will never be interrupted and we'll lose the signal until
       * something else wakes us up AND we remember to check even
       * though we never saw EINTR.
       */
      n = pselect(0, NULL, NULL, NULL, &timeout, &empty);
      if (n == -1 && errno != EINTR) {
        err(1, "pselect");
      } else if (n == 0) {
        errx(1, "timed out");
      }
    }
  
    if (interrupted != SIGHUP)
      errx(1, "wrong signal (got %d, expected %d)",
          interrupted, SIGHUP);
  
    puts("OK");
    
    return 0;  
  }

[1] FWIW, here's a correct implementation of pselect for macOS using kqueue. (https://github.com/wahern/cqueues/blob/snap-20160812/src/cqu...) The only caveat is that creating a kqueue descriptor might fail, and you don't normally expect pselect to fail with EMFILE or ENFILE; it might even make it non-compliant. Except for that caveat, it's a compliant implementation of pselect AFAICT.

Hey, I didn't catch your reply in time, sorry about that.

Anyway, the man page for pselect(2) in 10.12.1 doesn't have that section, and when I run your test program it prints "OK". So it appears that this particular bug was fixed. It only took them 2 years (could be less if it was fixed in 10.11) this time, which was an improvement over their turnaround for fixing the rename(2) bug[0]. :-P

[0] http://www.weirdnet.nl/apple/rename.html

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

I wish more people subscribed to this - I've banged on about this at previous jobs with little success (even though I've demonstrably caught "mistaken assumption" and other bugs through the exercise.)

From PSELECT(2):

STANDARDS The pselect() function conforms to IEEE Std 1003.1-2001 (``POSIX.1'').

See my reply to RJIb8RBYxzAMX9u, elsethread. It's misleading. The interface conforms, but the implementation is not compliant At least for all the version of macOS I've tested (I haven't tested 10.12, yet) the very problem pselect was created to address exists. When I said that the manual page admits it's non-compliant, I was referring to the section that said pselect was implemented as a wrapper around select; but you can't correctly implement pselect as a simple wrapper around select.

But see my link in the other reply to a correct implementation I wrote that relies on kqueue. I even submitted it to Apple years ago along with the bug report.

I use Linux for that. I have a pretty and modern UI, all of the unix commodities I want... all on a brand new and powerful laptop that has plenty of battery life. (My last laptop... a Samsung Series 9... would last 14+ hours on a charge. My current laptop is a bit more power hungry... but it has a fairly beefy i7 and such. It still gets me through the day though)

It's just a matter of momentum... and Apple certainly has that in spades.

I did switch to using MacOS for several years... but am now back on Linux. It's just a better for development for me. But hey... Linux has been my primary workhorse since the 90s... so I am certainly biased. I did give the MacOS bandwagon a try though. :D

Wow, that is impressive battery life. I am curious, what Linux distributions you used? (especially for those back in the 90s :D) I was stuck on Gentoo than Arch for the most of the time.

Probably just MakingStuffUp.iso

I get about 10 to 12 on my x240 with Debian if I turn down the screen brightness. Especially if I am mostly in vim.

I'd get about 9-10 hours on a Macbook Pro simply lazily web browsing. This is theoretically reported battery life, however.

I never actually let it run down to 0. It's possible the last 10% would have vanished in 30 minutes instead of ~2 hours like it claimed.

I can certainly believe a Linux machine can get 14hrs. It's just a matter of having a bigger battery, and a processor that will step-down its speed when its not needed.

I used to get 8-9hrs on macOS and about 6-8hrs on Ubuntu on the same Macbook. I'm sure Linux can do much better on non-apple hardware that is more or less open or well known in the Linux community. The problem with Linux and power savings is that a lot of the proprietary hardware manufacturers don't release specs that make writing drivers easy for obvious reasons so Linux open source driver implementation is never as good as macOS or Windows. Dell's XPS13 developer edition has been doing quite well in the last couple of years. If it picks up more steam, we could see Dell or Intel write proper open source (or closed) drivers to support the hardware better.

> That simply is not true. Most of the people that likes commodities of UNIX, nice UI and long battery life in combination with nice hardware uses Macs. Even people who do not do any iOS development.

Citation needed. Some people like the mac UI sure, but there are people who hate it too. People who use a mac only because they have to to develop for iOS or OSX certainly do exist.

I was indeed one.

I used OS X for a while. The MBP was provided to me by my employer.

I got tired of it in about one year. Now the laptop, which I barely use (my desktop runs circles around it), is running a Linux distribution. More comfortable UI, comparably solid, (usually) seamless software upgrades and better management, more customizable, etc.

This is neat, but I can't think of a single non-GUI tool on OS X that I need or doesn't have an equivalent in Linux...

How about "packagebuild" and "productbuild"? They build OSX packages. You could use a linux server to build DEBs, RPMs, and OSX packages without using OSX.

Ever since the gpl bomutils project you can, here's a nice tutorial:

http://bomutils.dyndns.org/tutorial.html http://hogliux.github.io/bomutils/tutorial.html

Photoshop?

And Scrivener. The OS X variant is a full major version ahead of Windows, and it isn't even supported on Linux.

Pretty sure Photoshop does not count as a "non-GUI tool".

Op is talking about non-GUI apps, the kind that run only on the terminal.

"non-GUI tool" - Photoshop is very much a GUI tool.

No it's not.

You can actually use the features of Photoshop in scripts without the need of the GUI. Being able to do that on Linux would be great!

http://www.adobe.com/devnet/photoshop/scripting.html

Every non-GUI tool I use on my mac is installed via homebrew, so I would agree. Oh, except caffeinate. :)

Caffeine is available on Cask:

  brew cask install caffeine

mediafilesegmenter and mediastreamvalidator used for creating and testing M3U8 (HLS) files.

You can of course use open or closed source alternatives, but they're fairly shitty in comparison to the mac native tools.

Last time I tried mediafilesegmenter had a dependency on some of the core audio libraries that were missing under Darling.

I've had success with segment filter for ffmpeg. Yes it's more complicated, but I wouldn't describe it as you did.

I have 3 outstanding bugs with ffmpeg that are directly related to m3u8 segmenting. I've processed 10s of thousands of files with ffmpeg. There are many edge cases and sharp edges still. It works pretty good but at high volume the small bugs add up quickly. It's definitely one of the better tools out there, but it's not as good as it could be.

Maybe jsc (webkit) v node (v8) issues/performance keeping the variable of the hardware the same?

The xcode cli tools could be useful. Maybe you could even build and sign and upload iOS applications with it in the end.

This is a thing you can do: http://www.eswick.com/2014/03/11/Building-iOS-ARM64-Binaries...

I was thinking the same thing. Nobody uses OS X for the command line tooling. I think in most cases the Linux "equivalent" is usually better.

It's a good first step, though. It'll be interesting to see how well they can get GUI applications running.

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

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.

MoL was PPC only, and didn't do any transformation of Toolbox calls to Linux native calls.

It was essentially a hypervisor.

https://sourceforge.net/p/mac-on-linux/code/HEAD/tree/trunk/

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.

I don't think such a thing exists, probably because there are few/no applications that target Linux and not OS X that aren't also open source. Can you give an example of an app that is only released as a compiled binary for Linux and not OS X?

FPGA development tools from xilinx or altera are one example.

Pretty much all HDL tools. I've heard on the grapevine that Apple's own internal chip teams have to use Linux or Windows because the HDL vendors won't port to OSX, even with Apple willing to fund the effort.

It's not so much "applications" as such, but it isn't uncommon for programs in bioinformatics to only be released as a binary (often only a Linux one) because they want to reserve the right to license their code. Or they will only release the source code to academic researchers because they don't like the idea of industry benefiting from their work. This is changing with a lot of people hosting projects on Github and the like, but is still there.

Pragmatically, run a Linux VM and point $DISPLAY to the host XQuartz.

That's a lot of overhead compared to translated sys calls.

Could you maybe reuse some of the Docker integration into the host system?

Docker just uses a Linux VM under the covers, which can obviously run Linux binaries.

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

It shouldn't be too hard if Apple is interested. The Linux ABI is pretty stable. FreeBSD and Windows both do Linux binary emulation well enough to run most Linux binaries.

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

This project has been around since 2012. I'm glad to see it's getting some momentum!

I am following its status since it was created, i think it is pretty much dead.

Repo even starts in 2011.

The commit log doesn't look like momentum at all though...

https://github.com/darlinghq/darling/graphs/commit-activity

That's because I (the author) still work on it alone and nobody wants to contribute. I receive tons of e-mails that go like "when will it run XYZ", but practically no pull requests.

I hope more visibility can help, you can try to highlight more the need for contributions in the project homepage and in the github readme maybe

You might find the LGPL used by the Wine project to be more attractive to potential contributors. The first thing I thought a few years ago when I read that your project was GPLv3 was that any code that I develop using it would have to be GPLv3. Even if the GPLv3 itself might not force that for "system libraries", the harassment from armchair legal experts would. As much as I like OSS licensing, I do not like having my choice of OSS license forced on me. I am probably not the only one who feels that way. The LGPL is a far better choice for this kind of project.

For what it is worth, that is from personal experience. I went through the trouble of re-licensing a script with consent from all contributors from GPL-2 to BSD-2 in a package in the past because of harassment from armchair legal experts. It had been mistakenly marked GPL-2 when it should have been BSD-2 to match OpenRC. It had been included with binaries under the CDDL. There was no incompatibility and the GPL FAQ even talked about the case under mere aggregation, but that did not stop the harassment from the stream of arm chair experts rushing to tell me that I had committed some egregious offense for having the package marked both GPL-2 and CDDL. Relicensing the script to the license it should have had in the first place put an end to it and created one less GPL licensed thing in the world.

Anyway, switching to the LGPL now would be easier than switching later. It only gets harder as a project ages because you start to lose contact with past contributors.

It doesn't make much sense to target Darling as a development platform - like "winelib" - which is why I stick to GPL. I don't want any company to ever use Darling for "porting" their app to Linux, because I consider this an abomination when done with Wine. I think it's fair to say "our app also runs under Wine/Darling", but it's unfair to produce a binary with bundled Wine and say it's a Linux version.

I also want to avoid the inception of businesses providing enhanced Darling for money without releasing the full source code (think Cedega), because in my view, that's akin to a fraud committed on other developers who invested considerable time and didn't ask a dime for it.

> Why “Darling”?

>The name Darling is a combination of “Darwin” and “Linux”. >Darwin is the core operating system OS X and iOS build on.

If that's the case, why not Darlin? But then, I'm southern so that's why it makes more sense to me.

I was looking at emacs documentation the other day and thought that RMS is probably right that Linux should be called GNU/Linux. In that case, newcomers to this project might ask "What's GNU Darlin?

Well since you're abbreviating you can abbreviate GNU futher to G and then change the order to get DarlinG.

I think nowadays we should start to use the name SystemD/Linux

How about poetteringOS ?

Gnu/Linux/Darwin == Gnarlin?

Seriously though, i used to think GNU/Linux was just envy of linux' success, but Gnu basically IS OS without a kernel (Herd, where art thou?).

If you're using a distribution like Alpine Linux, which uses musl libc and busybox en lieu of much of the GNU userspace, it's not really a GNU/Linux by any definition.

I feel like "Darlin" only sounds "cute" when said with a southern accent.

Yeah, me too. :)

I think it sounds like something a "Cockney" market trader (played by someone who's not actually from London) would say in a 1970s Carry On film.

"Orl right darlin' how's about some of these luverly toms? Luverly bag of toms for one pan ten"

Darlin would be a better name anyway, as it's not a pre-existing word. I also think it sounds less 'cute' than 'darling'. You even have a rhyming animal for the logo for that...

Wouldn't be a terrible idea to do something similar for the BSDs, particularly FreeBSD. A lot of the syscalls would be passthroughs, which would make things a little easier at least.

Go and whisper in these people's ears. (-:

* http://www.nextbsd.org/

Related: http://www.puredarwin.org/, partial OS built from open-source Apple libraries / kernel.

The problem with both of these is re-implementing the Core Foundation (only partially open-source; https://en.wikipedia.org/wiki/Foundation_Kit#Major_implement...) & proprietary Cocoa API's that almost all GUI Mac apps use. Wine has done the equivalent for Windows, but so far nobody wants to do all the hard work of bug-for-bug compatibility. Probably because Apple is already becoming irrelevant, and almost every Mac product has a corresponding Windows equivalent.

If there were build tools that could help deploying to the App Store/Google Play/Windows Store/Amazon Marketplace in a straightforward way, this would motivate people to write more portable software.

Those marketplaces are not only places to buy applications. Many applications there are free. They are also distribution channels that help people finding and installing your app.

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.

No GUI support at the moment.

Basic Cocoa apps work, as long as they don't crash and burn with GNUstep.

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 Ulysses, which has a very good way of organizing and searching for notes.

Linux does of course have vim, emacs, etc but I'd say if you want a more modern feeling editor you got a lot more choices on Mac: TextMate, Sublime, SubEtaEdit, Smultron, Coda, Chocolate etc.

Then there are all sorts of specialized tools, e.g. I use a Dash a lot of looking up developer documentation. Paw is pretty neat for working with REST APIs. Base is great for looking at and manipulating SQLite databases.

Especially for any kind of graphical work, say you got to modify some application or toolbar icons, then you have a lot of great choices on Mac. Not only do you have the big powerful tools like e.g. Photoshop and Affinity Designer, but you to also small neat little tools like Pixen.

It really depends on how long you worked on the platform. I didn't use nearly as many of these tools some years back. But the longer you stay on a platform there more tools you start using as particular needs arise.

I've worked with plenty of colleagues who have used Macs for years, but who aren't really mentally into the whole Mac eco system, and so they often use various cross platform tools, websites etc before they actually explore the rich collection of desktop apps available on the Mac.

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

Exactly. That's what I use.

People still use Atom? I switched to Atom ~1 year ago, and my life has drastically improved. The in-app plug-in store is one of the greatest innovations. Anytime I encounter a situation where I wish my text editor did something a little better, I have been able to find a suitable plug-in, install it, and get back to work all without closing the app.

It's a shame that you can't run a container with MacOS installed and just run the apps natively.

Unlikely to ever happen though. You'd have to run the MacOS kernel and Mach concurrent with the Linux kernel without virtualization (something I am not sure is possible). At that point, you might as well just bite the bullet and run a VM.

I'd be happy enough if I could run the VM.

You can: https://news.ycombinator.com/item?id=12556609

and if you can install KVM on the host, you can even run the VM inside of a container: http://rancher.com/introducing-ranchervm-package-and-run-vir...

I have a list of links on the subject: https://docs.google.com/document/d/1VwLJqgc2VkD-EZnMzSFmZRq0...

Do you mean legally, or at all? Because if it's "at all" I believe there is a very vibrant community who have a lot of tutorials for doing that

There's a nice (pretty inclusive to beginners I might add) community for mac VMs on other OSes, but I've tried using such VMs for the past 4 years and each year I've had worse results.

* Is it usable for dev work -> yes * Is it like using a mac -> no

Usually When I'm on windows, I generally just run a Ubuntu VM and live inside it.

That is not something you can generally do on an OSX VM.

(just to add, my opinions based on my experience - your milage may wary)

I mean legally. And with decent performance, without overly major bugs.

Very impressive. I wonder how useful the existing GNUstep libraries would be for supporting at least some subset of GUI apps. I wonder how far at this point OS X's CoreFoundation etc. differ from what's in GNUstep.

GNUstep is stuck around half supporting Panther, if I remember correctly.

They forked GNUStep for that.

This is great. But I can't think of a single macOS-only app I'd like to have in Linux, other than Terminal.app, Control Panel, Activity Monitor, etc. Everything else I use already runs in Linux.

Smutefy?

Sketch is probably the only reason I'm not 100% Linux at this point.

Is there a licence issue preventing the use of http://www.cocotron.org/, an existing Cocoa for Windows/Linux?

I don't think the virtual esc key is going to be an issue. The placement actually seems more convenient than the current esc key location.

I am going to miss a regular USB port and MagSafe.

Maybe this might work as a replacement for MagSafe?

https://www.amazon.com/Griffin-BreakSafe-Breakaway-Chromeboo...

I haven't tried it myself, so it probably does not feel as fast and fluid as MagSafe.

Oh this looks excellent, I was thinking of trying to make something like this work for running the Bonjour Compatability Suite for automated testing against Avahi.

Just an amusing thing to notice: 大零 ''da ling'' means "great zero" in Mandarin Chinese.

Darling has been around for sometime. In my experience it's buggy and not nearly as far along as Wine.

80% of my apps i use run on electron :D

So thats why people need more than 16GB of memory on their MacBook Pro.

A general rule I follow on my Mac to minimize memory and power consumption:

- Use Safari

- Avoid web based desktop app like Atom, Slack, etc.

- Limit maximum of 3 app open, e.g. Xcode + iTerm + Safari. Bonus: I can focus my mind on the things that I need to do.

- Limit maximum of 3 open tabs on my Safari.

iTerm finally!

Nope. That's a GUI app :)

> "At this point, does not yet run macOS application with a GUI"

Great, so I can run OS X's shitty versions of Linux utilities... on Linux.

Technically, they are't really OS X's shitty versions of Linux utilities but rather the BSD versions of GNU utilities.

Technically, those utilities were originally BSD, but Apple took them and modified them and did not release the sources back into BSD. So they're not really BSD anymore.

It would be really great to be able to build macOS-only open source apps on Linux.

Maybe this will some day mean Imgix can stop racking mac pros.

what can apple's lawyers do to kill this project?

Pivot their career as engineers and make better professional hardware at Apple so nobody will consider using this project?

Reply on news.ycombinator.com