> 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.

There is a related problem with warranty: an inferior third-party replacement part may cause damage to higher-quality original parts. There is a line here between "making sure you don't have to deal with follow-up damage caused by inferior parts" and "preventing the use of inferior parts". This is a bit more blurry because most cases won't be clear-cut, and dealing with them will be a burden on the original manufacturer.

I think it is important that we reward the nice players as much as we punish the bad ones. A blanket "all companies bad" just means that no company has an incentive to be anything less than bad.

I mean this as a hint for people who are similarly stuck with RTL tinkering when they actually want to tinker with system architecture.

(1) or referencing them from the same directory, which was the earlier metaphor.

> And I would argue also that this scarcity of ability was already a problem for the last 100 years. The whole iterative process of ideation (ie. designing, sketching) gets so much less intuitive, if one has to pull out a ruler first, or boot up his machine.

You mention sketching explicitly, which is exlcuded by the author. And making technical drawings without a ruler seems insane to me.

> In dev-speak, removing hand-drawing from the skill set of architects entirely is as if you were deliberately removing HMR from your local web dev-setup.

That would be true if you removed sketching, but removing hand-drawn technical drawings is more like replacing hand-crafted optimized assembler code with an optimizing compiler.

Sending cash to a postal address isn't low-effort nor low-risk.

Payment by cheque is something I have never done, nor would I know how to do it. I'd have to ask at my bank -- not low effort. I don't know if I'm an outlier here but I have never heard from any of my peers who ever did such a thing.

The same or even worse is true for international money orders. The whole concept of making a money transfer to a postal address is something I have never heard of. Where's the IBAN?

The Wine team is right to put even PayPal before all of these.