This sounds off by an order of magnitude? Firefox's local translation models are only 20-70MB per language pair direction (e.g. en-to-fr or fr-to-en).[1] These models are also only released when they reach at least -5% of Google Translate's COMET score.[1] Currently Firefox ships with support for 32 xx-to-en language pairs and 29 en-to-xx language pairs.[1] As the number of language pairs increases, it probably isn't unreasonable for browsers to stop bundling every language pair and instead prompt users to download uncommon models the first time the user wants to use them.
Does the API trigger the download automatically, or does it ask for user permission?
(Answered my own question): Doesn't look like it requires the user's permission. Upon first use, the model will start downloading. The user has to wait for the download to finish before the API will work. That could take hours for 22gb.
Seems very backwards for markets where wired/wifi connections at home are nonexistant, 4g/5g is already unmetered and phones are the wifi you connect your devices to.
They must have sold the domain to the job portal cord.co. I got an email about it in February:
> We're becoming cord.com
> Hi,
> Over the next few weeks cord.co is becoming cord.com. Adding an "m" to the end of our URL is one of the smaller things we've done. But it represents something much bigger: that cord has become the trusted source for tech hiring in the UK.
This is the kind of thing you should implement in a JS library, or by preprocessing the image before you upload it to the web site, not add to the browser platform spec.
I was half-joking, and primarily meant to point out that the pixelated versions aren’t how those icons looked like to users back in the day either.
But also, for faithful CRT rendering you want to take the actual screen pixels into account, possibly even the subpixel layout, very much like for text rendering. Therefore there’s something to be said for that to be a browser-level feature.
> I hope these security efforts don't lock legitimate owners out of access to their vehicles.
Well that's the thing with cars. Anything the legitimate owner can do because they have physical access, a thief can also do... and even if you force manufacturers to provide a "rooting mode" aka you enter some PIN that you get at purchase into the car's infotainment and it will relax restrictions on the CAN bus, now you open up the gates for thieves as well.
And on top of that come the actual reasons for the security theatre: people modifying their ECUs to tune up their engines for higher power or speed limiters in trucks than is stated in the vehicle papers (at least in Europe, if you tune your vehicle and don't have the papers updated you're in legit felony territory), doing shit mods like "rolling coal" or otherwise tampering with emission controls (say to avoid having to refill adblue)... governments really REALLY do not like this and so regulations get tightened ever closer.
All it takes to pwn a Volkswagen T4 from the mid-90s is to rake the lock, pry open or smash the door, and then about half a minute to hot-wire three pins on the ignition switch (one for the main power and one for the starter motor), although I think that you should be able to motor-rake the ignition switch as well.
Source: owned and heavily worked on one for a few years. Reliable as fuck but thank god Europe doesn't have much of a "joyride" scene.
62 fairlane, I'd welcome the attempt. If they somehow manage to both prime the fuel pump and trick the carb into introducing enough fuel into the engine to get it to start before the battery's stone dead I'd pay a princely sum for live video of them trying to figure out where first gear is while getting a rude introduction to purely mechanical steering. Given what I paid for it, I could have 6-10 of it stolen before I'm in the neighborhood of sticker on a "cheap" new car.
And column shifters still exist- hell, even the Tesla Model 3 has one- so any gen z kid who knows how a manual transmission works can shift it into gear.
I am quite certain that getting this vehicle started and out of it's parking space is fraught in ways that beggar belief for anyone who hasn't spent a significant portion of their life dealing with the vagaries of shitty vintage project cars, and even then this one's got several tricks up her sleeve that the initiated won't see coming. Think three on the tree, on the floor, with more than one wildly out of place barrier preventing straightforward movement through the shift pattern. Getting this thing in first is less like shifting a car and more like picking an oldschool lock with ward plates. Then there's the combination of dodgy battery and mulish fuel delivery system to contend with. The only person I've ever met who can consistently get this thing to crank cold is the lunatic that chopped out the aftermarket electric fuel pump and replaced it with an OEM mechanical pump out of sheer perversity. Equipment? Hell I could leave the key in the ignition and a sign in a window DARING someone to try and I still like my odds.
2000-2005 is the sweet spot. Cars had immobilizers but not keyless entry. Basic electronics: airbags, electric windows, radio. Engines were naturally aspirated with port injection.
> Sol, borrowed from Latin, is used in contemporary English by astronomers and many science fiction authors as the proper name of the Sun to distinguish it from other stars which may be suns for their own planetary systems. [citation needed]
I would argue that HTTP statuses are a bad design decision, because they are intended to be consumed by apps, but are not app-specific. They are effectively a part of every API automatically without considerations whether they are needed.
People often implement error handling using constructs like regexp matching on status codes, while with domain-specified errors it would be obvious what exactly is the range of possible errors.
Moreover, when people do implement domain errors, they just have to write more code to handle two nested levels of branching.
> I would argue that HTTP statuses are a bad design decision, because they are intended to be consumed by apps, but are not app-specific.
Perhaps put the app-specific part in the body of the reply. In the RFC they give a human specific reply to (presumably) be displayed in the browser:
HTTP/1.1 429 Too Many Requests
Content-Type: text/html
Retry-After: 3600
<html>
<head>
<title>Too Many Requests</title>
</head>
<body>
<h1>Too Many Requests</h1>
<p>I only allow 50 requests per hour to this Web site per
logged in user. Try again soon.</p>
</body>
</html>
> because they are intended to be consumed by apps, but are not app-specific
Well, good luck designing any standard app-independent protocol that works and doesn't do that.
And yes, you must handle two nested levels of branching. That's how it works.
The only improvement possible to make it clearer is having codes for API specific errors... what 400 and 500 aren't exactly. But then, that doesn't gain you much.
A colleague who should’ve known better argued that a 404 response to an API call was confusing because we were, in fact, successfully returning a response to the client. We had a long talk about that afterward.
No, it is pretty confusing: the difference between 404 from hitting an endpoint that the server doesn't serve (because you forgot to expose this endpoint, oops!) and a 404 that means "we've successfully performed the search in our DB for the business entity you've requested and guarantee you that it does not exist" is rather difficult to tell programmatically.
If the URL identifies a resource (REST-style) and that database entry doesn't exist, then yes, 404 is less confusing response. If the URL identifies an API endpoint (RPC-style) then, sure, tunnel the error inside a "I successfully failed to handle that request" response if you like.
All URLs used when interacting with an API obviously identify API endpoints. There is no such thing as a URL which is part of an API but which is not an API endpoint.
There is a difference between /api/entity/123 and /api/search with a payload of 123, though.
The request couldn't be processed due to semantic errors... perhaps such as not being mapped to a handler :->
I suppose from the right point of view that could also be likened to a reverse proxy not being able to send the request on (502 bad gateway), but sane people would probably find that even more confusing.
There were also attempts to use 204 no content for "I successfully confirmed that what you asked for doesn't exist", but I think I managed to shoot those down.
Why not? I wouldn’t say „I performed the search and there’s 0 results“ is an error condition. It’s just the result of a search, and everything went fine.
Hm, maybe? I guess it depends on what we mean by search; if myapp.com/search?someproduct finds that there are 0 matches then yeah that's probably a 200, but if myapp.com/products/123456 fails because no product has id 123456 then that's a textbook 404.
It’s both nonsense, cause what you see here is a double conversion from an arbitrary problem domain into http domain and back again. Using a specific http code together with an app-domain code could make sense iff you wanted an intermediate host (a proxy etc) to perform some additional operation based on that status. Otherwise http status doesn’t speak the call language and can be just OK. (400/500 should still be handled by a client).
Back-and-forth conversion is a very poor idea. It works for what was “internet resources” initially (basically files and folders), but later people stretched that on application data models and that creates constant issues because people naturally can’t understand the mapping, cause there’s none. This is not a good idea. Talk to http hosts with http and talk to your client with a language you designed specifically for talking to it. 200 vs non-200 is http level and orthogonal to in-service statuses.
No, the latter is absolutely a 200 because of separation of concerns and layering.
The HTTP server, when it detects "URI handler not found" condition, builds an 404 HTTP response and sends it as a normal payload through the underlying connection instead of turning it into an TLS error packet or an RST packet on TCP level (that's the TCP's standard response for "port handler process not found", after all) or something silly like that, and that is absolutely fine, because the application-level (HTTP) error messages should be transmitted by the transport level (TLS/TCP) just as normal messages would.
The same reasoning holds just the same when we consider the usage of HTTP as a transport-level protocol for some higher-level RPC exchange. Yes, HTTP has some assortment of error codes that superficially look like they can be reused to serve as the upper-layer errors as well but that's a red herring.
