lukepothier
lukepothier on Hacker News
This isn't how driving works in practice. Suddenly stopping on a fast freeway isn't a reasonable thing to do unless it's absolutely necessary, and it's not reasonable to expect the following driver to constantly be considering the possibility that the driver in front will slam on the brakes for no reason.
Insurance companies (at least in some parts of the world) have a standing agreement to just hold the following driver responsible when there's a collision like this, because in the majority of these collisions, the following driver is at fault. It's efficient for them to agree to this convention to avoid the cost of investigating each collision individually. This has led to the common misconception that the following car is necessarily responsible if there is a front-to-rear collision.
I thought I and all my colleagues were getting 500s, but then I checked the status page and saw a green check. Silly me!
What's the best way to prevent this for Chrome? Can the F-Cache be disabled entirely? Otherwise, would
a Tampermonkey script or Chrome extension which just GETs /favicon.ico on every page load work?
EDIT: Seems to be preventable with a quick Tampermonkey hack: https://gist.github.com/lukepothier/1b18905039b1ed960efebec3...
> fonts are larger than you might think because they need full Unicode support
Correct me if I'm misunderstanding, but don't the vast majority of fonts _not_ include full Unicode support, or even close to it? I know of GNU Unifont, but not many people are using that on the web...
I take your point on selectively downloading the relevant glyphs for the user's locale, but this could be done by the browser too - it is aware of the locale.
Maybe I'm being naïve, but why don't browsers ship with more popular fonts bundled to avoid problems like these? I have no issue with any of my browsers taking up fractionally more space for an extensive cache of the most popular web fonts when the payoff is better performance on so many sites.
Of course, servers should still be capable of serving the fonts that the client requires to render the content correctly, but the browser should be equipped to make that happen as quickly as possible.
Posted by
lukepothier on Tuesday May 05, 2020 @10:33AM
from the trello.status.atlassian.com dept.
Of course. I know even more who whitelist sites with ads that aren't overbearing.
StackOverflow ads are not the same as typical ads that technical users tend to block - they are typically just simple text links to job offers. Additionally, SO has fantastic analytics on logged in users which would drive the cost per impression up - if you've ever filled out their developer survey, you've given them everything they need to sell employers very expensive targeted ads directed at you.
There are a few more for numeric types:
var integer = 1;
var long = 1l;
var float = 1f;
var double = 1d;
var decimal = 1m;
var unsignedInteger = 1u;
var unsignedLong = 1ul;
Fingers crossed it has desktop clients that aren't written in Electron...
That's interesting, and a relief.
If it's true that Chrome on Oreo genuinely prevents picture-in-picture
for YouTube specifically, that's a troubling precedent to set. Why not allow all websites to enable/disable PiP (maybe via a meta tag, in the way that tab theme colours already work)? If I query
https://m.youtube.com while emulating a Nexus 5X, the response contains:
<meta name="viewport" content="width=device-width, initial-scale=1.0, maximum-scale=1.0, user-scalable=no, target-densityDpi=medium-dpi">
Is that what is preventing PiP on YouTube or is it some sort of underhanded inter-Google arrangement between Chrome and YouTube?
The entire Southern Hemisphere gets light on December mornings. The summer solstice for the Southern Hemisphere is during December.
> "One can walk just about the whole way from Mumbai to Kolkata without stepping foot outside a constituency whose MP isn’t facing a charge."
So there's a line of clean constituencies from Mumbai to Kolkota? That 'isn't' should be an 'is'.