Hacker News new | past | comments | ask | show | jobs | submit login

Agreed, not a "walled" garden but a garden. Essentially an app store.

So essentially if Windows had this, problem fixed?

Or put another way, if most users came to Linux and started downloading crap from everywhere, there would be incentive for malware authors to write it for Linux, bringing it to the current situation with Windows?




> So essentially if Windows had this, problem fixed?

The problem is that the nature of Windows isn't to have this. Linux package managers are run by the community. They basically include anything popular that meets the licensing requirements to allow them to redistribute it. Windows instead has a "store" that wants to extract a vig, but because most of the software people use on Windows is commercial, the vendors then avoid to store to avoid the vig and the default is to install things from random websites.

And even if they fixed that, people are used to doing it the other way, vendors have already spent the time to set up alternate distribution infrastructure and they don't trust Microsoft not to reverse course once a critical mass of things are using their system and they can increase the friction to installing things from outside of it and then turn the screws on anything inside it.

To make it work there you would need the distribution system to be run by multiple independent third parties so they'd have to compete with each other to keep distribution margins low. There probably is a market for a third party "store" for Windows that pays the 3% to the credit cards and then distributes the apps via P2P so they can charge no more than 5% to app developers, which the app developers might then actually use because they don't have to build their own system for payments and updates. But the stores want to charge 30% and then the developers don't want to use the stores.


> The problem is that the nature of Windows isn't to have this.

Interestingly, they're getting a version of it. The wingget command line package manager that windows ships with now has two sources, the MS store, and the winget community repo. The community repo is something anyone can submit to and it goes through some vetting process[1].

  PS C:\> winget search perl
  Name             Id                            Version                Match          Source
  --------------------------------------------------------------------------------------------
  Perl Formatter   9MSQVFZPRG3Z                  Unknown                               msstore
  Strawberry Perl  StrawberryPerl.StrawberryPerl 5.32.1001              Tag: perl      winget
  MAMP & MAMP PRO  MAMP.MAMP                     4.2.0                  Tag: perl      winget
  EditPlus         ES-Computing.EditPlus         5.6                    Tag: perl      winget
  XAMPP 8.1        ApacheFriends.Xampp.8.1       8.1.12-0               Tag: perl      winget
  XAMPP 8.2        ApacheFriends.Xampp.8.2       8.2.4                  Tag: perl      winget
  Sharperlight 5.4 PhilightPtyLtd.Sharperlight   5.4.60                                winget
  Wtils            Perlt.Wtils                   v1.0                                  winget
  Paperlib         FutureScholars.Paperlib       2.2.3                                 winget
  Teambition       Alibaba.Teambition            2.0.3                  Tag: paperless winget
  DingTalk         Alibaba.DingTalk              7.0.30-Release.6019103 Tag: paperless winget

It's not quite the same though, as there are different considerations when using a repository of things a unified group has decided should be included and built (or slightly modified existing) packages for and a repo where anyone can submit a package that will go through some level of vetting. In the end I still believe most this discussion is really about individuals and how much trust they apply towards different groups and sources and is not really about Linux or Windows in particular as much.

1: https://github.com/microsoft/winget-pkgs


The problem on Windows isn't exactly the lack of apt-get. It's the general problem of not making paid software distribution sufficiently fungible. Which is a cross-platform problem but manifests most on Windows because that's the platform where people use the most third party commercial software.

The Linux community "solves" this problem by directing commercial software vendors to the door and implementing anything they want as open source. But having something that works for this would help even there, for the cases where that hasn't worked, like AAA games.

Ironically the best way to solve this for proprietary software would be an open system. Have someone create a software distribution framework that uses open source code and federated P2P for distribution with pluggable payment processors. Make it an interoperable standard.

The idea is that it's a distribution system with no central distributor, a payments system which is independent of a payment processor. The vendor chooses which payment processors they want to accept (which might just be all of them), then the user chooses which ones they want to pay with, and if the vendor gets into a dispute with a payment processor their users automatically get diverted to a different one. If they get tired of their hosting provider they move to another one without the users ever noticing.

But then you need someone to develop it when its very purpose is to make sure nobody can extract high rents.

A coalition of mid-sized developers might be wise to pool their resources. Or, for that matter, get in with a bigger pool, because this is a problem that exists for subscription services and small businesses in general.


> But then you need someone to develop it when its very purpose is to make sure nobody can extract high rents.

It doesn't address a very important aspect of this which is trust, and that's most of the point of this discussion. People use repos usually because there's some level of trust in the repo maintainers. If anyone can push anything, then it's a liability to have that repo configured. If it requires careful vetting, then that costs money, and requires a central authority, which means it doesn't really matter whether it's P2P or not (except to lower cost), as it's centrally managed anyway.

Theoretically I could see a system like that in place where the "network" is all open and P2P and you just subscribe to sets of packages that have been "signed" by an authority you trust, but I'm not sure that the P2P portion is really all that useful then.

The whole reason the default repos in a linux Distro are things people feel safe running whatever they find in is because they know a group of people they trust has vetted it. If you're running Debian/Ubuntu/RHEL/Rocky/Windows/MacOS you've already trusted the maintainers of their default repos/etc by the nature of running their OS in the first place. People also often choose to trust large companies (Adobe, VMware, Google for Chrome in some cases) and/or well known groups/projects (Apache, ffmpeg, etc) when they distribute software separately, even it downloaded manually. Finally, people make ad-hoc choices about random less well known sites and people, and that's where random windows executable or Linux binaries, or installer scripts that are downloaded and run or piped to bash form curl happen.

All those levels of trust and those parties exist for every OS. Even Linux has it's fair share of third party downloaded applications people use, depending on what they use their system for. Some communities of people (e.g. developers) are much more comfortable with ad-hoc installation methods like curl|bash than others, and that's across OS boundaries. That's really what I meant way upthread when I said this isn't a Linux problem, it's a people problem.


Windows does have this, of course, so the question is, has security issues with windows decreased in line with the rise of users using the Windows Store to acquire packages, or is there just as much malware on the store?

(Genuine questions, I don't know the data, or even if the data exists outside of MS)




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: