Something this API gets right is having a unified interface for both IPv4 and IPv6. With the sockets API, you have to decide for one of them. Changing isn't easy as the constants and structures are all named differently.
While it's possible to use IPv6 sockets for IPv4 connections, this doesn't cover all use-cases. For example, you can't do IPv4 broadcast with an IPv6 socket. Additionally, as most examples are written for the classic IPv4 API, that's what everyone uses per default. Later on, when people complain about missing IPv6 support, they are turned down because it's a ton of work to change.
The optimal block size is probably the the amount of data which can be transferred with one DMA operation.
For NVMe disks on Linux, you can find out this size with the nvme-cli [0] tool. Use "nvme id-ctrl" to find the Maximum Data Transfer Size (MDTS) in disk (LBA) blocks and "nvme id-ns" to find the LBA Data Size (LBADS). The value is then 2^MDTS * 2^LBADS byte.
For example, the Intel SSD 450 can transfer 32 blocks of 4096 byte per NVMe command, so you'd want a block size of 128 kiB.
You have to trust some hardware, but not necessarily the full stack you listed above.
For example, chipTAN is commonly used in Germany to verify online banking. You have to trust the chip on the banking card and the card reader, but not your computer, network connection, or your smartphone.
A similar device may also work for online voting. The hardware would be simple enough to audit it. Your computer would never learn the vote.
This is exactly what the "block third-party cookies" option does. It really should be enabled per default, possibly with a permission prompt for cases where they are useful.
The interesting thing here is that third-party cookies usually allow a central site (e.g. an ad server) to track a user across many other sites. It's almost the other way around here: "other sites" can track status on a "central site".
Not really liberal - leaving out those tags is perfectly fine according to the specification and all compliant browsers will create the same DOM from it.
Is it really? Apart from the missing port-forwarding, DS-Lite seems to be one of the better solutions to the IPv4 shortage to me. There's only a single NAT at the ISP, the local router tunnels IPv4 packages directly to the AFTR. For peer-to-peer applications, both UDP and TCP hole punching work fine.
Maybe some ISPs will implement the Port Control Protocol [1] at some point, which would allow port forwarding with the DS-Lite NATs.
>This is the definition of a Hash Function. Not a cryptographic Hash Function.
No, a hash function is just any function which can be used to put values into a hash map. If your inputs are numbers, modulo will work fine as a hash function, but is obviously not one-way.
>Cryptographic Hashes should NEVER collide, on any inputs, ever, period.
This is obviously not possible, as the output of the cryptographic hash function is of fixed-length while the input is variable-length. Finding collision just needs to be hard, not impossible.
Looking at the source code, it's actually licensed under the GPLv3 as well, so the software seems to be free, just the resources and game content aren't.
But the thing is that a game targeting Windows XP or even Windows 98 still has a good chance of running on Windows 10. On the Linux side, good luck getting binaries made for Ubuntu 14.04 run on Ubuntu 16.04.
Nice to know that they're working on better HiDPI support. GTK 3 for some reason has two separate HiDPI settings, but one of them only supports integer scaling factors. Additionally, there is no way to specify different factors for each monitor. If you have two monitors with different densities, a GTK window will always have the wrong scaling on one of them.
Qt 5 gets this right. The only frustrating thing there is how many applications still use Qt 4… (same applies to GTK 2, I guess)
Did you look into the EventSource API? It's basically automatic long-polling with a simple file format built into the browser. It supports pretty much every "real-time" pattern: regular polling, long polling, and streaming.
The browser handles the log position for you (via the id field and the Last-Event-ID header) and automatically reconnects when the server closes the stream or the connection is lost.
The proposed Redis API seems to fit extremely well to this model. My previous usage of EventSource with Redis worked by sending the entire state whenever someone (re-)connects and using PubSub afterwards. This works well for me, but likely doesn't scale very well.
As I understand it (from reading the README) it's storing SHA(chunk) -> Enc(chunk) in its database. When adding to the backup, it checks whether SHA(chunk') is already there. Thus, it doesn't have to look at the encrypted data. However, it also can't verify that a chunk stores the correct data.
Note that your protocol isn't actually a zero-knowledge proof. While transcripts can be made up, a third person observing everything Gavin does would absolutely be convinced by the exchange. For real interactive zero-knowledge proof, even a dishonest prover has a good chance to provide a correct answer at each step. This isn't the case with the DH exchange.
I don't quite understand how that works. Surely there wasn't a crowd of 3000 people at the bottom of the escalator when people were walking on the left? Where do the extra people come from?
While it's possible to use IPv6 sockets for IPv4 connections, this doesn't cover all use-cases. For example, you can't do IPv4 broadcast with an IPv6 socket. Additionally, as most examples are written for the classic IPv4 API, that's what everyone uses per default. Later on, when people complain about missing IPv6 support, they are turned down because it's a ton of work to change.