One of the strong points of Linux has always been how solid the experience of installing and managing software is. Contrarily to what happens in the Windows and macOS world, software on Linux is obtained through something called a package manager, a piece of software that manages any piece of software the user installs, as well as its dependencies, automatically.
↫ Luca Bramè at Libre.News
It truly is. I can’t imagine using any operating system that relies (almost) exclusively on me going out to individual websites to download random installers or disk images, all with their own unique update mechanisms I need to keep track of, that eat up resources and interrupt my workflow. The combination of Fedora’s repository’s with the odd Copr or Flatpak package – all managed transparently through KDE’s Discover – is effectively perfect. I never have to manually install anything, nor do I ever have to rely on tarballs like back in the dark ages.
Dealing with a Windows or macOS machine is a nightmare compared to this. Managing applications on those operating systems feels hopelessly archaic and outdated, and I have no idea how users tolerate that kind of nonsense. They’ve got a dozen or more updaters running in the background, cluttering up the system tray and eating resources, or whenever they open an application they get an annoying popup interrupting their work to ask them to update. It’s barbaric and user-hostile, and nobody should be dealing with that in 2025.
It’s also highly unlikely things will ever improve for Windows or macOS users, since any attempt to bolt a package manager into them invariably fails. The official Windows and macOS application stores have been abject failures in more ways than one, and tools like winget are just glorified download managers that run regular installers in silent mode – incredibly crude and only really good for batch-downloading some installers.
The Linux world is far from perfect, but they nailed application management early on, and the competition has basically sat still ever since.
macOS applications are distributed as disk images, mount the image, drag it to your Applications folder to install. Uninstalling it involves dragging the application from Applications to the trash. I’m not sure what the problem with this process is.
Read both the linked article, and the article here. They both expressly detail the problems. It is generally good etiquette to read before commenting!
I did. My point still stands.
Download, install, use, uninstall. That experience cannot be topped. Not by package managers, not by app stores, not by anything.
> Downlooad, install, use, uninstall.
That might work OK for one-time use and assumes that the uninstall does actually remove everything it installed from the filestore/registry (you’d be surprised how many times it doesn’t). What if you use the app over a long period before you uninstall? How do you get updates for that app, especially if it isn’t a Microsoft product on Windows? As the article said, there’s no central mechanism for updating non-Microsoft software on Windows – everyone re-invents the wheel w.r.t. updaters (or don’t even include any way to update it at all!).
I know in the final few years of running Windows in my dual-boot system, most of my time was spent in Windows just going around updating every app in a myriad of different ways – a horrendous process as the article points out. Microsoft dropped the ball big time by not opening up Windows Update to all apps and having the idea of repos for each org/company that could be easily added (those repos wouldn’t necessarily have to be hosted by Microsoft either [because you know MS would charge for such hosting]).
If your goal is to install ransomeware and crypto-miners, yeah — that experience is top of the line.
Brainworm,
That’s a valid point that web downloads can be trojaned. Unfortunately I’ve been finding this to be the case even on official websites for software I trust like putty and filezilla. The advertisements on their websites are so well crafted to mimic official downloads that I have to confess I’ve been tricked by them. It’s not until I tried using the downloads that I discovered my mistake and sure enough google was serving malware ads on the official websites.
So I have to concede your point, however the assumption that one can’t get malware from app stores doesn’t always hold water either. Apple and google run automated tests that are easy to trick and they don’t have the manpower to actually audit every submission. Malware can and does get through.
https://decrypt.co/304595/crypto-stealing-malware-google-apple-apps
The advice, though sensible, doesn’t really give confidence in the system. Centralized app stores and repos are not a fix-all. Being selective runs counter to their business models and they end up moving the security threats into the walled garden.
IMHO mainstream platforms need better tools for sandboxing & auditing untrusted software, but it sort of runs contrary to the idea that we can simply trust everything from google/apple/microsoft/steam app stores.
@RumblePony
First, the macOS model is available on Linux. It is called AppImage. If you want to put your app on a website where Linux users can download it and run it like with macOS, AppIMage is there for you.
Second, your fourth word is “distributed”. How are Mac apps “distributed”? Not via a package manager. Distribution is one of the core problems what a package manager addresses. Does that help you see the difference?
Finally, what this article is about is the idea of “universal package management” which is the idea of creating packages which will install and run on any system. Flatpak installs its own runtime which is executed in a container. This allows a Flatpak app to install and execute on any system that supports Flatpak. This includes not only just different distributions (Ubuntu vs Chimera Linux let’s say) but also distributions that are much older or newer than the dependencies that the application distributor is relying upon. Using Flatpak, I can painlessly use the latest release of an application on Debian Stable or RHEL7 for example.
To make that last point in the context of macOS, RHEL7 was released when macOS 10.9 (Mavericks,) was current. With Flatpak, I can install an app released yesterday, which uses totally up-to-date libraries, on RHEL7 as noted above. Can I install current versions of macOS software on Mavericks using the method you describe? Microsoft Office requires 10.12 (Monterey). Microsoft Teams requires macOS 13 (Ventura). Google Chrome requires 11 (Big Sur). Even the GIMP requires Big Sur. Since Big Sur, 32 bit apps will no longer run on macOS. Flatpak will install 32 bit apps (like Steam) on any system that supports Flatpak, even if the base distro no longer supports 32 bit natively.
The tech in Flatpak is similar to Docker. So, there is no reason you could not port Flatpak to macOS. If you did that, you could use Flatpak to install any app from Flatbub and it could work on any version of macOS. Both distribution and compatibility would be solved problems vs the approach used on macOS today.
I call BS on this and linked article…
1) you have brew on macOS which is just brilliant most of the time (use it exclusively for ~10 years and guess what – I don’t have to run over the internet to search for apps) and this passage is just utterly false/ignorant or outright FUT
> The situation is a little better on macOS. You can install Homebrew, a package manager that allows you to much more easily manage a development environment. Sadly, though, Homebrew has its limits: it cannot, and it will not, update system components, and it does not contain every program under the sun. It is mostly useful for the purpose of setting up a development or DevOps environment, but it still does not free you from having to install most software manually.
2) you claim that flatpack is amazing – you know what? it’s what apple been doing for ages now 😛 and you have brew/cask so it’s basically the same stuff
It’s funny claiming that linux/flatpack is superior when it’s trying so hard to mimick bundled .app from macos and is stilll doing so-so job xD Not to mention other complain in the same regard from (1) where “they don’t allow to modify system binaries — guess what? linux is trying very hard to go the same way with atomic distros because upgrading individual binaries quite often leads to gigantic ef-ups xD
Flatpak is much more advanced than MacOS .dmg/.app, as someone who uses both. Flatpak uses the same Linux kernel sandboxing techniques as Docker does – cgroups and namespaces. Mac bundles are much more like Snaps where you have a disk image that gets mounted as a directory. And yes, you can install a flatpak from offline media these days.
You seem to think that brew/homebrew is a native part of macOS that comes with the OS and is Apple’s preferred way of installing software. It doesn’t, and it isn’t. Nearly all Linux distros and the BSDs have a package manager that is integrated in the distro and officially supported by it. On the other hand, macOS has Apple’s App Store as an officially supported and fully integrated application management system, and the ability to drag and drop .app files is separate from the App Store and .pkg installers for macOS.
You’re also wrong about Flatpak mimicking macOS’s .app paradigm; Flatpak is more similar to homebrew than anything else. Now Appimages, on the other hand, are basically the same concept as the macOS .app package; download the .appimage, make it executable, and double click it to launch. To delete the application just delete the .appimage file.
You seem to project your idea of what I’m thinking and assume your interpretation is correct… Sadly I can’t help with that…
I never stated that homebre is oficial or preferred. In general everything boils down to history and previous problems and decisions. Apple preferred static linking and *nix world dynamic linking (I guess smaller app size which made delivery easier especially in the context of central repo and possibly security implication – if there is a bug in a lib then it’s enough to update only that lib); but then it cause proliferation of repositories in distributions because you couldn’t sanely distribute your application because beloved NotInventedHere resulted in each distro being even so slightly different with own quirks. So the only option was to actually have central repo and rebuild everything ad nauseum 😀
As for flatpacks mimicking app paradime – it’s basically that – a shift towards bundled, statically linked, complete apps that could be easily distributed and installed easily on all supported platforms/distributions. That they have flathub as central repo for it? whatever – anyone can host a flatpack on their own website and install on their desired distro without worring that provided deb/rpm is not supported by their distro or their distro repo lacks required dependencies…
You were comparing brew/homebrew on macOS to the default, native, shipped-with-the-distro package manager on a given Linux distribution. They are not the same thing but you are arguing from a point of view that they are. This is disingenuous at best. The point of the article is that macOS (and Windows) does not have a native, dependency resolving, feature complete package manager; you as the user have to add it via homebrew (or chocolatey in Windows). The vast majority of Linux distros have a package manager built in and they are usually symbiotic in nature.
Now, if you want to say that homebrew is better than any Linux package manager, sure, that’s your opinion and your prerogative; maybe it is better for your needs. There are certainly arguments within the Linux community as to which package manager is the best. But to try to claim that homebrew on macOS can manage Apple system components is patently false and I don’t know why you insist that it does. Apple fanboyism is not an excuse to flat out lie.
Tbh who cares how winget works, fact is it does work and quite well at that. These days for me, using UniGetUI with exclusively winget packages, and always installing the winget version of apps instead of manually downloading (whenever possible), my Windows app update situation is just as easy and painless as it is on my Fedora with KDE Discover.
Also a little tip for Mac users: MacUpdater.
This is one of those things Linux fans tell themselves because so much of their identity rides on the software they run.
Linux package managers are great until they aren’t. Need to install more than one version of python on Ubuntu or Debian due to handling different projects? Have fun with PPA’s or compiling from source. Or use homebrew I guess, but I can already do that on my Mac. Of course if this is in the enterprise you can’t just add random PPA’s, so you’ll compile from source versus me going to python.org and downloading an installer for each version I need.
Need the latest version of some library but don’t want to switch to Fedora or Arch? Use homebrew like a Mac user would, or else fart around with PPA’s/backports and compiling from source.
Need a professional paid application to do work that you are paid for? That’ll never be in either flatpak or your distro’s repo. Better hope there is an appimage (or that it exists on Linux period). I still see apps only supporting Ubuntu.
I am running a Linux cluster professionally as we speak. I’m not a Linux dummy, I’m familiar with every major distro and am dabbling with void Linux in a vm to keep my mind sharp.
I’m also not a masochist, and dumped Linux on all my desktops years ago. I’m better off for it.
that_guy,
Yeah, I agree. Assuming your software needs are totally covered by official repos, then it’s hard to beat their efficiency and ease of use. But installing out of repo software or different versions presents challenges that the repos do not cope with well.
To this extent I’ve been very impressed with how simple appimage is to use, and to a lessor extent flatpak. These have made large strides in addressing the shortcomings of traditional package managers. Although the usual caveats apply such as the duplication of libraries and security updates not being coordinated. Still, I am quite thankful to have flatpak versions because installing/building dependencies manually can be a lot of work.
I agree it is unfortunate when your distro isn’t supported, but I do think solutions like flatpak have been gaining momentum in recent years.
I’ve embraced linux on all my desktops and I’m better off for it. Even with macs I’m disappointed in the amount of vendor lock-in going on and transition away from commodity components. Apple hasn’t supported competitive GPUs for compute since transitioning to ARM. Gaming remains a relatively sore point too. Of course there’s no one answer for everyone, we all have our own preferences and it’s ok to be different.
Largely this is a problem with languages like python that keep breaking things between versions… You should just be able to install the latest version and have it work.
That said many package managers do take things like this into account and allow multiple versions to be installed, with ways to choose which version you use either by setting a global default or by manually invoking a specific version. I can see python3.11 through python3.13 on a debian system i’m connected to right now. You can invoke specific version with the python3.xx command, or just running “python3” gets you the default version.
Linux package managers are great and better than any of the alternatives. I have yet to see a remotely convincing argument otherwise.
Homebrew is Linux package management ported to macOS so that it is funny that people are touting that. It is not as good though of course as it does not manage any of the core OS or libraries. It is a bolt on. Winget even moreso.
It is certainly true that Linux package managers work best when everything is available in the repos. For me, the Arch repos and the AUR have been best in that regard. If it runs on Linux, it is probably in there including a great many proprietary offerings (Twingate, IDEA Ultimate, Rider, and Burpsuite Pro are all on the computer I am typing on–all from the AUR). Probably more. Nix is also good on that front but I have never taken the plunge.
“Need to install more than one version of python on Ubuntu or Debian due to handling different projects?”. The right solution for this is Distrobox. Python is not just the interpreter. I am probably going to want entirely different libraries. Two versions of PIP? Do I also need to target a specific C library? A specific generation of OpenSSL? GUI libraries? Message queues? Instead of just the versions”, use the distro you are trying to target–including specific vendor packages or config. I would use a Distrobox for each project even if the Python version did not matter. No PPAs. No compiling dependencies. You know what makes it fast and simple to setup these Distrobox environments? That’s right, Linux package management.
“Need the latest version of some library but don’t want to switch to Fedora or Arch?” Again, just use a Fedora or Arch Distrobox. Done. I use a musl based distro. If I need dotnet, I get it from Arch (Distrobox). Much better package selection than homebrew (which again is just an alternative package manager–like nix but with fewer packages). I would choose Nix before farting around with homebrew on Linux.
“Need a professional paid application to do work that you are paid for?” Well, many such applications are in the AUR. At some point, Flathub is going to add paid applications. So, I reject the statement “That’ll never be in either flatpak or your distro’s repo.”. However, yet again, if I want to use or support a paid application that wants to target a specific distro, I would run that distro in a Distrobox. I have a RHEL9 Distrobox on my musl based system. Anything that would prefer to run on RHEL can run in there.
And, as this article states, there is also Flatpak. We don’t need Flatpak as a better package manager. We need Flatpak because there are too many different distros for app developers to target. Flatpak is more a platform than a package manager (the Freedesktop platform). Instead of having to target Ubuntu, or RHEL, or 12 other distros, you target the Freedesktop SDK (Flatpak). It is just like targeting any other single Linux distro except the resulting app can be run on any system supporting Flatpak. And, of course, Flatpak includes package management.
I think an interesting project would be to port the Freedesktop SDK and Flatpak to Windows. It could run on the WSL kernel. You port it to macOS as well. Then you could build your application once and distribute it across Linux, Windows, and macOS. Flathub could become the universal app store for Open Source and commercial applications.
AppImage is just the macOS application bundle idea executed on Linux. It brings the same advantages and disadvantages. One of the disadvantages is the lack of a package manager. Another is having to bundle all your dependencies. And since you do not bundle the core system, another disadvantage is that it only works on a core system that is compatible. If you do not keep upgrading the OS, you will run into this on macOS. And since you cannot upgrade the OS on older hardware, you eventually end up with applications not working on older hardware. Legacy patcher on macOS exists primarily to restore app compatibility on older Mac hardware. I do not have that problem on Linux.
I am typing this on a 2009 Macbook Pro. It can run anything found on Flathub (including some that are closed source or require paid subscriptions). Take Microsoft Edge as an example. The latest version will not run on this hardware in macOS as the latest version requires macOS which this hardware will not run. Or how about S3drive (proprietary). macOS requires additional software for that. I could get it through Homebrew but again that requires an OS version that I cannot run. On Flatpak, I click install and then start using the software. Microsoft Teams requires some kind of binary plugin that crashes in the web browser of my musl based-Linux system when I share my screen. The Flatpak just works.
Copr? Unfortunate name… κόπρος means feces in greek.
“and I have no idea how users tolerate that kind of nonsense”
That’s all they know.
“The Linux world is far from perfect, but they nailed application management early on, and the competition has basically sat still ever since.”
That’s in large part because they needed to rely on only open source and free software applications and hand lots of people (mostly volunteers) to help scale the project of packaging.
How about not updating adobe pdf every week, and keeping that mp3 player you enjoyed since college? How about continuing to use pre-pandemic versions of media player classic? How about using old versions of office, which are better than the 365 junk on every imaginable metric? If these archaic software stop working when you are forced to move on to enshittified windows versions for some reason, update to a newer working version, put the installer exe in a “programs archive” folder or something, and forget about it for the next 10 years.
Before shouting “security”, think about it… If your screenshot app needs security updates, there’s probably something else wrong with its design. Why should a screenshot app need security updates?
This is not 1990s anymore, and a ten-years-old box can easily meet the needs of most users.
I am not looking forward to getting a yellow pages for apps I install once every 10 years.
I really don’t want updates to notepad. It had been working fine for 30 years, and I don’t want to waste time on a new version which may well introduce new bugs (Yeah, to be honest, dark mode is useful. One useful update in 30 years.)
I really don’t want updates on my clipboard manager. I don’t want updates on my calculator. I don’t want updates on my image viewer. You say “updates,” I hear “new bugs, new problems, probably new subscription requirements, useless additions I won’t use, and a slower app overall.” And before you ask, I can live with Firefox ESR’s automatic updates once every two months or so.
From this perspective, package managers sound like a solution looking for a problem.
I think you are confusing two things. One is the philosophy behind updates and the other is how to distribute them. Single sourcing and robust dependency resolution do not require churn.
There are a few Linux distros that allow you to use the same software for 10 years or more with no new features. I guess you could forego security updates but that does not sound wise. Yes, even your screenshot program could be leaking information. I bet you have sensitive info on your screen sometimes. Linux package management allows you to stay on older versions without
new bugs, new problems, new subscription requirements, useless additions, or impaired performance while also ensuring that your system stays cohesive, functional, and secure.
Contrast this to Windows Update which entangles and forces new functionality with bug fixes and security updates. Or to macOS that requires you to frequently migrate to a new OS release.. Of course, if you prefer to keep your Linux system current, like I do, there are different distros that do that.
RHEL7 and Fedora 42 use the same package manager but they have totally different philosophies on upgrade frequency. RHEL7 was released in 2014 and will be supported until 2028 before requiring application upgrades. Fedora 42 was released this month and will be unsupported a year from now. Again, same package manager.
Even if you want your system to stay frozen in time, you will probably eventually need an app you have not needed before and do not have installed. How do you find and install this app while ensuring that it will be compatible with your older setup? What if it needs dependencies you also do not have installed? This is exactly the capability that Linux package managers provide.
And if you do want an up-to-date application on your otherwise ancient system, what do you use? Well, that is exactly what Flatpak is for (or Distrobox). Flatpak works on both RHEL and Fedora. So, as an app developer, Flatpak let’s me target both sets of users with a single build of my application despite their very different core system preferences.
By the way, I am running this on a computer sold in 2009 (more than the 10 years old you mentioned). It is running KDE Plasma 6.3.4 and Wayland on kernel 6.14.3 and I am typing this in Firefox 137. My root partition is bcachefs. You do not always need to use old software to use old hardware.
“Before shouting “security”, think about it… If your screenshot app needs security updates, there’s probably something else wrong with its design. Why should a screenshot app need security updates?”
Any application that can accept input from a user needs security updates. Think of Acrobat Reader. You receive an email with a PDF. You open the PDF in Reader and bang – your machine is compromised because the PDF is crafted in such a manner to exploit a buffer overrun bug in your out-of-date Acrobat Reader.
sloth,
To be fair, cevvalkoala did carve out an exception for more complex software with his browser example. I think his point was about simple local software like calc. My opinion is that buffer overrun faults ought to be extinct in all software except we’re still using unsafe languages. Oh well.
Software management is a chore, no matter what OS you’re using. Linux isn’t any better, it’s just different, with different strengths and different weaknesses.
As an Ubuntu user, I swore off of snap. I’ve already switched to the latest release (25.04), and the first thing I did was get rid of Snap.
I don’t like it. Since I’m actually using Kubuntu, Snap GTK apps are untouched by KDE’s theming, so they stick out significantly. The configuration option for Firefox to use the KDE file picker has no effect, my existing significantly customized configuration is ignored (Firefox for Snap stores its configurations in a different location), and the third party helper util for converting certain videos downloaded with the VideoDownloadHelper extension doesn’t work.
But to install third party software that isn’t in the Ubuntu repos (For example, non-Snap versions of Firefox), I have to add a half dozen or more PPAs or other third-party repos to get the software I want. Launchpad is slow so updates take forever if they have to pull from there.
And, often times apps in the repos don’t get major updates… ever. If I want the latest version of a particular app, oh man it can be a pain to track one down. Flatpaki is okay, but damn it is hit-or-miss. The client I use for my VPN service is an example – they actually maintain the Flatpak version (Not always the case on FlatHub), but they also maintain an Ubuntu repo. I’ve used the FlatPak version on Fedora, and it was somewhat unstable.
I’m not sure centralized package management for Linux is much better than individual apps downloaded for Windows. Beyond common software, the experience isn’t any better and can be significantly worse than on Windows or macOS, and it is also a ton of extra work for distro maintainers and for software developers as well.
Software on Linux is just a mess though. Always has been. The biggest example of that I have is Steam. There are games that have native Linux ports that don’t work anymore, and the ideal way to run them is to use Proton. That was more of a pain than it needed to be to figure out.
A few good points but mostly it sounds like you do not like your distro.
If I was forced to use Ubuntu, I would install an Arch Distrobox precisely to avoid the mess that you describe. Show me a PPA that you use that is not in the Arch / AUR repos. Everything is a one-line install. Everything stays extremely up-to-date.
Ubuntu keeps its software versions fixed by design (avoids upgrades). That is why they made Firefox a Snap (so it could upgrade more frequently). If you do not like their design choices, maybe use something else. I sure do.
Your point about Linux game ports no longer working is a very good one and userland ABI stability is one of the great strengths of Windows and, historically, once of the biggest pain points in Linux. That said, this is precisely the problem that Flatpak was designed to address. If those games had targeted the Flatpak runtime, they would still be working. Steam itself is available as a Flatpak.
I pretty much only install software from my distro repos because they have everything. It is a dream. I have none of the problems you describe.
When I use other distros, I take those repos with me using Distrobox. Beyond that, I have needed two Flatpaks. On a musl based system, I use a Microsoft Teams Flatpak because Teams uses a binary plugin that crashes in the native musl browser. I also use Flatpak for PgAdmin4 because the version in the repo sucks. One dud out of hundreds of packages works for me though. No biggie.
I think I just don’t like operating systems anymore. Why can’t I just run Windows 2000?
I actually prefer OpenSUSE, but Ubuntu is better supported by third party software, especially proprietary third party software. I haven’t tried Distrobox, but it seems excessively complicated, and I’m not thrilled with the level of duplication that implies.
All distros have their warts though, and since package management is really the activity I spend the least amount of time doing, it being janky isn’t that big of a deal for me.
Drumhellar,
When repos have the software (and versions) you need, they work well. But otherwise I share all of your gripes and I agree with you there needs to be a good way to handle out of repo software. It’s not because they’re doing a bad job as such, but because the model is based on a flawed assumption that centralized maintainers can be everything to everyone. They cannot.
Flatpak/appimage help users install what they want & need rather than what the repos have chosen for them. This is genuinely helpful, although I’d like the process become smoother still. A decentralized standard that lets publishers self host their software (via bittorrent?) while users can use software managers that can browse software & reviews, create containers, install & manage software, create launchers, etc. These could be submitted to public directories/indexes.
The distro software managers do a lot of the heavy lifting today, but I’d like to see it specifically become decentralized and much less dependent on distros to host the software.
I think the way that Google and MS distribute packages for Debian/Ubuntu is a great start. Their deb package also installs a repo so their updates are included as part of the normal update process. I think Microsoft missed a great opportunity in this regard. They could’ve done this with winget, but then again they could’ve done this with the Windows Store, but they also really could’ve started this back in the Windows 98 days when Windows Update was introduced.
This was a golden opportunity for a fantastic solution that they missed no less than 3 times. Linux is just too fragmented for that to be a workable solution for any distro that isn’t Debian or Red Hat-based.
My goodness, it’s almost like these statements are purposely ignorant. Package mangers are not wonderful. They are a walled garden and do nothing but hide one of the biggest design flaws of the “Unix Way” of thinking.
Windows got it right. Anyone could write an application, publish it, and not have to ask for permission to be included in a package repository or app store. The end user experience was clean and simple. No need to worry about dependencies. Run the installer, then launch your newly installed application. It just worked. The MSI installation framework was a good in-between.
MacOS was even better, even if it didn’t always work as advertised. Drag the icon to your apps folder.
Linux/FreeBSD… hope that someone has decided to package the app, added it to the repo, and it’s the latest version. Otherwise you are going to be compiling, installing dependencies, and rethinking your life choices.