It’s a year later and we can now safely conclude that WinGet is terrible. It calls itself a package manager, but it doesn’t really manage packages: it can only install them. With AppGet you could actually manage your software. If it got outdated, you could update it. If you no longer wanted it, you can uninstall it. WinGet doesn’t do that. It just downloads software and installs it.
For months there’s been “experimental” support for the most important feature of a package manager: upgrades. It just doesn’t work. Sure, it will download the updates. It’ll even pretend to install them. And if you run it again, it will do it all over again for the same packages. It’s pointless. It just pretends to upgrade software, just like it pretends to be a package manager.
One of the main reasons I use Linux is just how insanely superior installing and managing applications is on Linux compared to Windows and macOS. As a Linux Mint user, I’m part of the Debian ecosystem, meaning virtually every piece of Linux software comes packaged as a .deb (you’ll have a similar experience with e.g. RPM or Arch-based distributions), managed from one central place. I never have to think about how to install, update, or remove an application.
Windows and macOS have various different methods of installing, updating, and removing applications, and many of these methods leave files all over the place. On both Windows and macOS, you have to deal with individual per-app update tools, application stores, downloading individual updates from the web, using tacked-on, always-breaking ports systems, and it’s up to you to remember how, exactly, each application handles its installation, update, and removal procedures.
WinGet is just another mess to add to the giant pile of garbage that is managing applications on Windows.
Msofties are busy making Androids/iOS apps. Not to forget Teams!!!!!!
Forget Tabs on 21H2. Or things like proper rotations of photos in the mail client.
This has kind of been my fear about the new Microsoft that does things I like. Still hopeful for wsl future, but this is a worrying sign.
I totally agree with all that is said. But if you nevertheless have to use Windows: Just use Chocolatey.
It works. Most of the time at least.
https://chocolatey.org
I was surprised at how much software on macOS dumps a bunch of stuff into /Libraries with non-obvious naming conventions. It gives every indication that you can just drag an app into the trash to remove it, but nope. It often doesn’t work that way.
(As an aside, I’m surprised at how much of Microsoft Office for macOS is files duplicated between Word, Excel, and PowerPoint. Every font included with Office is duplicated in each .app package, and you can save a couple gigs by running a script to turn the duplicates into hard links.)
Back to package management, Windows software has gotten much much better about cleaning up after itself when uninstalled. However, having each app handle its own uninstall independently of the OS is a major weakness. I’m surprised more software doesn’t use the MSI format, and I’m surprised AppGet is so terrible, considering the capabilities that MSI.
Of course, Linux is no panacea either. Using OpenSUSE Tumbleweed means when major updates are out it becomes a challenge to upgrade without breaking software that I might pull from other repos. Codecs especially are a problem, since you have to pull modern codecs from third party servers, which may not be so quick to update. Ick.
The problem is that free non-MSI installer builders like NSIS and InnoSetup are easy to find and, though moreso InnoSetup than NSIS, easy to use compared to the MSI options.
Basically, unless you’re willing to buy something like InstallShield (yet, it still exists), the only option for building MSI that’s even remotely well publicized is Microsoft’s WiX, which is a masterpiece of Microsoft “we don’t understand how to design stuff for others to use” software. (I really wanted to do the right thing, but gave up on WiX and went back to InnoSetup because its the worst confusing, XML-based hellhole of an overengineered project definition format I’ve ever personally had to deal with.)
Since then, of course, I discovered niche projects like WiX# (WiX Sharp) which transcompile something sane into WiX definitions, but I can see why corporations wouldn’t want to trust some dev’s hobby-project compile-to-WiX solution.
ssokolow,
Haha, +1.
Wix is non-intuitive, hard to follow, and definitely over engineered. I find myself having to look things up every time. As a user, the idea behind MSI is appealing, but as a software developer it feels like fitting square pegs into round holes. The “Keep It Simple, Stupid” rule would have gone a long way in making it a more popular choice IMHO.
Can’t say I’ve used that. I don’t do windows development as regularly as I used to.
FTFY
“One of the main reasons I use Linux is just how insanely superior installing and managing applications is on Linux compared to Windows and macOS. As a Linux Mint user, I’m part of the Debian ecosystem, meaning virtually every piece of Linux software comes packaged as a .deb (you’ll have a similar experience with e.g. RPM or Arch-based distributions), managed from one central place. I never have to think about how to install, update, or remove an application.”
Utter nonsense. Granted, when you know the package exists, and what it is called, it can be as simple as executing a command to install / uninstall it.
But the reality is a lot more complicated than the utopia you are describing. It can be difficult to find the software you want is in the central repository. Then, it may or may not be the version that you require (this may not be a big issue when you are just installing LibreOffice, but when you are installing something like a Java JDK, the version that is made available to you becomes a seriously important issue). And that’s if the software is even there at all – all of the repositories have policies around what they distribute, largely guided by the licence of the software – so great if everything you care about is GPL, it quickly becomes a lot less convenient when you want to use software distributed with a different licence (e.g. Oracle JDK). And then you’ve got potential dependency issues, software that is only distributed as source packages and potentially even wants to patch the kernel (e.g. some VM products).
When it works, it does work well. But there are plenty of times when the Linux central repository mechanisms break down.
Those issues could be fixed without abandoning repository-based package management. The OS I’m working on will have a somewhat Nix-like functional package management layer inserted underneath dpkg and apt using a dpkg-deb wrapper that builds a filesystem hierarchy out of union mounts, and will allow ultra-lightweight containers that share everything but installed packages (with a mechanism allowing for programs to run things installed in other package-only containers). This will eliminate most of the dependency issues that are common on Linux (as well as eliminating the need for “over-the-top” package management systems like Snap, Flatpak, and AppImage).
There will also be tools that make it easier to add a new repository to the package manager, as well as making it easier for upstream developers to create and manage their own repositories (unlike with typical Linux distributions there won’t be any assumption that the official repositories are all you’ll ever need, and third-party repositories will be encouraged). Distributing binaries as raw tarballs (or worse, self-extracting installers) will be strongly discouraged (and will be made a bit more difficult by the purely process/role-based security model and lack of support for reversion to the legacy Unix model).
There will also be a stronger separation into a base system and add-on packages as in BSD although they will only be separate repositories rather than requiring completely separate install mechanisms.
Your proposed functional package manager corresponds to OSTree, Red Hat’s answer to using snaps for non-GUI applications, which Flatpak is built on top of.
Flatpak isn’t just a package manager, but also a sandboxing system with pre-declared permissions similar to APK manifests (the core component of that is a Firejail competitor called Bubblewrap), a “portals” standard similar to Android Intents, and an equivalent to the Steam Runtime which uses OSTree’s internal support for deduplication to enact a compromise between deduplicating dependencies and ensuring upstreams don’t need to build and test for every version of every distro they want to support.
(For the record, snappy didn’t originally have many of these things (eg. portals) and has since joined in on using the ones Flatpak created while it was known as xdg-app.)
Which is why virtually every package manager allows you to add multiple repositories. Even Microsoft maintain repositories for deb and rpm packages these days. Add their repo to your system and you can get centralised updates for their stuff (teams, edge, mssql, powershell, azure support tools etc) all through your system package manager.
https://docs.microsoft.com/en-us/windows-server/administration/linux-package-repository-for-microsoft-software
It really is the most sensible way to distribute software.
Actually, the package manager is great. If you need something else, something like Snap or drop it in /usr/local, etc. solutions might be best. At least in Unix/Linux we have a dedicated place for that.
Yes, WinGet is terrible and totally pointless, but it’s not the only option around.
I use Chocolatey and Scoop on Windows, and Brew on macOS, and to be honest I don’t have a worse experience than using aptitude. In fact, I even use Brew on WSL Ubuntu, because it has some software that in the Ubuntu repos is either older, or completely absent.
The Linux packaging systems are fantastic as long as you stick to what’s available in the official repos, but if you need something else or even just newer… good luck.
That’s what I use Flatpak for.
It’s got a Steam Runtime-like means of supplying dependencies the application can rely on, Flathub insists on distributing stuff they built from source you can inspect using build manifests you can inspect, the Flatpak CLI asks you to confirm the permissions you’ll be granting, and you can use either the CLI or a GUI named Flatseal to overrule the package’s defined permissions if, for example, you prefer security but the maintainer decided that the average user would prefer to have the application able to see your entire home directory despite it building its own file dialog rather than using the Open/Save portal.
(Applications using
GtkFileChooserNativeor usingQFileDialogwithout the non-defaultDontUseNativeDialogwill automatically switch to the Open/Save portal when run under Flatpak.)I’m partial to something like PortableApps on Windows where individual apps reside in their own folder.
FriendBesto,
I am too: unzip and run in place. It’s how we did it in dos and earlier versions of windows. Still, at least windows programs get their own directory under “program files”, which is fine. It’s unfortunate that they used a long file name just to show up the new LFN support as that would become a pain for command line and scripting. Also, their decision to segregate programs into “program files” and “program files(x86)” was unnecessary and ill conceived.
But I still prefer the windows hierarchy to the unix/linux model though, Stuffing all programs into a few global bin directories is a mess. I’ve never appreciated this design choice, it’s bad IMHO. It’s like someone thought up the idea for PATH and then designed a directory structure that made PATH convenient to implement instead of designing a rational directory structure and providing a tool to automatically indexing the binaries with symlinks or something like that. But no, we’re expected to move all binaries into shared directories, ugh. I wish we could standardize on something more like Gobo Linux. Oh well.
Programs usually reside in “Program Files”.
…unless they’re in “Program Files (x86)”.
…or even a subfolder of “%USERPROFILE%\Application Data\”
How about program settings and/or temporary files?
Maybe they’re in “%USERPROFILE%\Local Settings\”
…or “%USERPROFILE%\Documents\”
…or “%USERPROFILE%\Application Data\”
…or “%USERPROFILE%\AppData\Local\”
…or “%USERPROFILE%\AppData\LocalLow\”
…or “%USERPROFILE%\AppData\Roaming\”
Uninstalling any program can unpredictably leave behind lots of data in any of these places.
I use Scoop on Windows. It’s pretty good, actually. https://scoop.sh