homebrew-cask

itors/viewers, but I'll keep MarkNote around for when I need to search through my MD files.

d for them, but gives me no way to trace back to any file in https://github.com/flutter/flutter/tree/3.24.4

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/ 1: https://github.com/Homebrew/homebrew-cask/blob/HEAD/Casks/ad...