Étoilé – desktop built on GNUStep
etoileos.com
etoileos.com
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.
and for the computer also.
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.
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...
> 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...
Otherwise give https://lobste.rs/s/w3zkxx/lobsters_interview_with_bjorn_sta... a try?
Ståhl _hates_ attention, both from being a quite private individual to having problem with weirdos showing up at his apartment when some of his videos have gone viral here on HN. (Everyone's home addresses are public here in Sweden)
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.
https://github.com/mpw/Objective-Smalltalk
i hope to give this a try soon and learn something new ^^
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.
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?
Yes they still have no idea what they are trying to do.
Yes. In my eyes it’s both. I mean that in a good way, relative to the way Oberon is both an OS and a language or that Smalltalk is both a language and its authoring environment. Or how Bash is an interactive command shell and a language.
Some people might not like that tight coupling, but sometimes it can be really powerful.
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.
It's based on Debian Bookworm.
Nonetheless, being the maintainer of this project, i'd like to point out that this is no dedicated GNUstep distro, but a mostly Debian based distribution using a thoroughly preconfigured Window Maker as its primary user interface, and that just happens to have the whole range of available GNUstep applications added on.
As already written elsewhere[3], citing my own words, this is a better characterization of its scope:
»Window Maker is just a highly compatible X11 window manager and is supposed to work as such. There is no interest to specifically integrate it with the provided GNUstep applications, as this is not supposed to be predominantly a GNUstep desktop. The included GNUstep applications are just an addon to give people a practical way to verify what GNUstep has to offer. In fact, wmlive would be perfectly usable without providing any single GNUstep application. The freedom and flexibility provided by an X11 window manager instead of the walled garden of a specific desktop system is much more preferable to many Linux users. NeXT nostalgists might want to look elsewhere. [1][2]«
People who's interest has been sufficiently piqued to download wmlive are advised to better wait until after Debian's bookwom 12.12 point release this saturday. A final bookworm based wmlive release will be uploaded shortly after. This will also be the last and final 32bit i386 variant of wmlive. After that work on an exclusively amd64 trixie based wmlive variant will begin.
[1] https://github.com/trunkmaster/nextspace
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.
Meanwhile i'm still using the same mediaplayer binary i built ~7 years ago on a different computer against a C GUI library.
Its entirely stagnated.
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.
Choice is a defining factor in freedom.
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...
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.
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!)
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
They are extremely minimal and really get out of your way. I had to write my own service to power the info on the Sway bar [1] because the entire thing is so minimal.
For me, I have title bars in windows disabled, and the gap between different windows is literally 1 pixel.
[1] First version: https://github.com/tombert/swanbar Rust rewrite: https://github.com/tombert/rs-swanbar
Actually, it has its own toolkit named WINGs. Which stands for WINGs is not GNUstep ;)
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.
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.
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.
"Distributed version control + Object persistence"
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.
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:
[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 being said, this looks like it could turn into a really cool project.
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?
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.
Seems it also had more lofty goals than just making GNUstep mainstream.