3 ms·

> [T]he Linux community abhors the concept of managing applications like they were just regular files and prefers complicated tooling, gigantic databases of dep

by pxc 5y ago

> [T]he Linux community abhors the concept of managing applications like they were just regular files and prefers complicated tooling, gigantic databases of dependencies, and armies of maintainers. > Flatpak is gaining ground, which is better than continuing with the current paradigm as far as I'm concerned, but it is still worse than the simple way things were done in saner desktop operating systems. (and from your other comment:) > Application management on Linux is already complicated enough without having to learn a new language to use it effectively. 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. You are absolutely correct that people using such a system are loathe to return to the fundamentally unmanageable anarchy of a system like Windows, where * every installer does basically whatever the hell it wants; * you can never really be sure that an uninstaller does its job; * much software simply cannot be installed or uninstalled non-interactively; * managing non-interactive installation for apps which DO support non-interactive management is often achievable only through some bespoke process; * every single fucking program feels entitled to litter your system with its own bespoke auto-update mechanism (sometimes one that runs in the background constantly!); * a brand new system with virtually no desired application software takes up 20-40 GiB, instead of 4-8 GiB; * it is difficult to even *discern* whether or not the whole system is up to date, and bringing a system up to date requires several manual processes; * even in the year of our lord two-thousand and twenty one, whole system installs mysteriously become slow after a few years so that they must either be reinstalled (the only sure-fire way) or treated with a laborious, manual cleanup process just to achieve sane, normal performance again. Software management on Windows is absolutely riddled with problems that are hugely minimized by traditional Linux package managers and can be more or less totally eliminated by more innovative ones. People who are already using Linux are opposed to your proposition because we've been there on other operating systems and you are asking to drag us back to hell. Flatpak isn't a 'step in the right direction' which will eventually take us to the manual, repetitious, chaotic, redundant mess of managing software on other operating systems. It's a fundamental improvement over that model, because it retains * very good deduplication of shared runtimes via OSTree; * easy management by automatic tools; * conventional and technical constraints on what applications can do to set themselves up; * a single central interface for software distribution; * a more complete specification of the dependency chain, unlike the implicit and unspecified dependencies on various Windows components from different eras that cause the base Windows installation (even without any applications) to grow and grow and grow. Flatpak is not going to give those things up, and if it did it would not be 'advancing'. > > > standard in Linux Desktop application distribution > > There is no such thing. There never has been, and there never will be :P > Did I mention the other thing I hate about Linux Desktop? It's community. 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. :)

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

by pxc 5y ago

AnIdiotOnTheNet 5y ago

> 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...