Your logic is self-defeating. How are distro volunteers going to know that you are interested in this topic if, by your logic, you don't have the privilege to ask them in the first place?

But I don't think that asking needs any privilege. I'm going to ask again: Why not? Or worded differently: What is stopping language package managers that is not at the same time stopping distro package managers?

Why not? Seems like exactly what is being asked for.

I'm not so surprised, given that you cannot write support tickets if the bug prevents you from registering...

Also, I don't think people have high hopes that a broken government website will ever get fixed.

In other words, physics can explain Shakespeare's plays when you hand-wave away the biggest reason it cannot.

> theoretically

... meaning not in reality, but in an abstraction of reality that conveniently leaves out the hard part.

> This is just a data problem though.

The word "just" makes it sound like that data problem is a minor inconvenience, and not a fundamental obstacle.

Becoming a billionaire is simple, after all it's just a money problem.

I mean, you're right in that (leaving out quantum randomness), you could predict macroscopic outcomes based on a physics simulation that includes all elementary particles explicitly, if you assume that such a simulation can be scaled from <10 particles to macroscopic numbers. But there is no evidence that this assumption is true, so it remains an interesting thought experiment that gets confused with reality because people like to slap the "in theory" label on it.

This is false. It is meant to protect users from a confused-deputy attack made by malicious websites, where that website makes a request to a "serious" API but the user has never asked for, or approved, that request.

Blaming the user for everything that happens serves nobody.

You have to already know from experience that these strange devoid-of-information requests have been blocked by CORS, then find the preflight request, and there you will find a bit more information, but still much less than would be possible to show.

Showing more information would, AFAIK, not circumvent the layer of security that CORS (or actually origin isolation, which CORS makes an exemption from) adds. My best guess is that this just had very low priority when building the dev tools.

> How much of an impact can this have? > Reading is:alive (1 byte) Across 1M Monsters

You aren't reading one byte here, you are reading 1M bytes! Of course, optimizing the access to 1M bytes is something to consider. Optimizing the access to one byte isn't.

The article is definitely worth reading IMHO, but it really needs a better headline!

> You can always improve, but pretending like there’s an easy solution is lazy - if it was easy it would have been done.

I claimed that it is possible, not that it is easy.

Also, historically, permission lists have been fine-grained but too coarse at the same time, meaning they were "fine" in the wrong way, based on what is easy to implement instead of what the user needs.

Yes you can. Extension systems of today have multiple problems that prevent that. The basic assumption that has to go, though, is that a core application like VSCode can be written once, then be extended to infinity without the core evolving. That's an assumption you see everywhere in extension systems, and it restricts everything to "features or security, but not both".

Taking your examples:

> run a locally installed linter

VSCode and its extensions have certain files opened. The linter can do much less if it gets read-only access to those files, but not write access and no other files, not the open internet or something.

This has then to be coupled with those permissions being displayed before installing, allowing them to be reviewed by users as well as plugin repo curators. Basically listing those permissions as declarative metadata.

Because then a user or curator won't see "this plugin can read and write all your files" but "this plugin can read (but not write) the files being opened by VSCode". If the plugin wants to exfiltrate those files, the permissions would also list "this plugin can send HTTP requests to totally-legit-site.ru" instead of "this plugin gets arbitrary internet access".

Main lession: permissions are WAY too coarse. But if they are fine-grained, they will soon no longer match the evolution of extensions, so the core system has to evolve too.

> view the status of docker containers

"This plugin can view the status of all docker containers started by other VSCode extensions in the same VSCode window".

> users will scream and cry about extensions being limited

Are those the same users? We might need two different products here, "feature VSCode" and "secure VSCode".

"big machine farm" reminds me of folding@home, which needed the same and got it.

"manual curation" is what Wikipedia did, as well as the free software community.

"technical expertise" is present in the free software world too. It is sparse since it is sparse in the world as a whole, but it exists.

"no Linus Torvalds figure" might be the main problem ATM.

Also, doing this on a per-service basis doesn't seem that far-fetched to me, so you'd only kill that service and get at least some chance that the rest of your system remains usable.

Also, if implementing a cap is a desired feature that justifies trade-offs to be made, then it is psosible to translate the budget cap (in terms of money) back into service-specific caps that are easier to keep consistent. Such as "autoscale this set of VMs" and "my budget cap is $1000/hour", with the VM type being priced at $10/hour, translated to "autoscale to at most 100 instances". That would need dev work (i.e. this feature being considered important) and would not respect the budget cap in a cross-service way automatically, but still it is another piece in the puzzle.

The guy who has to keep it running day by day, next to the other 30 local-first systems.

Why are you assuming that they are given a choice? In my experience, whenever a team is trying "agile" in some way but hate it AND are given the choice, they drop it ASAP and are 100% convinced that they are better off without it. Those that hate it and don't stop doing it, are doing so because they are forced to.