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...
Wow, I didn't know Microsoft was that shady. The original story was bad enoguh, but this makes it even worse. So they took the time to get ideas out of him and do the exact same thing he did, when a CS 102 guy could do the same thing when YAML files and exec... wow. I have no other words.
> So they took the time to get ideas out of him and do the exact same thing he did
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.
Wow!... if this is true (little reason to think otherwise), then it's completely disheartening.
The effort to be honest and upfront with this person would be minimal, and realistically would not even have to change anything from Microsoft's side; after all they are free to develop whatever tools they want.
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.
The "unwritten" rules around open source code/licenses is getting out of control.
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.
There are people that license software under MIT or BSD licenses that gets upset when someone else runs with it or makes it proprietary. If you don’t want someone else to just dump you and run with your code without upstreaming contributions, you should at least use GPL. It won’t prevent them from forking it and never giving back, but at least you can take their contributions and merge them back into your own.
Yeah, I feel there are many people who license as "MIT/BSD but please pretend it's LGPL/GPL3" - they want maximum adoption BUT ALSO want to remain in control and have code contributed back.
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.
Microsoft requested meeting with the author in the guise of helping him. Told him that the company would acqui-hire him and flew him out to Redmond for a interview. Did not respond to him for 6 months. And finally released their own version.
I've heard similar stories coming out of Apple related to csound.
Not sure why you’re being downvoted. He says in the article that Microsoft wanted to hire him to keep working on appget. He asked for an acqui-hire instead, and was told that’s not possible.
He wanted more than Microsoft was willing to give.
Here is an excerpt from the article: 'After about a month of prolonged email back and forth, we came to the conclusion that the arrangement will be very similar to an acqui-hire...'
But then : 'I was told that the acqui-hire process through BizDev would take a very long time. An alternative to speed up the process would be just to hire me with a “bonus” and then work on migrating the code ownership after the fact. I didn’t have any objections'
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.
Then it should be easy enough for them to install it to Windows 10 on the next Feature Update. If they can stick a News toolbar on my taskbar with an update than surely something as important and useful as this can be added as well.
There is still a 21H2 update for Windows 10. (It's a strange confusion that seems like it should have been avoidable that 10 and 11 will both have [different] 21H2 versions.)
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).
It is available on Windows 10 and takes less than a minute to install.
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.
you might not have installed anything from it but win10 comes with a bunch of store stuff bundled and store stuff auto-update (eventually).
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.
And any Windows 10 now with an up-to-date "App Installer" package installed, which I believe is slowly updating all the way back to the Windows 10 Anniversary Update (1607). (This is the same package that provides the Installer GUI for double-clicking MSIX packages and has always been Store deployed rather than "in box" in Windows 10.)
On many Windows 10 machines without intentional store blocks just typing "winget" works now.
I was more thinking from a usability point of view, available packages etc. But from the other comments I learned winget is in Windows 10 already so tried it and it doesn't feel that much faster on a couple of things (ran some searches under Measure-Command and for finding 7zip for example the best case was twice as fast, but hit that only once, other attempts took roughly 3 seconds just like Find-Package). But whereas Find-Package returns only one result, winget returns 4 of them and again like 10 more from the store so that means figuring out which one. And winget search sysinternals doesn't return anything, whereas Find-Package has it. Again that's all from spending a minute with it and only for 2 packages, but just comparing based on this it seems it's not a super straightforward migration for me.
I cannot stress how much I do not want a package manager on windows. If it is like chocolatey (optional) I am ok with it, but if it turns out to be like Linux where you install from repos and then you add multiple repos and then you have dependency resolution issues because that's what the package and version needs and the upstream and down stream devs need to sort it out and... ugh that is one part of Linux I hate with passion. I mean it works ok on Linux given who is using it but on windows it is normal, even a requirement for regular users to install apps (repos too in this case). And without AWL , even if you restrict this, people will install "portable" apps.
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.
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.
If you want to use your device for about 6 years, you have to consider how big these apps are going to be in 6 years. Google Chrome is not going to be 50mb in 6 years.
I use Debian and have three non-Debian repos in my sources.list. No problems thus far.
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’ve been using Red Hat, CentOS, Debian, and Ubuntu servers for the past 20 years and only once I painted myself in a corner with an EPEL RH repo and, even then, I admit it was totally my fault.
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 used Linux for a slightly shorter time and I always fight the distro because it should do what I want not the other way around. I need to get things done, with or without the distros cooperation and in this case with or without MS.
If you want to get things your way, I suggest using a distro that’s not as opinionated. Arch and Gentoo seem like good options. Never tried Clear or bare-metal Alpine, but I assume they are similar.
I did, not that different. To clarify, I accept things on Linux I just don't want that on windows because it is a mostly solved problem that does not need the complication. It only introduces a false sense of stability. The endless sea of windows software makers will not suddenly stop their development/deployment practices.
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.
Even on ubuntu, I run headless servers and this is almost always the case for me. But hey, thanks be to survivorship bias and people jumping on the walled garden bandwagon.
>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.
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).
> There's just no advantage to having shared libraries outside of ensuring that you'll eventually break every application
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.
Hard disagree. I'll decide which applications I want updated and when. I don't need my applications breaking because someone decided I'm not allowed to use it anymore.
That's not how security risk assesment work. You do get to decide when and how long you remain hackable and implement mitigating security controls. Not everyone has the luxury of being tolerant to outages and it is terrible security practice to take a forceful uncompromising approach like that with no consideration to why and how the software is being used and in what context.
The last thing you want in securing a system is for your securitu effort itself to be a security risk (availability)
It was always great, especially when compared to the Windows routine of downloading an installer and running it as Administrator on your server and, for every upgrade, do it again, keeping testing environments to make sure the new version works with the currently applied OS patches and so on.
It was pure pain and anyone who misses those days is either a masochist or has memory issues.
No it is not a way to limit what can be installed? Did you read my comment? Even when I am the admin i alwayd end up having to bypass repos. I get why it is that way for Linux but don't push this on windows.
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"?
Windows has a manifest system for shared libraries that allow multiple versions of a library to coexist side-by-side. My hope is that this alleviates problems.
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.
> then you have dependency resolution issues because that's what the package and version needs and the upstream and down stream devs need to sort it out
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.
> The distribution repos can be severely outdated, maybe even buggy
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)
Buggy includes non-security bugs, like a flaw in the UI that upstream already corrected in a newer version, or a feature you need that was compiled out by the packager.
In that case, I’d suggest either paying someone to backport the fix and offer it to the distro, or rolling your own repo with your package and a minimal set of dependencies (the more minimal, the better) and live with your almost-distro. The beauty of open source is that you can always work your way out of a situation.
Yes, and can you imagine a windows install by regular users without too many 3rd party repos? If you do then I suspect you may not understand how vast and complex the software ecosystem is in Windows land.
Installing software on MacOS is only convenient when it is distributed as self-contained .app bundle. Only self-contained GUI apps are distributed this way. Managing software that comes in ".pkg" files is strictly worse than using Linux packages. Unlike on Linux, there is no dependency tracking or interface for un-installing such software.
This is an example of a comment that is I think incorrect in a few different respects already reasonably explained in replies however its not rude or poorly written and in fact although incorrect in my opinion it prompted useful discussion.
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.
I did not claim package managers are evil. I only claimed they are a bad fit for windows if if their usage is mandated because of the specifics and nuances of the windows software ecosystem which isn't exactly similar to the FOSS ecosystem.
I think a fundamental misunderstanding is conflating Linux style system package management
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.
The "app repository" is a github repository [1]. I'm not sure how I feel about that. It worked for appget, it's easy to audit, nobody can do any shenanigans without obvious traces. But the UX could be better, for example this is what publishing a new version looks like [2]. I guess we can always build a separate UI.
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?
those PRs are appalling.. bots talking to each other, commenting to run bot commands, bots adding and immediately removing labels. as if the github PR user experience weren't bad enough
Blast from the past: Around 2004 I made a package manager for windows with that same name. I had a prototype, but I quickly got in over my head, since I wasn’t the greatest programmer at the time, and was in college for something other than programming :)
One nice feature of winget that I discovered after the Win11 update is that it doesn't bother with any restrictions on uninstalling Edge, XBox Game Bar, "My Smartphone", Maps and all the other useless fluff that is supposedly not uninstallable.
I can confirm that it's working on Windows 10 too. It let me uninstall Cortana :), lets see if anything breaks after restart or if it comes back in next update.
Scoop was designed to be able to work without admin rights, keeping everything in the user's directory. Which is good for users, but not really for system administrators who don't want six versions of Teams or whatever out of sync on the system. (which is a bad example, because Teams does that anyway even if you use the system-wide installer. I digress.)
It seems the manifest file requires an installer. This is pretty much why package managers in other platforms are cool - they install the programs, solve dependencies, and so on.
It's probably a lot easier to make a useful product when you work with what's already out there rather than asking thousands of other developers to make new packages, or doing all the work yourself and only having open source software.
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.
And Microsoft already tried making a better package format (msix) for their other centralized package manager (Microsoft Store), complete with sandboxing and everything. It wasn't exactly a roaring success.
Microsoft's power to dictate what developers should do and how is curiously small considering their market share in the personal computer market. Apple, OTOH, has no issues deprecating functionality when they consider removing it (and disabling applications that rely on it) is beneficial to their ecosystem.
Isn't Microsoft's backward-compatibility widely considered a reason for their overwhelming share of the PC market? You get more developers and more useful programs when people don't have to rewrite them for the new hotness every year.
Wow, I've just tried it and it's really good. As mentioned in the article, I already had winget in my PC. So I was able to use winget upgrade and it listed all the apps that I can upgrade(None of them were installed using winget but it still worked).
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
92 comments
[ 3.6 ms ] story [ 162 ms ] threadhttps://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.
https://en.wikipedia.org/wiki/Cover_Flow
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.
[0] https://github.com/microsoft/winget-cli
[1] https://github.com/appget/appget
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/
[1] https://appget.net/
[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
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.
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.
1: https://github.com/microsoft/winget-pkgs
2: https://github.com/microsoft/winget-pkgs/pull/30035
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.
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.
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