Windows Package Manager Preview
devblogs.microsoft.com... this thing literally just downloads .exe files and then executes them. There's no dependency management.
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.
Would dependency management really make much sense on Windows?
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.
their "store" failed because nobody wanted to go through all their BS.
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.
Sounds like a good idea, hey, that's exactly what Windows 10X does.
Do you really want every app to have access to pretty much every piece of user data on the system, and every other app?
I just want to be given the option. 90% of the creepy stuff MS and Google do is for "performance" and "security"
Well, that's why there's Linux
Has this changed from the 90s/2000s? I've been on Lin/Mac for the past decade, but back then many libraries (DLLs) required (msxml4.dll, msvbvm50.dll) - note specific versions.
Windows has supported installing multiple versions of the same system library ever since Windows XP via WinSxS. It's been a non-issue for a long time.
Still, for application developers the idea of installing "system-wide libraries" is all but gone. An application installer will just install to \Programs and that's normally it, even for very large applications (Obviously something system-y like a driver still installs system files). Even things that used to be typical system things like runtimes (C++, .NET) can now be locally deployed, which is nice.
In the 90's it wasn't uncommon for installers to just poop application files or config files into Windows\System32.
Typically that's not a problem any more, no.
So is everything statically linked now?
You can't statically link because of licenses, but your own directory is higher in the dll load path than anywhere else, so you just ship a copy of all the dlls you use.
Basically, this is a good way of getting most of the worst features of both dynamic and static linking.
No, you just usually ship all of your DLLs and put them next to your exe, if that is in any way possible. It might as well be statically linked...
Agree, very little shared libraries but there may still be dependencies. ffmpeg, correct .net framework version, etc.
Uninstall, Deps and other items are on the roadmap here: https://github.com/microsoft/winget-cli/blob/master/doc/wind...
Scoop on Windows and Homebrew on Mac are quite similar and they work just fine.
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.
I'm not 100% sure about Homebrew, but Scoop uses the "portable" installers every time it's possible, trying to put all the files in a well defined position, controlled by Scoop itself. I think that Homebrew (not Cask) does a very similar thing. What this Windows package manager does is running classical installers and there's absolutely no way to know exactly what the installer is going to do. Homebrew Cask follows a similar approach, but thanks to how .app and .pkg work it's actually possible to manage the uninstallation quite well
>There isn't even any uninstall functionality.
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.
As a former SCCM admin, I can tell you that packaging things like this will be a nightmare. Microsoft really needs to revamp the way software is installed on Windows, and make it all work the same way. Putting a wrapper around an MSI or EXE can be a nightmare. I mean, /SILENT is not good enough for many apps to make installers silent, so the switch /VERYSILENT came out. And even then, it's still not standardized, and many programs will still pop up dialogs and kill your automation. And then you'll find that the same package won't run the same depending on what version of Windows, what edition, 32 or 64 bit, etc and the installer will fail.
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...
I haven't had the misfortune to have to repackage other apps for SCCM, but I have had the misfortune to create MSI installers for several apps.
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!
Well that's what the windows store was meant to do but then they added a pay toll, limited it to apps that could run on a fraction of the machines deployed, so it never took off.
But agree, there should be no need to things like docker if apps were sufficiently compartimented and explicit about their requirements.
I recently went down this path. I discovered the WiX MSI toolkit and it was very smooth. If you ever find yourself needing to create an installer and haven’t used it, give it a look. It can install dependencies, customize the UI, create/start/stop/remove Windows services, configure IIS websites, and run custom actions.
It’s all done via declarative XML and made my life much easier.
WiX is great tool but a bit steep learning curve because it won't abstract MSI spec so I need to learn MSI spec.
It is powerful, but the curve is really steep, and it is still subject to the seemingly random, myriad of constraints and limitations - for example, there is a whole class of variables that you can only write to at certain stages in the install process.
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.
> Microsoft really needs to revamp the way software is installed on Windows, and make it all work the same way.
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.
Anything that requires an old school code signing certificate is DOA IMO. A website, GitHub account, MS account, etc. are better indicators of trustworthiness than some LLC. EV code signing certificates are a money grab and anyone willing to spend a few dollars on an LLC + certificate can distribute all the adware / malware they want.
We need a trust / verification system that's built for more than grabbing money out of the pockets of developers.
Pity Microsoft don't use it then. I've never seen an MSIX.
You could tell they were screwed when even Microsoft didn't use MSI after they invented it.
They use it extensively. The file extension isn't "msix" though.
Excellent brand awareness then. Apparently they're in C:\Program Files\WindowsApps\ but I'm denied access to that.
Great. So now we have:
* 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.
You forgot about Microsoft InTune.. basically cloud-based SCCM. It has its own packager as well. Basically wraps up MSIs. https://github.com/Microsoft/Microsoft-Win32-Content-Prep-To...
Can we add “Windows Optional Features” to that list? It’s basically “Windows Features”, except everything has a different name
Not to forget ClickOnce!
Oh God, choice! Options! They're so awful! Why don't Microsoft force one standard on everyone, so we can complain about a lack of options instead of complaining about having too many options?
Why are multiple options a bad thing? Seriously.
If there were fewer things, I probably would have had a better chance of having heard of msix.
Some people just like citing XKCD and downvoting anyone that calls them on it.
This is how Chocolatey works too for most stuff. Most Chocolatey “packages” are config and/or script files that point to the URL of an MSI installer.
Though at least it does let you update everything you've installed with it by running a single command, which is one of the nice things about 'proper' package management like apt etc.
I think their approach is a very nice start. This way it can be immediately useful. It would risk not getting any use if it was too involved to create new packages. With this approach anyone can create a package.
There is nothing stopping them from adding more traditional packages in the future.
This isn't useless. Just the fact that Microsoft decided to make its own package manager is great!
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
Please give chocolatey a try.
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 give chocolatey a try
Please don't (see my other comment for a range of reasons why).
I find scoop far more reliable than chocolately.
I don't have an opinion on the respective technical merits, but after a quick glance at the package list, it doesn't come even close. Including "essential" desktop apps like Chrome, Firefox, SQL Management Studio, iTunes, Sysinternals, notepad++, irfanview, azure storage explorer, skype, etc.
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.
The amount of software available has been my only gripe for scoop vs chocolately - but I find scoop superior in every other way.
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).
The other consideration is how frequently are the packages updated?
I don't know, TBH. I've only used scoop for new installs.
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.
I am not questioning your experience but for the packages that I used (I just counted 63 on my desktop), I haven't noticed any of these problems.
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.
scoop does a git pull to update the index.nthe Giles themselves all have various third party sources. rate limiting had never been an issue for me. Most scoop packages use regex matching on urls or page content to auto detect new versions. I think the maintainers regularly update the index based on these values, with a very active contributor community handling edge cases.
I use chocolatey, but an official pm would be better. Just the ability to install tools in a drive other than my small ssd would be nice.
I've been using OneGet + ChocolateyGet provider for that for a couple of years now. So on Powershell that's basically sudo { Install-Package A B C }. After Install-Package Sudo, that is.
These are on the roadmap: https://github.com/microsoft/winget-cli/blob/master/doc/wind...
The declarative package format on Windows is MSIX
> ... this thing literally just downloads .exe files and then executes them. There's no dependency management.
But do snap and flatpak do the same thing?
This[1] is the repository from which it pulls. It sounds like third-party repos are a planned feature. Basically, every package is a yaml file like this:
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
YAML? That’s very surprising to me (I grew up in the XML-for-everything days). Would this be the first-ever first-party Microsoft project to use YAML?
Azure (DevOps) Pipelines use YAML. Not sure if that counts?
Not sure about YAML, but I was happy to see Windows Terminal use JSON for configuration instead of XML.
https://github.com/microsoft/terminal/blob/master/doc/user-d...
VS Code also uses JSON for configuration, IIRC.
Yes, it uses jsonc (“JSON with Comments”), which is even better. :-)
using anything white-space delimited, or as verbose as XML for configuration should be forbidden.
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.
As far as I know, YAML 1.2 I think, is a superset of JSON so you could still use both. But maybe they use an older version or a custom parser...
Similar to a PKGBUILD file for Arch. It is 2020 and like WSL, it will probably take at least 2 iterations and 3 more years before this half-works and honestly as much as I want this to be successful they will have to create an entirely different package format for it to. Like EXE installers are so unpredictable already and Chocolatey does okay but packages frequently get broken and many of them are unmaintained.
At least having the package repo in a git repo removes the biggest problem (IMO) with Chocolatey, that a package owner would abandon it then never update it. Now, a package can be updated by anyone through a PR. However, whoever maintains the git repo (Kevin Larkin and some others) is likely to be overwhelmed quickly.
That is sort of how Chocolatey works already. You can modify any of their abandoned packages and submit a request to become owner. They still need to have admins or package authors maintaining packages though in order to ensure the hashes are correct. Otherwise if anyone can make a change then it will become ripe with viruses and malware.
I found the issue I think Microsoft is going to actually foul up poorly here, which I... went ahead and filed an issue on: https://github.com/microsoft/winget-pkgs/issues/288
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.
This was a bug of sorts, we’ve engaged the Java team at Microsoft to get this sorted. Disclaimer - I run the Java team at Microsoft
Good to hear. While I noticed Java as the example here, I feel this does speak to a general issue about how to handle multiple releases and some of the decision-making the Package Manager team is going to need to have in place before this leaves preview. For winget to be not just useful, but trusted, it needs to make decisions, not just be an open dumping ground for package installers.
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!
It also installs OpenJ9 instead of HotSpot which is what most people are expecting when they install the JDK. For now I'd recommend using the Scoop Java Bucket [0] if you want to install the jdk.
What's wrong with Java 8? It's probably the most widely used Java.
Java 8 is six years old. It's not remotely current. Java 14 is the current release. Java 11 is the current LTS release. Depending upon your priorities, either of them would make sense to pick as a default.
Most package managers provide multiple JDK versions, but default to the newest stable version for the default metapackage.
I worked at a consulting firm in 2019 and one client had us upgrading some legacy, but still essential, applications from Java 6 to Java 8. So yeah it’s still relevant. Enterprise systems for a slow, painful, terribly drawn out death.
You can have multiple versions of Java on your machine. Packages in other OSs usually have lists of packages they depend upon, packages they conflict with, and "virtual" packages they provide. Therefore, an app that prefers OpenJDK 14 can require it directly while one that doesn't care can require a virtual package called 'java' that's provided by both 8 and 14.
Sure, but it doesn't really look like Microsoft has a plan or implementation for this yet, and currently serves a version of Java from 2014.
Java 8 is still widely used, it seems. For example, Mojang (owned by Microsoft) still ship Java8 with Minecraft. Pretty sure 8 still gets updates in 2020 too.
Java 8 still gets updates, but you have to have a license to get them for business use (kind of like paying for extended support for Windows 7). And then things like OpenJDK fill the gap by making an open source release available that doesn't cost money you can drop in as a replacement.
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.
Latest Oracle JDK8 needs license but AdoptOpenJDK8 is still supported and free.
I'm aware. But the point is that it highlights how old Java 8 is: The original developer has moved it from being a free version to something you have to pay them for fixes to. This is similar to how Windows 7, an 11 year old operating system, gets patches at this point.
Oracle JDK11 also needs a license like Oracle JDK8. So not good a metric for how the software old. (Another example: CentOS6 still supported but free)
Hell, even Spring boilerplate generator still defaults to Java 8.
Java is 21st century's COBOL, minus the cool mainframe hardware ;-)
Oh WTF seriousry?
I'd recommend to take a look at the project's roadmap to get an idea where Microsoft is going with this:
https://github.com/microsoft/winget-cli/blob/master/doc/wind...
I'm pretty satisfied with the package manager scoop. Scoop for now works best when you just install binary software. It is not a replacement for package managers like vcpkg yet with which you can pull dev dependencies for a project.
How does winget compare to scoop? Does it replace vcpkg/nuget/conan/...?
Anyone else looking to try scoop should be familiar with this list: https://rasa.github.io/scoop-directory/by-score
I like scoop, and this is a show stopper for me.
"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
Why is that a showstopper?
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.
It's not opt-in, so quite likely a breach of GDPR.
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.
It’s logging what’s used so that the app can be improved to fit the use cases of its users.
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.
Software has always been developed that way and it has never been a problem. It’s only recently that developers somehow got the idea that they are entitled to perform surveillance on their customers. It’s nonsense.
> Software has always been developed that way and it has never been a problem.
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.
I'd consider it reasonable if there was some way to opt out, and if they made it clear what telemetry was sent - that should be in the readme, I shouldn't have to trawl through the code to find it.
Note that I'm saying this as someone that generally doesn't mind providing telemetry - but they need to be clear.
> It's not opt-in, so quite likely a breach of GDPR.
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?
In order to use those you agree to terms in advance, and agreed to data processing. That is an opt-in.
It’s really not. I develop mobile apps for clients and we collect analytics (Firebase/GAnalytics, Facebook SDK, hand rolled metrics etc) none of which is opt in. Why is Microsoft held to a different standard?
With regard to Apple or Google recording the applications users install from the store I think there is indeed an opt in.
That is the comparison I was making with the new Windows package manager.
Ignorantia juris non excusat. You or your clients may also be in breach. MS aren't held to a different standard.
I don't think that the fact that an anonymous person installed a particular piece of software is considered personal data under GDPR.
Microsoft is incredibly anal about GDPR. I doubt they’re committing a violation here.
Microsoft being anal about GDPR? It's under investigation with billions in GDPR fines pending.
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.
I don't personally mind telemetry, as long as it's opt-in, or I can at least opt-out, and the data that is collected is clear.
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 :/
A bigger showstopper is no support for removing packages yet.
Most of the responses here do a really great job at pointing out the flaws of this project. My biggest gripe is it currently has no plans to be integrated by default. So just like all the other package management tools for windows the tool itself is a prereq requiring another hoop. If I have to deal with more configuration management to install this from the app store I’d rather use chocolaty at least that can be installed reliably.
I'm not a Windows user... but didn't they already do this with OneGet? Did that get deprecated? Is this just a re-branding?
I'm a Windows user, but I've never even heard of OneGet?
This one, as I recollect: https://docs.microsoft.com/en-us/powershell/module/microsoft...
So in 199{7,8,9}? I was using yast and/or apt-get to get packages. That was >20 years ago. Now MS have offered something like tar.gz of binaries without dependencies.
But I guess this is an answer to the "where's package management" question. Still not there.
All the dependencies are just in the original thing. I have very limited experience with Linux but chasing down problems with dependencies of dependencies feels like a special circle of hell to me.
> chasing down problems with dependencies of dependencies feels like a special circle of hell to me.
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.
I don't remember. I tried to do some rails development in linux like 10 years ago. I know I was using apt, or at least started there. I don't think I ever even got the environment running. I'm sure I was doing something wrong, so no need to blame me, I already know.
Still better than the status-quo where you have different launchers auto-updating programs and programs self-updating randomly (and some just not updating causing security issues)
How does this relate to `install-package`, the Microsoft-official 'package manager for package managers' released a few years ago?
Microsoft would be much better off if they had a YAML format for creating Windows installations, as opposed to their current unattended installs.
Frankly, this is a very lame attempt at the package manager. All it does is download installer executables and run them. There is no ability to list installed packages, neither is the ability to uninstall. Where's the actual package management functionality?
Both Scoop and Choco are way better than this.
It mentions oneget, isn't that nuget now? and also by Microsoft?
It talks about installing apps. But what about DLLs? .NET framework versions?
It has been ages that the best practices are to install them alongside the applications instead of polluting C:\Windows.
Also .NET Core is supposed to be bundled with the application.
Unfortunately, this causes file duplication (which is not that bad these days of endless storage) and unnecessary vulnerabilities when outdated vendored libraries are used by applications.
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.
Which is why nowadays Linux suffers more from .so hell and ABI breakages than Windows does.
Not really? In the Debian ecosystem, at least (can't speak for any other), every major version of a library package is expected to be packaged as its own separate concurrently-installable package. You'll find e.g. postgresql-11-dev and postgresql-12-dev both exist as packages, and one provides libpq.11.y.z.so + its headers, while the other provides libpq.12.y.z.so + its headers. Each gets updates independently. One will never automatically switch you over to the other.
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.
All true in theory, but in practice these mechanisms are worthless because for most libraries Debian developers are dropping older version of libraries immediately after transition to the new version is completed. Want to to run a 3rd party binary that depends on an older library? You're favorite package was dropped during the transition? Tough luck. Your best bet is installing needed library packages from previous debian release and praying that'll work.
True enough, but if stability is your desire, that is precisely why distros cut releases (and especially LTS releases) in the first place. If you want a program that can run without ABI-conformance changes for years and years, base it on an LTS release, and that LTS release will keep whatever ABI-major versions of the .so library-packages it shipped with updated (with security updates, at least) until the release's EOL. If you don't want ABI breakage, then don't dist-upgrade!
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.
Or Docker, or Nix, or LD_ env vars. It's annoying that sometimes major dependencies don't support side by side versions (libcurl! openssl as libssl!), but the solutions are well known and relatively simple. And much more maintenable than a Windows box.
Haven't seen that in ages, but, then, I try to avoid installing packages from non-official repos. Distributions work hard to make sure that everything within the distro ecosystem is self-consistent.
Exactly, if you're not doing anything interesting you'll never notice, but the second you step out of the distro's box and do something crazy like try and install a new version of software direct from the developer, install a second version for testing, or run software compiled 10 years ago, the world falls apart.
> if you're not doing anything interesting you'll never notice
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 > {} \;`.
Never had a single issue with official repositories.
fwiw, on Windows MSIX deduplicates identical files across all package installs.
It gives rise to some interesting issues - if program A wants to update IMPORT~1.DLL that was installed also by program B, what happens if B requires a different version of IMPORT~1.DLL?
Then they'll no longer be identical, so they'll go back to having separate files.
They don't, because MSIX introduces UWP sandboxes also for Win32 applications.
In other words, because runtime dependency management is terrible, Microsoft added a core feature to the OS.
Yeah, lets pretend SNAP and Flatpak don't exist.
No, but we can pretend they are a good idea.
I’m sure the developers of Chocolatey have been dreading this day for years.
Depends on how good the Microsoft implementation is. Afaict, mainly power users use Chocolatey, and they're going to be particularly critical of a solution that is half-baked and doesn't solve the problem as well as an existing, third-party solution that they're already using and they're already used to.
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 think most power users switched to scoop, because chocolately is... not great. Scoop is much better, but has a much smaller list of apps.
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.
scoop and scoop extras (https://github.com/lukesampson/scoop-extras) covers pretty much everything I use on Windows. I didn't realize the other repos existed for a while, but once I did, I got rid of choco entirely.
I wasn't aware of scoop extras until you mentioned it, so thanks!
> 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.
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.
Not tried scoop, but not had many problems with choco, installing stuff on 100 machines at work, made a smb share to store the package files, wrote a script to grab xml files based on machine names of lists of things to install.
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
My gripe with Chocolatey is just that I can't set a non default dir. Everything is installed in my small SSD.
You can probably work around it using reparse points https://en.wikipedia.org/wiki/NTFS_reparse_point
E.g. just move all the files where you want them, and create a directory junction/symbolic link.
sure, but I have to do it manually for each one. Who has time for this?
Oh, I thought you want to put all chocolatey packages on a different drive (in which case you'd just move the root folder).
You can change the installation directory, but you need pay for it
https://chocolatey.org/docs/features-install-directory-overr...
Dreading? I doubt it. It's a relief when the problem your library solves no longer needs solving!
No, can't you see? Microsoft is going to Embrace, Extend, Extinguish Chocolatey!!! /s
If it was just a free library that would be one thing but they have a company with multiple employees.
I won't say it was silly to ever make Chocolatey, but it was living on borrowed time from day one.
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.
Still lame that Microsoft has been waiting that long to deliver such a basic functionality.
Kind of like the .net framework celebrating its first json serialization library in the CLR a couple of years ago. Welcome to 2010!
I suspect third parties will continue to do this way better than Microsoft, to be honest. Microsoft can't pick winners and losers, they can't offer an opinionated system, which package repos generally are, without being monopolist.
Software management on Windows is such a mess.
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.
UWP and MSIX are/were intended to address the problems you mention
Do you need a microsoft/whatever account for this? I can't see anything about it but wouldn't be surprised if they forgot to mention it...
I'm interested to know whether the SHA256 hashes are just done on a TOFU basis, or whether they actually verify the Authenticode/GPG signatures of the EXE files to get an 'authoritative' or 'trusted' hash.
What about uninstalling apps?
Maybe the most exciting thing I've heard so far from Build 2020.
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.
Given that edge is just chromium now, I'm curious as to how an edge headless runtime would differ from node or electron
Is this an msi hiding in a wrapper? Anyone who has dealt with the innards of an msi file knows it's a dog's breakfast!
Are they doing any form of caching (think CDN) to battle link rot?