One of the ways in which Windows (and macOS) trails behind the Linux and BSD world is the complete lack of centralised, standardised application management. Windows users still have to scour the web to download sketchy installers straight from the Windows 95 days, amassing a veritable collection updaters in the process, which either continuously run in the background, or annoy you with update pop-ups when you launch an application. It’s an archaic nightmare users of supposedly modern computers should not have to be dealing with.
Microsoft has tried to remedy this, but in true Microsoft fashion, it did so halfheartedly, for instance with the Windows Package Manager, better known as winget. Instead of building an actual package manager, Microsoft basically just created a glorified script that downloads the same installers you download manually, and runs them in unattended mode in the background – it’s a download manager masquerading as a proper application management framework.
To complicate matters, winget is only available as a command-line tool, meaning 99% of Windows users won’t be using it. There’s no graphical frontend in Windows, and it’s not integrated into Windows Update, so even if you strictly use winget to install your applications – which will be hard, as there’s only about 1400 applications that use it – you still don’t have a centralised place to upgrade your entire operating system and all of its applications.
It’s a mess, and Microsoft intends to address it. Again. This time, they’re finally doing what should have been the goal from the start: allowing applications to be updated through Windows Update.
Built on the Windows Update stack, the orchestration platform aims to provide developers and product teams building apps and management tools with an API for onboarding their update(s) that supports the needs of their installers. The orchestrator will coordinate across all onboarded products that are updated on Windows 11, in addition to Windows Update, to provide IT admins and users with a consistent management plane and experience, respectively.
↫ Angie Chen on the Windows IT Pro Blog
Sounds good, but hold on a minute – “orchestration platform”? So this isn’t the existing winget, but integrated into Windows Update, where it should’ve been all along? No, what we’re looking at here is Microsoft’s competitor to Microsoft’s winget inside Microsoft’s Windows Update, oh and there’s also the Windows Store. In other words, once this rolls out, it’ll be yet another way to manage applications, existing inside Windows Update, and alongside winget (and the Windows Store).
They way it works is surprisingly similar to winget: application developers can register an update executable with the orchestrator, and the orchestrator will periodically run this update executable to check for updates. In other words, this looks a hell of a lot like a mere download manager for existing updaters. What it’s definitively not, however, is winget – so if you’re a Windows application developer, you now not only have to register your application to work with winget, but also register it with this new orchestrator to work with Windows Update.
This thing is so incredibly Microsoft.
Linux and BSD have the same “sketchy installers” issue: you can do everything you want with post-install scriptlets in DEB and RPM packages (I know, I used the functionality to enable and start systemd services as part of my job), but Linux and BSD fanboys pretend to not know that (they also pretend that commercial developers wouldn’t abuse the post-install scriplet feature if Dekstop Linux was popular enough to warrant its own bloatware/adware). Also, those post-install scriptlets run as root.
The only OS that gets packaging right is Android (with apk files).
Yes, that’s a missing feature of Windows. It’s one of the design clues Microsoft should have gotten from iOS and Android (after the huge success of those OSes), instead what they understood is that they should mess up the Windows 7 UI and make it look more like a frickin’ tablet.
Most developers will not bother with winget (since it has no GUI), and the Windows Store is for those Metro/Modern/UWP apps nobody cares about, so Windows Update it will be.
Well, they surely don’t need to scrape the web for them, and with flatpak plus boxbuddy I’d say you don’t need to worry about them being sketchy either. In fact I’m using Aurora which is an immutable distro for almost 6 months and never looked back. You *can* use this outdated technology, and probably the new linux stack is not as refined as android, but I’d say we are in no way on the same clusterfuck that app distribution is on Windows.
Desktop Linux has the other more important problem: You have to rely on someone to repackage the app for your distro. It’s the reason VLC for Windows ships with libdvdcss but most ditros omit it when they repackage VLC. Yes, Flatpak exists, but is not the most common way of distributing apps on Desktop Linux.
Also, Windows has msi, and you can ship portable apps, and it even supports containers, app developers use exe because it allows them to run arbitrary scripts during installation, and they will utilise deb and rpm files and abuse post-install scriptlets in a similar manner if Dekstop Linux ever becomes popular enough to warrant its own bloatware/adware.
kurkosdr,
Yeah, it would be nice to have more devs standardize on it, but there’s still quite a lot available and I for one am quite happy when I have a flatpak version of software that’s outdated in official distro. Running things in a container has caveats, but on the flip side it helps with consistency as opposed to running in an unknown environment with incomplete dependencies. It’s the perpetual debate around what needs to be bundled versus expected on the host.
MSI lets you run vbs scripts too. I’ve used it at work to initialize settings that weren’t practical to achieve in other ways, such as updating config files. Although I agree with you that package managers running scripts isn’t ideal especially because these are often running as admin.
Edit:
Just to supply examples…
https://www.itninja.com/question/calling-a-vbscript-in-a-msi-custom-action
https://stackoverflow.com/questions/8487935/running-a-vbs-within-a-msi-setup
I posted this below, but there is a GUI for winget: https://github.com/marticliment/UniGetUI
Also your statement about Windows Store being only for UWP is at least 5 years out of date. The newest iteration of the Microsoft Store, as it is now called, is actually based on winget and allows any kind of apps to be installed, not just “modern” ones.
I’m really not sure this will have any impact in the consumer space, to be honest. Maybe for certain classes of software, like graphics card drivers. But for installing software that updates itself, the consumer story continues to be to publish on the Microsoft Store.
You mean Apt? Yum? Dnf? Flatpack? Snap? AppImage? AUR? Pkg?
I so love a good standard.
Apple in fairness mostly sticks with with Brew
But Mac OS doesn’t come with Brew/Homebrew. Arch Linux comes with PacMan and it works fine. Most distros just need whatever their package manager is and don’t require you to play directly with Snap, AppImage, Flatpak, or whatever.
Bazzite comes with brew! No casks though. I’m kinda digging the immutable nature of Bazzite. I mean, it also has all the other ones – flatpaks, and all the distrobox stuff. But hey, what’s life without a little excitement.
Flatpak also works on Windows, kinda. Neat.
To be fair, the only one of those that aims to be a cross-distro standard is Flatpak. While Flatpak has its issues, it delivers on its promises fairly well. And within any given distribution or even distribution family, the native package manager is consistent.
Apple, in fairness, does not have a package manager at all unless you consider that to be the App Store. First of all, Homebrew does not manage the operating system or anything that comes from Apple. Second, Homebrew is an independent project:
https://github.com/Homebrew/brew
While popular, Homebrew is not even the only Open Source package manager for macOS. You could use Nix as well. And, as above, you need at least two package managers on macOS (the built-in Apple updater and something like Homebrew). That is worse than a Linux distro where you can almost always get away with just the native package manager for everything. At worst, a Linux distro with out-of-date repos will lead you to install Flatpak alongside the native package manager. So, you will have two systems–just like macOS with Homebrew.
Windows is exactly the same. This is their attempt to change that I guess. If successful (big if), they will have one update mechanism for everything.
I’d say it exists and that is exactly flatpak. deb or rpm repos are no good, since a repository will not work for a distro that was release 6 months later, complete oposite of the binary compatibility offered by Windows, sometimes of decades. snap only really works on buguntu derivatives, and the server is controlled by Cannonical. We all know appImage is a hack to get portable apps you can put on a pendrive. However, flatpak fits the bill, yes. Install flatpak on any distro and you will have access to the same applications on the same versions on every distro. And just needed to be packaged once. Same application, compatible with fedora, debian, arch, whatever. With increased security, automatic updates, support for third party repos, community ownership of the de facto standard repo, and so on.
Technologically, flatpack Could be it. But right now, its certainly not.
Go on to flathub and search for “chrome”. You’ll get multiple results, not one is officially Chrome. Until they have substantially more safeguards in place, its not something any corporation could rely on. The risk of MITM attacks make it untouchable.
To be fair, while Chrome is not “official” (packaged by Google) on Flathub, it’s just a repackaged version of the official .deb release: https://github.com/flathub/com.google.Chrome/blob/master/com.google.Chrome.yaml#L100
I mean, in normal the Linux repos all the open source stuff is built by your distro, not by the app developer himself.
Same for F-Droid, where most apps are built by the F-Droid project.
In a way, Windows is the exception in that you actually download the app from the developer without middleman.
joscher,
Yea, regardless of which repo/store you use, the element of trust is still implied.
Ideally I would like to see software distributed by something like bit-torrent. With a client that acts both as a search engine and as a certificate verifier. This way you could list all the versions of software available from anyone publishing it.
For example:
The client could have a configurable list of publishers, that you’d be able to add/remove for your needs. You’d have flatpak for packaging, but you also have a flexible agnostic client to consistently obtain software and even reviews from the sources you trust without being so tightly bound to centralized repos.
I don’t see why they wouldn’t use the packages with verified publisher. It doesn’t need to be perfect now. I’m sure its a matter of time before Google maintains it.
Yes, each OS has their own centralized, standardized application management, as Thom says.
> So this isn’t the existing winget, but integrated into Windows Update, where it should’ve been all along?
Yuk. Windows update should be fixed first. I wouldn’t want the current windows update touching a single byte more than necessary to install the security updates.
And security updates as in really security updates. Not changes to block startallback etc.
BIG correction, there is indeed a very good GUI option for managing winget.
https://github.com/marticliment/UniGetUI
It’s not built-in, but it’s easy enough to install and use even for non-technical users.
Also it should be noted that winget and by extension MS Store packages are not just “any old EXE” but rather have to be in the MSIX format. They can also depend on other packages, just like in Linuxland. And of course the system handles updates for you. So it is a bit more than a glorified download manager. In any case, I’m not quite sure what the point of emphasizing the technical differences is tbh, because if it works the same from an end-user perspective, who really cares?
Another BIG thing it seems Thom is missing here is that this isn’t supposed to be a feature targeted at consumers, but rather for IT admins who have to manage whole fleets of Windows installations, many on the server side. Anytime “orchestration” is in the name this should be a big clue – this has nothing to do with how a private individual manages their computer. At the moment administering software updates to a big group of Windows installations still sometimes requires third-party tools – with this move it seems to me that Microsoft is hoping to make those obsolete. Ultimately a lot can already be done by scripting with winget, but the thing is, winget is only for open source and/or Microsoft Store apps. (Unless you create your own private repository, which then comes with all the headaches of additional maintenance.) This new thing seems squarely targeted at proprietary enterprise software (probably a lot from Microsoft itself) for which winget isn’t an option.
To sum up: nothing to see here, move on. On the consumer side, nothing is changing here as far as I can tell. Most developers and users can stick with winget and the winget-based Microsoft Store.
UniGetUI isn’t shipped with Windows, it isn’t even a official Microsoft project. So Thom argument stands.
But yes, calling winget just a glorified script is a stretch. It still far away from what exist in Linux world, but indeed it does a lot more than just downloading apps.
when it comes to WinGet, never forget AppGet: https://medium.com/@keivan/the-day-appget-died-e9a5c96c8b22
Sometimes I suddenly remember that not all Windows users update their apps using UniGetUI (https://github.com/marticliment/UniGetUI) like I do, and my anguished howl shatters the silence of the night.
I’m not a big fan of Winget or UnigetUI or whatever you choose, but all the package managers MS, MacOS or Linux have their share of problems.
Yet I understand why MS might be going down this track as delivery is obviously a large part of the security issues, secure the delivery channel first, then worry about getting the content right.
MS don’t have the user base that can check a hash or examine certs and signatures, it needs to do it for the vast bulk of it’s users. I just hope the checks are genuine and not spurious like some other major vendor’s historical efforts who settled on claiming their platform was secure when it really wasn’t.