[HN Gopher] WinGet is terrible, I want AppGet back
___________________________________________________________________
WinGet is terrible, I want AppGet back
Author : lucumo
Score : 161 points
Date : 2021-04-17 16:35 UTC (6 hours ago)
(HTM) web link (niemarwinget.medium.com)
(TXT) w3m dump (niemarwinget.medium.com)
| formerly_proven wrote:
| 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.
| bostonsre wrote:
| What other stuff hasn't gone well for them lately? From my
| experience with giving wsl2 a chance for the past year has been
| amazing.
| siproprio wrote:
| WSL2 is much worse than WSL1, it uses too much memory on my
| machine.
|
| Microsoft now days just pretends to fix the issue, but locked
| the discussion around the problem.
| dragonwriter wrote:
| > blundle
|
| is this an intentional portmanteau of "bundle" and "blunder"?
| yuuta wrote:
| 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.
| michannne wrote:
| That sounds so lazy
| voidfunc wrote:
| 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
| chungy wrote:
| > Windows isnt like Linux where programs spew files all over
| the FS.
|
| Are we living in the same universe? Did you mix up the OSes?
| majkinetor wrote:
| It was mostly true tho, even nowdays... Windows tools where
| historically in single folder.
|
| Then came the registry
|
| Then came the AppData.
|
| Now its more or less the same as on linux.
| alkonaut wrote:
| 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.
| majkinetor wrote:
| Matter of taste I guess. I always disliked the linux way
| and prefer clear separation of concerns.
| alkonaut wrote:
| Same. Especially sharing any binaries between
| applications. For a single user desktop system it just
| seems like a backwards idea.
| horlux wrote:
| Linux programs don't normally do that, they put files in
| known places /bin, /etc /lib and so on
| encryptluks2 wrote:
| 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.
| easton wrote:
| 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.
| alkonaut wrote:
| Don't some of those help build msi packages? I thought at
| least InstallShield did.
| EvanAnderson wrote:
| 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.
| EvanAnderson wrote:
| 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".
| schusterfredl wrote:
| WinGet is not a package manager. (never was, and probably never
| will be)
|
| this 'old' thread still nails it:
| https://github.com/microsoft/winget-cli/discussions/223
|
| it's just sad.
|
| use Chocolatey, if you can't for some reason try Scoop.
| ddevault wrote:
| Dude, just use Linux.
| bootlooped wrote:
| Three words: work issued laptop
|
| Some people don't have complete control over every computer
| they use.
| trulyme wrote:
| 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.
| bootlooped wrote:
| 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.
| IshKebab wrote:
| Maybe he wants to have working WiFi and monitor hotplugging and
| sleep mode and games and battery life that doesn't suck and...
| sedatk wrote:
| Apart from those, what else Microsoft has done for us?
| mixedCase wrote:
| So he should just use Linux?
|
| It takes very little effort to look up if something's
| compatible before you plop 2 grand on it.
| EdwinLarkin wrote:
| If you have to preach something like a zealot it means it
| is not as good as you think it is.
|
| Most people dont look up whether "something will work" on
| Windows or Mac.They just simply use the machines they buy.
| g00gler wrote:
| Who's preaching? Doesn't get much easier than this
| https://certification.ubuntu.com/desktop
| mixedCase wrote:
| Completely incorrect for Mac. At least for those that
| want their peripherals to work.
|
| Correct for Windows. But then they just buy the machines
| and complain about their issues later, hence, this
| subthread.
| fiddlerwoaroof wrote:
| 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.
| cpach wrote:
| To each their own (^_^)
| majkinetor wrote:
| 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.
| ur-whale wrote:
| Package management comes to Windoze?
|
| 2021 ... it only took 26 years.
|
| lol who is masochistic enough to still use something like Windoze
| 20 years into the 21st century?
| trinix912 wrote:
| > 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...
| bostonsre wrote:
| 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.
| berniemadoff69 wrote:
| is this article about monster trucks
| nikeee wrote:
| What happened to OneGet (now called PackageManagement?)
|
| It apparently got to the point where it shipped with Windows:
|
| > OneGet is shipped in Win10 and Windows Server 2016!
|
| It seems to support pluggable backends (docker, chocolatey etc).
|
| https://github.com/OneGet/oneget
| SOLAR_FIELDS wrote:
| 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.
| mavhc wrote:
| Are Microsoft the new Google?
| jimmar wrote:
| 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.
| cosmic_quanta wrote:
| Indeed, taking a look at the roadmap there's lots coming:
|
| https://github.com/microsoft/winget-cli/blob/master/doc/wind...
| mavhc wrote:
| Except v0.2 is still only in preview, so it's 7 months late,
| on an 11 month old project
| guitarbill wrote:
| 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.
|
| [0] https://keivan.io/the-day-appget-died/
| [deleted]
| protomyth wrote:
| 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._
|
| https://devblogs.microsoft.com/commandline/windows-package-m...
| a-dub wrote:
| 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?
| zo1 wrote:
| 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.
|
| https://docs.docker.com/engine/install/ubuntu/
| cocoafleck wrote:
| 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.
| JoeyBananas wrote:
| Why do people put up with Windows
| neatze wrote:
| After following this issue[0] closely, I am not surprised.
|
| [0]https://github.com/microsoft/winget-cli/issues/353
| andybak wrote:
| Fascinating to see the MS response.
| ggoo wrote:
| Wow they really screwed the appget guy over. damn.
| jdonaldson wrote:
| I've been willing to cut Microsoft some more slack in the Nadella
| era, but this reads as classic "embrace, extend, extinguish" all
| over again.
| trulyme wrote:
| 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.
| neatze wrote:
| 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.
| protomyth wrote:
| It looks like they failed at the "extend" part.
| siproprio wrote:
| Winget is just garbage.
|
| The simplest possible install scenario would be: unzip this file,
| and add to path.
|
| To uninstall: delete this folder.
|
| Microsoft's solution [0]: if your app is in a zip file, repackage
| it as a msix/whatever proprietary technology.
|
| To this day, you still can't update, or even uninstall stuff with
| winget.
|
| But guess what it had baked in since day one (literally the third
| commit) [1]?
|
| Telemetry.
|
| [0]: https://github.com/microsoft/winget-cli/issues/140
|
| [1]: https://github.com/microsoft/winget-
| cli/commit/67800b07618b5...
| shawnz wrote:
| 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)
| alkonaut wrote:
| MSIX I believe supports self-updating and is no longer bound to
| the store
|
| https://docs.microsoft.com/en-us/windows/msix/non-store-deve...
| jpalomaki wrote:
| Windows task scheduler is suitable for periodically checking
| for updates.
| Spooky23 wrote:
| Because people will go apeshit over it.
|
| They are slowly moving stuff like snipping tool and HEIC
| support behind the windows store. Eventually, it will be the
| App Store.
| bentcorner wrote:
| > _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.
| fassssst wrote:
| Windows Store is no longer UWP only.
| [deleted]
| alxlaz wrote:
| Just sayin', for a supposedly "new Microsoft", this is _exactly_
| the kind of stunt that Microsoft would have pulled throughout the
| 90s and 00s.
| jasonhansel wrote:
| Once WinGet comes preinstalled with the OS, Microsoft will have
| completed the cycle.
| atkbrah wrote:
| 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.
| bostonsre wrote:
| 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.
| ocdtrekkie wrote:
| 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.
| Jenk wrote:
| A quick shout for https://scoop.sh which is, in my humble
| opinion, better than either *Get offering.
| koshersalt wrote:
| Also, a quick shoutout for Chocolatey which I use for making
| embedded packages for managing servers. https://chocolatey.org/
|
| Scoop seems awesome too, just doesn't fit my particular needs
| jamesgeck0 wrote:
| Note that the Scoop project is pretty much dead.
|
| 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
|
| Someone made a workaround patch using a different GCC mirror,
| but it's been sitting open for a month.
| https://github.com/ScoopInstaller/Main/pull/1933
|
| 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
| Jenk wrote:
| The last commit was 18 days ago, though I do see the last
| release is October 2020.
|
| Well if it is dead then that is a damn shame.
| pseudalopex wrote:
| The main package repo had over 100 commits this week.[1]
|
| [1] https://github.com/ScoopInstaller/Main/commits/master
| majkinetor wrote:
| This has nothing to do with scoop itself.
| pseudalopex wrote:
| They called the main package bucket unmaintained. I don't
| know what you're trying to say.
| iudqnolq wrote:
| There's a patch to fix this.
| https://github.com/lukesampson/scoop/pull/4137
|
| 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.
| GordonS wrote:
| I love scoop, another recommendation from me too.
|
| 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?
| majkinetor wrote:
| 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
| ?
| GordonS wrote:
| > 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.
| majkinetor wrote:
| > 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].
|
| [1]: https://github.com/majkinetor/au
| imiric wrote:
| 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.
|
| [1]: https://github.com/lukesampson/scoop/wiki/Chocolatey-
| Compari...
| Jenk wrote:
| 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.
| siproprio wrote:
| Scoop is amazing.
|
| You can install, update, and uninstall software.
|
| And it also won't leave crap on your machine - everything is
| portable by default, and sits on a single folder.
|
| Installing software with scoop gives me peace of mind.
| chx wrote:
| 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...
| sharken wrote:
| 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.
|
| https://github.com/chocolatey/choco/issues/508
|
| 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.
___________________________________________________________________
(page generated 2021-04-17 23:01 UTC)