3 ms·

> Linux is the only system (maybe now FreeBSD, if they've completed the migration to a packaged base system yet) where every single piece of software on a compl

> Linux is the only system (maybe now FreeBSD, if they've completed the migration to a packaged base system yet) where every single piece of software on a complete and usable system can be managed uniformly with a single set of automatic tools. Only the software that has been painstakingly packaged for that particular version of that particular distribution can be managed by said tools. This is one of its biggest flaws and part of the reason Flatpak even exists. You rightly describe a lot of problems with the installer mechanism of traditional Windows, which is not what I am advocating for[0]. I'm advocating for something more like original Mac applications, or RiscOS AppDirs, or NeXT/current MacOS Application Bundles, or just folders with files in them in DOS, or you know, AppImage. Single object applications that can be copied, deleted, and moved the same as any file without a bunch of special tooling. I contend that the need for special tooling is to work around an overly complicated model, not inherent to the problem space. > This is how you react to playful commiseration about the difficulty of coordinating unification between independent, distributed, democratically managed volunteer projects? Please, I urge you in the strongest possible terms: continue using Windows exclusively, forever and ever. :) When someone asks me about my use case for features for the sole purpose of being pedantic and telling me things I already know that are entirely useless and that I have heard variations of for twenty goddamn years while literally using an emoji that represents a human face sticking it's tongue out... well let's just say I'm not inclined to have a high opinion of them. Frankly, there's good reason Linux is in a distant third place as a Desktop OS, despite how much Windows sucks, and it isn't because it provides a seamless experience and its community is so helpful and welcoming. [0] It's weird that when you criticize something in Linux Desktop, for some reason its proponents always go all whataboutism on Windows.

pxc 5y ago
> Only the software that has been painstakingly packaged for that particular version of that particular distribution can be managed by said tools. This is one of its biggest flaws and part of the reason Flatpak even exists. Yes, that's true. This is a pretty marginal problem for F/OSS-oriented end users of distros with large package repositories, and that's probably why it's not a problem that gets the kind of focus you'd like to see within the Linux community. My needs are well-served by the package management model, and I don't use very much proprietary software, so for me personally, it feels very worth it to package whatever new hotness I need on my system and retain the management benefits of the package manager. But 98% of end users (even fairly technical end users) don't want to package any software themselves, and it's not really possible for third parties to do so properly with proprietary software. (Although you can find many examples of shoehorning proprietary binaries into normal-ish packages in the AUR and in Nixpkgs.) The fact that ‘Linux’ is not really an OS platform is a real problem for publishers who might want to release software on the Linux desktop. > You rightly describe a lot of problems with the installer mechanism of traditional Windows, which is not what I am advocating for[0]. I'm advocating for something more like original Mac OS applications, or RiscOS AppDirs, or NeXT/current MacOS Application Bundles, or just folders with files in them in DOS, or you know, AppImage. AppImage has one big problem, which is that it basically just assumes but doesn't specify a fairly large base runtime. This is a serious portability problem, and it's why AppImages are not usable in their intended way on systems like NixOS and GuixSD, and instead require a wrapper/launcher. Flatpak doesn't share this problem because its design involves a launcher program that can be wrapped or provided with a special environment, and it's designed to more fully encode the runtime dependencies of apps packaged for it. (In principle, Snap is the same way, but I doubt it'll ever be packaged in Guix due to the proprietary server-side code and I just don't think there's much interest in it on the Nixpkgs side.) This could be solved by standardization, but I have to agree that that is very unlikely to happen. Of the examples you give, macOS ≥10 application bundles are the only ones I've really used. Maybe this is nitpicking, but I don't think macOS .apps are a great model because * they still leave us with the same update management problems as I outlined in the Windows case * 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) * AppBundles can and do have dependencies which are unmanaged * 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]) * 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) To get decent software management on macOS, you end up having to build automation on top of the AppBundle system, and what is required for every package can be totally custom. Homebrew Casks are neater than something like Chocolatey, but they're essentially the same kind of wrapper around custom install tools which come from publishers and can basically do whatever they want. (Casks get to be neater and faster because the AppBundle design almost works, so most .pkg installers only do a few extra things around the edges.) Something like Flatpak can address the problems with AppBundles in a way that clones like AppImage can't. That said, this: > Keep runtimes in "installations" and let applications exists as single-directory self-contained units wherever the user wants them. What is fundamentally difficult about this? basically sounds okay to me and I don't see why it couldn't be done. But there are two problems (for me, at least): * 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; * 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. I'm not sure those problems are fatal, though. You could probably have something pretty good that lets you distribute Flatpaks as files, if you want. > It's weird that when you criticize something in Linux Desktop, for some reason its proponents always go all whataboutism on Windows. 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 thought about including a section about the case on macOS (similar to the one in this comment), but I didn't do so because you mentioned Windows and not macOS in your original comment here. ————— 0: https://formulae.brew.sh/cask/ https://formulae.brew.sh/cask/ 1: https://github.com/Homebrew/homebrew-cask/blob/HEAD/Casks/adobe-air.rb https://github.com/Homebrew/homebrew-cask/blob/HEAD/Casks/ad...
- AnIdiotOnTheNet 5y ago
  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.

pxc 5y ago

> Only the software that has been painstakingly packaged for that particular version of that particular distribution can be managed by said tools. This is one of its biggest flaws and part of the reason Flatpak even exists. Yes, that's true. This is a pretty marginal problem for F/OSS-oriented end users of distros with large package repositories, and that's probably why it's not a problem that gets the kind of focus you'd like to see within the Linux community. My needs are well-served by the package management model, and I don't use very much proprietary software, so for me personally, it feels very worth it to package whatever new hotness I need on my system and retain the management benefits of the package manager. But 98% of end users (even fairly technical end users) don't want to package any software themselves, and it's not really possible for third parties to do so properly with proprietary software. (Although you can find many examples of shoehorning proprietary binaries into normal-ish packages in the AUR and in Nixpkgs.) The fact that ‘Linux’ is not really an OS platform is a real problem for publishers who might want to release software on the Linux desktop. > You rightly describe a lot of problems with the installer mechanism of traditional Windows, which is not what I am advocating for[0]. I'm advocating for something more like original Mac OS applications, or RiscOS AppDirs, or NeXT/current MacOS Application Bundles, or just folders with files in them in DOS, or you know, AppImage. AppImage has one big problem, which is that it basically just assumes but doesn't specify a fairly large base runtime. This is a serious portability problem, and it's why AppImages are not usable in their intended way on systems like NixOS and GuixSD, and instead require a wrapper/launcher. Flatpak doesn't share this problem because its design involves a launcher program that can be wrapped or provided with a special environment, and it's designed to more fully encode the runtime dependencies of apps packaged for it. (In principle, Snap is the same way, but I doubt it'll ever be packaged in Guix due to the proprietary server-side code and I just don't think there's much interest in it on the Nixpkgs side.) This could be solved by standardization, but I have to agree that that is very unlikely to happen. Of the examples you give, macOS ≥10 application bundles are the only ones I've really used. Maybe this is nitpicking, but I don't think macOS .apps are a great model because * they still leave us with the same update management problems as I outlined in the Windows case * 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) * AppBundles can and do have dependencies which are unmanaged * 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]) * 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) To get decent software management on macOS, you end up having to build automation on top of the AppBundle system, and what is required for every package can be totally custom. Homebrew Casks are neater than something like Chocolatey, but they're essentially the same kind of wrapper around custom install tools which come from publishers and can basically do whatever they want. (Casks get to be neater and faster because the AppBundle design almost works, so most .pkg installers only do a few extra things around the edges.) Something like Flatpak can address the problems with AppBundles in a way that clones like AppImage can't. That said, this: > Keep runtimes in "installations" and let applications exists as single-directory self-contained units wherever the user wants them. What is fundamentally difficult about this? basically sounds okay to me and I don't see why it couldn't be done. But there are two problems (for me, at least): * 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; * 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. I'm not sure those problems are fatal, though. You could probably have something pretty good that lets you distribute Flatpaks as files, if you want. > It's weird that when you criticize something in Linux Desktop, for some reason its proponents always go all whataboutism on Windows. 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 thought about including a section about the case on macOS (similar to the one in this comment), but I didn't do so because you mentioned Windows and not macOS in your original comment here. ————— 0: https://formulae.brew.sh/cask/ https://formulae.brew.sh/cask/ 1: https://github.com/Homebrew/homebrew-cask/blob/HEAD/Casks/adobe-air.rb https://github.com/Homebrew/homebrew-cask/blob/HEAD/Casks/ad...

AnIdiotOnTheNet 5y ago
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.