Should be doable to put a Rhapsody theme on it... GNUstep is very flexible in this regard. Thanks to Method Swizzling, themes can change things pretty substantially.
We are on it. The whole UI is going to be overhauled a lot. Would you like to help us get things in shape? AppearanceMetrics.h in gershwin-eau-theme is a start.
Is there anything XAR can do that AppImage cannot?
There are very complex Python applications (e.g., Ultimaker Cura) which are packaged in the AppImage format as self-standing single-file executables, including the Python interpreter, libraries, and other resources.
AnIdiotOnTheNet, I couldn't agree more. Which is why I've started the AppImage project roughly a decade ago. Would you like to join, even if only as an evangelist? Please get in touch with us via GitHub. It's important to spread the word.
I'm a fan of AppImage, a lone island of sanity in the ocean of bad ideas on the Linux Desktop. You were involved with Klik before that right? So it has been more than a decade. And you're not the only one, there's also been efforts like GoboLinux and RoxOS, both of which have been more or less completely ignored by the community, which is why I think the Linux Desktop is unsalvageable.
The Linux Desktop community is simply not culturally ever going to accept a desktop that actually works like a desktop. I can't put my finger on why. Is it dogma? Do they just prefer needless complexity? Do they simply lack the experience to know how awful the system is? I don't know.
Point is, I think the only real way forward is to do what Google did with Android: take the kernel, which is actually pretty reasonable, and put a completely new userland on top of it. Forking some currently existing software may be acceptable in some cases, but the new system should separate itself as much as it possibly can from the currently existing Linux Desktop community. It won't be a Linux distribution, and I think it'd be best to not even mention Linux.
I have done some preliminary work regarding the design of such a system, how its applications would work, completely re-imagining how the filesystem tree works and even what it is for, that sort of thing. But the more discussion I have about ideas in that vein the more I realize that nobody really wants that, they all just want their over-engineered web-kiosk with 1970s-era tooling and sensibilities.
Yes, I started klik about a decade ago, over time evolved and simplified the concept and renamed it to AppImage. Thanks for calling it a "lone island of sanity in the ocean of bad ideas on the Linux Desktop" ;-)
After having heard that "this is not how Linux works", I was about to give up when Linus Torvalds himself gave me the impression that maybe the idea wasn't entirely insane altogether.
As for what should be done, I don't think that doing the 1.001st distribution will make any significant difference. Building a system on top of the Linux kernel that is intended to be a platform might.
But then, building something entirely from scratch would require resources I clearly don't have. So how about this:
1. Take the most popular distribution as the basis (that would be Debian/Ubuntu probably)
2. Determine a set of "Core OS" functionality that is comparable to what Windows and macOS do out of the box, and decide that this will be shipped by the Core OS
3. Use distribution packages to install that Core OS into a filesystem image
4. Uninstall the package manager (because it is a tool for the maintainers of the Core OS, not meant for users)
5. Guarantee that only new APIs/ABIs will be added to the system, existing ones can be considered stable and will deprecated only after 5 years (or so) prior warning
6. Release the Core OS once a year (Core OS 2018, 2019, ...)
7. Apps come as bundles (e.g., Rox-style AppDirs or AppImages)
8. Maybe call the loader (ld-linux.so) differently to intentionally only run applications specifically crafted for this system (debatable)
9. Guarantee 5 years of support for each yearly release
10. Developers are advised to always develop against the oldest still-supported Core OS (e.g., the 5 year old one); i.e., if we introduce a new API today then developers can assume it is "there" for everyone 5 years from now; or else they must privately bundle it (similar to how Android works)
11. Address the Desktop Linux Platform Issues https://gitlab.com/probono/platformissues in this system
12. Address the Desktop Linux Usability Challenges https://medium.com/@probonopd/make-it-simple-linux-desktop-u... in this system (possibly modify a desktop environment like XFCE to be more like the Mac/NextStep in philosophy - without copying it verbatim)
Most of that is similar to what I had in mind. My thought was to go a step further than what could be achieved by simply choosing a base set of packages from an existing distro:
Consider what we currently consider the "filesystem" tree to instead be a "namespace" tree. /dev (device namespace), /proc (process namespace), and /sys (kernel namespace) remain where they are and two new namespaces are introduced: /file (filesystem namespaces), and /app (application namespace). Under /file, volumes are mounted to directories named after them, e.g. '/file/Primary', '/file/Vacation Photos', '/file/Windows', etc. The namespace hierarchy is a tmpfs, real disk space only exists under volumes mounted in /file. /app is any application's own AppDir.
See, each application has it's own namespace like Plan9. When an AppDir is launched, it immediately has its view of the filesystem unshared and a new namespace hierarchy is built for it under /app according to a combination of its own specifications and those imposed by the user. For instance, it may not require /proc, /dev, or /sys, and the user may have restricted it to read-only access to /file, so the new hierarchy under /app is setup accordingly. /app/app is bind-mounted to the AppDir itself, and then the actual application is launched with a chroot into /app (the new namespace we set up for it). Now it can always refer to its own AppDir relative files using /app/* (conveniently the same number of characters as /usr/, for reasons I know you've thought of). Obviously, other Linux namespaces (ipc, network, even user I suppose) can similarly be configured. The isolation portion of this plan is not entirely unlike how firejail can be used with AppImage, but it's the way the system works by default.
This allows a lot of flexibility for compatibility. An AppDir could specify that it uses the (legacy) GNU library set, so it gets a /lib in its namespace that is a bind mount to the system provided GNU libraries (/file/Primary/System/Libraries/GNU, for instance). In fact, you could run an entire linux distribution inside an AppDir this way, and you could setup its net namespace such that it displays in an Xephyr or XWayland window (or some other X server on whatever display system ends up being used). And hey, why not do the same thing for Windows with WINE? Now you have Windows and Linux compatibility layers and they're isolated as much or little as you want.
The AppDirs could also contain multiple binaries. For instance, they could be like "fat" binaries were for MacOS and NeXT where the application came with a binary for each architecture and the appropriate one was launched. Or imagine an office suite, where double-clicking the AppDir might launch the "pick the tool" window, or you could right-click and get a context menu letting you choose which tool you want to run. I was a fan of the old-school Windows Start Menu that was just a menuized view of a folder structure, so lets say that was part of your GUI, then AppDirs with the context menu show those menu items as subitems of the AppDir.
Anyways, that's a sample of the lines of thinking I have on the subject. Like you said, it's a lot of resources for one person to muster. I've gone as far as writing the code to configure application namespaces and launch them, which was shockingly easy, and I started to lay out how the init system would have to work (since it'd be responsible for automounting volumes in /file, setting up networks, feeding firmware blobs to the kernel (ugh), and launching applications at a minimum). But I find it hard to feel motivated because whenever I talk about these ideas I get into long arguments with people who think things are better as they are. I think I'd totally be enthusiastic about working on this system, or something close enough to it, if only I could find the community that actually wants something like that.
App availability makes or breaks every platform. App developers only release stuff for platforms with a large user base, and "Desktop Linux" as a whole is at a mere 2-3 percent at this point. So I think the new system would need to ensure that whatever energy an app developer invests into developing for this platform could be re-used to have the same app run on regular Linux distributions. This is something that would need to be solved...
Also, a large brand name behind it (not necessarily a commercial company and in no case a Linux distribution company) would probably help adoption.
In theory most AppDirs could be run on a normal linux distro with a wrapper script and a package of the base system libraries if certain choices were made (like using wayland instead of a new display server). I'm not opposed to practical compromises, but part of my design goal was to get rid of legacy stuff that doesn't make sense anymore (like the way UNIX handles the file tree) and build a better (and simpler) mousetrap where it was reasonable.
I disagree that it needs to have its applications be runnable on Linux Desktop to work. I think that if you build a system people actually want to use then the applications will come. After all, Linux is a tiny percent of the desktop using population and it still gets targeted just because people are getting kind of sick of the behavior of the companies behind the proprietary OSs. Imagine if people actually wanted to use the Linux Desktop instead of just put up with it.
I think compatibility in the opposite direction is much more important. Like how MS included an XP VM in 7, or Apple included a MacOS Classic VM in OSX, the new system could offer ways of running "legacy" Linux applications to make the switch easier (also Windows via WINE, though with a much lower success rate, and possibly Android via something like Anbox).
There's also this artificial distinction between the uninstalled and the installed form of the same software. Once you have installed it, it is married into a system that makes it very hard to get it out of the running system again and transfer it to another system (unless you kept the debs or hope that they are still online in some repo).
A better system is one in which the archive/installer and the installed instance of a software is one and the same. Such as a Mac .app bundle or an AppImage for Linux.
