Class D amplifiers use that same trick, just at much higher switching frequencies (pushing quantization noise ultrasonic, where it can be filtered). Since transistors are most efficient when fully on/off, very little power is wasted as heat. That's what made the modern revolution in tiny amps possible.
Interesting, could it be mitigated by the server doing its own prediction and defogging the peeker early? Or is lag prediction in CS2 not entirely client-sided.
It's more that momentum-based defogging means that the peeker has control over how to manipulate the server's prediction, whereas the victim who is already disadvantaged by network latency now gets an additional penalty of the movement initiation being not telegraphed.
To solve this, the fog of war would need to use purely positional near-edge tolerances, which defeats the entire purpose of fog of war to begin with, which is the pre-aiming reaction time advantage of tracking the peeker through walls in addition to having a farther lever point from the cover than the peeker.
That doesn't sound at all like any ORM I've ever used. I've struggled in the past because The ones I've used are actively hostile to laying out data in the database in a way not proscribed by the ORMs philosophy. Heck of the ORMs I've used, one didn't support parameterized joins and the other didn't support joins at all.
---
It's not usually a DB guy gatekeeping, it's that multiple apps use the same database so layout changes are costly.
Except for the "multiple ORMs" part which is a level above it, it applies to the only one I've used extensively: Django for python. It has standard defaults, but just about everything overridable, and because models are python objects you can add methods or properties for extra data. There's even ways to define your own field types (the "serialization/de-serialization of individual properties"), which a decade ago people were using to provide json fields through libraries long before it was officially supported.
...and Django was like this 15 years ago when I first started using it. The core design hasn't changed, it just sounds like most other ORMs don't really know what they're doing.
>and Django was like this 15 years ago when I first started using it. The core design hasn't changed, it just sounds like most other ORMs don't really know what they're doing.
Django is an opinionated web framework that uses an ORM, not just an ORM.
Django can by all means be a great way to make a web site (I have little experience with it) but if you have a db that is accessed by various systems written in Java, dotnet, erlang or whatever else I suspect the smooth sailing of Django can run into headwinds quickly and the python plumbing you have to deal with then quickly becomes an issue in itself.
> but if you have a db that is accessed by various systems written in Java, dotnet, erlang or whatever else I suspect the smooth sailing of Django can run into headwinds quickly
Only if those systems are constantly adding/removing tables and columns. And adding isn't a problem, Django just ignores what's not specified in the models.
Django does have default table and column names based on the models that it prefers, but all of it is overridable in officially-supported ways. We're using it with mysql databases originally made for VB6 and C++ with inconsistent naming schemes that aren't even close to Django's defaults, that nowadays are also accessed by perl, php, and python. Most of our python uses are daemons that only use the models and none of the rest of the web framework - the models are defined in a common library they all use.
Web fiction, freely produced and distributed by "consumers" already existed prior to 2019. There are thousands of novels you can read that people produced for their own enjoyment, some even managed to make money off of it via patreon or Amazon's Kindle direct publishing.
This is slightly different than web fiction. Text generation is arguably the cheapest and most “ready” medium for content production in the current AI wave.
You can speak a world into existence, entirely customized to you’re preferences, and interact with it.
Isn't CSRF about forging mutating requests? CORS doesn't block the underlying GET/POST request, the request still goes through and the server still needs to properly implement CSRF prevention. CORS just prevents javascript from reading the response.
CORS _additionally_ requires OPTIONS pre-flight to succeed, before allowing any kind of request outside of what can be achieved with a HTML form submit action. So it blocks PUT/PATCH/DELETE, specifying most Content-Type, and specifying nearly all other headers. But this is just blocking "non-standard complex requests that might confuse badly programmed pre-javascript-era servers".
It passes all standard requests that you could have made by: embedding the url as an image src, the target of a HTML form, endpoint for csp reports, etc. All still need to be checked methodically by the server for CSRF if it's going to take any mutating action due to the request.
CSRF can compromise the non-mutating path as well to exfiltrate data, but the mutating path and non-mutating are different, hence the OPTIONS preflight required prior to sending mutating requests.
The browser enforces the same-origin policy by preventing read on non-mutating (i.e. “simple”) request responses and preventing sending of mutating requests (i.e. non-“simple”). CORS provides a protocol for a service to loosen these controls.
If anyone's looking to sandbox network, I've had good experience with pasta [1] networking. I make a pasta+bwrap sandbox and expose only specific services via local sockets to cross the boundary.
reply