Admittedly mobile was a bit of an afterthought and I only tested it on 4 devices. What device are you using?
HN user
fivesigma
What DiThi said (read his excellent post)
There's also another important detail. Due to delayed ACKs on Windows and battery-preserving TCP stacks on most mobile devices/laptops, some of your packets will be delayed. Even with TCP_NODELAY. Desktop OSX/Linux do not display this behavior.
The only solution I have found, and it's a rather crude one, is to blast the server every 50ms with a 1-byte packet. It is ugly but it works well.
Are you using Chrome? Gamepad API is a bit buggy on 62.x
Everything is running smoothly so it's not the HN effect.
Might I ask what OS/Browser/ISP are you using?
That is up to your keyboard hardware. Unfortunately, most consumer level keyboards can't handle that.
THE comboy of bitcoinity fame? I'm honored.
I remember donating back in the day!
It better be! It's my homegrown panel that I use for all my projects.
I will definitely do a write-up but you're right. It's really hard to find info on any of that online.
A lot of trial and error.
Nothing too fancy. Just proper devops and a lot of testing.
I have tested all browsers on Linux. Got a screenshot?
Will do when this is over. Right now I'm trying to prevent servers from melting. HN traffic...
Just plain ol' Websockets. But with a twist.
I use 2 WS connections mirroring some packets on both, to deal with head-of-line blocking.
Safari on iOS is generally buggy. WebGL and WebAudio are very glitchy.
I don't have a BT KB so I didn't test that case. Will do!
PIXI.js for the graphics. Serverside is mostly Node.js.
Let's Encrypt is great.
I would like to see native ECC support and a more stringent validation mode that allows more than 3 months of certificate lifetime.
How can it support thousands of colors
Temporal dithering. Also called FRC - frame rate control.
You might not notice it, but if you are on a TN monitor right now (almost all non-professional monitors) this technique is being used to emulate 24 bit color. Most TN panels can only display 6 bits per channel.
3 motors.
Some kind of torque vectoring deal in the rear wheels? Like the Electric AMG SLS.
A legitimate usage case would be opening a login popup on another domain that can't be iframe'd. For example OAuth social network login popups. They require window.opener to send back login credentials to the original website.
What prevents the hardware offloading from being used on public interfaces? Even if microsecond-level jitter reduction on public networks is negligible this should reduce CPU load in high PPS deployments, right?
I was hoping to see v8 6.2 make into the LTS but apparently it will be merged into a future 8.x release in a few months from now.
v8 6.2 fixes a lot of Turbofan related regressions, for example: for in object performance [1]
[1] https://medium.com/the-node-js-collection/get-ready-a-new-v8...
This mirrors my experience as well. Try having a relatively simple piece of code exhaust all available memory because CS was kind enough to turn a simple loop into a clusterfuck of epic proportions all because you forgot to return null on a function that well, doesn't need to return anything. Then you go and decaffeinate the entire thing, actually look at the JS output and your jaw drops at the amount of useless crap that your "syntactic sugar" added. Is it really worth it?
This could easily be fixed by adding a -!> operator that disables implicit returns, but no, they are so opinionated that a change like that will ruin their perfect little universe. I know that there are forks that add this sort of functionality among fixing some of my other gripes with CS but my point still stands: I'm not going to invest my time into a cult.
600 billion instructions per second to show a poop emoji.
Being in the same physical location doesn't mean they have the same connectivity though. With colo cages, once you get big enough you get to choose your upstream providers.
I get 15 ms better ping to Frankfurt Linode compared to Vultr, for example.
This is my experience as well with Adobe CC. At least 10 different daemons, some of them instances of node.js constantly connecting to adobe-owned IPs. Some of them even using very high amounts of CPU. Turning everything off from the CC settings didn't even make a difference.
I don't want fucking software I paid for to make my PC a part of a botnet, so I deleted all their stuff and tried to cancel my subscription to CC. I couldn't do that because their terms allow them to charge your credit card for the remainder of the year, even if you receive no service. After a few angry emails with a supervisor they finally agreed to cancel my subscription.
What a shady POS company.
No they wouldn't, since its internal state is different than the output.
Same goes for SHA-224 and SHA-384.
Is this length extending [1] the already existing Google attack?
[1] https://en.wikipedia.org/wiki/Length_extension_attack
Edit: yes, looks like it is.
As sp332 and JoachimSchipper mentioned, the novelty here is that it contains specially crafted code in order to conditionally display either picture based on previous data (the diff). I can't grok PDF so I still can't find the condition though. Can PDFs reference byte offsets? This is really clever.
Edit #2: I misunderstood the original Google attack. This is just an extension of it.
This requires the addition of random garbage in the first file which someone will detect anyway. Why not release an infected file with a timebomb malware instead of colliding SHA1? Much cheaper. Still, none of this allows you to attack an already existing torrent.
None of what you mentioned is affected since this is a collision attack. They purposely created 2 files with the same hash.
Creating a file with the same hash as legit file is a preimage attack and is much more difficult to perform (many orders of magnitude more difficult).
This still doesn't mean that SHA-1 isn't dogshit however. It should have been phased out years ago.
Blizzard blew it from the moment they started downloading/syncing their games via BitTorrent - using their customers bandwidth to support games that they paid for.
Not if it's over HTTPS, since it guarantees data integrity. Corrupted network bits will cause the connection to fail.
If the file is corrupted at the edge server an SRI attribute [1] can detect it, although it's not supported on IE and Safari yet.
[1] https://developer.mozilla.org/en-US/docs/Web/Security/Subres...