Youtube uses EME for 1080p streams, no EME and you only get 720p or lower
Theo claims OpenBSD is unaffected. http://undeadly.org/cgi?action...
Theo claims OpenSSH is unaffected, because it isn't. OpenSSL, even on OpenBSD, is quite affected.
And Git's hashes are not for the sake of security. Linus made that abundantly clear when he refused to allow SHA-2 to be used, even after people were able to manufacture a Git collision using SHA-1.
Citation needed. I can't find a published example of any actual SHA-1 collision, much less one from a Git repo.
The MongoDB core is AGPL. Its drivers are all Apache license, as explained here, therefore not polluting your web application code and forcing it under the AGPL.
BerkeleyDB, on the other hand, is linked in directly, and would force anything using it to be under the AGPL.
Something like a config option - 'Enable OS installation for one boot cycle.'
If the purpose of secureboot were just to secure the boot process, that's all it'd take.
That limitation isn't possible, because the UEFI/BIOS is not a hypervisor. Once something else is running in ring 0 there is no way to prevent it from doing whatever it wants. Implementing those kind of hardware locks would entail a much more serious change to many parts of the PC architecture.
The whole system of key signing is a rather obvious attempt to squeeze all the little players out of the game so the big boys can seize more power and profits.
Despite the above, this statement is probably quite accurate, though. It's certainly a convenient side-effect.
Home video was traditionally 24 or fewer frames per second. (Unless by "traditionally" you mean the past few years when you could record digital video at more than 30 frames per second.)
The GP poster is correct. Super 8mm film is not "video" and hence is not "home video". NTSC VHS is absolutely 60 fields per second. The only way to get 24 FPS on VHS is with 3:2 pulldown, which no consumer cameras I know of ever did. Even getting close to a "real" simultaneously-sampled 30 frames per second instead of 60 interlaced fields would require a sample-and-hold, which again consumer VHS camcorders didn't have AFAIK.
You should have updated to IPv6, where is no such checksum in TCP.
I think you're misinformed. IPv6 has no IP header checksum, unlike IPv4. However, the higher-level protocol checksums are still there; in fact, UDP over IPv6 is required to include a valid checksum, unlike in IPv4 where it can optionally be 0x0000.
I wonder how they have managed to solved the condensation problem.
They run their oil at 40C. If the dew point in your server room is that high you have other problems...