However, the core problem with Windows software is there isn't a primary software repository for all approved and tested software, like there is for *nix platforms. Ideally that's what needs to be fixed first before yet more client-end installers get created.
To fix this, based on the current landscape, all third-party client-end installers need to support all existing third-party repositories. Even better, everyone agrees on a standard JSON format (or whatever) for their repository manifest and all third-party installers understand that. Then just like Linux et al. all you have to do is add the new repository URL to your installers config, and all the packages advertised within are immediately available.
It seems really simple to fix - but people have to co-operate.
Windows uninstallers and cleaners became a whole industry by itself.
Scoop is, I believe, the best solution we can hope for.
The MSIX format is supposed to support everything MSI currently does soon, and has preview support for even Windows 7.
> However, the core problem with Windows software is there isn't a primary software repository for all approved and tested software, like there is for -nix platforms. Ideally that's what needs to be fixed first before yet more client-end installers get created.
This is certainly a goal of the Microsoft Store, to be a central/primary software repository for Windows software. Sure, it has the "ugliness" of also including all the fun monetization things that -nix can often ignore because FLOSS doesn't necessarily have to worry about paying the bills in quite the same way. But it seems silly to me to turn down the usefulness of a "primary software repository" simply because it also doubles as a retail store for proprietary/closed-source software.
Beyond that, there probably isn't a huge demand for a command-line installer or other package manager. Most consumers wouldn't know how to install via the command line, and most enterprise environments will have images with necessary software preinstalled or push them out through SCCM or other such management interface.
All of these attempts at alternate installers really only seem to appeal to developers, but in the scheme of things, there are other more pressing concerns even for them.
Is there an apt-like command line interface for the microsoft store?
scoop uses portable binaries provided from the original source. For many people that's good enough.
Maybe chocolatery is more to your taste.
EDIT: I forgot that it can also verify checksums, there is obviously value to that.
Having been doing Windows development since Windows 3.0.
I have been hit by such errors, which on my case were caused by .exe installers.
Once I didn't have enough space on a flash drive to install Windows via an ISO...but I did have a liveboot ubuntu system and 2 spare drives. Interestingly enough imagex and WIM tools were ported to linux, and it was a surprisingly easy experience.
"Used to implement the HPFS extended attribute under NTFS."
Is your complaint is that the tools that are used to make the image of the installation files of the Windows don't include that? I assume that $EA entries don't exist in the installation files of Windows, for which the DSIM tool is used (and it's surely not an universal backup tool).
And how do you read or write these? And what do you use them for? I was able to find only ZwSetEaFile and ZwQueryEaFile which are documented for kernel-mode drivers? Are there any plain user-level API's? https://attack.mitre.org/techniques/T1096/ I also find: "it may (be) worth noting that Windows does not contain any api that can be used to remove extended attributes."
Other stuff does too, e.g. https://docs.microsoft.com/en-us/windows-hardware/drivers/if...
Those are user-level APIs as well, though usually called via NtQueryEaFile and NtSetEaFile.
And (part of) my complaint is that DISM's /EA flag is broken.
I'm also looking towards using the winre partition to store wins and some kind of iterative snapshots for PITR recovery.
Any suggestion is welcome!
Get-PackageProvider -name chocolatey
We ended up changing provisioning scripts to download .msi installers directly and run them with appropriate switches.
I also remember their website having a lot of "maintainers required" notices - I got the impression that the situation was a little desperate.
Has package quality improved? Is Chocolatey a genuinely reliable way to install software, now?
I'm not sure about the maintainer situation. Some packages get updates quite regularly while other packages are always a few versions behind the latest release.
As someone else notes, weirdly Chocolatey's packages seemed to get worse and grow staler after the Kickstarter than before. I guess in hindsight it's about where I stopped feeling an interest in volunteering to help packages, but I'm not sure if it was subconsciously about "what was the Kickstarter money for?" or not. I feel it was more the "kitchen sink" problem that hurt my interest in Chocolatey most directly, because those maintainers would happily sit on the most common name for an application (say, "python") with their kitchen sink, wouldn't take suggestions to better their packages and then you just ended up having to wade through search listings for "slim-python" or "real-python" or "just-python" or "brians-lite-python" or "python-dave13". It stopped feeling like a helpful community and more "every developer for themselves" at that point.
Is there any drawbacks to this considering this installation method isn't listed on the installation page on their website?
The closes I found to this installation method was:
"When you have Visual Studio 2010+ and the NuGet extension installed (pre-installed on any newer versions of Visual Studio), you can simply type the following three commands and you will have Chocolatey installed on your machine."
Just run with scoop. It’s very tasteful, and even makes powershell look attractive.
Linux has hardware compatibility challenges and software with bugs, but so does Windows. I don't, however, have to search through monstrosities like Download.com. I don't have to figure out what software may have a new release that is important to me. Critical dependencies are handled automatically. Every distribution may handle these in slightly different ways but these basics hold true.
Every time I've had to use Windows I've spent an enormous amount of time searching for and installing things. Once installed I then discover the software has changed to a limited free trial or some other nonsense that ends in another search, install and disappointment loop.
It's tools that have shown up in the last few years like scoop that have made dealing with Windows at least somewhat tolerable.
Most Windows applications, however, are fully self contained. They ship their dependencies right inside the installer. The key insight behind scoop is that on Windows you don't need a dependency manager. You just use need something that can download and extract installers without all the next, next, ok nonsense and without needing admin rights.
So that's scoop. It downloads an installer from the program's website, extracts the files to a directory under your homedir, and sets up a few PATHs and symlinks.
It has no repository that needs to be hosted and maintained: after all, installers come straight from the source. And the definitions of which program can download which version from where and what should happen next are tiny JSON files managed on scoop's GitHub repo. Want to tell scoop about a new version of your favorite program? Create a PR.
Chocolatey is a great effort that has taught many Windows users that yes, we can have that apt-get goodness too. But I hope that Scoop takes over as the de facto install-software tool. It's so much simpler with very few downsides. Its design is spectacularly good.
Scoop doesn't even (currently) have the concept of package maintainers. Anyone can make a PR with bumped versions or other fixes (though I understand that as Scoop's popularity increases, some cracks in that model are starting to show).
It's usually dependencies on other programs, eg scoop itself depends on git (to pull install instructions from GitHub). That's different than having a system wide shared libffmpeg.
- Installs to ~/scoop/ by default.
- No UAC popups, doesn't require admin rights.
- Doesn't pollute your path.
- Doesn't use NuGet.
- Simpler than packaging.
- Simpler app repository.
- Can't always install a specific version of a program.
- Focuses on developer tools.
Choco can do that (not that I am affiliated). Also, I like my "path being polluted". The least these programs can do is symlink to a single binary directory so I can run them from anywhere.
Simpler repository is just a euphemism for- we have little.
As an end user I have no business whether it does it doesn't use nuget.
I'm not trying to diss - I respect and appreciate not players in this space but its important to say it like it is. Also, given how "open" choco ecosystem is- I'd love to see non-official tools on top of that.
The question for me is, can I get all the VS build tools, python 2.7.x and 3.x, git for windows and node.js all installed and where it will work from a command prompt with scoop? Setting up a new developer is the primary use for the scripts I have currently. I have one for windows (chocolatey) and one for mac (homebrew), I wouldn't mind if the one for windows was cleaned up a lot.
It also seems pretty slow, having to download stuff to even tell if it can install a package.
Yes, and scoop does exactly that! Everything is added to the path, and if you do like how it’s added to the path, you can easily modify the JSON manifest and submit a PR. The community is thoughtful and considerate but generally against bloat.
Scoop also adds shortcuts to the Start Menu.
There are some proposals on the table (and have been for a while, without much support) to do more customizations like context menu modifications, but some applications (like VS Code) at least give some instructions for adding that yourself when you run the install.
Chocolatey packages are pretty complex , and even worse is the automatic system  used for building the main packages , which tries to keep everything updated. There's a very steep learning curve if you want to contribute and fix packages.
Contrast to the simple manifests in the scoop main bucket  and it's looking much easier. There's some variables there for auto-updating that aren't immediately intuitive, but it doesn't look nearly as complex as chocolatey.
Between the extras  and other community buckets  this is looking pretty compelling -- can't believe I've never heard of it before.
Also frankly, Chocolatey’s repos have become a mess, full of broken and untrustworthy software, and I just do not trust giving it admin permissions anymore. I don’t know what it is about windows software distributors that seems to lead all of them down this road, but I hope scoop can hold out...
I do kind of wish that scoop used ~/AppData/Local/scoop instead of ~/scoop (from other comments). Looking into it more, it's interesting. I just didn't get a lot of insight from the home page in the post link. But I do agree with most of the troublesome issues with Chocolatey mentioned in this and other comments.
I had a great experience, especially after adding the “extras” bucket. The last time I tried (a year or more ago) I found a lot of apps missing. Seems that has improved quite a bit.
The best thing for a Windows packager would be some kind of automatic change detecting site powering it -- so if there's a new release for WinWidget appearing on the Download section of Frobnicorp. Inc, the recipe for the previous release is tested and updated.
I'd rather just have a clear and concise README. Better yet, if vendors distributed their applications as single bundled EXE files like back in the day.
Don't take this the wrong way, I haven't used scoop and I have nothing against it. Just wish there weren't a need for it.
I can't seen to find it, but does such a UI already exist?
It's a common web interface on top of many package repositories, including this one.
Any thoughts on this installation method?
iex (new-object net.webclient).downloadstring('https://get.scoop.sh')
The windows filesystem still makes no sense but that's an NT issue (dropbox cant sync con.sh???). SSH has a surprisingly native feel but graphical apps (vim, screen) still have rendering problems, and the ssh-agent daemon isn't set up right by default.
Until they make Windows LTSC unusable, it's not _too_ horrible right now. But for a serious programming project there's still no question for me (but fix your damnable sound drivers Ubuntu).
Apart from the fact that the MinGW port of pacman is designed for the MinGW environment only, and therefore doesn't necessarily integrate all that well with the rest of the Windows system, the packages it provides are mainly ports of software from other systems (chiefly Linux and BSD) rather than native Windows software.
Doesn't seem all that relevant.
Is the leading line in the motivational paragraph for this tool, and its example usage is
> scoop install curl
Your comment doesn’t seem all that relevant.