> 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.
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.
https://michael.stapelberg.ch/posts/2019-08-17-introducing-d...
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.