moring

Anyone who hasn't thought deeply enough to answer this question doesn't have the privelige to say "just curate it, what's the problem?". Curation isn't that simple, as any distro package manager volunteer would tell you.

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?

language package managers are not [curated]

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

So statistically speaking I’m surprised that this bug hasn’t been noticed and fixed yet!

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.

Am I right with my assumption that by "fundamentally different problem", you mean we lack a good simulation model, but that the number of degrees of freedom would actually be manageable?

From the perspective of a deterministic universe, creative works theoretically can be explained as a physics outcome

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.

it’s meant to protect the users from themselves

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.

The message in the dev tools is, at least for Chrome, extremely developer unfriendly: The blocked request is displayed in a very strange way, without any information that it was blocked, nor that CORS was the reason for it, nor how that decision was made based on the preflight request.

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.

And yet, you did buy the fan despite the bright LED (because you didn't know it was there when you bought it). Rowenta got your money, so from their perspective, they did everything right.

The article shows nicely how "every byte matters" is false. First, it starts off by talking about the cost of a new field, when the actual topic is array-of-structs vs. struct-of-arrays. Then, this:

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!

This was bad wording on my part. I wrote "open" but that should have been "files in the workspace/project". Really, "open" WRT files is so overloaded already, they can be in the workspace, have an editor tab open for them, or have an active file handle, to name just three.

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.

Ideally, the permission list is meant for curators which end-users trust and can rely on.

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.

You can't have an extension system that (...)

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

To do things that a human could have done in theory, but did not do because it would have been too expensive.

It seems like one needs a big machine farm and a vast corpus of training data with a lot of manual curation to get started creating a competitive LLM, plus whatever technical expertise that I don't even know about. The stuff that makes LLMs exist now and not earlier.

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

Bonus points for the kafkaesque responses you get as the end-user when you try to actually pass that information upstream where it could be fixed...

So? Many would prefer a DoS-type event over spending $WHATEVER_THEIR_HARD_CAP_IS. This is kinda the definition of a hard cap, so you would place it sufficiently high that DoSing your system is indeed preferable.

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.

It seems hard to believe that a one-hour delay on such a counter is impossible to achieve, and one hour would reduce the risk from "catastrophic" to "serious problem" in most cases.

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.

If you made a local-first, P2P version of Figma what would break first?

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

The deeply unexpected thing about that, to me, is, if they hate some parts of the process, why are they keeping them?

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.

I think there is: It is the line between "not spending extra money to make sure it works" and "spending extra money to make sure it won't work".

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.

This may sound absurd, but it was a mental breakthrough for me to realize that all these "what-ifs" (multicore 6502 computers or whatever) are really simple to simulate in software only, with a bespoke simulator, WAY above register transfer level. There is really no need to deal with the peculiarities of FPGAs or Verilog; just write an instruction-level simulator for the ISA you choose (that's really simple for the 6502), make it run several instances for multicore architectures, and there you go for your custom computer.

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

By that logic, operating system developers struggle to understand that putting two files with the same name into the same folder(1) is very much possible in the physical world.

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

Questioning standard nomenclature is useful too, as long as it provides insight and is not just bike-shedding. "optimization" (in the context of an optimizing compiler) is generally expected not to alter the semantics of a program.

Your comment seems to miss that the author is speaking about technical drawings, not sketches, in particular this part:

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.

Paysafe cards. A store near me has them.

Yes, I do. It just means that you have to manually "recharge" your Steam wallet when it runs low. That's some effort, but it limits the possible damage if something goes wrong.

IMHO this supports the original point that payment via Steam would be an upgrade:

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.

Requires PayPal or credit card. The suggestion was to pay with your Steam Wallet or whatever payment method already used when you buy a Proton-based game on Steam.

That is only historic influence, though. Britain does not control the English language and cannot exert any further influence through it.

Actual application code was hardwired, entered manually with switches and lights, or with punch cards. Later, when ICs were sufficiently advanced, mask-programmed ROMs/PLAs.