Windows Package Manager 1.1
devblogs.microsoft.com
devblogs.microsoft.com
https://medium.com/@keivan/the-day-appget-died-e9a5c96c8b22
That said they DO credit him now on the repository. The whole story still feels really bizarre though.
I once interviewed a smart guy from a certain UC across the bay. Still undergrad, he played a lot with Python and wished he could have something similar to pip when doing C/C++.
So he wrote himself a "package manager" that could fetch binaries, place header files correctly and add them to his build. Neat little project.
That's basically what this guy did. It reads a YAML file and exec() whatever build instruction is in there. The CS102 guy I hired could do it as well.
Keivan was brought in by Microsoft for an interview and he didn't get the job. He kept talking about how "he could have patented this" or how it was an "acquihire" but there's nothing new to acquire in there! I mean it's not like he invented package management (NuGet, Chocolatey, Scoop all predate his attempt).
But hey, he flunked his interview and got a lot of eyes on his startup thanks to some well placed clickbait on HN...
https://news.ycombinator.com/item?id=28794352
I can only repeat myself: Microsoft is Microsoft, whatever they do.
No. Both package managers are open-source and share no code. They aren't even written in the same language. [0] [1]
It seems the author of AppGet wanted to sell it to Microsoft and Microsoft didn't see anything worth to acquire. He never even spoke to the people who could make the purchasing decision. Then they gave him a regular PM interview and it seems he failed it.
I used to maintain a few packages and it was pretty dang easy to publish, test, vet, and distribute this way. Everything else is in Git, why not this, too?
It was written in awful C++ and used GTK.
I even had the winpackman .com/.org domains !
I was so naive back then.
It's a huge improvement over downloading new version of VLC from their website for example.In total it upgraded 10 applications. The only annoying thing was that it still had to open GUI installers for updating applications. I'm also not sure how does it handle applications that are currently open during the update
chocolatey is a powershell script, whenever you run it it needs to initialize dotnet and the JIT needs to do its work
one downside:
i should be included in windows, and not having to install from the store, like wtf did they smoke?
It is included in Windows 11
The next feature update is Windows 11. I don't believe you should expect new features in 10 anymore, that wouldn't make much sense.
Also, winget is slowly getting installed automatically on Windows 10 (all the way back to the Anniversary Update if machines are still running 1607 for some reason but also still getting Microsoft/Windows Store updates, to my understanding).
Fair enough and your point about feature updates for 10 ending makes sense. My point is that I shouldn't have to use the store for a feature like this.
I avoid the store completely and have never installed anything from it. I don't think useful system features like this should be part of the store at all.
So you might even already have this.
in fact.. even if you don't use store for anything else i advise you to open it and make sure everything is updated (no login or accounts needed). There are some windows components with critical bugs that are updated trough the store like HEIF codecs.
On many Windows 10 machines without intentional store blocks just typing "winget" works now.
Anyway, Microsoft already has their own package format with MSI, which is not particularly elegant, but it's a reason to avoid reinventing the wheel.
This is what an 'extinguish' looks like after embracing the idea of a Windows package manager by interviewing the creator of AppGet [0][1] and then dumping him to skip the extend part to full on copy it [2] with little to no credit and bundling it in the OS.
This is a rare straight extinguish after an embrace, especially in open source.
[0] https://keivan.io/the-day-appget-died/
[2] https://www.theverge.com/2020/5/28/21272964/microsoft-winget...
I think open-source community needs to decide whether their stuff comes with strings attached or not and use appropriate licences.
It's understandable, however, but people really need to decide if their code is "fully open source" and anyone can snap it up and fork it, or if there are other strings attached.
To be fair, even the FSF has done the "take the ball and try to go home" with the GPL3 in some ways - not liking aspects of what they previously allowed.
I've heard similar stories coming out of Apple related to csound.
No. Microsoft never wanted to acquire anything.
They brought him in for a PM interview and he failed.
He wanted more than Microsoft was willing to give.
It was a mutual decision.
For anyone who was involved in an acquisition, it's a polite way to say "we're not interested". And considering he describes his PM interview as "I met with four different people; three of the meetings were more like your typical interviews;" it sounds like he went through the typical hiring pipeline because an employee gave him a referral.
Real acqui-hires are nothing like what he describes.
I have no clue. It also seems to trip some throttling in HN's code. I have unapproved opinions I suppose? Maybe dang knows the reason.
> He asked for an acqui-hire instead, and was told that’s not possible.
The funniest thing are his grandiose claims that he "could definitely have obtained a patent" for his package manager. Despite NuGet being 10+ years old and the fact that earlier in the article he explicitly states that he wrote AppGet so that he could replicate the Linux experience on Windows [0]...
That gives the reader an interesting insight on why he might have failed his interview.
[0] https://medium.com/@keivan/the-day-appget-died-e9a5c96c8b22
I like Macos's way best to be honest. Bu this is one practice Windows should not learn from Linux, different audience and requirements.
It looks like yet another competition to chocolatey for now.
But once you step outside of that it can get fun real fast.
And many things now basically do what Apple does anyway and bundle all libraries, etc with each app - Go does this explicitly I think. Space is cheap.
That is subjective. Yes generally the drive storage is cheap. Apple storage in other hands are not cheap at all and charging a premium for it. Looking in MacBook Pro catalog, they are charging $200 for 513 GB SSD to 2 TB for $800. Most of the SSD of that range is in $50 - $150 USD. Drive storage is cheap, Apple storage are not cheap.
App store/package manager gatekept by vendor + random binaries from the internet?
I really don’t know why people use anything else.
Sorry that you've worked your way into problematic edge cases but for everyone else this solves way more problems that it creates.
A world where you no longer have to update dozens of applications one at a time or worse never at all is a very good thing.
This is also a terrific non-SCCM/Windows Store way to provide access to and limit what all can be installed on a Windows box.
Been using Linux for over a decade and haven't run into any problems from apt/repo's. So I am using what I believe to be a qualified opinion when I say edge case here.
I have configured manually dozens of servers, and automatically many thousands, with no significant issues. Only when you fight the distro, you’ll end up caught in an edge case. These things are tested automatically 24x7.
I mean on Linux you have the source and everything is debuggable but imagine 10 apps needing 10 versions of the same software. If it comes to this, it will be a fork moment except you can't fork freaking windows!! Stop trying to make windows Linux and Linux windows. They are both great for their uses, this childish war where one or the other needs to be the only way is silly. This silliness is how we have one browser to dictate everyones needs now.
Maybe from a storage perspective but storage is practically free these days. It doesn't even make sense from a time perspective since application updating can be done in the background with no kerfuffle.
There's just no advantage to having shared libraries outside of ensuring that you'll eventually break every application on your machine due to some obscure versioning/corruption/capabilities issue that is nigh-impossible for a layman to solve. I'm with the parent poster - Linux can keep its Package Managers to itself (not to say Windows doesn't have equally stupid features - looking at you, Windows Registry).
If an application or service is using a vulnerable outdated library, I WANT it to break. It’s better to have it broken than have it expose sensitive user data.
The last thing you want in securing a system is for your securitu effort itself to be a security risk (availability)
The first time I used apt on RH I was like wow, this is great!
It was pure pain and anyone who misses those days is either a masochist or has memory issues.
The problem with how you think is that you expect users to be like you, follow SOPs and all that. This is a help desk nightmare.
AWL already exists in windows (lacks or sucks on Linux) and it can still be bypassed.
The only thing repos create is a walled garden like the apple app store where MS can gate keep who can write code.
Can I write some crappy program and publish it to my friends on a linux distro repo or any appstore? Then how can so many of you on HN that advocate software independence blindly support walled gardens just because it is "Linuxy"?
Apple App store or the package manager?
Apple does not have a package manager from my understanding and I uses macOS daily. I don't like the approach with the App Store since there are some FOSS that are charging a fee to use their apps in the App Store. I understand it was due to Apple's Developer fee. App Store is not a package manager, it is an application online store in the same vein with Google Play Store & Microsoft Store.
If you are talking about the package manager, then which manager you are referring to? Brew, MacPorts, Nix? I uses Brew daily and only once have to add one repo (using MBA for less than a year) due to external plugin that the app use which it's easy to add in the command line.
I think your problem is that you're adding too many third-party repos. The distribution repos can be severely outdated, maybe even buggy, but fortunately most third-party repos are not troublesome. If you have one that is, don't add it, try an alternate installation medium, or consider a different application.
They may be outdated (as in RHEL or Debian Stable) but even old versions get regular bug fixes. And RHEL and Debian and its family pretty much run the world (except the parts written in COBOL running under CICS and z/OS)
This is an example where down vote to disagree isn't useful because instead of discouraging people from expressing opinions you believe are wrong a fruitless endeavor you may actually be discouraging the useful discussion that follows.
It might be useful to the commenter, but to the community it is not.
A collection of resources that are inserted and removed into standard locations plus metadata used to retrieve additional resources many times including some that may be shared between multiple packages including but not limited to dynamically linked libraries and actions to be completed on addition or removal of a package.
and the fundamental concept of a package manager
A tool that provides a standardized set of steps easily add or remove one or more resources to or from a system from a previously configured set of sources without the user needing to manually attend to the details of each installation.
A package manager doesn't inherently impose any sort of constraints on how such packages are retrieved, their requirements met, or their operations actuated. It is the simple mapping between clicking or typing install foo bar in a singular interface and foo and bar being installed on your system. Foo and Bar could be msis individually retrieved from their respective web pages each bundling 100% of the resources needed to run and depending on nothing outside themselves. That is to say the result of running install foo bar could be the EXACT same result as navigating to each respective website, finding the appropriate download, running the installer, answering any questions, disabling any adware or toolbars and waiting for each routine to finish save only that you can't accidentally install malware, you don't need to google the website, its trivially repeatable and suitable to automation.
In that context even if you don't like Linux system package managers it is incorrect to reject package managers in general as they are strictly superior to the alternative of manually retrieving the same packages to the web and in no way impose the things you dislike about Linux system package managers that you are concerned about.
Although you may competently perform that task in fact the act of retrieving and installing software is one of the largest source of infections among users. Removing this source of challenges is as useful as the time saved by being able to run install foo.