Étoilé was so promising….the idea of using OpenStep (via GNUstep) infrastructure in ways that went beyond NeXTstep or Mac OS X. It felt like an even deeper embrace of the Smalltalk influences of the OpenStep API to enhance the desktop computing experience. Étoilé wasn’t merely a clone of NeXTstep or Mac OS X; it was its own thing that could’ve been a compelling contender to KDE, GNOME, and even macOS.
Unfortunately Étoilé seems to have been inactive for a decade, and even Apple seems to be abandoning its Xerox PARC influences as the old guard retires and passes away (RIP Steve Jobs, Larry Tesler, and Bill Atkinson). Ever since Apple struck gold with the iPhone and derivative platforms, Apple hasn’t been the same.
I’d like to see the ideas of Smalltalk and Lisp machines revisited for the modern era as a model for workstation-class personal computing. Smalltalk and Lisp environments pride themselves on flexibility and malleability (though it’s understandable to rethink some of these things in an era where security is very important), while mainstream personal computing these days feel less like productivity boosters (remember “the bicycle for the mind”) and more like advertising platforms and anti-competitive, rent-seeking moats.
gyomu · 15h ago
> Apple seems to be abandoning its Xerox PARC influences as the old guard retires and passes away (RIP Steve Jobs, Larry Tesler, and Bill Atkinson)
Haven't those people not had any influence on Apple for a very long time now? Steve has been dead for 15 years, Larry & Bill last worked there ~ 30 years ago.
There's definitely been a "change of the guard" at Apple, but it's not from Xerox PARC people...
thiht · 13h ago
Yep, the comment you're replying to is off by a few decades
mpweiher · 11h ago
Objective-S builds in these directions, starting with the linguistic foundations. Note: author speaking.
Those linguistic foundations take the form of a CLOS-like metaobject protocol, but organized not on OO lines, but rather on software-architectural lines, so including OO as a subset.
On top of the metaobject protocol sits a roughly Smalltalk-ish language, with extensions for dataflow ("!", "?", so CSP-inspired, but not CSP-based, fewer processes) in-process-REST like data access and identifiers (URIs in the language) and last not least component connection (→).
With that, you have a good basis for diverse environments that blend the Smalltalk and Unix/Plan 9 styles.
andai · 17h ago
Modern computing is bloat for the mind.
sorrythanks · 16h ago
I love the ideas of Smalltalk and Lisp machines too. Do you know of anything promising in that area? (other than Ink & Switch)
For taking notes and stuff you'd otherwise do in Jupyter or Livebook, try GT: https://gtoolkit.com/
It's not an OS, but you can just abstract over OS actions within either and keep them as your main interface, similar to how some people rarely leave Emacs.
David Chisnall (one of the main developers behind Étoilé) has been working full-time on CHERI for the last decade to bring hardware that enables Étoilé's vision.
> I’d spent a lot of the previous years on Étoilé, which was a project to build a user-focused desktop environment that was built out of composable components with end-user programming as a key focus. We were inspired by the STEPS project at VPRI, which tried to build an entire system in under 20,000 lines of code. Our rule was simpler: we aimed to keep individual components to under 10 KLoC, which is small enough that a single person can understand it. This meant that we needed to be able to both use expressive languages and build expressive DSLs. We were starting from an Objective-C base, which gave us a nice model for late-bound components but brought along a lot of C baggage.
> Unlike STEPs, I didn’t want to rewrite the world in high-level languages. I wanted to use things like libavcodec and libavformat as-is, but without bugs in them being able to destroy the invariants that higher-level software depended on. I’d tried building isolation mechanisms with the MMU and found it severely limiting. I’d also looked at Mondrian Memory Protection, but the table-based approach didn’t compose well with language-level abstractions. Early CHERI wasn’t the right thing either, but it was close enough that I felt I could evolve it into the right shape.
> Most of my fingerprints in CHERI ISAs are with that goal in mind. I want to be able to compile existing C/C++ libraries for a CHERI compiler and use them safely from higher-level languages and use them directly. I’ve written a bit about this before:
> I want to be able to have documents embed scripting-language programs that can directly call large native libraries and still have strong guarantees that my system won’t be compromised. The key point is this observation:
> Isolation is easy, (safe) sharing is hard.
> It’s trivial to fully isolate two components. Separate cores, sandboxed processes, or WebAssembly sandboxes can give this kind of isolation, depending on the degree of isolation that you need. Most interesting things are built from communicating components and keeping things mostly isolated, but able to communicate safely, is much harder. For example, Rust says FFI is unsafe, but if you wanted it to be safe except that objects passed from Rust to C may contain arbitrary bit patterns after the call, that’s harder. You can do it with deep copies, but that’s a lot of overhead and very hard to do in the general case. You can do it with CHERI fairly easily, including richer things like deep immutability (in CHERIoT, we can also provide shallow and deep no-capture guarantees).
Thank you for sharing this interview link! I didn’t know that Étoilé was inspired by Alan Kay’s STEPS project. It makes a lot of sense. It would have been really cool to see a desktop environment that pushed Alan Kay’s ideas further.
realA12l · 10h ago
Chisnall has stated several times over on Lobsters that he's thinking of basing is future project on Arcan (https://arcan-fe.com/). It's a very interesting project.
jfb · 9h ago
This thing about Arcan is that the writing about it is almost deliberately incomprehensible.
WesolyKubeczek · 9h ago
Sounds nice, but back in the day I couldn’t get it to work…
pjmlp · 18h ago
GNUStep is a good example that the bare bones language and compiler being open source it is not enough, when everything else doesn't come along.
Saying this as someone that used Afterstep and Windowmaker alongside GNUStep, and did seat a few times on the GNUStep room at FOSDEM.
Last time I checked was at the level of OS X Panther, and modern Objective-C still wasn't supported.
paride5745 · 10h ago
The main issue of GNUStep was that, when KDE appeared, the GNU project used GTK+ as a base for GNOME, instead of GNUStep. This basically killed the momentum behind GNUStep as a base for the official GNU Desktop.
It is sad because GNUStep is incredible, the IDEs alone are more advanced than anything in GNOME-space, even today.
Oh well...
deltarholamda · 8h ago
There's a lot of "oh well" in the tech space. I was watching something on Pick OS yesterday, which I hadn't even heard of, which was a kind of filesystem/database/OS all together that was, if the comments on the video mean anything, quite loved.
But like BeOS (also loved) and other things just never got traction for various reasons.
I used Windowmaker for a lot of years as it was lightweight and I liked the UI, and always wondered "why not this? why ape Windows of all things?" The answer is usually something along the lines of "that's what people know," and I get it, but still.
I guess I miss the times when computers were cool.
linguae · 18h ago
I’ve been periodically keeping up with GNUstep’s progress since 2004, when I first learned about it as a high school student brand new to Linux and Mac OS X (I grew up on Windows at home and on classic Macs in elementary school). I even wrote a report for a community college class on the history of Mac OS X.
I’ve wanted to see GNUstep succeed, but unfortunately it never got as much attention as the KDE/Qt and GNOME/GTK ecosystems. I have some theories as to why, but I think the biggest barrier is those who really wanted OpenStep/Cocoa in the 1990s and 2000s could’ve used readily-available NeXT/Apple software instead of waiting for GNUstep. It’s the same issue ReactOS and Haiku have; they’re competing against Windows NT/2000/XP/Server 2003 and BeOS, respectively. Even FreeDOS, which is architecturally much simpler, took quite a while to reach version 1.0; people could just get MS-DOS 6.22.
Of course, the Linux kernel and the GNU ecosystem are counterexamples, though I believe it’s easier to reimplement Unix due to its modular nature than to reimplement entire GUI toolkits, especially if source- and/or binary-level compatibility are required.
A GNUstep that was ready around 1998 or 1999 to capture the attention of former NeXT developers and deliver ports of NeXT software to Linux would’ve been the ideal opportunity, though it still would’ve been quite an effort to bring over other things that made the NeXT special, such as Interface Builder. I’ve noticed that most commercial Mac OS X software in the early days were Carbon applications, not Cocoa applications. Many legendary NeXT software products did not make the transition from NeXTstep/OPENSTEP to Mac OS X. They could’ve had a home on Linux or one of the BSDs via GNUstep had GNUstep been ready.
LeFantome · 17h ago
Actually, GNUstep has always had an Interface Builder:
My own take is actually that GNUstep spent too long trying to be an OpenStep successor instead of being a way to run Mac apps on Linux.
It took them ages to even clarify if it was a desktop environment or an SDK (and I am not sure it is even clear now).
There has never been a tonne of love for Objective C either. Pretty much the only reason to use it for most people has been because you had to for access to Apple APIs. Which would be the only reason to use it on Linux too.
It always amazed me that Darwin + GNUstep did not result in a macOS clone. Neither of them really went anywhere.
I think there was a funding campaign once where a developer offered to re-implement the missing Apple APIs, but since they basically put up a standard salary it didn't reach the funding target.
flomo · 16h ago
> I have some theories as to why
Curious what those might be.
I think might not have been so simple as well "Jobs = Le Bad". There might have been some oldskool unix thinking about linking. (Both commercial and gnu.) And *Step was a dynamic message API, so it "didn't fit their model". Total speculation I have to admit. It also seemed like a commercial dead-end pre-iphone.
Someone · 15h ago
> I’ve noticed that most commercial Mac OS X software in the early days were Carbon applications, not Cocoa applications
I think it’s a safe bet there were many more Mac applications than NeXT applications (that’s one of the reasons Carbon was created), so I don’t see how that’s surprising.
sunshine-o · 15h ago
20-25 years ago, one of the problem GNUStep had is it was never packaged in the Linux distros. You had to compile everything.
One of the reason might have been GCC refused to include the Objective C extensions or something like that. I vaguely remember there might have been some legal concerns.
Maybe someone can clarify this.
But damn GNUStep was fast, snappy and a much better platform than let's say Gnome at the time. There was simply no comparison.
You could take a GNUStep app like Mail.app and just compile in Apple IDE and run it on Mac OS X (but the opposite wasn't possible).
It was one of the most impressive Free Software project out there at the time.
pdw · 14h ago
Debian woody (2002) shipped gnustep. I tried it back then, but as far as I remember, it was weird enough that anybody who didn't have NEXTSTEP experience would bounce right off. The floating menus, the weird scrollbars, etc. There were also no non-trivial applications that I can remember.
People back then were looking for something that would be familiar to Windows/Mac users. GNUStep (at least at the time) was not interested in being that.
<- More recent, native to Debian but runs on other things.
chrsw · 8h ago
Thanks for this. So, if I were to run GNUStep as my desktop, what would I be missing from KDE, GNOME, XFCE, etc?
lproven · 7h ago
Hmmm. Interesting question.
Obviously enough there are not a great many native GNUstep apps. It's Linux, though, so there are a million alternatives, but they won't share GNUstep's look, feel, keystrokes, etc.
It comes with a file manager, both plain text and rich text editors, image viewers, a chat client, a pretty good email app, a terminal emulator (possibly a choice of them too), and GSDE also provides a web browser, although it's a wrapper around Chromium. It works pretty well.
There are lots of programming tools available too, including Gorm, which broadly replicates NeXT's Interface Builder.
I think it's beautiful, myself, but then I consider NeXTstep to be the high-water mark in desktop GUI design thus far.
I find GNUstep's choice of accelerator keys weird and frustrating, though.
I do not run it as my daily driver, but I am thinking about it.
The installation takes a while but it's a `git clone` followed by a few scripts. It's not actually difficult. It took me a few hours but that's because my VM kept crashing.
lproven · 6h ago
I forgot to mention... GNUstep's recommended window manager is Window Maker, which is still alive and in active maintenance with new versions coming out.
There are lots of little Window Maker applets out there to choose from, so you can accessorize your GSDE (or NEXTSPACE) setup with wm-applets and docklets for volume, sound output, mic control, power management, and all those little fripperies that other desktops come with or can do.
A slight limitation is that GNUstep has its own dock and suggests disabling the Window Maker dock, but you can go the other way round and disable the dock provided by GNUstep Workspace and use the WM dock instead.
Also, it is worth mentioning that there is a new entrant in the "GNUstep based desktop environment" race: Gershwin.
I have never played with GNUStep. By the time I actually started real work as a professional software person (2011) it was already kind of considered a joke, so I never bothered learning how to use it.
It bothers me a bit, though. Developing for desktop Linux is still a pain in the ass, and I really wish the Linux community had agreed on One Desktop Framework To Rule Them All, and I think GNUStep could have been that framework if the community had been willing to embrace it.
lelanthran · 9h ago
> I have never played with GNUStep. By the time I actually started real work as a professional software person (2011) it was already kind of considered a joke, so I never bothered learning how to use it.
I dunno if it was a joke or not, but I can confirm that I used Windowmaker as my daily driver from around 2004-ish to 2019-ish.[1]
The only reason I switched, and did not switch back, is due wanting my virtual desktops to be arranged in a 3x3 grid, and Windowmaker did not have that, nor was it on any roadmap.
The thing I miss about my Windowmaker days is how focused it let me be - the entire screen was devoted to a window (or multiple windows); nothing crying out for attention in some bar at the bottom of the screen.
Should I get a few free moments in the near future, I'm tempted to actually add that feature in.
All the other things (taskbar, wifi/sound/etc controls in the taskbar) I can either do without (i.e. I don't need it if I have a decent launcher that is bound to a shortcut), or I can use an existing dockapp.
I think that most active, current Linux users see fragmentation as a good thing, because they absolutely don't want consolidation of power. Many will point to a time when GNOME reigned supreme, and how did they use that power? To repeatedly completely redesign the GUI in ways that the community hated, because "we know better".
There is a much larger group of people who would support "One Desktop Framework To Rule Them All", but they aren't as loud, so they don't get heard.
tombert · 10h ago
Wait, did Gnome ever reign supreme? I feel like there was always a back and forth with Gnome and KDE?
roryirvine · 9h ago
I'd say that the momentum in the 1999-2001 timeframe was almost overwhelming, with a lot of buzz around the likes of Eazel and Helixcode, together with the excitement of Sun choosing it for Solaris.
It was certainly enough to push GNUstep/Windowmaker and Enlightenment into "also-ran" territory.
If Gnome 2 had come out a year before the dotcom crash rather than the year after, I think it probably would have definitively overtaken KDE as well. In the event, it didn't work out that way - and, as you say, KDE did enough to hang on (thanks largely to Konqueror!)
int_19h · 6h ago
KDE was going equally strong at the time though. Anecdotally, it feels like more people were running KDE 2/3 around that time period than Gnome. And while Gnome did get an overall user count boost from becoming the "enterprise Linux DE", that same thing also turned off some people, with projects like Xfce getting a boost. So I wouldn't say it ever really "reign supreme".
pjmlp · 8h ago
Meanwhile many of the folks responsible for those companies are now working with Microsoft and Apple technologies, which kind of tells how much they runned out of steam trying to make a useful GNU/Linux desktop.
wolvesechoes · 15h ago
> Developing for desktop Linux is still a pain in the ass, and I really wish the Linux community had agreed on One Desktop Framework To Rule Them All
Not going to happen. And even if it would happen, very soon there would be a split, because some super important addition to CoC wasn't accepted, or because someone committed a wrongthink on a public platform, or because some patch of snowflake dev superstar was rejected, or whatever else.
Hell, even Microsoft cannot agree with Microsoft on One Desktop Framework To Rule Them All, so it is hard to expect that from the Linux crowd.
pjmlp · 8h ago
At least with Microsoft there is still Win32, with Linux fragmentation not even that, Xlib and Athena are long gone, and aren't full stack as Win32.
LeFantome · 17h ago
The founder of the GNOME project founded Mono to be the “One Desktop Framework To Rule Them All”. It did not work out.
danieldk · 16h ago
That was to be expected, there was a lot of resistance against using C# because Microsoft tried to destroy Linux in various ways. Toolkit-wise, the Mono on Linux stack used Gtk+. So given the C#-distrust it was easier for people to use C, Perl, Python, or later Vala.
qiqitori · 17h ago
But what if that One Desktop Framework To Rule Them All had sucked? :)
wolvesechoes · 15h ago
Definitely wouldn't be worse than multiple desktop frameworks that suck.
const_cast · 7h ago
Current desktop frameworks are quite good. KDE/Qt are incredibly mature at this point. GTK still has a decent amount of churn.
bigyabai · 16h ago
> Developing for desktop Linux is still a pain in the ass
GNOME works great if your language has good bindings for it. Qt is a bit more iffy but still usable if you need cross-platform.
deaddodo · 16h ago
I would argue that it’s heavily in the other direction, having developed fairly extensively in both.
The QT Linux ecosystem is far more cohesive and consistent and QT apps work more seamlessly between KDE, Windows, and MacOS. In my opinion, at least.
smaudet · 16h ago
Agreed. Qt, for all it's flaws, focused on cross platform. Despite getting sold/resold nearly to oblivion, it had a commercial end (some paying customers), and so it received a level of polish that gtk just never did.
Not to mention, when the gtk3 devs went off the deepend, completely broke backwards compat so they could try some new UI...and you couldn't consistently run gtk on Linux...
silon42 · 13h ago
I wish there was a good Rust binding for classic Qt...
cosmic_cheese · 9h ago
It only having first class bindings for C++ and Python is a problem for a lot of folks, though. Plenty don’t want to write either.
SillyUsername · 16h ago
I miss the days of Sun Solaris' CDE desktop.
Afterstep looks too much like Stardock's Window Blinds from around 2000 (see the weird glass effect, font etc), but Etolie seems to nail the aesthetic for me.
I hope this comes back, I'd love to use it on an old netbook I have for accessing my servers remotely.
First, they should move to GitHub or GitLab (or Codeberg) to attract more contributors and make the process of development easier. Maybe it could also be ported to support Wayland and Unicode properly, and remove some legacy code to ease up the maintenance.
jimbosis · 19h ago
Also see this related Cocoa- or GNUstep-based project from some of the same people:
http://coreobject.org/
"Distributed version control + Object persistence"
Works fine if you don't use https, possibly your browser tries that first?
rfl890 · 4h ago
Site's HTTP-only. Shows a warning in Firefox
chris_armstrong · 18h ago
Damn this is a blast from the past - it was such an ambitious project with so many interesting ideas to explore. CoreObject itself was revolutionary in its thinking about distributed document sharing and versioning, let alone some of desktop environment ideas for managing projects.
I know Quentin Mathé, kept CoreObject going for a decade longer, but I haven't heard from the rest of those involved for a very long time.
grahamlee · 15h ago
David Chisnall is now at MS Research and does cool things with CHERI making a computing platform that's memory-safe by default.
bogwog · 6h ago
Man, I love GNUStep. I haven't done anything serious with it, but I did play around with it for a while and enjoyed every second. I event went all-in on WindowMaker for a couple of months lol. It really opened my eyes to how awesome Objective-C is as a language, and almost made me want to become an iOS/Mac developer.
Isn't GNUStep extremely old? I remember seing a webpage before even KDE existed. But I have never seem a GNUStep desktop. Just the window manager, it was popular for a while
guestbest · 7h ago
They had a really good blog with the intricacies for objc, but when swift came out in 2014/5. It all stopped. It’s good to hear that they moved on to to other things, though.
alkonaut · 15h ago
Technically, how does the "every UI action is a commit on a DVCS graph" work? Would every application that is a native étoilé app use this api to construct its UX and document formats? And every app that is not would _not_ have this?
That feels like an ambitious but perhaps misdirected invention of a new paradigm because you'd basically have a native text editor and two other utilities which use it, and then the other five dozen apps would not?
gyomu · 15h ago
Yeah, strong Xanadu vibes: cool philosophical idea in principle, in practice comes with heavy technical requirements + wouldn't be that useful to 90% of users 90% of the time.
lelanthran · 9h ago
I think if you're going to use words with ambiguous pronunciations as your product name you should at least let the reader know what it rhymes with.
That being said, this looks like it could turn into a really cool project.
webworker · 16h ago
We need all hands on deck to bring this back to life
rbanffy · 11h ago
A good first step would be a linter that goes over source code for macOS and flags things that are being used that GNUStep doesn't implement. That would inform the most important missing features for it to allow source portability.
BirAdam · 6h ago
Especially so if this could be built as a FreeBSD/NetBSD system for Apple Silicon...
alephnerd · 19h ago
It makes me glad to see Etoile is still around.
I played around with it in HS when it was in it's alpha stages because I wanted to find a Linux distro that had the same polish of MacOS X and on which I could dev Obj-C. It was a good attempt, but sadly I haven't seen any Linux skin or distro that has solved the UX polish issue.
Edit: never mind, Étoilé did die around the time I thought it did in the early 2010s.
Just one tiny project. The rest of the Etoile codebase hasn't been touched for at least a decade. Ofc it's not the maintainers fault - it's a FOSS project so imo it's bad form to bemoan release cycles if not contributing as projects are hard even if fully funded.
totallykvothe · 19h ago
What are your gripes with Elementary? I personally use KDE now, but I used to use Elementary a while ago, and it was very polished
Shorel · 13h ago
I used it in an old EEE PC laptop because of its lower resource usage compared with Ubuntu.
Elementary is (or was at the time of testing) wasteful of screen real state, there are huge spacers on the toolbars and in a low resolution screen it's just ridiculous.
It could look good and also have sensible design. It only looked good and had IMHO bad design.
alephnerd · 19h ago
Last I played with Elementary (couple months ago), there was a finickiness and latency issue with icons.
Elementary also isn't able to enforce a single unified design pattern the same way Apple is able to from a UX perspective.
Linux distros tend to overindex on power users and cli users (makes sense, given the technical userbase) at the expense of building a user experience that is much more user friendly for nontechnical personas.
cosmic_cheese · 17h ago
> Linux distros tend to overindex on power users and cli users
Funny enough, in my opinion one of the issues holding elementary/Pantheon back is that it’s too much like Gnome in how it prefers bare-faced simplicity over progressive disclosure.
It fades more with every release but I think much of the magic of macOS (both OS X and Classic) is how on the surface it’s simple which makes it palatable and welcoming for non-technical people, but is packed with touches that users pick up over time, effectively turning them into power users. Some of the people who get the most out of thier macs aren’t particularly technical but have just been using macs for their photography business or what have you for the past 20 years and know their way around the OS better than many software developers do. Sometimes they’ve even done a fair amount of script writing and such.
With Gnome and Pantheon, there’s very little of that. What you see is what you get, and after using it for a week you know everything there is to know about it.
actionfromafar · 15h ago
Amen. And a lot of discoverability comes from long term vision and a reluctance to break things. (Yes, I know, Apple breaks some stuff from time to time.) But in Linux land, you can have major UX things change completely from release to release, so that there is no use learning all the intricacies of a user interface, because the rug pull is probably close.
cosmic_cheese · 9h ago
The churn is real. For this reason, I’ve thought for a while now that a DE that intentionally locks its overall design and feature set once it hits 1.0, with 95% of engineering effort being put towards optimization and bug fixes afterwards would do well. A DE that doesn’t unexpectedly change even over the course of many years is massively attractive to many.
Probably the closest to this that exists now are XFCE and Cinnamon, but it’s for the wrong reason (those projects’ lack of resources).
actionfromafar · 15h ago
Elementary was/is perfectly positioned to adopt Objective C and now that Swift is open source, it too.
Ideally it would have adopted gnustep too but I understand that might have been a tall order to get working. But adopting Objective C and now Swift should have been a no-brainer, at least as a first class supported way of interacting with the APIs, if they didn't want to abandon Vala for themselves.
Instead it's become some kind of Vala Purity Contest it feels like.
fuzzfactor · 17h ago
The state of Texas is well-known as the "Lone Star" state, and appropriately enough there is a small town in east Texas known as Etoile, Texas. This is not even that far from the border with Louisiana and some of the unsettled parts of that old French territory.
But they can really tell if you are from around those parts or not, since the correct local pronunciation of the word etoile is of course "yeetaw".
rbanffy · 11h ago
> since the correct local pronunciation of the word etoile is of course "yeetaw".
Some things lose a lot with translation.
bitwize · 14h ago
That's not far from Nakadish (Natchitoches, Louisiana)!
nspattak · 12h ago
can someone please explain to me why is this a HN front page material? this seems to be a long abandoned project
frou_dh · 12h ago
It's an interesting road not taken, where there could have been much more commonality in application development between Linux and OS X.
Seems it also had more lofty goals than just making GNUstep mainstream.
GNUStep lost its opportunity to use D to go further and stuck with old ObjC.
Very good piece of software though.
gnoack · 16h ago
Etoile had its own Smalltalk dialect back in the day, Pragmatic Smalltalk. This was a Smalltalk based on the Objective-C runtime, based on an OMeta implementation and a LLVM backend. David Chisnall, who created it at the time, ended up getting involved more in LLVM in the long run, I believe.
fithisux · 10h ago
Indeed, still gcc objC has not been updated but D which shares a lot in gcc 15 was upgraded to the latest release.
Pragmatic SmalltaLk can still rely on LLVM since there is LDC.
No objection against objC but on windows it is not the best.
D has 3 compilers with similar or beter ergonomics than ObjC
pjmlp · 8h ago
Unfortunately D is still trying to find out what is the killer application that would push for industry's adoption.
Also D semantics have nothing to do with something that builds out OpenSTEP.
Unfortunately Étoilé seems to have been inactive for a decade, and even Apple seems to be abandoning its Xerox PARC influences as the old guard retires and passes away (RIP Steve Jobs, Larry Tesler, and Bill Atkinson). Ever since Apple struck gold with the iPhone and derivative platforms, Apple hasn’t been the same.
I’d like to see the ideas of Smalltalk and Lisp machines revisited for the modern era as a model for workstation-class personal computing. Smalltalk and Lisp environments pride themselves on flexibility and malleability (though it’s understandable to rethink some of these things in an era where security is very important), while mainstream personal computing these days feel less like productivity boosters (remember “the bicycle for the mind”) and more like advertising platforms and anti-competitive, rent-seeking moats.
Haven't those people not had any influence on Apple for a very long time now? Steve has been dead for 15 years, Larry & Bill last worked there ~ 30 years ago.
There's definitely been a "change of the guard" at Apple, but it's not from Xerox PARC people...
Those linguistic foundations take the form of a CLOS-like metaobject protocol, but organized not on OO lines, but rather on software-architectural lines, so including OO as a subset.
On top of the metaobject protocol sits a roughly Smalltalk-ish language, with extensions for dataflow ("!", "?", so CSP-inspired, but not CSP-based, fewer processes) in-process-REST like data access and identifiers (URIs in the language) and last not least component connection (→).
With that, you have a good basis for diverse environments that blend the Smalltalk and Unix/Plan 9 styles.
For taking notes and stuff you'd otherwise do in Jupyter or Livebook, try GT: https://gtoolkit.com/
It's not an OS, but you can just abstract over OS actions within either and keep them as your main interface, similar to how some people rarely leave Emacs.
> I’d spent a lot of the previous years on Étoilé, which was a project to build a user-focused desktop environment that was built out of composable components with end-user programming as a key focus. We were inspired by the STEPS project at VPRI, which tried to build an entire system in under 20,000 lines of code. Our rule was simpler: we aimed to keep individual components to under 10 KLoC, which is small enough that a single person can understand it. This meant that we needed to be able to both use expressive languages and build expressive DSLs. We were starting from an Objective-C base, which gave us a nice model for late-bound components but brought along a lot of C baggage.
> Unlike STEPs, I didn’t want to rewrite the world in high-level languages. I wanted to use things like libavcodec and libavformat as-is, but without bugs in them being able to destroy the invariants that higher-level software depended on. I’d tried building isolation mechanisms with the MMU and found it severely limiting. I’d also looked at Mondrian Memory Protection, but the table-based approach didn’t compose well with language-level abstractions. Early CHERI wasn’t the right thing either, but it was close enough that I felt I could evolve it into the right shape.
> Most of my fingerprints in CHERI ISAs are with that goal in mind. I want to be able to compile existing C/C++ libraries for a CHERI compiler and use them safely from higher-level languages and use them directly. I’ve written a bit about this before:
> https://www.linkedin.com/pulse/i-dont-care-memory-safety-dav...
> I want to be able to have documents embed scripting-language programs that can directly call large native libraries and still have strong guarantees that my system won’t be compromised. The key point is this observation:
> Isolation is easy, (safe) sharing is hard.
> It’s trivial to fully isolate two components. Separate cores, sandboxed processes, or WebAssembly sandboxes can give this kind of isolation, depending on the degree of isolation that you need. Most interesting things are built from communicating components and keeping things mostly isolated, but able to communicate safely, is much harder. For example, Rust says FFI is unsafe, but if you wanted it to be safe except that objects passed from Rust to C may contain arbitrary bit patterns after the call, that’s harder. You can do it with deep copies, but that’s a lot of overhead and very hard to do in the general case. You can do it with CHERI fairly easily, including richer things like deep immutability (in CHERIoT, we can also provide shallow and deep no-capture guarantees).
https://lobste.rs/s/ttr8op/lobsters_interview_with_david_chi...
Saying this as someone that used Afterstep and Windowmaker alongside GNUStep, and did seat a few times on the GNUStep room at FOSDEM.
Last time I checked was at the level of OS X Panther, and modern Objective-C still wasn't supported.
But like BeOS (also loved) and other things just never got traction for various reasons.
I used Windowmaker for a lot of years as it was lightweight and I liked the UI, and always wondered "why not this? why ape Windows of all things?" The answer is usually something along the lines of "that's what people know," and I get it, but still.
I guess I miss the times when computers were cool.
I’ve wanted to see GNUstep succeed, but unfortunately it never got as much attention as the KDE/Qt and GNOME/GTK ecosystems. I have some theories as to why, but I think the biggest barrier is those who really wanted OpenStep/Cocoa in the 1990s and 2000s could’ve used readily-available NeXT/Apple software instead of waiting for GNUstep. It’s the same issue ReactOS and Haiku have; they’re competing against Windows NT/2000/XP/Server 2003 and BeOS, respectively. Even FreeDOS, which is architecturally much simpler, took quite a while to reach version 1.0; people could just get MS-DOS 6.22.
Of course, the Linux kernel and the GNU ecosystem are counterexamples, though I believe it’s easier to reimplement Unix due to its modular nature than to reimplement entire GUI toolkits, especially if source- and/or binary-level compatibility are required.
A GNUstep that was ready around 1998 or 1999 to capture the attention of former NeXT developers and deliver ports of NeXT software to Linux would’ve been the ideal opportunity, though it still would’ve been quite an effort to bring over other things that made the NeXT special, such as Interface Builder. I’ve noticed that most commercial Mac OS X software in the early days were Carbon applications, not Cocoa applications. Many legendary NeXT software products did not make the transition from NeXTstep/OPENSTEP to Mac OS X. They could’ve had a home on Linux or one of the BSDs via GNUstep had GNUstep been ready.
https://www.gnustep.org/experience/Gorm.html
My own take is actually that GNUstep spent too long trying to be an OpenStep successor instead of being a way to run Mac apps on Linux.
It took them ages to even clarify if it was a desktop environment or an SDK (and I am not sure it is even clear now).
There has never been a tonne of love for Objective C either. Pretty much the only reason to use it for most people has been because you had to for access to Apple APIs. Which would be the only reason to use it on Linux too.
It always amazed me that Darwin + GNUstep did not result in a macOS clone. Neither of them really went anywhere.
Have you seen Gershwin?
https://github.com/gershwin-desktop/gershwin-desktop
Curious what those might be.
I think might not have been so simple as well "Jobs = Le Bad". There might have been some oldskool unix thinking about linking. (Both commercial and gnu.) And *Step was a dynamic message API, so it "didn't fit their model". Total speculation I have to admit. It also seemed like a commercial dead-end pre-iphone.
I think it’s a safe bet there were many more Mac applications than NeXT applications (that’s one of the reasons Carbon was created), so I don’t see how that’s surprising.
One of the reason might have been GCC refused to include the Objective C extensions or something like that. I vaguely remember there might have been some legal concerns.
Maybe someone can clarify this.
But damn GNUStep was fast, snappy and a much better platform than let's say Gnome at the time. There was simply no comparison.
You could take a GNUStep app like Mail.app and just compile in Apple IDE and run it on Mac OS X (but the opposite wasn't possible).
It was one of the most impressive Free Software project out there at the time.
People back then were looking for something that would be familiar to Windows/Mac users. GNUStep (at least at the time) was not interested in being that.
NEXTSPACE:
https://github.com/trunkmaster/nextspace
<- Ukrainian so not much development in a while; mainly targets CentOS
GSDE:
https://onflapp.github.io/gs-desktop/index.html
<- More recent, native to Debian but runs on other things.
Obviously enough there are not a great many native GNUstep apps. It's Linux, though, so there are a million alternatives, but they won't share GNUstep's look, feel, keystrokes, etc.
It comes with a file manager, both plain text and rich text editors, image viewers, a chat client, a pretty good email app, a terminal emulator (possibly a choice of them too), and GSDE also provides a web browser, although it's a wrapper around Chromium. It works pretty well.
There are lots of programming tools available too, including Gorm, which broadly replicates NeXT's Interface Builder.
Pic from one of my own machines here:
https://regmedia.co.uk/2023/07/05/deb_11_gsde.jpg
I wrote about it (and Lomiri):
https://www.theregister.com/2023/07/06/two_new_debian_deskto...
I think it's beautiful, myself, but then I consider NeXTstep to be the high-water mark in desktop GUI design thus far.
I find GNUstep's choice of accelerator keys weird and frustrating, though.
I do not run it as my daily driver, but I am thinking about it.
The installation takes a while but it's a `git clone` followed by a few scripts. It's not actually difficult. It took me a few hours but that's because my VM kept crashing.
There are lots of little Window Maker applets out there to choose from, so you can accessorize your GSDE (or NEXTSPACE) setup with wm-applets and docklets for volume, sound output, mic control, power management, and all those little fripperies that other desktops come with or can do.
A slight limitation is that GNUstep has its own dock and suggests disabling the Window Maker dock, but you can go the other way round and disable the dock provided by GNUstep Workspace and use the WM dock instead.
Also, it is worth mentioning that there is a new entrant in the "GNUstep based desktop environment" race: Gershwin.
https://github.com/gershwin-desktop
Currently only available in GhostBSD though.
It bothers me a bit, though. Developing for desktop Linux is still a pain in the ass, and I really wish the Linux community had agreed on One Desktop Framework To Rule Them All, and I think GNUStep could have been that framework if the community had been willing to embrace it.
I dunno if it was a joke or not, but I can confirm that I used Windowmaker as my daily driver from around 2004-ish to 2019-ish.[1]
The only reason I switched, and did not switch back, is due wanting my virtual desktops to be arranged in a 3x3 grid, and Windowmaker did not have that, nor was it on any roadmap.
The thing I miss about my Windowmaker days is how focused it let me be - the entire screen was devoted to a window (or multiple windows); nothing crying out for attention in some bar at the bottom of the screen.
Should I get a few free moments in the near future, I'm tempted to actually add that feature in.
All the other things (taskbar, wifi/sound/etc controls in the taskbar) I can either do without (i.e. I don't need it if I have a decent launcher that is bound to a shortcut), or I can use an existing dockapp.
=======================================
[1] Here's a video: https://www.youtube.com/watch?v=_W_4fH_ccQE
There is a much larger group of people who would support "One Desktop Framework To Rule Them All", but they aren't as loud, so they don't get heard.
It was certainly enough to push GNUstep/Windowmaker and Enlightenment into "also-ran" territory.
If Gnome 2 had come out a year before the dotcom crash rather than the year after, I think it probably would have definitively overtaken KDE as well. In the event, it didn't work out that way - and, as you say, KDE did enough to hang on (thanks largely to Konqueror!)
Not going to happen. And even if it would happen, very soon there would be a split, because some super important addition to CoC wasn't accepted, or because someone committed a wrongthink on a public platform, or because some patch of snowflake dev superstar was rejected, or whatever else.
Hell, even Microsoft cannot agree with Microsoft on One Desktop Framework To Rule Them All, so it is hard to expect that from the Linux crowd.
GNOME works great if your language has good bindings for it. Qt is a bit more iffy but still usable if you need cross-platform.
The QT Linux ecosystem is far more cohesive and consistent and QT apps work more seamlessly between KDE, Windows, and MacOS. In my opinion, at least.
Not to mention, when the gtk3 devs went off the deepend, completely broke backwards compat so they could try some new UI...and you couldn't consistently run gtk on Linux...
Afterstep looks too much like Stardock's Window Blinds from around 2000 (see the weird glass effect, font etc), but Etolie seems to nail the aesthetic for me.
I hope this comes back, I'd love to use it on an old netbook I have for accessing my servers remotely.
https://sparkylinux.org/cde-common-desktop-environment/
For me, it's a bit broken, though; I can't get the terminal to launch, and without that, you can't do much.
I wrote a comparison of CDE and modern recreation NotSoCDE:
https://www.theregister.com/2022/07/28/battle_of_the_retro_d...
A chap I know led the campaign to open-source it and I wrote about it at the time:
https://www.theregister.com/2012/08/09/cde_goes_opensource/
"Distributed version control + Object persistence"
[0] https://web.archive.org/web/20250901123900/http://etoileos.c...
I know Quentin Mathé, kept CoreObject going for a decade longer, but I haven't heard from the rest of those involved for a very long time.
Etoile is dead afaik, but there are some people making another GNUStep-based DE called Gershwin (https://github.com/gershwin-desktop/gershwin-desktop) for GhostBSD.
That feels like an ambitious but perhaps misdirected invention of a new paradigm because you'd basically have a native text editor and two other utilities which use it, and then the other five dozen apps would not?
That being said, this looks like it could turn into a really cool project.
I played around with it in HS when it was in it's alpha stages because I wanted to find a Linux distro that had the same polish of MacOS X and on which I could dev Obj-C. It was a good attempt, but sadly I haven't seen any Linux skin or distro that has solved the UX polish issue.
Edit: never mind, Étoilé did die around the time I thought it did in the early 2010s.
https://github.com/orgs/etoile/repositories
Elementary is (or was at the time of testing) wasteful of screen real state, there are huge spacers on the toolbars and in a low resolution screen it's just ridiculous.
It could look good and also have sensible design. It only looked good and had IMHO bad design.
Elementary also isn't able to enforce a single unified design pattern the same way Apple is able to from a UX perspective.
Linux distros tend to overindex on power users and cli users (makes sense, given the technical userbase) at the expense of building a user experience that is much more user friendly for nontechnical personas.
Funny enough, in my opinion one of the issues holding elementary/Pantheon back is that it’s too much like Gnome in how it prefers bare-faced simplicity over progressive disclosure.
It fades more with every release but I think much of the magic of macOS (both OS X and Classic) is how on the surface it’s simple which makes it palatable and welcoming for non-technical people, but is packed with touches that users pick up over time, effectively turning them into power users. Some of the people who get the most out of thier macs aren’t particularly technical but have just been using macs for their photography business or what have you for the past 20 years and know their way around the OS better than many software developers do. Sometimes they’ve even done a fair amount of script writing and such.
With Gnome and Pantheon, there’s very little of that. What you see is what you get, and after using it for a week you know everything there is to know about it.
Probably the closest to this that exists now are XFCE and Cinnamon, but it’s for the wrong reason (those projects’ lack of resources).
Ideally it would have adopted gnustep too but I understand that might have been a tall order to get working. But adopting Objective C and now Swift should have been a no-brainer, at least as a first class supported way of interacting with the APIs, if they didn't want to abandon Vala for themselves.
Instead it's become some kind of Vala Purity Contest it feels like.
But they can really tell if you are from around those parts or not, since the correct local pronunciation of the word etoile is of course "yeetaw".
Some things lose a lot with translation.
Seems it also had more lofty goals than just making GNUstep mainstream.
https://news.ycombinator.com/item?id=29537538
Very good piece of software though.
Pragmatic SmalltaLk can still rely on LLVM since there is LDC.
No objection against objC but on windows it is not the best.
D has 3 compilers with similar or beter ergonomics than ObjC
Also D semantics have nothing to do with something that builds out OpenSTEP.