Looking at https://keivan.io/the-day-appget-died/ and https://github.com/microsoft/winget-cli/milestone/5 (seven months late and that's just 0.3) with a nod at https://i.imgur.com/gADLhSW.jpg I'd say someone recognized the lack of package managers at Microsoft and various underlings came up with solutions. One was the Andrew mentioned by Keivan who basically wanted to acquihire Keivan/AppGet but he lacked the clout to do so. Another was a manager, let's randomly call him Bart who decided to build an in house solution, grabbed a few people and created WinGet. While Andrew couldn't make it, Bart also didn't manage to secure enough funding to reach his goals so we are now in this cursed state where AppGet is gone, and Bart's team is very slowly moving along so no good solution is available and frustrated by the lack of results Bart might get shut down any minute...
Keivan is the only one who ever mentioned "acquihire". Microsoft never did so... because there really was nothing to acquire! Keivan made grand statement about his idea being patentable but that he, in the goodness of his heart, decided not to patent anything but... package managers have been around for a long time now so there is really nothing to patent.
Reading through the AppGet code, it basically reads a XAML config with install instructions. CS101 project basically. Seems like he failed his PM interview pretty bad.
Now, all that whining did give him a lot of exposure for his startup here on HN...
Thanks, the URL I had is long dead https://bonkersworld.net/2011/06/27/organizational-charts and so I wasn't even sure whether that's the original author -- for all I know the website could've been replaced by someone else's since. Thanks, we should always give credit where credit is due.
That's what you get when you stop enforcing antitrust laws. Microsoft can make WinGet free to the end user because they are subsidize the development from the sales of Windows itself. Because it's not a major niche, they don't care much about it and won't assign much resources to deliver an excellent product. But having them maintain a free solution bundled with the OS discourages anyone else from stepping into the niche with a much better to use paid tool. So it's a stalemate now.
It's a small example and the annual market for Windows package managers could be less than a single team's budget, but the same holds for virtually every niche these days. Subsidized solutions offered by the pre-2008 companies with little chance for independent competition. We are not going to remain an innovative economy unless we find a way to crack down on this behavior.
I don't think there's a problem that an antitrust intervention could help solve, rather a lumbering hierarchy where the people who make the decisions don't understand or care enough about the niche.
Microsoft wants to attract developers from other platforms: Windows native code supporting no package managers that are all of good, general and fast is just the kind of situation that will make developers who come from other platforms hate the time they spend with theirs.
Microsoft's real interests don't seem to be the problem here: Windows losing its best package manager only hurts what they want to achieve.
serious question, what is stopping someone from restarting AppGet? all the source code and manifests seem to be on github, is there some backend server that isn't open to the public?
If Microsoft shifts gears they will annihilate you. Would you want to work on something with that threat looming over your head?
It is a no-win situation: if you do nothing, MS will continue doing little, if you push, then you risk them getting their ... together making your work irrelevant. I put this paragraph here because I don't want people pointing at this a year from now "you were wrong, we did nothing and see WinGet is still nowhere".
nor will it be the last time this giant, like many others do the what i call the "ole" shaft in the exit area.
My best advice, after learning after getting screwed by MS and Oracle. Lets call him Jim, partner of mine, and a fictional company lke Krackle.. They sued until discovery found something the engineers did..... running our version while developing competition. They sued because ours "processed too good" and "we had to copy them". Once the judge was showed the emails where they were DISASSEMBLY the pcode and sharing the map.
We got a fat check, and offered to buy us out. Jim and I retired from a 39k c app that till this day, most, if not all hospitals use
WinGet is more like a "software center" of "application store" compared to what I understood a "package manager" is. From my understanding, a package manager should take care of the installation process: (optionally) compile the source and test them, copy the files to the system and run optional scripts and hooks. Most importantly, a package manager records all files that are installed and knows which file belongs to which package. When uninstalling, a package manager should remove the files by itself and make sure the software is uninstalled safely and completely. What WinGet does is just download the MSI or whatever setup binary and run it. It is more like a software index and downloader rather than an actual package manager.
The MSI infrastructure already does most of that... there really shouldn’t be much need for all the other stuff. Windows isnt like Linux where programs spew files all over the FS. Programs stay pretty self-contained to their part of the registry, program files, and the user profile data directory
If application developers actually use MSI(X) instead of Nullsoft/InstallShield/Inno/random homegrown EXE installer that spews stuff all over the FS. I've been contributing a lot to the winget repo, and well over half of the applications (including Microsoft(!) software, including Office, Visual Studio, Teams, and VSCode) do not come in a MSI.
It's been a gigantic annoyance for the people at Microsoft as they are trying to figure out how to do upgrades/uninstalls without the data you'd usually get from a deb or whatever.
As a Windows sysadmin I pine for developers to use MSI. Having applications managed by the Windows Installer makes automated installation, removal, and repair so easy. MSI has its warts, to be sure, but "clean" MSIs (that don't rely on lots of custom actions, embed binaries that the just execute, etc) are a joy to work with.
How well a software developer / "manufacturer" deals with "setup" in the Windows ecosystem has almost always been a proxy for overall software quality in my experience. When "setup" is left as an afterthought I can usually expect other corners have been cut. When I see a custom binary running an installation I start thinking "brown M&M's".
As someone who dabbles in Windows desktop development, I still don't know the best way to even make an MSI. Some of the tools from Microsoft are usable but they all seem to be obsolete.
The preferred solution seems to be WiX, which was created by some of the people behind MSI and generates the MSI database from an XML description.
Unfortunately it requires you to write (or copy from somewhere) literally thousands of lines of incomprehensible XML. You have to learn all the details of both MSI and the various novel sublanguages embedded in the WiX XML.
But fortunately you can generate all the XML from just a few lines of nice and clean C# using WiX#, which adds a user-friendly API on top of WiX and lets you forget about XML and databases entirely:
https://github.com/oleg-shilo/wixsharp
The perspectives in the comments on this article re: WiX XML source and Windows Installer being difficult are interesting to me. Like I said elsewhere, I overcame that learning curve so long ago that I can't put myself in a position where it seems daunting now.
To be fair, though, an MSI to install a 10 files in "C:\Program Files\AppName", register a couple .NET assemblies, create a couple of shortcuts, and throw a few values into the registry would amount to <100 lines of XML.
I've only seen "thousands of lines" of WiX source when dealing programs that install a ton of files, or put scads of entries in the registry.
Most of the MSIs with WiX are based on a simple skeleton generated from a template, and using "includes" generated by the "candle" tool.
Understanding the Windows Installer and the WiX source feels analogous to what I see in "modern" web development-- a bunch of tools that developers use, seemingly without understanding what they do, to create a massive pile of edifice into which original code is finally placed.
If you start from scratch, I'd suggest to use MSIX [0] instead. It makes auto update trivial to implement with PackageManager.UpdatePackage(url_to_your_msix)[1] or plain execute via "ms-appinstaller:?source=url_to_your_msix". It'll do diffs properly and you also get package reflection for free via WinRT apis (such as where app is installed, appdata location, app version, etc).
Assuming I'm not building a UWP app, how do I build an MSIX. The only thing I found was the MSIX packaging tool and the description is this:
"You can run your desktop application installers through this tool and obtain an MSIX package that you can install on your machine or upload to the Microsoft Store. "
I need to look into MSIX. MSI has been handling my needs for awhile now but I hear MSIX is really nice. Thanks for the nudge to look in that direction.
I use the WiX toolset[1] to build MSI files. I can't comment on the learning curve, though. I've been using WiX for far too long to remember what learning it was like. I find MSI files and Windows Installer itself immensely valuable, so I can't imagine using anything that doesn't generate MSI files.
When I used WiX, I found it very... clunky? Everything in XML, lots of attributes to fill out, etc. And, at least when I was trying it out, the generated MSIs didn't appear to have any sort of GUI (or so I read. I don't believe I ever got to the point of generating an MSI).
I will say though, I remember the documentation being helpful and fairly straightforward, if a tad large (but that's what you get with a tool that's supposed to solve a complex problem).
InstallShield can, but they're not particularly nice MSIs. I remember an old Symantec Antivirus MSI (2005-2006 timeframe) that used InstallShield's "ISScript" which ended up not being capable of being uninstalled in an automated manner. It was a pain. Search-engining those keywords today shows me that ISScript-related problems persist.
Linux does have some weirdness still where apps occasionally put files in the same directory not just under the same directory. You have the same separation in windows as in linux mostly (user data, app data, app binaries, settings, startup ...) but on windows all of those are directories per-app under the folder in question. Like %ProgramFiles\MyApp, %UserProfile%\AppData\Local\MyApp or %ProgramData%\MyApp for example.
btw. with msix or flatpak things did change significantly. well microsoft does it a little better because production msix create a kind of sandbox appdata/storage.
And the package manager knows exactly where all the files are unless they are just config files, which are generally in .config or .local/share, and they are a lot easier than to track than the Windows registry.
That's true for legacy MSI. MSI comes in two versions now. There is also MSIX.
MSIX is actually quite good. Apps run inside a semi-virtualised container, so that writes to the registry and AppData are redirected. Uninstalling the app therefore uninstalls all of it, even if the app doesn't cooperate. MSIX can also be upgraded automatically in the background by Windows itself.
Scoop is my favorite tool of this type on Windows, but it's not a package manager either[1]:
> Simpler than packaging. Scoop isn't a package manager, rather it reads plain JSON manifests that describe how to install a program and its dependencies.
I haven't tried WinGet, but Chocolatey still seems like the best package manager on Windows. Which is unfortunate, as it's very unfriendly to use, promotes their Pro plans too agressively, and like the article says, slow.
Struggling to see the difference with chocolatey.. both do the same thing: download some binaries and install stuff, run arbitrary scripts for whatever they need, track dependencies, versions, etc.
In fact it took far too long for chocolatey to even consider _uninstall_ that it was a total mess for years while maintainers played catch-up.
The biggest difference is chocolatey is designed around admin installs. Even the command line tool needs to be run with admin rights. The advantage is things are installed the way Windows expects.
Scoop, by contrast, keeps everything user level and installs programs to its own folder in Documents aiming to portable.
Scoop is a fair amount simpler and doesn’t have any sort of pro version to upsell you on. Scoop’s catalog is smaller but still pretty well managed.
The link mentions the differences, though they obviously target similar functionality.
One key difference is that there's no such thing as a Scoop "package", unlike with Chocolatey. You can't build a file that can be moved and installed offline, since Scoop downloads and extracts it from a URL. I suppose you could setup a local proxy and workaround it, but it's not the main use case.
I use both since Scoop is limited in the installers it supports, preferring Scoop when a program is available there.
Scoop mostly doesn't run installers, the convention is to extract the files manually, put them in a specific directory, and symlink persistent files to a different directory. Additional installation steps are either automated based on the declarative manifest (shortcuts, CLI shims), or are defined as powershell scripts in the manifest itself.
There are some manifests that break it since they absolutely have to (like the VC++ Redist), but for most of the apps, Scoop actually acts a whole lot like a package manager.
There is Chocolately too, but I've never been a fan. The website is horrible for one thing, but there are 2 big problems: package updates sometimes take forever, and there are frequently multiple "versions" of a given application, made by different people - how do I know which one is the better quality, and how do I know which is more likely to be updated in future?
Multiple packages with the same name is due to popularity of the platform. Not really a chocolatey problem per se - you have that on other known managers too. You can use one with most downloads.
Updates take forever ? What does that mean and why would you care tbh if it takes minute more or less as it is unattended ?
> Multiple packages with the same name is due to popularity of the platform. Not really a chocolatey problem per se
I mean, it is a chocolatey, because they allow multiple packaged for the same software. I don't have this problem with scoop.
> You can use one with most downloads.
Sometimes it's that simple, but other times there are material differences between the packages, or multiple packages with about the same number of downloads. And then in the comments for package A you have people saying "this is rubbish, use package B instead!"... and of course, in the comments for package B you have people saying "this is rubbish, use package A instead!". Honestly, I can't be bothered with it - package managers are supposed to make things easier.
> Updates take forever ? What does that mean and why would you care tbh if it takes minute more or less as it is unattended ?
I didn't mean the time the actual install took, that's clearly nothing to do with chocolately - I meant that packages are often not updated by the maintainers.
> I mean, it is a chocolatey, because they allow multiple packaged for the same software.
I think this is more healthy then having one with maintainers refusing to do stuff you may need. The real thing would be for vendors releasing packages but we are far from that in Windows land. My hope for MS WinGet was that since it is backup from MS that vendors will adopt it, but since it sucks, this will probably not be the case.
> I meant that packages are often not updated by the maintainers.
Yeah, that was the problem far more before then today. I created AU to solve that issue [1].
- It's difficult to get Explorer shell integration to work.
- Apps are not installed in their expected locations, so Git Extensions won't recognize Notepad++ unless you tell it where it is.
- (the worst) Every application has at least 3 different EXE locations: the EXE in the shims folder (added to PATH, spawns the actual application as a child program), the EXE in the "current" folder-symlink (pointing to a specific version), and one EXE in every version's folder. And if you pin one of these to the taskbar, or associate a file extension to one of these programs, subsequent updates or app launches might open a different EXE that gets mapped to a different taskbar icon.
You make it seem like a huge PITA, but in my experience it's not so bad at all.
Explorer shell integration works just fine for me (7zip etc.), what app is giving you problems?
The fact that Scoops installs apps to a specific location may be sometimes problematic, but it's also the thing that makes Scoop great. In reality it's mostly stuff like you said, a one-off process of setting the current path.
The rule of thumb for the shims is to use the path with the "current" symlink. The exe in the shims folder is just a shim for CLI use, and version-specific folders are there just for updates/rollbacks. Windows may pin the "version name" path instead of the "current" path, but Scoop actually creates correct Start menu entries for GUI apps automatically (so you can pin that) or you could manually edit a .lnk's path and pin it.
7-Zip allows you to create Explorer integration from the app itself, so it's unaffected.
VS Code (Codium), Notepad++, possibly Git Extensions, forgot what else (maybe Windows Terminal) create Explorer integration if you check certain boxes in the installer. And Scoop skips the installer, and you can't add integration after the fact.
The Scoop GCC manifest (and everything that depends on it) has been broken since January. GCC for Windows is now distributed using an unsupported archive format, and development to support that format has stalled out.
https://github.com/ScoopInstaller/Main/issues/1752
One of the maintainers seems to be forking the scoop client, but their fork still uses the unmaintained main package bucket.
https://github.com/Ash258/Scoop-Core
I'm pretty unhappy with the behavior of the maintainers to the author, though. There are better ways to suggest issues with documentation than just "this is a lie", and better ways to say a function name could be better than "is a horrible name". I also think it's rude to ask for a patch to be completely rewritten and then ignore it after the author does so.
The maintainer you are referring to isn't one of the original maintainers. It looks like they are missing in action, but for what it is worth, I never saw them respond in this way.
Looks like a frustrating choice between a polite maintainer that isn't around or a rude maintainer that is still active.
Ash258 is not one of the official maintainers, but he's a very active member of the community (more active than the actual maintainers), commenting on most PRs to official buckets and maintaining his own bucket https://github.com/Ash258/Scoop-Ash258 as well as a Scoop fork https://github.com/Ash258/Scoop-Ash258 with many improvements and issue fixes over the upstream. He also mods the Scoop Discord server.
However, his comments are often harsh, like you noticed. He's mostly on-point, but is very quick to rudely shoot down anything he disagrees with. Also he bans discussing or even mentioning his fork of Scoop on the Discord server, which is super weird since he put it publicly on GitHub in the first place.
Interesting. I haven't had any issues with scoop in a long time and the manifests continue to be updated, so I had not even realized the original maintainers had gone quiet. It would be a true shame if this project decays without a successor or official word from the maintainers.
Scoop is maintained, but just... really slowly. It's a shame. For example it took more than a month and two maintainer pings to merge an absolutely trivial PR to add Python 3.8 (a single character change over the Python 3.7 manifest): https://github.com/ScoopInstaller/Versions/pull/226
For the most part, this does not matter. Most of the existing stuff is already present in buckets and auto-updated by CI. The problem is just when something breaks or something new needs to be added, which can take a non-deterministic amount of time.
Also Scoops makes it super easy to add 3rd party buckets and even install stand-alone manifests published on a HTTP URL (so even update is working). If you really need something that has a PR but is not merged yet, you can install directly from the PR and just change the source once it's merged, which is just a small hassle.
Notwithstanding all the benefits of a package manager, it's always seemed to me like it's not a very idiomatic way to manage Windows apps.
I wonder why after all this time Microsoft hasn't created an API to allow applications to register background update checks, like for example allowing applications to hook into the Windows update process or something. That seems like it would be more intuitive for most Windows users than a command-line package manager.
Of course they have some attempts at this but they don't cover every kind of application. Like ClickOnce (only for .NET) or Windows Store (only for UWP)
> allowing applications to hook into the Windows update process or something
I really want this. I have several game launchers installed and it's a pain to want to play a game and realize there's a multi gig update you need to install because you haven't run the launcher in awhile. It would be nice if there was a central component that kept everything up to date but didn't require the software to live in the windows store.
Chocolatey is quite good as well and in my opinion it does what it is supposed to. It only supports NuGet v2 which is becoming a problem, but being a open source project it's anyone's guess when improved NuGet support will be available.
The big win with WinGet is mostly that it is a proper supported solution backed by Microsoft. But WinGet seems to require some more months before it is ready for primetime.
WinGet was announced less than a year ago and is still in preview. The main critiques in the article fault WinGet for lacking features that are under development. I would also love to have WinGet working fine yesterday, but it seems like Microsoft is actively improving it.
Except why not build on AppGet, or acquire it? I mean they kinda half-tried, it's an interesting read [0]. Microsoft has tonnes of money. They could have probably bought AppGet outright (I assume that since the author shut it down, they weren't too attached and MS could've bought it out), saved a lot of development time/money, had something that worked, and gone from there.
There's obviously more to this story, but it just seems like Microsoft don't value DevOps/automation (true from my experience trying to do CI on Windows). Think about how many man-hours both inside Microsoft and outside are being wasted by WinGet not doing these things. A colossal waste of time. So yeah, from my perspective, the criticism is entirely justified.
One thing I don't like about the Apple/MS ecosystems these days is that major pieces or open source now are pretty much required for most developers to do their jobs. Yet both seem to hold hostility to open source solutions. So some still believe in MS that open source is the devil, especially if you've spent 20 years in that mindset.
Example:
25 years ago in college, ssh was getting popular, and became the de facto connection tool a couple decades ago. Only in 2018 did MS finally add it to windows.
I don't want to go too much into Apple, for sure there's some things to be worried about and keep an eye out. But at least it's POSIX, so driving CI isn't awful. I agree Homebrew is a godsend though
In reality homebrew is a third-party crutch to make a broken system more palatable for developers.
To my knowledge homebrew hasn't received one cent from Apple, yet most of the developers who use Macs use it. Yet, Homebrew is probably directly responsible for driving a significant amount of sales to Apple.
And it also looks like with winget, microsoft wants to push people to use the awful msix, where everything is locked down, much harder to edit and change and patch, much more complex.
It's the opposite of scoop, where everything sits in a single folder, and you can get rid of it easily, and even monkey patch and hack things.
Winget is beyond terrible. The concepts, features, no scripting, pace of development, are all beyond even one-man-foss projects. I was happy to see MS developing this but I guess it was overly optimistic stance.
So far chocolatey is the only mature one. Scoop is nice too, but it can't really compare with it with number of packages.
I was following this project when it was initially released. It was primarily written by one guy who left the project right around the time that it shipped in Win10. Some new people came in and basically no development or promotion happened on the project since. I wonder if it was a political thing.
Anything related to windows command line or automation is flimsy and you never get the same results. Administering windows build environment makes me want to cry.
Have you tried powershell? I haven't used it in a while, but it was straightforward to automate stuff while being in complete control of what was happening. The object oriented aspect of it lent itself very well to object introspection and seemed pretty intuitive.
The only reason Microsoft makes any effort, even if abortive, is that other systems have very successful package managers. Best of breed, until recently, was Debian's Apt, which has worked well for decades. Lately it is beginning to be eclipsed by Nix and Guix, which automatically manage multiple versions of libraries installed simultaneously, for subsystems that need specific versions.
Dependence on windos was always an exercise in masochism. But it is easy enough to switch. You can still run any old windos programs you still need, under Wine, typically faster than native; or keep windos VMs, one per app.
every once in a while i flirt with the idea of installing windows 10 on my laptop thinking maybe it's better... then i read stuff like this and associated comments and quickly dispense of the idea.
why doesn't windows have real package management yet?
I honestly have an easier time installing software on windows than I do on Linux. This is in general when it comes to many tools. I know package management seems like a solved or "mostly" solved problem on Linux as opposed to windows, but its not all rainbows and butterflies.
Just a small example I encountered just recently: Look at the install page for docker. Curl, pipe to some random folder, mix in some sudo access, then finally can I "install" the docker package.
That is mostly due to the company (Docker) not doing it the usual way. Normally they should have a build server, and then have a few line install. First is to add their repository, second is to install the software. From then on you just use your normal distributions update system. (Such as for example https://software.opensuse.org/download.html?project=hardware....) The real issue is that many companies choose to not do it the right way, and instead come up with weird new installation ways. When they do the same on Windows it just works because there is only one Windows, but there are multiple Linux distributions. As Windows begins to support Arm, and Apple moves to Arm (meaning more targets to support), I suspect that currently Linux specific issues will become more universal.
I totally agree. I'm amazed by how opaque and difficult to understand the process to create debian packages is because of all the various layers/helpers/tools that can/should be used in different cases and the difficulty in customizing things. There's a slew of interacting tooling (`dpkg`,`dpkg-buildpackage`, `debhelper`, each of the debhelper `dh-*` helpers, `sbuild`, `pbuilder`, `git-buildpackage`) that all has different documentation of varying quality, some of it replaces other pieces, etc.
My best experiences with packaging on linux have been gentoo ebuilds & arch pkgbuilds. These keep the build model pretty straight forward if the goal is to "just build a package".
That said: creating a dpkg is not an impossible thing to do. It's just more painful than it needs to be
1. Docker doesn't have to create anything ‘from scratch’ to package for Debian, Ubuntu, etc.— it's already in Debian
2. They are running their own apt repos already anyway! The thing the grandparent commenter is complaining about is part of normal apt usage. It's not a manual installation of some piece of Docker, just a normal part of configuring apt in order to install something that is, in fact, properly packaged.
> . Docker doesn't have to create anything ‘from scratch’ to package for Debian, Ubuntu, etc.— it's already in Debian
But the version is fixed per Debian release, which means that by its EOL it will be obsolete ( it's Docker, not a database, having the latest and greatest is a huge bonus). The whole point of custom repositories is to ship independently of the OS release cycle.
This is where Flatpak and Snapcraft can help you out. Just bring all dependencies with the binaries. But then people complain that dependencies aren't up2date and how they're a security nightmare because they aren't packaged by the Debian team.
That's the same as the version in the latest nixpkgs unstable:
nix search nixpkgs '^docker$' 15:41:11
* legacyPackages.x86_64-linux.docker (20.10.2)
An open source project to pack, ship and run any application as a lightweight container
Also, afaict Nixpkgs doesn't expose any unit files for the Docker daemon, so it'd take a bit of monkeying around with a new package definition to expose the one from the Moby source so that you could use it on some random distro (or you could write your own). Nix doesn't currently have any system-wide module system for managing services on non-NixOS Linux, unfortunately.
Both docker and flatpak are quite new in comparision to APT. Nix isn't really new, but gained traction lately, so in comparision to APT i would say It too is "new". We're not there yet, but i i believe shipping your dependencies with your application is how it'll all pan out for a lot of things. Even if it's a security nightmare not being able to update the dependencies for the entire system.
EDIT: And being new, there facilities aren't as mature, userbase smaller, so not enough work is put into packaging the latest versions. Since they also take on the goal of sandboxing the barrier for entry might be higher.
In general, Nixpkgs is very up to date. I'm a little surprised that the latest point release of Docker isn't in the master branch already. Maybe that's because emphasis is elsewhere for the upcoming NixOS 21.05 release at the moment.
But I think the main barrier to running Docker from Nix on non-NixOS is the lack of a systemd unit file or other init system configuration in Nixpkgs. Nixpkgs just doesn't have any facilities for that atm and afaict no one is working on them right now. There are definitely precursors to that functionality in:
• the NixOS module system, which provides exactly this functionality for NixOS, where the module system is in charge of configuring systemd
• nix-processmgmt, an experimental Nix framework for writing Nix expressions to describe services to be managed by a range of process managers that may or may not be PID 1 (which means the could be usable on non-NixOS): https://github.com/svanderburg/nix-processmgmt
• nix-darwin, a module system for macOS that provides some NixOS functionality, including managing services: https://github.com/LnL7/nix-darwin
The discussion on the service abstraction layer for Nixpkgs/NixOS is also very relevant. It shows that there has been interest in something like this for many years, but it's never quite come together: https://github.com/NixOS/nixpkgs/issues/26067
I wouldn't assume it's just around the corner or inevitable. It is a really exciting possibility, though, and the nix-processmgmt framework seems like something that could evolve into a service abstraction layer for Nixpkgs that could make facilities for managing services available in a uniform way even on non-NixOS Linux.
... yeah, maybe it's a mess on linux too heh. at least it's a mess you can interact with via version controllable text files and scriptable cli tools though...
in the section labeled ‘Add Docker’s official GPG key’, where you download a GPG keyring for Docker's apt repository and install it to /usr/share/keyring?
But overall, that sentence you quote of mine was me trying to condense my general feel of the instructions in a bit of an exaggerated tone. Let's be honest, not all of the instructions there are super obvious if you're not comfortable with the Linux ecosystem. Most people will just copy paste everything on that page till docker works, ignoring the big fat warning saying "Always examine scripts downloaded from the internet before running them locally.".
I guess if you're a developer and you just picked up some laptop pre-loaded with Ubuntu and you've never used the command line in your life, it would be better for you to download some file with metadata for apt to consume, and a default file association that gives you a GUI prompt asking you if you want to add the repository. It is kinda lame that Ubuntu doesn't have that. (openSUSE does have GUI facilities for adding repositories, although it's been a long time since I've used them. I wonder if Fedora has something like that, too.)
If you're using Docker to develop applications for Linux servers, the bash builtin `echo` and `tee` are probably among the absolute minimum basics of the command line you ought to learn ASAP. And if you're gonna run Ubuntu at all, the format and use of `/etc/apt/sources.list.d/*` is part of your absolute minimum curriculum, too. I don't think the confusion of folks who are unwilling to do those things is a huge problem in this specific use case.
But you are right in general: it's unusual among desktop operating systems that in the Linux world, users are expected to know about how the configuration for the system is stored. And while I don't think that's necessarily a problem, it would be better if for extremely common use cases (like adding an external software source), users could always use tools (including command-line tools!) that didn't confront them with implementation details such as configuration file paths or lines to be appended to them and instead summarized what was to be done in human terms and asked them if they wanted to do it.
The Debian-based tooling is especially weak here, and especially at the moment, since `apt-key` has been deprecated for security reasons but there's no convenient tooling to replace it at the moment. :-\
It was so obvious when Microsoft announced this that they weren't actually putting any real effort into doing this right. They had no answers for important questions like which versions or release channels to support or how.
So WinGet is terrible even though it was copied from the great AppGet? And WinGet is still in insider, no GA, and AppGet is ceased? I don't get it.
AppGet was a hobby project, and its maintainer ceased to maintain it, because Microsoft came up with something that doesn't work??? I thought that was that was exactly the thing that made Kaiven start his project...
As someone who has never heard of this before, I have a question. Why would anyone want it? For me as a dev, modern windows' greatest thing today is WSL. Why would you want to muddle around in the windows app ecosystem at all? WSL2 with docker and VScode is pretty great.
At this point in time it'd be far easier to maintain the short list of things Microsoft didn't blundle yet, instead of reporting what user-hostile garbage they made this time. It's like the broken window theory, but in reverse: You're actually surprised when you see a working Window.
I don't like what they handled interaction with the AppGet dev either, and can't understand why they can't seem to get a great solution working, but I would argue it's not 3E approach. In this case it would actually benefit them if AppGet stayed alive because it serves their users and doesn't present any danger to them whatsoever. I assume that they simply decided internally (for whatever reason) not to acqui-hire the AppGet author and then rolled out their own.
How they managed to do a bad job with so many awesome examples is however beyond me.
How winget initially responded to criticism for not giving credit to appget, and how winget interacted with appget developer before releasing winget, my only conclusion so far is; ignorance and some form of entitlement.
> lol who is masochistic enough to still use something like Windoze 20 years into the 21st century?
You mean almost every enterprise out there? Most gamers? Most home users who can't afford a Mac and don't know about Linux? Yeah, who still uses Windows...
I think most people would be surprised about how elegant a setup wsl 2 on windows can be. Have you tried windows in the past 20 years? You don't think it's possible that they could have improved? Macs have been turning into the default engineering laptops at a lot of organizations but I'm not sure of anyone that would say that they are perfect and without faults. I was on macs for at least ten years, but never got completely comfortable. Someone mentioned that wsl2 was amazing to me and I decided to give it an honest shot. I'm on the infrastructure side, so maybe having Linux as my primary shell and working environment makes more sense for me, but not sure if it's for everyone.
Yep. Had to use work-mandated Windows laptop and it sucked big time. Lots of small annoyances, it just couldn't compare to ThinkPad + linux when what you need the most is terminal.
We got to choose a Thinkpad or Macbook Pro. I went with the Thinkpad and I wonder once in a while if I made the wrong choice. Things like WSL and Windows Terminal have made my life significantly easier and more productive, it's hard for me to overstate the value I get out of WSL in particular, so I always balk a bit when I hear something like "lol just use Linux". With JetBrains IDEs just recently having the ability to run things on remote machines (and VS Code having been able to do this for quite a while) I think the productivity gap between Windows and Linux is closing.
With WSL, I still have to account for poor FS performance when files are not in correct location. GUI is still not seamless (Wayland is coming, but not yet arrived). I still have to fight the terrible UX that is Windows DE, instead of natural flow of i3wm.
Its the little things that eat up my cognitive budget that tire me way early in Windows compared to full fledged Linux distro.
The Mac comparison is better than the Windows one but Mac is in exactly the same position as Linux here: either you use the manufacturer recommended hardware (Apple hardware or the various pre-configured Linux laptops like System76) or you spend time looking up compatibility (Hackintosh/roll-your-own Linux).
The difference is that the manufacturer-certified hardware for Macs has a giant advertising budget.
All of that works on my System 76 Ubuntu 20.04. The real reason corporations use Windows is so that they can lock down the desktop to prevent users from installing tools without corporate approval. They could do it on Linux as well, but it's more difficult.
Given what they wrote in their release announcement, I have a bit worse opinion of them:
Why not contribute to another open source package manager?
We looked at several other package managers. There were several reasons leading us to create a new solution. One critical concern we had was how to build a repository of trusted applications. We are automatically checking each manifest. We leverage SmartScreen, static analysis, SHA256 hash validation and a few other processes to reduce the likelihood of malicious software making its way into the repository and onto your machine. Another key challenge was all the changes required to be able to deliver the client program as a native Windows application.
