I might be silly but I don’t get the point being made there.
I believe due process is important in every case, and I want to believe that having a mixed system eventually results in due process being skipped more and more, but the example from the end of the article goes against that: England and France diverged, so it’s possible for a mixed system to go either way?
No one claimed that. The point was that Valve controls the API and can cut access to said API to the gambling sites. This is not like sports betting, where the gambling sites don't need any integration with the actual sport : if Valve wants, they can seriously affect the abity of the sites to function.
Yes, they provide the API that those sites need to function. That doesn't mean the API is exclusively for those sites. Just that Valve is the one enabling those sites, they're not completely independent.
Nonsense argument. They provide an api that players use, that can also be used by boys to perform trades. Maybe the problem you have with this is that they can do trades.
I really don't get what you're confused about. Yes, the existence of the API is good and useful. What Valve should do, if they really cared about stopping CS or TF2 gambling, is to limit access to this API for the gambling sites. The API should ONLY be accessible to individual players. That means IP restrictions, client agent sniffing, bot behavior analysis, etc - not trivial, and not foolproof, but also not exactly rocket science.
> Reserving full GPU instances for these models leads to allocating 17.7% of our GPUs to serve only 1.35% of requests
> Deployment results show that Aegaeon reduces the number of GPUs required for serving these models from 1,192 to 213, highlighting an 82% GPU resource saving.
82% of their CPUs were serving 98.6% of all traffic. If they reduced the cluster size, they got it to 96.2% of their CPUs serving 98.6% of their traffic. If they reallocated those, which is more likely, then 96.8% of their CPUs are serving 98.6% of all requests, or around 17% more capacity for popular requests on the same hardware.
These tips are great, but they don’t address some of the core ways that these supply chain attacks may happen: global modules and npm modules installed with editor extensions.
So `yarn global add nx` will still install the latest version by default, unless you specifically have a `~/.yarnrc` disallowing lifecycle scripts they will still be executed. Using a package manager that doesn’t allow lifecycle scripts by default is the solution here I guess.
I don’t know what the solution is for stuff like [this](https://github.com/nrwl/nx-console/blob/d2fa56509679fc942bbc...) where the editor plugin automatically uses the latest version, or where in general you have little control over what version is used. Any eslint, typescript, nx, prettier, etc plugin will presumably depend on their corresponding package from npm, and if any of those gets compromised then just installing an editor extension could be enough to get you in trouble.
Why wouldn’t it? The end result of a npm install or a bun install is that the node_modules folder is structured in the way it needs to be, and I think it can run node-gyp for the packages that need it.
I know the screen is an arbitrary size, but in general if you need more screens you could be walking around with an iPad to use with your laptop instead of a Vision Pro
Disclaimer: I did not watch the video yet