It's close, but it doesn't quite capture the old DOS pixelated gradients aesthetic.
It also doesn't (yet?) capture the meta-game that was the biggest part of playing scorch in my youth: when you killed a tank it would pop up random insults, and the insults file was just a text file so your local file would eventually be full of in jokes and personal insults for you and your friends.
We could in theory replace gas taxes with per-axle weight taxes (again; most US interstates were originally built on per-axle weight taxes prior to the switch to gas taxes for maintenance funding). Per-axle weight is a much more direct number to road wear and tear than gas taxes have ever been (especially because it's exponential, road wear and tear is related to per axle weight to the fourth power).
Maybe you just knew more cops? At one time that often seemed to be the way to spot an off duty cop was a civilian dressed Crown Vic that probably parked at home next to the work provided Crown Vic. Though I also knew someone that bought used cars solely from cop auctions partly because they weirdly liked the "harshly restored to civilian use after several years of work abuse" aesthetic about a former cop Crown Vic and also supposedly because they were incredibly cheap at auction if you didn't mind being a lifetime mechanic because those cars were in awful shape coming out of the auction.
The author is proposing replacing a suite of security tools that integrate with package managers in a variety of ways (directly inside the package manager, through package manager hooks when available, as firewalls/repo hosts/network proxies) with a single security tool that "universally" works for every package manager that supports a new standard ("global hooks").
Some security experts are still going to prefer the firewalls or network proxies given the choice. Some security experts are still going to prefer package manager-specific security tools rather than a single "universal" one.
Package managers have individually supported hooks, configured in different ways, and with different metadata available unique to the package manager in each hook. Any attempt to standardize hooks "globally" would be a new standard. It might borrow elements from existing implementations of this package manager or that package manager, but it doesn't sound like you build a "universal" hook without some deeper standard on which events get hooked, what metadata is presented and how, etc. It stands to reason as you start to standardize that sort of stuff the final standard won't resemble any specific package manager's existing hooks.
Right, that process works today just fine, but that's application code that the browser (and middleboxes) can't assume. The idea is that QUERY directly represents that flow to the browser as a direct participant (and to caching middleboxes as well). A QUERY can (optionally) create a search or filter resource and return a Location: response header that points to a GET resource to refresh the next time the same QUERY is asked. The browser can directly cache that Location and associate it with that QUERY body. (So can middleboxes.)
A POST can return Content-Location: to the GET resource, but the browser can't assume that the same POST body contents create the same result Content-Location, whereas the QUERY Location represents the QUERY itself as a repeatable object. (Also, QUERY can return Content-Location instead of or in addition to Location for subtly different caching implications.)
There are good arguments that if you were designing this from scratch it would still make sense to separate GET and QUERY. GET are things addressable purely by URI. QUERY are things that need HTML forms or JS to initiate (but optionally may return GET addressable URLs for future requests).
Similarly there are good arguments that if you were designing this from scratch it would make sense to still separate QUERY and POST. To some extent they mean very different things: "search" versus "create"/"do". Some of that is a modern expectation from years of mapping the common "CRUD" concepts to "REST": POST ~= Create; GET ~= Read; PUT ~= Update; DELETE == Delete. But that's a lens that's still useful in designing the thing from scratch even if it wasn't necessarily in mind when HTTP was first designed (especially given the different verbs in HTTP terminology).
Sure but 405 Method Not Allowed is a response you can fallback from, whereas "body was silently stripped by a middlebox" is not as easy to know when it happens, much less deal with.
1) Changes to how GET works likely require a new HTTP version to assure maximum breaking change awareness. We're already in a Postel's Law state where we have HTTP/1.1, HTTP/2, and HTTP/3 all running side-by-side for reasons that all three are very different under the hood at even the transport layers. Do we really want to add HTTP/1.2, HTTP/2.1, and HTTP/3.1 to that list? An entirely new method is easier to apply horizontally to all three versions, because the HTTP standard already allows that as an extension mechanism. (There's an IANA registry for HTTP methods and HTTP methods such as WebDAV's have always been their own standards outside of HTTP RFCs.)
2) A plain separation between GET should only accept query string parameters and QUERY should only accept body parameters potentially reduces attack surface of attackers trying to mix and match the two to find potential order of precedence attacks.
It also doesn't (yet?) capture the meta-game that was the biggest part of playing scorch in my youth: when you killed a tank it would pop up random insults, and the insults file was just a text file so your local file would eventually be full of in jokes and personal insults for you and your friends.
This copy of the shareware demo is also browser playable: https://dos.zone/scorched-earth/
reply