Étoilé – desktop built on GNUStep(etoileos.com)
etoileos.com
Étoilé – desktop built on GNUStep
http://etoileos.com/
115 comments
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:
> 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...
> 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...
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.
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.
This thing about Arcan is that the writing about it is almost deliberately incomprehensible.
There are yt-videos embedded on the site. They may be helpful.
Otherwise give https://lobste.rs/s/w3zkxx/lobsters_interview_with_bjorn_sta... a try?
Otherwise give https://lobste.rs/s/w3zkxx/lobsters_interview_with_bjorn_sta... a try?
Yes, it's good! And I have a lot of sympathy for what I perceive to be Stahl's goals, and indeed, his methods. But I think I need an intercessor or interpreter to his prose style. This is probably a me problem and not a him problem, to be maximally fair.
Björn's writing style is intentional. He tries to make it understandable for people that have deeper understanding of the subject, but to keep out the people that doesn't know enough. It's primarily to convey what Arcan is to the people that can do something with Arcan, but to avoid attention that will ultimately lead to flame wars.
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)
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)
Oh man, that's awful.
I love the ideas of Smalltalk and Lisp machines too. Do you know of anything promising in that area? (other than Ink & Switch)
Are you using Pharo already? If not, give it a go: https://pharo.org/
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.
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.
> 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...
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...
Yep, the comment you're replying to is off by a few decades
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.
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.
last time i was looking into this to try myself i never bothered to to check github but today i looked and there it is:
https://github.com/mpw/Objective-Smalltalk
i hope to give this a try soon and learn something new ^^
https://github.com/mpw/Objective-Smalltalk
i hope to give this a try soon and learn something new ^^
Sounds nice, but back in the day I couldn’t get it to work…
Not loading for me. Here's an archive mirror [0].
[0] https://web.archive.org/web/20250901123900/http://etoileos.c...
[0] https://web.archive.org/web/20250901123900/http://etoileos.c...
Also see this related Cocoa- or GNUstep-based project from some of the same people:
http://coreobject.org/
"Distributed version control + Object persistence"
"Distributed version control + Object persistence"
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.
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.
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
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.
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.
> 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.
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.
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.
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).
Probably the closest to this that exists now are XFCE and Cinnamon, but it’s for the wrong reason (those projects’ lack of resources).
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.
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.
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.
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.
There were commits in 2024:
https://github.com/orgs/etoile/repositories
https://github.com/orgs/etoile/repositories
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.
[deleted]
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.
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 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.
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.
Actually, GNUstep has always had an Interface Builder:
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
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
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.
> 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).
Yes they still have no idea what they are trying to do.
Yes they still have no idea what they are trying to do.
>It took them ages to even clarify if it was a desktop environment or an SDK
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.
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.
> 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.
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’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.
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.
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.
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.
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.
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.
Anyone interested in trying NeXTStep, it's included on <https://infinitemac.org/>
I also advise reading through the manuals at https://www.nextop.de/ while they exist, or save local copies.
I have started an ArchiveBot job for this website, so the site and all the pages it links to will be on web.archive.org for future viewing. Should be up in a few days to a week.
https://wiki.archiveteam.org/index.php/ArchiveBot
https://wiki.archiveteam.org/index.php/ArchiveBot
Be aware that these are built on very barebones disk images compiled by a community member many years ago; the NeXT community is working on more tourist-friendly packages that we hope to offer to Mihai soon.
The current best GNUstep distro is WMlive: https://sourceforge.net/projects/wmlive/
It's based on Debian Bookworm.
It's based on Debian Bookworm.
Glad you like it and thanks for the recommendation!
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
[2] https://github.com/onflapp/gs-desktop
[3] https://news.ycombinator.com/item?id=44640378
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
[2] https://github.com/onflapp/gs-desktop
[3] https://news.ycombinator.com/item?id=44640378
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...
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.
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.
The other main issue is that GNUstep is incredibly bug prone and fragile. Case in point, two years ago i installed GNUstep from source and then built a pixelart editor called PikoPixel. The app felt very clunky, like all GNUstep apps do (note that i'm using Window Maker as my main WM so GNUstep gets the best environment it can hope for). Then two years later with some OS updates in between it doesn't work anymore.
Meanwhile i'm still using the same mediaplayer binary i built ~7 years ago on a different computer against a C GUI library.
Meanwhile i'm still using the same mediaplayer binary i built ~7 years ago on a different computer against a C GUI library.
It's also an example of how stubborn people can ruin a project. While it's nice to see the old NextStep GUI, it's from the 1990's. They never made any effort to improve. They never made any effort to integrate nicely into the rest of the Linux world. They never made any effort to add new Objective-C features.
Its entirely stagnated.
Its entirely stagnated.
Microsoft tried to replicate the iOS libraries and everything with project Islandwood. It was a valiant effort but that moment (iOS 5->6->7) was a major time of upheaval for iOS libraries and they matured and this project was ultimately canceled.
https://github.com/Microsoft/WinObjC
https://github.com/Microsoft/WinObjC
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.
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.
But what if that One Desktop Framework To Rule Them All had sucked? :)
Definitely wouldn't be worse than multiple desktop frameworks that suck.
It definitely would be.
Choice is a defining factor in freedom.
Choice is a defining factor in freedom.
Current desktop frameworks are quite good. KDE/Qt are incredibly mature at this point. GTK still has a decent amount of churn.
The founder of the GNOME project founded Mono to be the “One Desktop Framework To Rule Them All”. It did not work out.
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.
> 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.
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.
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.
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.
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...
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...
I wish there was a good Rust binding for classic Qt...
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.
> 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.
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.
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.
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.
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.
Wait, did Gnome ever reign supreme? I feel like there was always a back and forth with Gnome and KDE?
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!)
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!)
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.
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".
Never fully, but it's how we got systemd nearly everywhere - GNOME 3.8 arrived with support for polkit-based approach for, among other things, power management, and mandated logind. Which at the time was very much a banana that required the gorilla and the whole jungle to run. Some tried to deal with it, some managed to even separate udev and logind out, but the immediate effect was that distributions that avoided systemd or made it optional - including ones that were exploring alternative paths, were forced to adopt systemd or remove support for GNOME 3.8 and newer.
> 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.
=======================================
[1] Here's a video: https://www.youtube.com/watch?v=_W_4fH_ccQE
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
You might like something like i3 (if using X) or Sway (if using Wayland), or another tiling manager like Xmonad.
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
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
WindowMaker certainly was quite popular for a while, probably also because it can be used without GNUstep, just as a plain X11 window manager.
Actually, it has its own toolkit named WINGs. Which stands for WINGs is not GNUstep ;)
https://www.windowmaker.org/docs/wings.html
Actually, it has its own toolkit named WINGs. Which stands for WINGs is not GNUstep ;)
https://www.windowmaker.org/docs/wings.html
GNUStep lost its opportunity to use D to go further and stuck with old ObjC.
Very good piece of software though.
Very good piece of software though.
Or Swift
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.
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
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
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.
Also D semantics have nothing to do with something that builds out OpenSTEP.
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.
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.
David Chisnall is now at MS Research and does cool things with CHERI making a computing platform that's memory-safe by default.
A previous discussion in 2021:
https://news.ycombinator.com/item?id=29537538
https://news.ycombinator.com/item?id=29537538
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".
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".
We need all hands on deck to bring this back to life
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.
Especially so if this could be built as a FreeBSD/NetBSD system for Apple Silicon...
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.
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.
CDE was open sourced a while back: https://sourceforge.net/projects/cdesktopenv/
CDE is included as one of the options in Sparky Linux:
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/
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/
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.
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?
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?
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.
can someone please explain to me why is this a HN front page material? this seems to be a long abandoned project
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.
Seems it also had more lofty goals than just making GNUstep mainstream.
Relevant -- there are 2 other desktop environments built on GNUstep that are in more active maintainance.
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.
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.
Thanks for this. So, if I were to run GNUStep as my desktop, what would I be missing from KDE, GNOME, XFCE, etc?
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.
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.
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.
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.
https://github.com/gershwin-desktop
Currently only available in GhostBSD though.
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.
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.
That being said, this looks like it could turn into a really cool project.
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.
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
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.
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.
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.
I remember trying to get this to work in 2008 or 2009 or something and still failing. I'm amazed the website is still up.
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.