It's fine but it's sharp-edged, in that it's recommended to use IHttpClientFactory to avoid the dual problem of socket exhaustion ( if creating/destroying lots of HttpClients ) versus DNS caching outliving DNS ( if using a very long-lived singleton HttpClient ).
And while this article [1] says "It's been around for a while", it was only added in .NET Framework 4.5, which shows it took a while for the API to stabilise. There were other ways to make web requests before that of course, and also part of the standard library, and it's never been "difficult" to do so, but there is a history prior to HttpClient of changing ways to do requests.
For modern dotnet however it's all pretty much a solved problem, and there's only ever been HttpClient and a fairly consistent story of how to use it.
I always liked these benchmarks, I've been following them since the earliest rounds.
One thing to note is how much things have improved over that time. Numbers that used to top the benchmarks would now be seen as "slow" compared to the top performers.
The other useful thing about these benchmarks is being able to easily justify the use of out of the box ASP.NET Core.
For many languages, the best performers are custom frameworks and presumably have trade-offs versus better known frameworks.
For C# the best performing framework (at least for "fortunes") is aspnet-core.
That side-steps a lot of conversations that might otherwise drag us into "Should we use framework X or Y" and waste time evaluating things.
Are the benchmarks gamed? Yes of course, the code might not even be recognisable as Asp.NET Core to me, but that doesn't really matter if I can use it as an authoritative source to fend off the "rewrite in go" crowd, and it doesn't matter that it is gamed, because the real-world load is many orders of magnitude less than these benchmarks demonstrate is possible.
It's why all bars will have a little plaque saying what size their shots are. Almost always 25ml these days, but 35ml was common in many places. You're allowed to serve shots of either size but not in the same pub.
The way they got to the 25/ 35 split involves even more craziness. In England the law said spirits are always measured in sixths of a gill. This entire unit is obsolete, but 1/6 is a tiny bit less than 25ml. Fine.
However in Scotland two sizes were common, a fifth of a gill (slightly more generous than England) and a "nip" or quarter of a gill (a lot more generous). If you're used to ordering a "nip" of something and now you get a lot less you'd be very angry! So the 35ml option is there for the kind of Scottish or Irish establishment which would have been used to these larger measures rather than either try to keep the gill (which is a stupid unit nobody else needs) or anger drunk people.
I wouldn't be surprised if the "Make a sign" difference was to allow licensed premises to gradually shift to the more profitable, smaller, size. Maybe you change the place you own in Glasgow to 25ml first, and if the locals don't kick off you can try Aberdeen next, otherwise try again in a few years.
I got poured a pint by a newbie behind the bar at a hotel recently and she looked embarrassed as it was about 40% head, but to her credit she went to fetch the shift supervisor before I said anything.
He explained after pouring it better that, even the remaining head (It had ~3/4 inch even after fixing it) might still be met by derision by many customers. "They'd be asking if you would be charging them for just for the half" etc.
There's a bit of leeway but you'll quickly hear about it if you short a pint too much.
Yes. Americans/Canadians famously can't pour beer properly. If you are pouring a pilsner or really any lager, a head of at least 2 inches is actually correct and absolutely desirable. The way it's poured in Canada (no head) is borderline undrinkable to me.
Preferences vary on both sides of the Atlantic. Another comment on this post complains that Americans pour beer wrong because they _do_ pour with a head.
> Also in the US (probably due to lack of training and the customer too embarrassed to complaining) tend not to fill it the brim (and so not even 16''). I've seen 2-3 inch heads and asked them to top it up. They look at me as if I've just insulted George Washington
If an establishment wants to serve drinks with a head they should use glasses with a mark on the side indicating the measure, rather than glasses which need to be brim full. Using the latter style of glass and including a head is just ripping off the customer.
We call that kind of beer without any head "dead". Measurement here is about two fingers width, and if you do it the first time and screw up it is two fingers in length (second part is of course tounge-in-cheek).
Right? Just top it up, let some of the foam cascade over the side... Foam always forms in the keg if it sits for too long so you need to let some of it out anyway.
Next time please ask it to respect system dark/light mode preference, it's trivial to do, especially for an LLM which can spin up light/dark alternatives easily.
By "free windows" do you just mean an unactivated copy of Windows? That doesn't prevent the user from configuring their preference in the browser itself.
I kind of want webrings but with federated OIDC. I.e. you can create an account at any of the sites and re-use the login on the others to leave comments/add content. This has to exist in some neat package right?
There is indeed a lot of similarity with webrings and StumbleUpon but there are some differences as well. I discuss this in more detail in the project README here: https://codeberg.org/susam/wander#faq
It's the lack of transparency that is bad. PokemonGo did not make it clear it was taking (and uploading) pictures.
You could argue that "of course it must be for AR", but that isn't clear at all. The camera shows a live image before I take a photo, and I wouldn't expect a photo to be captured and sent if I didn't press the (virtual) shutter.
There are probably some cheap phones that do precisely that, and I'd be just as annoyed at them and raise the same concerns.
It isn't recording surreptitiously. The data was collected as part of an optional feature which is a very intentional process where you start a scan and then move around the object being scanned to get data from multiple angles, and then click to upload the data to Niantic. The uploading is called out specifically as a separate step (at least early on it was common for uploads to fail, so it had the option to save the scan to upload later when you had better signal). There is nothing secret about the fact that Niantic is collecting this data.
The lack of transparency is about how Niantic is using the data, selling it to third parties for purposes unrelated to the game. And I agree with the parent that this is a fair trade for a free game, especially since that part is optional, but more transparency would be better.
The article doesn’t say when this collection happens but there is some part of the game the involves photographing specific landmarks which does involve pressing a shutter. I’m guessing that’s where this comes from but would be great to hear from a better source.
Otherwise you've ended up with a brief snapshot, and not the top posts of the day.
It also seems odd to have a "summary of 16/03" produced while that day has barely begun in the US timezone, so looking retrospectively at the previous day would make this better.
Huh, that definitely explains it. I wonder how many people know that. In that case it's particularly unfortunate to downvote the OP simply for filling a field in the submission form! Sigh… I guess it's another case of LLMs having made the world a little worse for everybody.
Yeah, but before LLMs we didn't have "reads like LLM output" as a downvote reason. In 2022 nobody would've had qualms with the phrasing of the comment.
And while this article [1] says "It's been around for a while", it was only added in .NET Framework 4.5, which shows it took a while for the API to stabilise. There were other ways to make web requests before that of course, and also part of the standard library, and it's never been "difficult" to do so, but there is a history prior to HttpClient of changing ways to do requests.
For modern dotnet however it's all pretty much a solved problem, and there's only ever been HttpClient and a fairly consistent story of how to use it.
[1] https://learn.microsoft.com/en-us/dotnet/core/extensions/htt...
reply