Hacker News new | past | comments | ask | show | jobs | submit login

It was nice endevour to port NeXTSTEP development stack.

Nowadays with it being several releases behind macOS tooling, and the whole issue of what from Objective-C v-latest is actually supported, it is more of a curiosity and nostalgic experience.




Since roughly 2004 (that's when I first learned about Mac OS X, NeXT, and GNUstep as a high school student), I've been periodically keeping track of the state of GNUstep since I believe there's value in having a FOSS alternative to macOS and its technology. GNUstep could have been the primary GUI development toolkit for the Linux desktop. Unfortunately, GNUstep never caught lightning in the way other FOSS desktop projects did, and I attribute this to bad timing.

My understanding is that when the KDE project started in 1996, GNUstep wasn't ready yet (remember that the OpenStep specification that the original GNUstep was based on was released in 1994), and GTK+ was not separate from GIMP. My understanding is that options for FOSS GUI toolkits were sparse in 1996. What did not help GNUstep's case in 1996 was the fact that NeXT appeared to be dying; nobody in early 1996 would have guessed the outcome of NeXT. Thus, the creator of KDE decided on Qt, which had licensing terms that were not-quite FOSS. This caused consternation among some people in the FOSS community, which lead to the founding of the GNOME desktop. GNOME ended up adopting the now-separated-from-GIMP GTK+ toolkit around 1998. Meanwhile work continued on GNUstep, but by the time 2000 rolled around much of the Linux desktop community rallied behind KDE and GNOME.

Ever since Mac OS X was released, every now and then somebody with Mac OS X and Cocoa experience would look at GNUstep and say, "Wow! I saw what Apple could achieve with NeXT technology; what if we used GNUstep to build something similar for Linux?!" and then get started on a project, only for that person or team to lose momentum and eventually give up. One such promising project that is now dead is Étoilé (http://etoileos.com), which was based on GNUstep and inspired by Mac OS X, yet had ideas of its own, such as versioned objects and support for a dialect of Smalltalk called Pragmatic Smalltalk that leveraged GNUstep's Objective-C APIs. Étoilé would have been a fresh, new Linux desktop experience that would have brought us closer to the dream of a modern "Smalltalk operating system," but unfortunately that project lost momentum, like so many open source projects that don't have corporate backing or massive community support.

There is a really interesting project called helloSystem (https://hellosystem.github.io/docs/) that is a fork of FreeBSD that aims to re-create the Mac OS X Tiger user experience and conventions. However, this project is built on the Qt toolkit instead of GNUstep.

Will GNUstep ever gain momentum? I don't know; on one hand there is a vocal minority of long-time macOS users who are disappointed with Apple's software direction and would like to have an alternative to macOS that involves the least amount of friction as possible. However, different macOS users like macOS for different reasons. For those who like macOS due to its user interface guidelines and consistency, helloSystem may look promising to them, especially if it gains traction. For those who like macOS due to its object-oriented APIs, they may be interested in taking a look at the .NET ecosystem and the languages it supports.

Personally, I'm dreaming of a Common Lisp desktop heavily influenced by Smalltalk, the Mac, and OpenDoc (Apple's commercially unsuccessful component-based software technology). I remember coming to the realization a few years ago that NEXTSTEP is essentially a pragmatic Smalltalk desktop environment, except instead of running a Smalltalk VM it ran Objective-C and Display PostScript on top of Unix. I'm thinking, why not go all the way with a programmable object-oriented environment and build a desktop environment from the Common Lisp Object System and its meta-programming facilities. It would have a standard set of UI guidelines for user-facing applications, but for power users, because everything is an object, it is possible to combine objects using scripts. If only I had more free time....this would be the ultimate realization of a desktop environment for power users based on taking Xerox PARC's technology to its limits.


My graduation project was porting my supervisor thesis of a particle engine originally developed on a NeXT Cube in Objective-C/OpenGL into Windows/MFC/OpenGL, because it was clear it was going nowhere (OS X wasn't yet announced).

So I actually lived through those events, and also think most modern environments fail short of what desktop computing could have been, and in a twisted way Windows is the closest of them all with COM and .NET, yet the whole WinDev vs DevDiv politics messed even that one, most likely beyond repair in the presence of current UI stack chaos.


Thanks for commenting. I've been reading your posts for quite some time and I enjoy your commentary about how Windows, from a developer's point of view, is the closest living thing we have to the types of Smalltalk and Lisp environments people at Xerox PARC and other places enjoyed in the 1980s and early 1990s. Windows has the infrastructure to make a truly great operating system; I've been reading a lot more about the .NET ecosystem this year, including multi-language interoperability through the Common Language Infrastructure and PowerShell scripting. What's unfortunate about Windows are the ads, the telemetry, the aggressive attempts to make people use Edge, and the strange UI choices that Microsoft made starting with Windows 8 (and, arguably, since Windows XP's Luna interface). I think of Windows as a gem that's unfortunately encrusted with layers of dirt.

Another project I pay periodic attention to is ReactOS. If ReactOS matures to the point it can run on modern hardware and can run modern Windows software, then I'd make ReactOS my daily driver. A daily driver version of ReactOS combined with .NET would make quite a compelling platform for me.


I fully agree. When you know what to take from Windows, it's a great OS. The hackability of the UI with AHK is way above what Gnome or even KDE can offer.

Yet in a funny way, when I explain to seasoned Linux hackers that my OS of choice is Windows, they look at me in a funny way :)


> helloSystem ... fork of FreeBSD ... re-create the Mac OS X Tiger user experience and conventions

There are also a few GNU/Linux distros in this UX category, e.g. Zorin, Elementary, Budgie ... They are listed on https://distrowatch.com/. (I have no association with these distros.) Maybe helloSystem should be added to Distrowatch?

In general, the spirit of Gnome was/is to improve UX (user experience). There have been misadventures shall we say. At this point, I have come to want just a terminal, an editor, and a Web browser. ^_^

[1] https://elementary.io/

[2] https://zorin.com/os/

[3] https://ubuntubudgie.org/


I think it's worth mentioning that a lot of MacOS design language has been absorbed into Gnome itself: grayish/metallic windows, the app launcher, the top menu bar, et alia.


But no menu in the top menu bar, making it kind of a waste of space


I was a developer in the 90s and 00s and frankly I thought peoples dislike of Qt was pretty superficial. The problems being that GTK sucked. I’d have forgiven NIH (not invented here) syndrome if GTK was at least as good as Qt but it wasn’t. Frankly I even preferred oldskool Tk over GTK.

In the time frames we are talking about, I also cared very little for NeXT. It did have its fans and deservedly too. But I was banking on BeOS becoming the POSIX workstation of choice. I even preferred that over Linux. But 90s Linux wasn’t exactly a smooth experience like it is today.

These days little has changed my mind about GTK vs Qt.


Well, I guess you can still run Emacs on top of Guix :)

I'm being tongue-in-cheek, but Emacs could be considered a graphics toolkit in its own right.


Yeah this was a really interesting project when it got started, like in the late 90s ? Now, realistically, even though I like the idea, who is going to use this ?

Maybe like a compatibility setup for old NeXTStep applications ? Or porting some old macOS applications to Linux environments ?

Working on top of the X11 implementation also doesn't really provoke trust to look into the project.


I co-host a GNUstep developer stream at https://twitch.tv/objcretain (replays at https://replay.objc-retain.com). The motivation my co-host and I have for using GNUstep in 2021 and beyond is to provide a familiar environment for macOS developers and users who are not happy with Apple’s direction and would benefit from a free software alternative. To that end we mostly work on the basic desktop tools like calendar, mail, and addresses, and fix framework/dev tools bugs and missing parts as we find them.


Sounds like a cool hobby. But solving basic desktop tools, sounds like bikeshedding to me :) Not to disrespect the project, I find Objective-C and the Cocoa model nice, but realistically looking at it almost nobody uses GNUStep, so why write apps for it ?


That is precisely why... it's new ground. It's fun. It's interesting. Why write applications (or, in your words "bikeshedding" -- an interesting term, I had to look it up. :))... because it's a chance to create something totally new. The mission is two fold:

1) Bring the elegance of easy development to every other operating system... and 2) Give Apple developers someplace else to deploy their applications.

GNUstep is meant to be a drop in replacement for Cocoa. By Cocoa I mean Foundation and AppKit, not all of the Core this and Core that libraries. We have those, but they are less mature than Foundation and AppKit. GNUstep is also themable, as I have pointed out in other responses.

GC


Well, that is a noble goal. Hope you can manage even portion of it. Would be nice to have a way to deploy macOS applications on other platforms, but seeing it is already difficult enough to make sure macOS applications even work on different versions of macOS, that is a difficult task to achieve.

But godspeed to your project, Objective-C, Cocoa and the whole NeXTSTep visual identity is a nice combo.


> Working on top of the X11 implementation also doesn't really provoke trust to look into the project.

Vs Wayland? I'd have way more doubts about anything that ran exclusively on Wayland than on X11.

Wayland isn't ready, I have serious doubts it's ever going to be ready.

X11 is old, but so is vim, emacs, grep, everything I want to actually rely on.


> Wayland isn't ready, I have serious doubts it's ever going to be ready.

I don't know enough to have opinion about Wayland - could you share more details about why you do not think it is ready?


Yeah well Wayland doesn't provoke trust either..


> Working on top of the X11 implementation also doesn't really provoke trust to look into the project.

Well, back when this project started X was really the only game in town. If they had started out rewriting the low level display server and graphics drivers they would never have gotten anywhere (to the extent the current state of the project can be considered "anywhere").


There is a wayland backend for GNUstep.


> Now, realistically, even though I like the idea, who is going to use this ?

Someone who thinks that OpenStep is a good way to build end-user applications, I imagine. I've never used it myself, but I know that it had an excellent reputation once upon a time. I wouldn't be surprised if it's better than Qt or gtk+.

> Working on top of the X11 implementation also doesn't really provoke trust to look into the project.

X11 is the standard display technology for Unix and Unix-like systems. Not working atop X11 would provoke distrust. I imagine that you are actually advocating for Wayland. Wayland may actually be the future, although I am still unconvinced that its design is sound (I worry that it throws out the baby with the bathwater).

edit: I did not realise that there is a Wayland backend for GNUStep.


I'm generally speaking about the state of X11 vs macOS or Windows. Like configuring multiple monitors, getting your mouse working just right or other tasks that sometimes can just be freaking difficult with X11. But not wanting to go into that flamewar now.

I would be surprised if it's better than Qt, in fact I know it's not. GTK+ also has had a lot of work during the years, but they have dropped the balls many times over major revisions, so in that sense it might be a better framework than GTK.

But then again, it all comes down to who uses these. Qt is widely used beyond Linux in application development, and modern QT is actually a very nice development environment.

Wayland is also in a state of not-complete. What I'm trying to say here is that the display technologies behind most Linux environments are not in a good state. They work, yes, but some things just don't work or are impossible to setup compared to eg. macOS or Windows.

This is mostly due to open source fragmentation and legacy code in my view, and the fact that everybody and their brother would rather fork out their own desktop environments than decide to make couple of good ones, but hey that's Open Source. Also missing commercial support of course.


> Someone who thinks that OpenStep is a good way to build end-user applications, > I imagine. I've never used it myself, but I know that it had an excellent > reputation once upon a time. I wouldn't be surprised if it's better than Qt > or gtk+.

GNUstep is Cocoa now and, apparently, a lot of people thought building apps this way was a good way to build end-user apps... macOS and iOS. ;) -- Gregory Casamento GNUstep Lead Maintainer


Linux desperately needs a good DE. We might as well dumpster dive for something reusable from the past.

NeXTStep actually really reminds me of Windows 7 and other things. I wouldn't mind trialling it for a week as long as I could get my usual tasks done.


Once you switch to Fluxbox/Rox/Urxvt and custom keys, you won't need anything else. BT? Blueman. Network? NetworkManager/Connman plus the applet. Done.


The Unix philosophy doesn't work as well when it's mandatory to enable building a GUI. I specified that we need a good DE because we don't have a good story for integrating all of those things you mentioned within a UI that I consider usable (and GNOME isn't it, and KDE is not quite it either).


Yeah, I explicitly mentioned Objective-C v-latest, because not only the users have to figure out the whole runtime support in GCC vs clang in regards to Objective-C 2.0 and GNUStep, to further improve interoperability with Swift, many aren't aware that Objective-C still has a life and gets updates even if in tiny portions.

Finally the whole way how makefiles work (classical NeXTSTEP style) isn't any longer like that.


You can use either clang or gcc. ObjC v2 is supported. There is currently no interoperability with swift, but that is coming and you can just build using your .xcodeproj file if you build and install buildtool+libs-xcode. How's that?


It is even more of a shame, since Etoile was the project to bring frontend WM and library synchronicity to Linux / macOS (then OS X). But it died and hasn’t been updated in ages, as the last great hurrah in that effort.


Which of course it doesn't have to be, but the current developers are very hostile to changing anything about the UI, which of course no one today really wants. Providing the old UI as theme for those who want it is fine, but not updating it to something modern and useful is not.

I really wanted to contribute and help out with GNUstep, but that put me off from attempting anything.


Do I know you? We really are pretty nice. GNUstep can be themed very easily. You are more than welcome to help, ESPECIALLY to make more themes.

See the link below... This is GNUstep using the rik theme... Just one of the many ways the project can look:

https://user-images.githubusercontent.com/12986802/33520300-...

Gregory Casamento GNUstep Maintainer


I contacted you a bunch of years ago - and actually I was the maintainer of the script/instructions for building on Ubuntu in the 14.04/16.04 era until plaurent took it over.

Everybody is very nice, but I believe more than just themes is needed. We need a wholesale UI redesign. A discussion happened a bunch of months ago, and it was clear there was no desire to do that.

(And yes I do run the Rik theme :) )


I love that FinderSTEP mash-up icon :)


NeXTSTEP? That's how it started, but not where it currently is. GNUstep is currently pushing for 10.15 compatibility at least. GNUstep supports the current release of clang which is fully ObjC2 compliant. GCC is also still supported. There is also a tool called buildtool and a library which can read and build xcodeproj files fairly seamlessly.


Objective-C moved on, nowadays is it more 2.x than 2.0, and those small changes are not there as far as I am aware.


Which small changes are you referring to? We use LLVM/clang and so does Apple. We have ARC, we have properties and other features as well. Be explicit... BTW, I'm the lead maintainer, so I kind of know what is there and what isn't.


Apple uses their own fork of LLVM/clang, hence why watchOS bitcode is more stable than what the open source variant offers.

"Swift and Objective-C Interoperability" - WWDC 2015 (Nullability qualifiers, audited regions, generics, typed collections, kind of types)

https://developer.apple.com/videos/play/wwdc2015/401/

"What's New in LLVM" - WWDC 2017 (API Availability checks, ARC warnings and stronger function declarations)

https://developer.apple.com/videos/play/wwdc2017/411/

"What's New in LLVM" - WWDC 2018 (ARC updates)

https://developer.apple.com/videos/play/wwdc2018/409/

"What's New in Clang and LLVM" - WWDC 2019 (runtime optimizations)

https://developer.apple.com/videos/play/wwdc2019/409/

"Advancements in the Objective-C runtime" - WWDC 2020

https://developer.apple.com/videos/play/wwdc2020/10163/

I didn't fell to go all the way back to the WWDC 2006 when Objective-C 2.0 was announced.

Explicit enough?




Consider applying for YC's Fall 2025 batch! Applications are open till Aug 4

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: