Windows Package Manager Preview
devblogs.microsoft.com
devblogs.microsoft.com
Look at the firefox "package": https://github.com/microsoft/winget-pkgs/blob/master/manifes...
There isn't even any uninstall functionality.
This is a package manager as much as a piece of cardboard is a swiss army knife.
Even if you say "but it's a preview", there's just no where to go when your starting point is "execute some arbitrary binary". The point of packages is to be declarative as much as possible.
Under normal circumstances you share as little as possible. There isn’t a situation where an app needs “library X version Y or greater”.
Some runtimes etc is usually all that’s shared.
Now they're making it so anyone with a keyboard can add to their package manager. Probably with the end goal of a walled garden ala Android and Apple.
The next stage is probably to "sandbox" whatever code runs in these installers into a virtual restricted environment. I would bet money on it.
Do you really want every app to have access to pretty much every piece of user data on the system, and every other app?
In the 90's it wasn't uncommon for installers to just poop application files or config files into Windows\System32.
Basically, this is a good way of getting most of the worst features of both dynamic and static linking.
I wouldn't call such tools "package managers" but "installation and update managers", they have some functionality overlap with tools like apt or pacman, but in the end they serve a different purpose, installing tools and application on the command line and keeping track of what has been installed.
Control Panel --> uninstall apps
The issue is with how windows setup exes are designed. Most allow you to uninstall after running the exe again...others do not and leave traces of themselves everywhere.
This is a great first step and leads to some automation possibilities when setting up new installs.
Then when the MSIs aren't built correctly, they will leave you with a detection method that gets hosed when the software auto-updates. So you run your package manager, and it'll detect that your software is no longer installed, because the MSI product code changed for the newer version.
I mean we have so many ways to do software on Windows. Let's count them:
* MSI * EXE * MSU * AppX * Windows Features * dism * Windows Update * SCCM Deployments
Even just open up the "Uninstall Apps" control panel, or the old "Add / Remove Programs" and look how long it takes to load the list. It's pulling from like 20 different places in the registry and various places in the WMI database just to build that list. So when you want to use that as a detection method, good luck...
It's horrible. MSI is so complex, and there are constraints, limitations and oddities at every twist and turn.
I love Windows for desktops, but my all time favourite item on my wishlist is for Microsoft to completely revamp how software is installed, from scratch, to improve things. I really mean from scratch - I know Microsoft like every new thing they do to be compatible all the way back to Windows 3.1, but no, really, from scratch!
But agree, there should be no need to things like docker if apps were sufficiently compartimented and explicit about their requirements.
It’s all done via declarative XML and made my life much easier.
The last MSI installer I wrote had to install 2 Windows services, write to the registry, grant file system access rights, and install a minifilter driver. There was a lot of swearing, and I was really close to launching my laptop out of a Window several times. It was a very unhappy period of my life, and if I never have to write another MSI installer, it will be too soon.
They did, it's called MSIX and there are apparently few HN commenters aware of it, especially among those that complain about installing things on Windows. I'm not referring to the comment I replied to.
We need a trust / verification system that's built for more than grabbing money out of the pockets of developers.
You could tell they were screwed when even Microsoft didn't use MSI after they invented it.
* MSI * EXE * MSU * AppX * Windows Features * dism * Windows Update * SCCM Deployments * MSIX.
So now everyone uses MSIX? Or are there still a combination of all of the above being used today?
Creating a new standard is one thing, enforcing it is another. It's like XKCD 927, just yet another option to add to the list.
Why are multiple options a bad thing? Seriously.
There is nothing stopping them from adding more traditional packages in the future.
With it I can:
- rebuild my machine from scratch. I've bought a new machine 2 months ago and still need to install something that I don't have. - know that the packages I'll install have less chance of being malware. - maybe I can install authorized packages myself in my business computer. - automatic updates
That combined with batch files that sets all my environment right, plus all my data backed up with synology cloudstation means setting up a new machine is a 15 min job.
And even if you installed softwares manually, try uninstalling them and re-installing them through chocolatey (usually you don't lose the settings). The ability to update all of your softwares with just one command line is something you quickly get addicted to.
I wouldn't wait for this Microsoft version. Until it has thousands of 3rd party packages it will be pretty much useless.
Please don't (see my other comment for a range of reasons why).
I find scoop far more reliable than chocolately.
Because the worst pain the in the ass is not so much to install them all initially but to keep all of those updated over time.
But someone else here mentioned scoop-extras[0], which I hadn't heard of before, and contains over 1,000 apps (including Chrome, Firefox, notepad++, Irfanview, Skype, Sysinternals).
I've used chocolately for both new installs and updates in the past though, but wasn't impressed. IME, packages are frequently broken in part or fully, they are not regularly updated, or they are completely abandoned.
The only grief I have is that I have a bunch of VMs (<10), and if I set them to all update all their packages simultaneously, I get rate limited by chocolatey and need to wait a while for my IP to be unbanned. But for a free service, I can't really complain.
But do snap and flatpak do the same thing?
Id: string # publisher.package format
Publisher: string # the name of the publisher
Name: string # the name of the application
Version: string # version numbering format
License: string # the open source license or copyright
InstallerType: string # enumeration of supported installer types (exe, msi, msix)
Installers:
- Arch: string # enumeration of supported architectures
URL: string # path to download installation file
Sha256: string # SHA256 calculated from installer
# ManifestVersion: 0.1.0
https://github.com/microsoft/terminal/blob/master/doc/user-d...
Preferably use something as simple as TOML, or even just plain JSON.
Indentation is pain in the ass to work with in huge files and with editors that do not support autoindent(which occasionally you have to use) - especially if the comments do not follow the indentation.
In short, a Microsoft employee added AdoptOpenJDK 8 to the repo. ...Java 8? ...In 2020? Another user has opened a PR to add what looks like the FSF's OpenJDK 14 to the repo. So are we supporting 8 or 14? Are users who want to "winget install openjdk" going to get 8 or 14, Adopt or FSF?
I doubt Microsoft is willing to pick winners or losers or opinionate on the authority of third party package sources, and hence, the dream of "winget install powertoys" will probably only reliably do what it should for Microsoft tools.
The decisions the team chooses will end up informing the community on the reliability of it as a platform. And I'm definitely excited to see what happens here!
Most package managers provide multiple JDK versions, but default to the newest stable version for the default metapackage.
Sure, there are still products that use it (the oldest legacy Java app I still see runs on OpenJDK 11 just fine, mind you), but if you're launching a new package manager in 2020, the only apps that will use it are new apps. So you might as well start with the latest possible release. There's no good reason for Windows Package Manager to start with OpenJDK 8 as the baseline.
https://github.com/microsoft/winget-cli/blob/master/doc/wind...
How does winget compare to scoop? Does it replace vcpkg/nuget/conan/...?
"This project collects usage data and sends it to Microsoft to help improve our products and services. See the privacy statement for more details." from https://github.com/microsoft/winget-cli
People do not give feedback so it's impossible to tell how their programs are being used.
The other choice is to listen to the vocal minority that offers feedback than you get into issues of implementing features that no one wants/uses.
The telemetry in question seems to be logging what is installed, not just how the application is used.
Regardless of consumers willingness to provide feedback it's not a reasonable choice for a large software vendor to collect data from customers computers about competitors products.
Of course it’s reasonable. The other choice is developing blindly or listening to the vocal minority. Both of which hurt ALL users in the end.
It's always been a problem, most people just don't know that because the majority of users don't express their concerns in the way(s) that the developers are open to hearing those concerns.
Note that I'm saying this as someone that generally doesn't mind providing telemetry - but they need to be clear.
This doesn't make any sense. You don't think that every single installation via the iPhone or Android App Store isn't logged and telemetrized?
That is the comparison I was making with the new Windows package manager.
FAANG are also knowingly and willingly breaching the GDPR to this day with all sorts of products.
Just try to exercise your GPDR-given rights as an EU citizen and try getting ALL of your data from e.g. Facebook.
Not the subset of it that you are allowed to download, ALL of it.
You'll be laughed at really, really hard then shown the door.
Don't get me started on Microsoft.
The docs don't make any mention of how to opt out, or what data is collected. Which is incredibly annoying, as I really want an official package manager for Windows :/
But I guess this is an answer to the "where's package management" question. Still not there.
Were you getting source from author sites or using the package manager?
I've never had problems with apt or yum. In the days before yum it was a different story in Red Hat. Debian have always had it right with apt IMO. You could attribute the success of Ubuntu to it I feel.
Both Scoop and Choco are way better than this.
Also .NET Core is supposed to be bundled with the application.
Linux distributions tend to keep shared libraries in their own packages and applications depend on them so that when you install an app, the packages with the libraries also get installed. And all packages in the distribution tend to use the same versions of those shared libraries.
And major versions are the only things that need to be separately packaged, because the Linux native-library ecosystem is expected to keep .so ABI compatibility through both "patch" and "minor" updates (the only difference between the two being that "minor" updates can add new exported symbols to the library; they still should not break usages of existing symbols.) This particular arrangement was, in fact, what the Semantic Versioning standard was introduced to accomplish—getting upstream developers to use their version-tuples to mean the same things that Linux-distro package maintainers expect them to mean, allow Linux-distro package maintainers to reuse upstream version schemes rather than needing to maintain their own.
But, this is also to say: if you're creating a new, greenfield project, or a new major version of your own app—and you haven't yet deployed it into the wild as a fixed binary that people rely on to continue running on their boxes between upgrades—then nobody else but you has any incentive to keep things stable for you. If you want to develop against the newest Debian release at any given time, then it's up to you to catch up to whatever the newest ABI-major versions of your deps are at any given time. That's a problem you've chosen for yourself.
s/interesting/suicidal/
Replacing .so binaries with other arbitrary .so binaries is not what I would call "interesting". Interesting is deleting your /var folder. Or doing a `find /sys/devices/system/cpu -name 'online' -exec echo 0 > {} \;`.
I'm certainly not going to switch over just because it's MS. It's going to have to prove it's at least as good as, if not better than, Choco.
There are also benefits to Chocolatey that probably can't be replicated by MS, such as the package repo being a community effort and it being a relatively open platform for anybody to add whatever package they need.
I don't want to hate on chocolately too much, because it has filled a very obvious gap in the Windows landscape for so long, but I really don't like it.
The biggest problem is that there are invariably 5 different packages for anything you want to install, with no reliable way of deciding which is the real/main one.
Another problem is packages constantly breaking. This can happen because packages actually pull files from remote, primary sources, and those files disappear or the site goes down, but also for a myriad of other reasons.
Yet another problem is the reliability of the chocolately site - it seems to go down or be slow as hell quite frequently.
Another gripe is that AFAIK, chocolately doesn't support 3rd party repos.
And finally (and this one is totally subjective) the website is ugly.
So as glad as I am that chocolately filled a void, I'll also be glad for Microsoft to provide an official, reliable replacement that also supports 3rd party repos.
> Another problem is packages constantly breaking. This can happen because packages actually pull files from remote, primary sources, and those files disappear or the site goes down, but also for a myriad of other reasons.
How are these different on Scoop? The first one seems to only be related to the actual amount of packages. E.g. if Scoop ever grows to the same size, it will get it too.
The second one is also unclear. Does Scoop test all the packages it provides? Somehow I think it is unlikely.
The search does seem to break sometimes, but not had much problem with the packages themselves, a few end up installing in a user context, which isn't helpful when the user is SYSTEM.
Easier than constantly repackaging things as MSI/writing install scripts
E.g. just move all the files where you want them, and create a directory junction/symbolic link.
https://chocolatey.org/docs/features-install-directory-overr...
What's interesting to me about this announcement is that it seems to replace something they already had; Microsoft released OneGet several years ago and was positioning it (I thought) the same way they are positioning this. It's in maintenance mode now. So I would say Chocolatey is doomed only if this actually sticks.
Kind of like the .net framework celebrating its first json serialization library in the CLR a couple of years ago. Welcome to 2010!
After decades of opportunity for improvement, it's largely gotten worse. Uninstall is too often a myth, and the majority of programs out there leave bits and pieces behind. These add up over time to bloat your registry, disk, kernel drivers, etc, degrading the performance and reliability of your computer. Multiple conventions for where things go makes it difficult to track down the bits. (Program Files? (x86)? AppData\[Local|LocalLow|Roaming]? SteamApps\common? ProgramData? System32/SysWOW64? Dozens of registry locations?)
So many installers require unfettered, administrative access to my computer with little indication of exactly what they intend to do (Litter my desktop with new shortcuts? Add shell hooks? Install a rootkit?) and no opportunity from the OS to consent your partial permission or retroactively examine the changes. (Don't miss that popup balloon about a new driver! Have fun parsing through all the noise in your event logs).
Even simple chores like managing file type associations became more painful somewhere along the way.
There's a reason professionals so often fall back to advising a reformat. Makes me miss the days when your program went someplace like C:\PHOTOSHOP and most everything for it was contained within.
It's easy to point fingers at individual software publishers (I've called out some incompetent ones) but mostly I blame Microsoft for failing to evangelize rigorously thought-through best practices and provide better tooling to make it dead easy for developers to get it right. I might be wrong about this, but the preview looks like a gimmick for finding and running installers. I would have liked to see improved methodologies, packaging tools, and end-user empowerment announced alongside it.
Hats off to folks like Nir Sofer and Mark Russinovich who've shown the world just how much you can pack into a small, single-file, zero-installation EXE that just runs when you click it.
I've been using the same computer for 10 years now (with upgrades to components like video, RAID controller, SSD's) and have over 700 programs installed on it. I use third party monitoring software [1] to capture a disk and registry snapshot before and after any installation (and often on updates). The machine is still nearly as snappy as the day it was built (yes, I benchmark!), but it's taken a LOT of ongoing work to keep it that way. I use other tricks, like locking down certain registry keys and folder locations which programs like to pollute (or where that causes breakage, using startup scripts to clean them out after the fact in a cat and mouse game). One big win was completely giving up on My Documents. I treat it like just another AppData, and organize the content I really care about elsewhere.
All that said, I really like that my Windows software still comes directly from the vendors. I'm not sure how I feel about distribution becoming more centralized under Microsoft's control. Part of me hopes to see a vibrant ecosystem of third-party repos emerge, while another part dreads the confusion about where to get a package that may entail.
I do have to give Microsoft credit for enabling third party tools to take care of some of the shortfalls they haven't. On more locked down platforms that's been more difficult.
Getting Closer to my dream install:
* WSL 2
* VS Code
* .NET 5
* Windows Terminal
* Package Manager
* Edge
All that's missing is Edge on Linux and letting me write cross platform apps that use edge as a (headless) common runtime.