Wait, so now we aren't setting read/write status in fstab anymore?
How do you set filesystem read/write status for just the ntpdate process in fstab?
Ugh.
The bloody MUSB driver/OMAP hardware combination caused me to have to write this horrible thing:
local kmsg = io.open('/proc/kmsg', 'r')
for line in kmsg:lines() do
--...
--elseif line:match('USB IS HORKED %- HELP PLEASE!') then
----local reset_usb =
------io.open('/sys/devices/platform/<product>-kludges/reset_usb', 'w')
----reset_usb:write('1\n')
----reset_usb:close()
----log.log('Reset USB')
--end
end
...because some (rare) USB devices would occasionally cause the harware to basically completely lock up when plugged in. I could identify this and cry for help from within the driver, but the only way I found to successfully unkludge it was to completely remove and reinstall the kernel device, thereby completely reinitializing the device and driver.
Fortunately(?) it looks like this product is unlikely to actually ship...
Youtube uses EME for 1080p streams, no EME and you only get 720p or lower
Youtube uses Media Source Extensions for 1080p streams. That's completely different; it's a way to source data to a <video> element from Javascript. They use it to implement their dynamic HTTP streaming, where rather than just sucking down a file you suck down individual file segments allowing dynamic quality adjustments based on your available bandwidth. There's no DRM involved.
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.
What are you talking about?
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.
He has not acquired a fortune; the fortune has acquired him. -- Bion
