Gave an update on #Gershwin Desktop development for #FreeBSD, #GhostBSD, and #Linux in yesterday's #GNUstep meeting. Working super hard to make the desktop welcoming and familiar to switchers from proprietary OSes - but not just superficially. Design, after all, is how it works, not just how it looks. @greg_casamento put up the recording: https://www.youtube.com/watch?v=DDwLzy8map8&t=1000s
Post
Replies:
10
Really exciting. It would be great if someone could take a look at the OpenStep / Cocoa implementations from RavynOS, which would remove the LGPL dependencies from the GUI toolkit and the GOL dependency from the associated daemons. It looks like they support more of the modern Cocoa APIs (and don’t insist on maintaining compatibility with 25-year-old GCC).
@david_chisnall @probono @greg_casamento
Also David it goes without saying I am a huge fan of your work by the way. Between all these projects Nextspace, RavynOS, Darling, Puredarwin each have their own CFNetwork for example. I feel like what Gershwin needs is not do repeat that but convince 100 people to write GNUstep applications so that progress can be made in parallel. Gershwin uses CLANG for all its apps like Workspace BTW. We are modernizing those apps and hope to convince others.
@david_chisnall @probono @greg_casamento
The fact that I could port ladybird from macOS to GNUstep with minimal effort is testament that I know we are doing the right thing and should not get bogged down into trying to make Gershwin more things. Let’s focus on the right things and say no to the rest. Focus is about saying no.
@david_chisnall @probono @greg_casamento
Maybe someday we will have live ISOs that are image based and immutable and apps are all bundles installed in a writable Local Domain and User Domain. Windows users can just grab an exe and go etc. I don’t think we should be core libs, and a desktop environment, and an OS though for these reasons. Let’s lift up GNUstep and bring more developers to it to make the apps.
@david_chisnall @probono @greg_casamento
Also distros like Debian are never going to let us package the right way as “/System”. We use clang and objective C by default. I am thinking beyond distros. I am thinking Gershwin runs on windows runs on anything and the only requirement is a kernel. Distros will choose GCC in packages so we don’t want them or to follow that model hat restrict us from doing it right.
@pkgdemon @david_chisnall @greg_casamento Personally I quite like the setup where the distro manages everything outside of /System and we manage everything inside ourselves. The clear separation allows for some neat features, like running /System from a loop-mounted filesystem image for easiest updating.
@probono @pkgdemon @greg_casamento
I vaguely remember on FreeBSD ensuring that all of the packages GNUstep things installed in /usr/local/System leaving /usr/local/Local for the user. You could also symlink these into the root directory. Because Local had higher priority than System, users could drag and drop things there to replace things installed from packages.
@david_chisnall @probono @greg_casamento
Before I started Gershwin I wrestled with the idea of making a distro. One of my primary goals was to make something that could compete someday with other desktop environments, and also design in way that it could run on nearly any OS, device, and work in immutable environments. I believed it was better to adopt GNUstep since the other efforts didn’t have centralized work and were just reimplementing.
@david_chisnall @greg_casamento Great points David. GNUstep (it has GNU in the name, after all) is LGPL. Are you saying RavynOS wrote a drop-in that is liberally licensed? For new code I write I typically choose 2-clause BSD. Wish we can find a way for all of us to collaborate.
They have implementations of Foundation, AppKit, and several other OS X frameworks. They aren't all from-scratch implementations, they pull in code from a bunch of other permissively-licensed projects.
There's also WinObjC, which is now mostly dead / unmaintained but had a quite complete UIKit implementation. The lineage of this one is quite interesting, it was originally an iOS to Android porting layer so doesn't depend on Windows APIs much. It's pretty clean code (sensible use of Objective-C++ and so on).
