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 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.
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.
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.
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.
...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.
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.
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.
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.
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.
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.
> 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 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.
> 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.
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).
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.
- 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.
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.
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.
Most of "cocoa" came from the OPENSTEP specification, and GNUstep offers quite a complete implementation.