I think we pretty much agree with where the problems that I have with Linux Desktop application management largely come from.
> * they still leave us with the same update management problems as I outlined in the Windows case
Not necessarily, there are a lot of ways to go about discovering which applications need updates and where to get them. Off the top of my head: they have a manifest file (or header) that specifies a URL for acquiring the update and the OS maintains a list of paths for every application ever launched to be checked with a single command, as well as optionally being able to search for applications to update.
> * they don't really cover everything application packages or installers are expected to be able to do, like bundle kernel modules, modify the operating system configuration, or set up runtimes for programming languages (this is why you end up with executable scripts that run as root for macOS .pkg installers)
Agreed, but I'm mostly concerned with desktop applications, if that wasn't clear. Such add-on software needs some mechanism of being easily visible to the OS, which probably necessitates something like a fixed path, but I don't think it can't still be self-contained. IIRC Slax did something with AUFS that involved self-contained objects in a special directory that were applied as overlays over the base system at boot and on-demand, which is one way to do it. I think all Haiku packages kinda work like that too.
> * AppBundles can and do have dependencies which are unmanaged
I don't think they should. Or rather, the dependencies that are not part of the base system are considered part of the application and should be contained with it and updated with it. UI toolkits, system interfaces, cryptography, networking, and other such libraries used by a large number of applications should be part of the base system. As you mentioned, part of the problem here is that Linux Desktop has never had a concrete idea of the separation between platform (base system) and application. However, Flatpak kinda does, because it has 'runtimes'. If Flatpak managed the runtimes as it does today, but allowed self-contained portable application folders to run from wherever and use said runtimes, that'd be pretty close to ideal I think.
Out of order because related:
>> * I don't really like the idea of Flatpak applications being distributed as files becoming popular, because I'd rather developers submit their apps to Flathub or somewhere similar so that they're still usable via remote management tools;
Whereas I don't like the idea of developers and users being beholden to the whims of a repo to be able to distribute and consume software conveniently. We may just have to agree to disagree on that one.
>> * and where to draw the line between the runtimes and the application is not clear, since in Flatpak, runtimes can depend on other runtimes. The more you deduplicate, the more you lose the ability to manually manage your application storage. The more AppBundle-like you make Flatpaks, the less deduplication and internal dependency management you can do.
It shouldn't be that hard to find a reasonable balance I don't think. Some duplication isn't really a problem because, as I mention elsewhere, assets are a heck of a lot bigger these days than any binary. Further, many (some would say most) "shared" libraries are only really used by a single application. There are obvious candidates for the 'base system'/'runtime' platform: UI, system interface, networking, cryptography, etc. The problem there with Linux of course is that ABI compatibility is frequently broken in some of these so you'd have to have a bunch of versions to cover everything.
> * real applications often involve multiple bundles, which is one of a few reasons that your tools again have no real uninstall capabilities (take a look at a few Homebrew Cask formulae[0] and you'll see examples of this, e.g., here[1])
See above. To reiterate: I think this is just a poor way to do things. If you have some tightly integrated set of applications they should be managed as a single unit. Think an 'MS Office' application instead of a separate Excel, Word, and Outlook.
> * it's not hugely important, but AppBundles do still result in enormous application/installer downloads, and a base macOS install takes up 2-4x the space it probably could (this is less egregious than on Windows because at least Macs come with a fairly comprehensive set of basic GUI applications)
I don't really use a modern mac and haven't since the early 2000s, but as far as I can tell from using applications in general the actual binary portion of them is usually dwarfed by things like graphics and sound assets, which isn't helped by the traditional package management system anyway. Besides, we're living in an era when people voluntarily bundle an entire goddamn web browser to handle their application's GUI. There's no way native-GUI AppBundles are worse.
> You mentioned that Windows is the desktop operating system you're currently using, so it seems Windows' application management norms must be acceptable to you.
I guess that's one way you could word it. Another one is that Windows does a lot of things wrong, and its application distribution mechanism isn't ideal, but overall the things Windows does wrong don't bother me as much as the things Linux does wrong. As I mentioned in the very first post in this thread though: Windows is rapidly become so bad that Linux might soon be the least-worst choice. When that day happens I will not be any more inclined to like the way Linux Desktop does things, I'll just finally hate Windows more.
> Not necessarily, there are a lot of ways to go about discovering which applications need updates and where to get them. Off the top of my head: [manifest file with a simple registry]
I generally like the centralization and vetting associated with Linux distro repos, but this would be a decent approach for desktop applications that at the very least wouldn't be annoying to use or deal with.
> part of the problem here is that Linux Desktop has never had a concrete idea of the separation between platform (base system) and application
Yeah. I kind of like that Linux is this way but I do see how it is also a problem.
> If Flatpak managed the runtimes as it does today, but allowed self-contained portable application folders to run from wherever and use said runtimes, that'd be pretty close to ideal I think.
I think that could be pretty nice. It would certainly be user-friendly, and it would still allow Linux distros to vary and experiment in all of the ways that they like to vary and experiment.
> we're living in an era when people voluntarily bundle an entire goddamn web browser to handle their application's GUI. There's no way native-GUI AppBundles are worse.
lmao true
> IIRC Slax did something with AUFS that involved self-contained objects in a special directory that were applied as overlays over the base system at boot and on-demand, which is one way to do it. I think all Haiku packages kinda work like that too.
There's a research distro called Distri that does some tricks like this, and I think the design is really good. It doesn't allow hooks and triggers (which I think you'd like) and distributes packages as SquashFS images. It does some union mounting stuff (and I think user namespace trickery) to handle shared dependencies.
There's also GoboLinux, which rethinks the shared global paths in a Mac-ish way that's pretty neat: https://www.gobolinux.org/
Neither is usable as a daily driver or has a sizeable community or anything like that (of course lol).
I do think that for some things, we do need to rethink the FHS, and if we want something that publishers can deal with, we need a clear separation between base system and end user applications on Linux. (We also need that for users who don't want to be system administrators, and who will be surprised and upset that installing what they think of as end user applications can result in dependency conflicts. See the LTT ‘do as I say!’ debacle.)
Imo, some day it would be great to have something like Guix or Nix generate a base system that is made available in what Nix/Guix folks would call an ‘impure’ way, and then for applications to be installable on top via something like Flatpak for desktop applications and an old-fashioned ports system for developer tools. The complexity of tools like Guix and Nix makes sense for distro makers, and sharing dependencies is actually valuable on a base system where you want tight integration. But then publishers and users who don't want to deal with that complexity can use distribution mechanisms like we've discussed, and the door to the packaging system is open for people who want to intervene in the base system instead of just building on top of or alongside it.
I think we will probably get there, very, very slowly.
> * they still leave us with the same update management problems as I outlined in the Windows case
Not necessarily, there are a lot of ways to go about discovering which applications need updates and where to get them. Off the top of my head: they have a manifest file (or header) that specifies a URL for acquiring the update and the OS maintains a list of paths for every application ever launched to be checked with a single command, as well as optionally being able to search for applications to update.
> * they don't really cover everything application packages or installers are expected to be able to do, like bundle kernel modules, modify the operating system configuration, or set up runtimes for programming languages (this is why you end up with executable scripts that run as root for macOS .pkg installers)
Agreed, but I'm mostly concerned with desktop applications, if that wasn't clear. Such add-on software needs some mechanism of being easily visible to the OS, which probably necessitates something like a fixed path, but I don't think it can't still be self-contained. IIRC Slax did something with AUFS that involved self-contained objects in a special directory that were applied as overlays over the base system at boot and on-demand, which is one way to do it. I think all Haiku packages kinda work like that too.
> * AppBundles can and do have dependencies which are unmanaged
I don't think they should. Or rather, the dependencies that are not part of the base system are considered part of the application and should be contained with it and updated with it. UI toolkits, system interfaces, cryptography, networking, and other such libraries used by a large number of applications should be part of the base system. As you mentioned, part of the problem here is that Linux Desktop has never had a concrete idea of the separation between platform (base system) and application. However, Flatpak kinda does, because it has 'runtimes'. If Flatpak managed the runtimes as it does today, but allowed self-contained portable application folders to run from wherever and use said runtimes, that'd be pretty close to ideal I think.
Out of order because related: >> * I don't really like the idea of Flatpak applications being distributed as files becoming popular, because I'd rather developers submit their apps to Flathub or somewhere similar so that they're still usable via remote management tools;
Whereas I don't like the idea of developers and users being beholden to the whims of a repo to be able to distribute and consume software conveniently. We may just have to agree to disagree on that one.
>> * and where to draw the line between the runtimes and the application is not clear, since in Flatpak, runtimes can depend on other runtimes. The more you deduplicate, the more you lose the ability to manually manage your application storage. The more AppBundle-like you make Flatpaks, the less deduplication and internal dependency management you can do.
It shouldn't be that hard to find a reasonable balance I don't think. Some duplication isn't really a problem because, as I mention elsewhere, assets are a heck of a lot bigger these days than any binary. Further, many (some would say most) "shared" libraries are only really used by a single application. There are obvious candidates for the 'base system'/'runtime' platform: UI, system interface, networking, cryptography, etc. The problem there with Linux of course is that ABI compatibility is frequently broken in some of these so you'd have to have a bunch of versions to cover everything.
> * real applications often involve multiple bundles, which is one of a few reasons that your tools again have no real uninstall capabilities (take a look at a few Homebrew Cask formulae[0] and you'll see examples of this, e.g., here[1])
See above. To reiterate: I think this is just a poor way to do things. If you have some tightly integrated set of applications they should be managed as a single unit. Think an 'MS Office' application instead of a separate Excel, Word, and Outlook.
> * it's not hugely important, but AppBundles do still result in enormous application/installer downloads, and a base macOS install takes up 2-4x the space it probably could (this is less egregious than on Windows because at least Macs come with a fairly comprehensive set of basic GUI applications)
I don't really use a modern mac and haven't since the early 2000s, but as far as I can tell from using applications in general the actual binary portion of them is usually dwarfed by things like graphics and sound assets, which isn't helped by the traditional package management system anyway. Besides, we're living in an era when people voluntarily bundle an entire goddamn web browser to handle their application's GUI. There's no way native-GUI AppBundles are worse.
> You mentioned that Windows is the desktop operating system you're currently using, so it seems Windows' application management norms must be acceptable to you.
I guess that's one way you could word it. Another one is that Windows does a lot of things wrong, and its application distribution mechanism isn't ideal, but overall the things Windows does wrong don't bother me as much as the things Linux does wrong. As I mentioned in the very first post in this thread though: Windows is rapidly become so bad that Linux might soon be the least-worst choice. When that day happens I will not be any more inclined to like the way Linux Desktop does things, I'll just finally hate Windows more.