GNUstep: Open-source, Object-oriented, Cross-platform Development Environment | Hacker News Reader

GNUstep: Open-source, Object-oriented, Cross-platform Development Environment

gnustep.org

319 pointsecliptik162 comments

25 years ago I was excited to learn that the Quake editor (and Doom before that) was written on NeXT. I figured with my rudimentary Linux and C skills I could get it working, but of course it was a little harder than installing everything and running make

From JohnC:

"This is a NEXTSTEP application, so hardly anyone is going to be able to use the code as is. This is not an OPENSTEP application. It doesn't even use the foundation kit, so porting to gnustep or openstep-solaris/mach/nt would not be trivial."

"This application was really not a very good fit for NEXTSTEP. The display postscript model fundamentally doesn't fit very well with what we need here -- if you run in an 8 bit color mode, the line drawing runs at an ok speed, but the texture view goes half the speed it should as it dithers from 24 bit color down to 8 bit. If you run in 24 bit color mode, you get less screen real estate and significantly slower line drawing as a 3 megabyte XY view is flushed. Sigh. If anyone does actually run this on NEXTSTEP be advised that you want a fast machine."

"QuakeEd is written for NEXTSTEP 3.3, while GnuStep is an implementation of the OPENSTEP spec. I haven't had time to port it to openstep yet, but it looks like it will take a little effort. NeXT has tools in NS 4.0 to help, but it still isn't automatic."

An ultimate Hacker News comment here; John Carmack, Quake/Doom anecdotes, relevant ties to NeXT.

Just saying, greatly enjoyed it.

Still missing Rust, blockchain, and gut bacteria but it's not bad!

If he rewrites it to include those things then it’ll be like the Mearle Haggard “perfect country and western song” thing.

“I was drunk the day my mom got out of prison…”

LOL

I'm pretty sure that Carmack was running NeXTSTEP 3.3 on an HP PA-RISC machine.

NeXTSTEP ran on m68, x86, SPARC, and PA-RISC. Then it was ported to PowerPC and renamed.

https://wiki.c2.com/?NextStep

Yup - from another .plan file:

We hadn’t really used them for much of anything in the past year, so it was just easier to turn them off than to continue to administer them. Most of the intel systems had already been converted to NT or 95, and Onethumb gets all of our old black NeXT hardware, but we have four nice HP 712/80 workstations that can’t be used for much of anything. If someone can put these systems to good use (a dallas area unix hacker), you can have them for free. As soon as they are spoken for, I will update my .plan, so check immediately before sending me email.

You have to come by our office (in Mesquite) and do a fresh OS install here before you can take one. There may still be junk on the HD, and I can’t spend the time to clean them myself. You can run either NEXTSTEP 3.3 or HP/UX. These are NOT intel machines, so you can’t run dos or windows. I have NS CD’s here, but I can’t find the original HP/UX CDs. Bring your own if that’s what you want.

I’m a bit nostalgic about the NeXT systems – the story in the Id Anthology is absolutely true: I walked through a mile of snow to the bank to pay for our first workstation. For several years, I considered it the best development environment around. It still has advantages today, but you can’t do any accelerated 3D work on it.

So I use GNUstep and I really like it.

It is not an Apple emulator—it is an OPENstep emulator and so it implements the amazing Cocoa API and many mac/iOS frameworks can be used server side with minimal porting.

This makes it easy for what I intend to keep as a one person project forever or as long as Apple continues to support Objective-C.

You want to know an unpopular opinion?? I love Objective-C and I think it is better—way better than Swift. And—if you have discipline, the preprocessor is excellent.

So while many might say GNUstep is buggy, it is working for several of us—and happily so.

I do agree that the homepage is terrible and that what should be done is put some installer scripts so you can start using it immediately. An Ubuntu installation following the corresponding script here is foolproof: https://github.com/plaurent/gnustep-build

Check it out!!

> You want to know an unpopular opinion?? I love Objective-C and I think it is better—way better than Swift. And—if you have discipline, the preprocessor is excellent.

Very curious to the reasoning here. If you can get to the pointer level of Swift, you basically have obj-c without all the unnecessary syntax?

In my view, excessive syntax is a crutch to make the language parser's job easier, not making the thought to code job easier. Obj-C seems to suffer from the excessive syntax?

To be fair, the syntax has changed since the days of NeXT. Accessing object variables been more C like (dot notation).

Personally, I never had any difficulties understanding the old syntax.

If anything, the old syntax was pure and consistent with what actually happens - message sending. Dot notation muddies the waters, IMO, but certainly is convenient. Ditto the collection literals.

I still say they did properties wrong. If you have a property prop, it should synthesize methods prop and prop: and expose them to the user. Then, to get you say [obj prop] and to set you say [obj prop: newVal]. This is a convention widely used in Smalltalk, and is nearly as convenient to use as dot notation. Dot notation in Objective-C makes the dot operator mean two different things; and in one case it takes a bare struct and in the other case it takes a pointer. Utterly weird. But it's a belt onion: done because it was the style at the time.

This is in fact how @property works; the declaration is sugar for a pair of accessor methods. The dot syntax is sugar for calling those methods.

    #include <Foundation/Foundation.h>

    @interface Foo : NSObject
    @property (copy) NSString *bar;
    @end

    @implementation Foo
    @end

    int main(int argc, char *argv[]) {
        Foo *foo = [Foo new];
        [foo setBar:@"Hello, world!"];
        NSLog(@"%@", [foo bar]);
        return 0;
    }

The dot syntax makes it difficult to parse whether you are dealing with a C struct or an Objective-C object.

Objective-C was grafted onto C with very clear demarcation lines.

We don’t mind being able to declare a property with `@property`. We do mind that they introduced dot syntax

Same here, I was never a proponent of the dot syntax. As we know, compiler development at Apple got taken over at some point by C++ people, and we can all see the results: https://blog.metaobject.com/2014/06/remove-features-for-grea...

t.rotate (a, v); // Original

t rotate (a, v); // Who needs dot?

t rotate a, v; // Who needs brackets?

t rotate by: a around: v; // Who needs ambiguity?

t rotateBy: a around: v // This is Smalltalk

I’m rolling — this is perfect.

Civilization has used dot notation in basically all thought, as evidenced by pretty much any nation’s laws / code

Which of course means it's in no way ambiguous or overly used. One syntax for one purpose. Until dot notation was used for @property you never had to guess if you were looking at a structure or at a class. See how that works?

Greg—the funny thing is that the comment I read the comment where they explain notation differences as sort of saying that Smalltalk is the best thing on the planet and we should all aspire to be Smalltalk. No ambiguity with Smalltalk which is of course the whole point of readable, paintable code. The most easily maintainable code is that which does not need documentation.

On Smalltalk: Objective-C of course aspires to be Smalltalk. It just so happens that it's happy to be a muggle and integrate C as well. Good for us. Use Smalltalk for most things and C where necessary.

> In my view, excessive syntax is a crutch to make the language parser's job easier, not making the thought to code job easier. Obj-C seems to suffer from the excessive syntax?

Another perspective is that the syntax of Obj-C exposes and supports the core model of the language, which is objects sending messages to each other. That it happens to be fast to parse seems secondary, and certainly further developments since version 2.0 have made parsing slower, not faster.

In my experience people complain about Obj-C syntax when what they actually dislike are verbose Cocoa/Foundation/etc APIs. Try their C Core* equivalents and you'll find you probably dislike those, too.

> In my experience people complain about Obj-C syntax when what they actually dislike are verbose Cocoa/Foundation/etc APIs

If so, that’s a real shame. Foundation may be the single best-designed standard library for a (non-functional) language ever.

I agree, Foundation is a gem! The method naming is one of the assets - the names are clear, regular, and usually fairly obvious. The downside to that regularity and clarity is that the names are long.

One CoreFoundation example at random:

    CFURLRef CFURLCreateCopyDeletingLastPathComponent(CFAllocatorRef allocator, CFURLRef ref);

I think nearly everyone who reads that prototype will immediately understand what it does, but there's no denying it's a mouthful.

Tack on some unfamilar square-brackets and intersperse argument names, and it's understandable that people will conflate the syntax with the APIs.

CoreFoundation is not written in ObjC, it's C only (although toll-free bridged).

For me Foundation lacks composability. This method should be really two: CreateCopy (I assume it already exist) and mutating DeleteLastPathComponent.

I don't mention immutable by default behavior because it was long ago and written in C.

I love the expressiveness of Obj-C, I love the brackets, and I love how easy it is to write.

I hate Swifts boiler plate words (var, let [why not const???], func), I hate the obtuseness of it (eg question marks everywhere), and I hate how hard it is to read because it makes it very easy to be so "clever".

> I love Objective-C and I think it is better—way better than Swift.

You are not the only one. This is exactly how I feel.

But GNUstep is ... not great. I want it to be! But it needs a lot of work on the interface side.

Judging by your comments, you seemed to have talked to the GNUstep maintainers, but they haven't been receptive to your ideas.

May I propose a fork? How about SiDESTEP ® for the project name?

No one ever spoke to me and I am the lead. Also SIDESTEP has been taken by another project. :)

Email me... anyone is free to join at any time. The whole project would appreciate the help.

I am already on the mailing list (and I even backed the failed Kickstarter :'( ).

My issue is it needs an entirely new UI, and the last time that was brought up it was clear nobody active wanted to do that.

Well, for one thing it's not an emulator... AT ALL. And for another thing the idea behind GNUstep since about 2000 has been to implement Cocoa. I do appreciate your enthusiasm. :)

Greg C. GNUstep Maintainer

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.

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.

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?

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

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.

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

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

> 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

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.

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

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.

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.

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

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.

> 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

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 love that FinderSTEP mash-up icon :)

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

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?

The last time I evaluated a small, supposedly cross-platform framework which uses GNUstep for macOS, I quickly realized there’s no obvious or even documented way to install the development libraries on macOS: there’s no Homebrew formula, a broken MacPorts port that was last updated ages ago (I’m not sure if it includes the development libraries or just a desktop suite), and some ancient, partial instructions on the wiki. I guess the only way to install it is to grab the source and try to get it to build, but everything about it screams “don’t use”.

I am not a mac developer, but if GNUstep is trying to keep to being source compatible with cocoa as possible, do you need to? Shouldn't the Apple provided dev libraries work too?

I could be missing something, and most probably am, but I looked into rust bindings for this library and they had build options to use gnustep/libobjc with macos and linux.

Hope that helps.

edit: here is the crate I am talking about: https://crates.io/crates/objc-sys

You're certainly not going to be able to -lgnustep-base -lgnustep-gui on macOS without installing libgnustep-base and libgnustep-gui. You should be able to link against libobjc without GNUstep.

I'm not sure if Cocoa has diverged enough to be incompatible.

The OpenStep specification is from October 1994. For perspective, the first version of Netscape navigator was in December of 1994 (and the first version of Internet Explorer was in August 1995). Now picture yourself in 2022, building a modern web page, testing with Firefox 100 and expecting it to work with Netscape 1.0

WINE doesn't seem to be packaged in Scoop, MSYS2, or Chocolatey. Yet none of that would be a dealbreaker when using WINE.

A quick search reveals that GNUStep is packaged in Debian, Fedora, NixOS, OpenSUSE, Arch, Gentoo, Void, FreeBSD, OpenBSD, and more [1]. I think that should be enough to cover most platforms that people would actually want to use GNUStep on.

[1]: https://repology.org/project/gnustep-base/versions

GNUstep is not WINE for Mac/NEXTstep (Darling is tho: https://www.darlinghq.org/)

Why would you want to use GNUstep on Mac? Because it lets you write native software using Foundation/Cocoa/etc that you can actually port to other platforms.

The analogy still holds because people wouldn't use GNUStep on macOS for the same reason people wouldn't use WINE on Windows. That GNUStep doesn't run macOS binaries makes no difference here.

They would use it though, that’s my point. A developer that wants to create a portable Cocoa-based GUI, or a Foundation-based Objective-C CLI can use GNUstep to do so. If they just use Apple’s frameworks directly, they’ll have a hard time porting it anywhere.

The one cross-platform app I know that uses GNUstep to run on Linux is Hopper, which just uses Apple's libraries on Mac. Not sure how hard the porting effort was, but I thought I'd throw that anecdote in there.

As for wine, it's worth pointing out that wine consists of both the plumbing to get win32 apps running on Linux as well as a recreation of the win32 userland libraries. Darling is similar, and it uses GNUstep for some of its userland recreation.

Ideally, GNUstep should be a drop in, source compatible framework to compile code written for the native ones on MacOS, similar to how Wine can be a source compatible framework for Windows. There are actually Wine ports to CPU architectures like 64 bit PowerPC that never had native windows versions, and Wine lets you recompile and run win32 software on ppc64le.

(Of course, the practical caveat is GNUstep isn't implementing OS X's API, but OpenSTEP, which OS X/MacOS still mostly (?) implements as a subset of its current API. So, if you wanted to be cross platform and use GNUstep, you'd either need to develop on Linux, link against GNUstep on MacOS, or be super familiar with MacOS to know what APIs are available on both)

I think it's more common practice to use Apple's frameworks on macOS and GNUStep on Linux. At least, that's what unar [1] and the Hopper Disassembler [2][3] does. That's probably the reason why GNUStep is absent in Homebrew.

[1]: https://github.com/NixOS/nixpkgs/blob/1cfd83e859002d1f053bb3...

[2]: https://github.com/NixOS/nixpkgs/blob/a0dbe47318bbab7559ffbf...

[3]: https://github.com/NixOS/nixpkgs/blob/a0dbe47318bbab7559ffbf...

As an Apple dev since ‘86, I’ve used (in order of appearance):

    MPW

    THINK Pascal

    THINK C

    CodeWarrior

    Xcode

I never warmed to other IDEs (like AppCode), but find IDEs to be more productive (for me) than CLI tools. Yeah, I know some fairly awesome CLI people, but that has never been the case for me.

I write in native Swift, so it’s really important that what I use be right on the “cutting edge.”

Right now, that’s Xcode.

Xcode is a bug farm. It’s also frikkin’ huge. I have to sometimes force-restart when the code parser goes walkabout.

But it does give me what I need. I’d certainly be open to viable alternatives, but nothing has come up that has enticed me.

> Xcode is a bug farm. It’s also frikkin’ huge. I have to sometimes force-restart when the code parser goes walkabout.

Have a look at JetBrains CLion with the Swift plugin. It has served me well.

> Have a look at JetBrains CLion with the Swift plugin. It has served me well.

Thanks.

The most recent development (updated a month ago) is 'NEXTSPACE' which is designed to sit on top of a minimal CentOS 7 install.

See: github.com/trunkmaster/nextspace

I have used it in a VM under Windows and it was pretty nice.

It felt very NeXT-ish.

Of course you could install and run regular X windows programs as well.

For a while, GNUSTEP Live CD was the best option to try and test GNUstep. Latest version is even available for Raspberry Pi: http://www.aiei.ch/gnustep/

Last time I looked, GNUStep was really, really, really buggy reimplementation of 2000-era macOS... sorry, Mac OS X back then... toolkit.

I say really 3 times, because I really tried to port a MacOS-only terminal app (don't ask) to Linux, and I failed miserably on very basic functions.

I guess I should have tried more, make minimal examples and report that, but I never bothered. It's what I would do now, anyway.

I remember GNUstep since the 90s. It existed even before Gnome. It had a (for the time) pretty home page, but very little information and very little outward progress. What happened behind the scenes I have no idea about.

Still going. ;) -- Gregory Casamento GNUstep Lead Maintainer

"GNUstep is a free, object-oriented, cross-platform development environment that strives for [...] elegance"

Well personally, I gotta say, I dig the 1995 optics of this.

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

Yeah, I know, right? ;) </sarcasm> It is fully capable of looking like macosx using any number of themes.

Gregory Casamento -- GNUstep Lead

I remember seeing GNUstep on Linux distributions 20 years ago, along with early KDE and other options. I appreciated the aesthetics of it at the time, but - can someone explain its benefits today, and why one would prefer using it?

Actually, I'm not even clear what I would replace with GNUstep, exactly.

I imagine you can compile some programs designed to run under macOS to run on it, with a NeXTSTEP look and feel.

Apart from that, it's mostly for historical interest.

GNUStep is not a desktop. Try NextSpace (see above) if you want a GNUStep based desktop. NextSpace is a clone of NextStep desktop.

Like its ancestor, NextSpace is fast, light and very consistent. I like the vertical menus that I can move were I need them, the dock in the file manager, the file manager itself, … It is an advanced desktop that hide the difficulties: you don't need to learn, it is logical. It is like macOS, without targeting beginners. I am a long time KDE user, I know how it works, it is my desktop of choice. But there is still some glitches, and it is a different user experience than NextSpace.

A few of us maintain scripts for building the latest GNUstep from source under Linux (desktop, PinePhone, and Raspberry Pi) here: https://github.com/plaurent/gnustep-build

Thank you for this! I was the a maintainer for this years ago, and I'm glad its way better than I had it.

How does it compare to Window Maker?

Window Maker is an X11 window manager with a NeXTStep look.

GNUStep is an attempt at creating a Free/Libre NeXTStep-like environment, including all the apps.

"The GNUstep project does not provide a window manager; you can use any window manager you want, although we recommend that you use WindowMaker for a better experience." http://gnustep.org/information/aboutGNUstep.html :)

GNUstep is really a framework and closer to something like Gtk+ or Qt. Window Maker is a window manager, it has its own GUI toolkit (WINGs) but it is really only meant for use with Window Maker and perhaps some dockapps (though some dockapps use other toolkits anyway).

It doesn't. They're different types of tools. GNUstep commonly runs under and uses Window Maker.

Window Maker is a window manager.

GNUstep is a large set of libraries and foundation classes, and almost as a byproduct, they happen to implemented most of a desktop environment: a file manager and actual desktop, a dock, plain and rich text editors, a pretty good email client, a chat client, a terminal emulator, image viewer, etc. etc.

But like any other xNix desktop, it needs a window manager. KDE uses kwm, GNOME uses mutter, Xfce uses xfwm, LXDE uses OpenBox, etc. GNUstep can use whatever you want, but Window Maker is the recommended choice because it matches the look-and-feel nicely.

What are the advantages over FPC/Lazarus?

- First and foremost, it's not Pascal, but the more elegant Objective-C.

- You can in theory compile sources for NeXT/OpenSTEP or early OS X applications with minimal changes[1], while FPC would require you to rewrite them completely.

- Different GUI components, inspired/based on the *STEP design.

Realistically, I guess you're better off using Lazarus for anything new, nowadays.

[1] The original DOOM editor was developed for NeXT machines, and the sources surfaced a few years ago. Here it is running under Ubuntu with Window Maker and GNUStep: https://www.doomworld.com/forum/topic/111229-redoomed-maclin...

> First and foremost, it's not Pascal, but the more elegant Objective-C.

That depends on the beholder and their eye :-P.

Absolutely :)

Well, no doubt the curly braces look… curlier!

I like the procedural version of Pascal, with records, procedures and units, however the more modern Pascal that you can find in FreePascal where you have to either inherit or implement a class for any advanced container is cumbersome.

The language had support for dynamic arrays for ages and the intrinsic functions like insert, etc have been extended to work with them in latest version (i'm not 100% sure if this is available in the latest relase, but it is available in the trunk). So for simple stuff that should work.

But yeah the containers that FPC provides are indeed cumbersome and i blame Delphi for that and FPC's insistence on copying all those bad features (ok, i understand the need to remain compatible so people can switch to FPC, but they can always provide better tools too - perhaps they're burned from when they implemented generics first and then Delphi implemented theirs in an incompatible way and now they have to support both).

On the other hand, you can make your own and i have mine which can use any old data structure, be it primitives, records or classes.

Typo in the banner: http://gnustep.org/information/banner.pdf

> GNUstep uses the same langauge and API as Cocoa on Mac OS X.

That small nitpick aside, that seems like and interesting project! I don't think i have seen many (if any) other attempts at creating a set of portable tools like that, entire workspaces that can work over a variety of OSes, unless i'm reading this wrong. Sure, we have portable editors and so on, but this seems like a step well above that.

I’d say that Flutter[1] probably meets that same definition today of cross platform development and tooling in a much slicker way.

[1] https://flutter.dev/

I'm afraid that i can't agree there, because of how it was implemented.

Flutter is plain hostile from certain standpoints: in the browser, it does use canvas for rendering and therefore denies any ability to learn about how a particular site was developed (how many of today's devs have benefited from "Inspect Element"?). Not only that, but it also breaks much of browser functionality, such as right clicking, selecting text, using plugins that manipulate the DOM, user styles, and historically even screen readers (though they're getting better at that last bit recently).

Just have a look here: https://gallery.flutter.dev

Open the Reply app, open a message, try copying the contents. Try seeing how the block with the sender information has been formatted. Pretend that Taxes folder is spam instead (e.g. an ad, or a flashing element that could cause you seizures), try blocking it with uBlock Origin or a similar plugin.

I agree that technically it fits the criteria that you're describing, but it fails on certain platforms (the web) in my eyes due to all of the shortcomings and how badly it implements this platform support. Use it for native apps? Sure, i guess...

Fire dances of celebration where thrown around the lands with the demise of Flash, ActiveX, Silverlight, Java Applets and all others that followed the same cursed path, yet the powers of be down at the druid dungeons came up with WebGL/WebAssembly, thus the natural order was eventually restored and everything old was new again.

> WebGL/WebAssembly

You know, it's kind of unfortunate, because the actual tech is nice and has lots of potential. I mean, WebGL is great for online games (even if many will suggest that it's not quite as easy to work with as Flash was) and other interactive content, like visualizations etc.

Whereas WASM has the potential to make high performance code in the browser a reality, especially for the aforementioned physics simulations, or curious usecases of tech such as having access to Python or .NET in the browser environment, which remain sandboxed at the same time. The ability to do this feels really interesting, as do Web Workers being a thing (even though maybe JS should have had proper threading support and support for joining threads from day one instead).

It's just that the way these technologies are used can end up a bit misdirected or sometimes outright malicious, something that we'd possibly get in other forms without this (just look at how evil ad industry sometimes is and how unethical many of the ads have historically been).

Too late, the train has departed already, https://workspaceupdates.googleblog.com/2021/05/Google-Docs-...

Watching Google leading the transition, of the web from a hypertextual, common, extension-able user-agency-embue-ing medium, into an unmalleable, hard, pushing-pixels-in-our-faces application is one of the most evil malignant acts I can imagine being perpetrated against good upstanding tech society has. This is such a huge step into the dark, out of the sun, for the world wide web.

It is called ChromeOS nowadays, thanks to everyone that helped Chrome achieve its hegemony (Electron also counts).

I think to be fair to Flutter their entire concept of web support is literally months old at this point outside of beta, it obviously has a long road ahead of it to become more web native.

At the same time, I think that we need to start thinking about what web apps can and should look like strictly outside the context of just the DOM. It's not clear that it is really going to be the right tool for the job moving forward for more complicated applications. For example Google Docs is moving (has moved?) entirely to canvas based rendering for performance and flexibility reasons.

Technologies like WASM, canvas, WebGPU and HTTP3 means that the list of available options is about to change rather dramatically in the next few years I think.

These new approaches are going to require new solutions not just for the use cases you outlined but also things like just general accessibility. I've had a chance to look at what the Flutter team are doing on that front and I think it would be safe to say that they aren't in anyway unaware of where things fall short currently but have public plans already in various stages of implementation to address them.

Not asking anyone to drink to kool-aid just yet but I feel good about their plans to play catch up over the next couple of years. I could easily see it becoming a very sensible default option for app development before too long.

I have no interest of being fair to Flutter.

Flutter is just another proof that for Google as an organization[1] being nice, open and friendly was just a trick that lasted as long as it was useful for Google.

[1]: I think the majority of people there are nice, there is just some dynamic that drives them to become dumb[2], manipulative[3] and destructive[4] when they operate together ;-)

[2]: still haven't managed to fix search a decade after they broke it.

[3]: censorship etc

[4]: destroying their own products, companies they buy, and even entire markets (like web browsers)

Edit: I don't hate Google, neither as an organization and definitely not as individuals but I really really really wish Googlers could get their act together and start being Google again because they behave as a small child with super powers or something :-/

> I really really really wish Googlers could get their act together and start being Google again

Google has always abandoned projects suddenly--even in the era you're describing.

Yep.

But search used to be rock solid and Google used to be a driving force behind the open web.

> At the same time, I think that we need to start thinking about what web apps can and should look like strictly outside the context of just the DOM.

In my eyes, the DOM is an inseparable part of how web apps should work - the web being composed primarily of documents, even if more dynamic ones nowadays thanks to SPAs and intermediate technologies like virtual DOM implementations.

Throwing away the entire model while chasing performance gains due to overcomplicating what websites should be in the first place is not good, in my eyes.

That view may change some day, however, but for now i'm happy with creating and consuming primarily lightweight websites (HN is a good example of this, as is the old Reddit layout) and using specialized software for the things that the web doesn't always do good in my eyes, such as Thunderbird for e-mail and Libre Office for documents.

Should people have the choice to use different architectures and approaches for the cases where it's necessary (e.g. educational physics simulations with WASM in the browser)? Sure. But should we push those approaches as the new normal and usurp decades of progress? I don't think so.

I guess that’s the part where we differ. I can’t help but see an inevitable merging between the idea of a native app and a web app until they are possible to be one and the same.

So for me the browser is more of a rendering pipeline that can deliver DOM for pages and apps or something like canvas for “native apps”.

As I was saying above I totally share that fear of sending these opaque blobs of binary data down the wire that paint arbitrary pixels that I have no control over. That isn’t how “the web” works.

So you are going to need to find a way to think about accessibility APIs for example that aren’t tightly coupled to the DOM. Those things are already happening. Source maps are another important tool to maintain that slick view source experience.

But I think there is a reasonable case to be made that the browser should 100% be capable of running native apps so long as they are able to play nice with the web as a platform.

Note: I have to just explicitly make that distinction between pages and apps here. I don’t ever want to see this try and become the new normal for anything that would reasonably be considered “document based”. I think they can comfortably coexist each with their own specialities.

While we are in disagreement, this is a really nice point:

> But I think there is a reasonable case to be made that the browser should 100% be capable of running native apps so long as they are able to play nice with the web as a platform.

In my eyes, the problem is that DOM seems to be what makes up the current "platform" of the web, since that's what most of the pages out there are based on, what most of the development effort is centered around and what most of the browsers work best with.

That's not to say that it couldn't feasibly change in the future, or that trying to do so isn't worth the effort, but i'd definitely posit that it's extremely tricky to get that right. Flutter might not be the right tool for that job, but maybe in a decade or two someone will have borrowed some of its good ideas and built something better.

Though to me it feels like any such development would need new standards to describe what could actually be in such a platform, how all of it would work and would also need to be included in all of the browsers - a true Herculean effort. Approaching the problem from the other end, by working with canvas/WASM/whatever is probably easier, since it doesn't require changes to the browser code, but in my eyes that's a bit like trying to create a 3D renderer in Excel or something, maybe going one layer of abstraction too deep (platform in platform).

I might be wrong though and it all could work out yet somehow. Hopefully when it happens, it won't be a case of one large org pushing a new standard and being like: "This is how we'll approach the web now, get with the times and the APIs that we've developed."

Freepascal/Lazarus

Lazarus and the modern versions of Pascal are lovely for desktop development!

For anyone curious, here's a nice writeup: https://castle-engine.io/modern_pascal_introduction.html

And here's Lazarus, the actual IDE: https://www.lazarus-ide.org/

Though they're more along the lines of cross platform language/framework (their approach to GUI frameworks across platforms is great https://en.wikipedia.org/wiki/Lazarus_Component_Library#/med...), as opposed to a set of utilities to develop inside of.

Edit: for example, see http://www.gnustep.org/softwareindex/index.php?count=100

Either way, it's a shame that Lazarus and Pascal never really caught on, since they feel like an older and more mature Go or something, except with actual GUI tools out of the box and a variety of useful drivers (think along the lines of Swing in Java, but less rude to the underlying platforms), which mostly makes them dead nowadays and not the best option for new projects.

Also, their web dev scene is lacking, there's nothing like Spring/Django/Express.net/ASP.NET in Lazarus. At least not "one true framework" to do webdev in.

It looks like it's straight out of 1995. Ultra dark gray and ugly aesthetics, despite what some people say, will not attract developers or users. This seems to be a meme, Linux desktops and apps with zero thought given to UX and UI. In some cases it almost seems like the approach of "how can we make this as cluttered, messy, and ugly as possible" to look at.

1995 GUIs have far more usability left in them them modern UIs. Just the fact that MS thought it's acceptable to dumb down the right click menu (!), aka the most prominent symbol of a power user, is telling.

We need to step back to 1990s/early 2000s, steal a few modern UI innovations that make sense while retreating, and take a long and hard look at the kind of GUIs we want to see built around ourselves.

A GUI can follow 1995 principles without being an oppressive grey and ugly icons and either too much or too little spacing.

Colour was on offer since at least Widows 98. In fact, desktop themes were a thing, with custom wallpaper, colours, icons - precisely so the computer looks less dreary. If GNUStep was impossible to theme (or if theming was hard to implement there), I'd be surprised.

Information density the one thing 1995 interfaces got right for power users. Modern applications fit 10 items per screen, and most don't bother to make this adjustable. My desktop computer or laptop could outcompute a Cray twice over, and yet I'm made to feel like I'm stripped of all that power.

I think modern folks see w9x themes in the same way as we do with the Amiga UI ones.

No, I grew up with Windows 98. Compare the quality and thought given to Windows 98 dialogs and windows compared to this GNU software in 2021.

https://www.ross-tech.com/vag-com/usb/usb-config-98.htm

http://gnustep.org/

> Ultra dark gray and ugly aesthetics

> A GUI can follow 1995 principles without being an oppressive grey and ugly icons

> Compare the quality and thought given to Windows 98 dialogs and windows compared to this GNU software in 2021.

The NeXTSEP/GNUstep look is a little older than Windows 98, and I agree is a little less clean looking than Windows 98, but it's in no way ugly or oppressive. In fact it was a refreshing and highly acclaimed design at the time, and IMHO it still holds up pretty well three decades later.

> The NeXTSEP/GNUstep look is a little older than Windows 98

A full decade older.

NeXTstep was demonstrated in 1987 and launched with the NeXT Cube in 1988 with v1.0 being released in 1989.

I mean, come on -- look at it next to its contemporaries: https://arstechnica.com/features/2005/05/gui/6/

Windows 2.0, OS/2 1.1, DR-GEM.

I really feel that even if someone doesn't like the grey-and-black look (I love it myself) that one _must_ admit it was streets ahead of its contemporaries.

Personally I think W95 looked better than W98, and W98 looked better than XP.

I grew up with Windows 98 (and before, DOS), so I knew pretty well both w9x and GNUStep under Debian Woody. Both look equally well.

This steadfast denial is why Linux desktop apps look as terrible as they do.

Yes, I'm no fan of the modern Metro UI either (Settings is the worse offender) but I personally believe Explorer in Win10 is peak windows design. Minimalist but with vibrant colorful icons, neatly organized but still information dense and no abuse of whitespace. It's a shame the entire Windows UI can't be based around it.

Who remembers the Smalltalk browser?

So, is like windowmaker?I kind feel like when I was in college in the early 2000`s and used Windowmaker as my main window manager.

GNUstep is a framework (and some applications that use that framework), it is closer to Gtk+ and Qt than to KDE or GNOME. Most importantly it does not provide any window manager and instead rely on an existing one (you can use it with KWin/KDE, Mutter/Gnome, XFWM/XFCE or any other window manager).

Window Maker is a window manager with a NeXTSTEP/OpenStep style, though it has nothing to do with GNUstep aside from looking very similar and thus being a good choice for when using GNUstep programs with the classic NeXTSTEP/OpenStep theme.

I tried to answer this above:

https://news.ycombinator.com/item?id=29544763

Thanks. It cleared a lot!

Oh good. Glad to hear it. :-)

Wondering how Steve Jobs would have reacted to GNUstep...

He wouldn't react at all: GNUstep was already an established project before his death, so he already had an opportunity to react and, unsurprisingly, he didn't care much.

Apple didn't really like OpenDarwin or whatever was the name, right. But more on trademark concerns, if I'm not wrong.

GNUstep started in 1995 back when Jobs was still at NeXT before Apple bought the company. He didn't try to stop it back then.

Can it be used as a GUI for C++ programs?

Does it support OpenGL ES?

Yes, it can and yes it does.

-- Gregory Casamento GNUstep Lead Maintainer

Is it strictly necessary that it be ugly?

I think it looks amazing. I wish I could work on an UI like that all the time... Not long ago I was working at an office (non-IT stuff) and they had these very old computers, still running Windows 7, and I remember being able to enable the Win 98 theme, I was so happy about that... at home I was running Windows 10, where you can no longer give your desktop that ancient feel...

I'd say Windows 95/98 was peak UI design. This UI feels even better...

Ok, if there are enough people sharing that opinion, then I certainly get it.

Honestly, it is the singular reason why it failed. They had no intention of evolving with the times.

Bingo. Had they made a better more modern UI, I think it would gain some traction. But they are entirely resistant to updating anything with the UI.

Doesn't GNUstep have a theming engine now? Do you think the current maintainers would accept a new theme if we were to make a more modern one?

It does have a theme engine. There are multiple alternative themes out there.

For me, and IMHO, every single one of them that I've seen is uglier than the original. For me, NeXTstep was the pinnacle of desktop UI design and everything else since has been less attractive.

Mac OS X was quite pleasing, if inconsistent, for a while around 10.4-10.6 or so, but now it's a mess. (I am typing on 10.14 right now.)

Win11 is a big less ugly than Win10, but the desktop is so crippled I find it hard to use, and there are ribbons everywhere. I hate the ribbon.

Win10 is kinda ugly but at least it's mostly black.

Win7 was and is a bit garish but it was the sweet spot.

XP was fugly.

Win2K was the high point for Windows, and everything before and after were worse.

You know that NeXTstep is the only GUI that was pretty enough to feature in a music video?

It's in Madonna's _Rain_ (1993 I think). https://www.youtube.com/watch?v=15kWlTrpt5k

The NeXT cube also featured in _Flatliners_. http://www.starringthecomputer.com/feature.html?f=398

It’s dead and has been for a decade

That turns out not to be the case. It is in both active development and use.

There is slow but active development. Occasionally new releases appear. There is a new, active distro under development.

I don't think this fits the definition of "dead". Not very lively, but not dead.

Then join us. Help us get it the last mile. Don't just say "it looks like it's dead".. be part of the solution. :) You are more than welcome to join!

-- Gregory Casamento GNUstep Lead Maintainer

Hi Greg. :-)

I think you meant to reply to @safdev, to whom I was also replying.

Oh, yeah, i did. Thanks. :)

:-D

Software dies with its last user or curious historian. Open step is quite far from that.

Not dead at all. I have been working with a number of companies to help them use it. Surprising definition of dead. ;) Join us, be part of the solution!

GC -- GNUstep Lead

Reply on news.ycombinator.com