Did you actually read that article? It clearly describes exactly what I said: they use resistors on the data pins to signal the available current. There is no bidirectional negotiation going on. There are no extra pins or wires. The charger just has 4 resistors to create two voltage dividers for the D- and D+ pins.
This is incorrect. There is no bidirectional negotiation between chargers and devices, nor are there any magic extra pins (at least for pretty much all Android and Apple products - dunno about Zune).
What there is is one USB charging standard, that basically says one thing and one thing only (that matters): if the data pins are shorted together (but otherwise not connected to anything), then the port is a Dedicated Charging Port. A DCP must meet certain voltage/current curve ranges and may be engineered to supply anywhere from 500mA to 1.5A (or more), with the voltage dropping as the device exceeds the charger's maximum. Devices are simply supposed to regulate current draw upwards until the voltage drops below a threshold, indicating the charger's capability. No digital negotiation takes place. Devices are limited to 1.5A charging current, which is quite typical for modern devices (and significantly better than the 500mA of a non-charging port).
There is a newer USB Power Delivery specification that is much more recent, supports higher powers, probably uses more complex negotiation (I haven't read it), and nothing implements it yet.
Then there's what Apple does - they have an incompatible implementation that uses resistors on the data pins in the charger to signal its current capability. Different resulting voltages mean different current levels. This is completely incompatible with the USB charging standard. Recent Apple devices (since the iPhone 3G or so) do support DCP chargers (to some extent - some charge more slowly, and I don't know about larger iPads?), but non-Apple devices will only charge at 500mA or worse from Apple chargers.
This is false. Decoding for modern video formats is strictly defined, and all decoders must produce bit-perfect output. You can add as many filters as you want after that, but that's a postprocessing step in the video player and has nothing to do with the decoder. Things like in-loop filters are strictly defined as part of the decoding process and must be there for the decoder to be considered correct.
Nope, they just crash, lag, or play it with severe artifacts (the latter happens with some hardware codecs and 10bit files).
Basically no modern video codecs are designed to gracefully degrade given limited decoder features, because they rely on bit-perfect output to be used as a reference for future frames. Any error accumulates in the decoding loop and becomes significant artifacting until the next I frame.
0x80 is just a null byte with odd parity. What she apparently missed is that this is bog-standard Bell 202 AFSK (1200 baud) with 7 data bits and odd parity, and the data is ASCII. By throwing away the top nybble, she was throwing away the parity bit and the top 3 bits of the ASCII encoding of decimal digits. The fact that it was a parity bit should've been pretty obvious, since the top nybble flips between 0x3x and 0xbx in the pattern that you'd expect for a parity bit.
You can decode it with off the shelf software, throw away the top bit, and get back mostly ASCII: $./minimodem --rx 1200 -f ~/helicopter.wav | tr '\200-\377\r' '\000-\177\n' ### CARRIER 1200 @ 1200.0 Hz ###
282 0002.3 #L N390374 W09432938YJ #AL #NA 282 0002.3 #L N390374 W09432938YJ #AL #NA 283 0002.3 #L N390372 W09432928YJ #AL #NA 283 0002.3 #L N390370 W09432918YJ #AL #NA 283 0002.3 #L N390370 W09432918YJ #AL #NA 283 0002.3 [...]
I'm actually surprised that she missed / didn't mention this, considering her experience with signals analysis and demodulation. This is pretty much as basic as telemetry data modulation gets! Then again, as a reverse engineer myself, sometimes we get caught up doing deep analysis of something that later turns out to be totally trivial:)
The MHz number on the box is the bandwidth, not the sample rate. The sample rate is measured in samples per second (GSps). A 100MHz scope is probably adequate for analog signals up to 100MHz. However, if you're debugging a digital signal, you want a scope that has 3x the bandwidth of your signal's base frequency or more, because square waves are composed of the base frequency and an infinite number of harmonics. If you only have bandwidth for the base frequency, your square wave will be distorted into a sine wave and you won't be able to accurately see ringing, glitching, and other artifacts.
I have a 1GSps, 100MHz scope. I wouldn't use it for serious digital signal debugging above 30MHz (which is 33x lower than the sample rate), due to the bandwidth constraint. It's adequate for seeing if stuff up to 100-150MHz is "there" though (and for reading the bits out if you just want to use it as a poor man's logic analyzer), just don't expect to diagnose signal integrity and timing issues at those speeds.
You can correct for chromatic aberration in software, to a varying degree. You can approximate it (so the aberration is ~1/3 of what it would normally be, by aligning the centers of the primary colors) for arbitrary inputs, e.g. a photograph captured with an imperfect lens (image editing software can do this). You can do it on the output side with perfect accuracy if you're displaying an image using three monochromatic light sources (e.g. a laser display), since the three wavelengths involved would then be distorted by three discrete amounts that are perfectly correctable. For RGB panels like LCDs and OLED displays the primaries aren't monochromatic, but they are more concentrated around the dominant wavelength than a natural light source with a uniform frequency distribution, so you get a result that's somewhere in between. This is what the Rift does to correct for chromatic aberration in software.
Uneven pixel density is only a problem if the pixel density at the sparsest point is too low. Today's displays already exceed visual acuity when viewed at a reasonable distance (e.g. a Nexus 10 or an iPad with a Retina display at a normal operation distance), though of course that is without covering a large fraction of the FOV. Give it a few more years and it'll only get better - once we have 8K phone-sized displays this will probably be a non-issue.
Obviously you were concerned enough to measure if there was any imminent danger
I wasn't concerned. I'm just a curious geek who happens to own a logging Geiger counter.
The issues is not radiation emitted, it's the radionuclides emitting them.
That is true. Ingesting radionuclides is definitely a much bigger problem than external exposure.
That's great but it's more likely that Japan now has very high concentration of radionuclides in very specific places in the ocean or land or sea, some of that area will be producing food. The likelihood of encountering in the food chain is now higher than the initial accident because the radionuclides have propagated further up the foodchain so if you ate food in Japan the likelihood of ingesting it has increased. The longer you stay there the more you will increase your chances of a permanent dose in your body, the more times you get one of those means the probability of some sort of cancer increases. A big problem for the locals, but not really a worry for you.
It's hard to get real data about these issues, as there is a ridiculous amount of fearmongering in the media. For example, there are plenty of articles talking about the spread of radiation in the Pacific Ocean from Fukushima to other countries, but a simple dilution argument shows that any claim of danger from that effect is nonsense - the ocean is ridiculously bigger than the quantity of radioactive water released, and even if you can measure the effect, it's going to be negligible in practice.
Locally produced food is another issue, and yes, the possibility for concerning contamination exists. Supposedly, food is tested in Japan, and the limits are stricter than in the US. Converting that into the probability that you will eat something that exceeds the limit (and by how much) is tricky. If you know of any serious studies attempting to calculate this, please do let me know.
FWIW, I do plan on moving to Japan in the not too distant future.
Interesting. I didn't stop at Fukushima station, but I went past it on the Shinkansen with my Onyx in the outer pocket of my backpack (obviously it won't be picking up any alpha radiation there, but still useful data). Looking closely at the logs it is possible that one spike correlates with roughly the time I'd have been in that area, though I really would have to check the times closely. The Onyx was set to log every 10 minutes so it's also possible that it just missed the interesting times. The peak readings were about 0.2uSv/h, and that wasn't near Fukushima. Tokyo averaged somewhere around 0.11 uSv/h, while Hakodate (where I stayed a couple of days) was around 0.07uSv/h.
Interestingly, my return flight hit 3.0uSv/h, higher than the first flight (I just dumped the last chunk of the log which I hadn't done yet).
These readings seem to be using the default calibration of the Onyx. I haven't delved into the details yet (the firmware is still WIP as far as I can tell), but AIUI they are supposed to come calibrated, so either the default calibration is spot on, or the firmware isn't using the calibration data, or my firmware upgrade wiped the calibration data, or the calibration data was never there. Either way, I assume the default conversion factor is good enough for rough measurements of background radiation.
Somewhat amusingly, he typoed the one relevant box in there - "Extra dose to Tokyo in weeks following Fukushima accident" should probably be 40uSv (not 40mSv) if he means per person (and even then it sounds a bit high), or be in the orange chart if he means the total dose delivered to all of Tokyo.
Using my Safecast Onyx (hi Safecast folks!) I measure ~0.32 uSv/h in Dublin, next to a granite wall (granite is everywhere around here, and naturally radioactive). The article speaks of of 0.484 uSv/h, not much higher than that. On an airplane at cruising altitude I get about 2.0uSv/h. At home I might see 0.08uSv/h, and in the middle of the street somewhere around 0.15uSv/h. *
I just visited japan and took the Safecast everywhere I went. At no point did it go significantly above what were normal background radiation readings in Dublin (not even when I was passing by Fukushima station, though admittedly that was on a high-speed train).
Radiation is everywhere. Unless you can identify the source as the Fukushima disaster, it might be perfectly normal. Even if the source is Fukushima, at low levels, at some point you have to stop worrying about it and realize that plenty of other places on Earth have higher naturally occurring background radiation.
* Rough numbers pulled from memory in CPM and converted to uSv/h using the conversion factor in the firmware source code, since my Onyx battery is dead at the moment. Take with a grain of salt.
I started doing this after getting a dozen Vodafone marketing calls. Except instead of just leaving the phone off-hook, I said "please hold while I transfer you" and then treated them to an endless random shuffle of Never Gonna Give you Up, Friday, Trololo, Caramelldansen, and Nyan Cat, played via a voice modem.
They stopped calling after they got that a couple of times.
Google uses ephemeral Diffie-Hellman key exchange for its SSL implementation, as long as the client is modern enough (i.e. everything except IE on Windows XP). That provides forward secrecy. Even if the NSA had the private keys, they wouldn't be able to snoop on anyone's traffic by passively sniffing - they'd have to mount an active MITM attack, and that is much harder to do, and even harder to do undetectably.
There's two problems with the current crop of 3D printers. First, the printers are fiddly. It is possible to print out decent objects on a good printer (personally, I'm a fan of the Ultimaker). However, it requires tuning the printer and the software and maintaining them. It's a solution for tinkerers, not for Joe Average. Companies like MakerBot are deluding themselves when they think they've got a RepRap-class printer they can sell already assembled "for the masses". They still need too much maintenance.
Second, you can't just print anything and expect it to look good. If your object doesn't require support material (overhangs are all under a reasonable angle), and the slices don't contain more than one connected surface, then it will look beautiful on a decent printer. If you need support material though, then you have to deal with removing it, which is nontrivial. If you have more than one surface per slice, then you have to deal with stringing. That's not too bad if the surfaces are far apart (you can remove it easily), but it's difficult if they are close together. These are the limitations of plastic extrusion printers today, and you need to design models taking them into account.
On decent prints: http://www.flickr.com/photos/marcan42/8542507791/in/photostream/ . That's a gear, about 8cm across. You have to get up really close to be able to see those layers with the naked eye (they're 0.1mm tall). The roughness on the top and bottom surfaces is probably on the order of 50 microns. It is possible to go smaller on this printer. On fiddling: http://www.flickr.com/photos/marcan42/8543920590/in/photostream/ . Left print is before tensioning belts, right print after. Of course, one of the cool aspects is that I was able to print the belt tensioners on the printer itself.
I'm very happy with my printer, but I would never recommend it to someone who isn't already a hardware hacker.
I've written DRM that is good for the "customer" (user). It's a bit bizarre, though. More like reverse DRM. It's purpose is to ensure that the software isn't "pirated" and sold for money, instead of downloaded for free, as it should be.
I'm one of the authors of BootMii and The Homebrew Channel for the Nintendo Wii. It's a free (as in beer) piece of software that you can use to run untrusted code on your console (what people like to call jailbreaking these days). Before it had any kind of security, we found out that scammers were selling it (in violation of our license) along with "piracy packs". We added a big "scam warning" to the installer to clue users into the fact that the software is free, and if they have paid for it they have been scammed. However, the scammers started telling users to use the same tools used to pirate WiiWare games to install The Homebrew Channel itself - this bypasses our installer and the scam warning. So we added DRM that ties each install to a given console (if you try to copy it, it still works, but then you get the scam warning every time you try to use the software instead, until you reinstall it using the proper installer). There's enough obfuscation to stop the (generally clueless) scammers from working around it.
I'm nominally very anti-DRM, but I've thought long and hard about this and I really can't see a significant downside for users. It doesn't affect normal users in the slightest, as far as I can tell. It doesn't actually prevent anything from working (sometimes, you can damage system firmware such that The Homebrew Channel is one of the few or the only option left to repair it, and you can't run the installer - we never want the DRM to accidentally close off a user's last hope for their console, so it's designed to be extremely annoying if the check fails, but not actually stop working). Of course, it doesn't prevent you from installing it on as many consoles as you want - just use the installer (which is a great idea for many other reasons anyway - it's so paranoid about system checks and safety that it has never bricked a single console in millions of installs) and you're fine.
As far as I can tell, this only adds support for using the nvidia card for everything (rendering the whole desktop) while sending its final framebuffer to the Intel for scanout. This is a strictly different use case from what bumblebee enables (rendering *specific apps* on the nvidia card while using the Intel for everything else).
Personally, since I only need the performance of the nvidia card one in a blue moon, the bumblebee approach is much more useful to me. Otherwise, I'd have to deal with tearing on everything (the current version of the nvidia RandR output provider does not support vsync) and increased power consumption.
I think what nvidia calls "render offload" in their README (which is currently not supported) is what would in fact replace bumblebee, if/when implemented. I'm curious as to how it would interact with power management, though. One of the very nice things about Bumblebee is that it doesn't even power up the nvidia card (via ACPI) until required, and that's easy because it starts up a background X server on demand to do the rendering. It's probably trickier to puil this off if you have to load the nvidia driver into your primary X server to take advantage of the direct integration.
The active noise cancellation indeed only works for low frequencies, but noise-cancelling headphones muffle higher frequency noise by design too. I find them quite acceptable in very noisy environments, and I suspect they will work well anywhere where there's a wall between you and the noisy human anyway. If you must, feed them white noise to drown out what remains.
First of all, you mention the TCP/IP checkum, at the same time as key exchanges, long PSKs, and money transfer. Which is it, simple message integrity or message authentication? If you need authentication, you shouldn't even be mentioning TCP/IP checksums. If all you need is integrity, then just append an MD5.
Assuming you need authentication: I don't have any opinion on Blake2, but you should use an HMAC instead of just appending the shared secret key and taking the hash. HMAC can be built on top of any hash function, including Blake2. You should also make your MACs at leasts 128 bits long, preferably 192 or 256. 64 bits is definitely bruteforceable these days. I wouldn't settle for anything shorter than 256 for a protocol that involves money.
Keep in mind that a basic message authentication code is only one piece of a secure protocol. There are many possible attacks that might slip through (e.g. replay attacks, MITM, timing attacks,...). For example, you need to ensure that an attacker can neither reinject a message from the current session back into it (e.g. by using a sequence number in the signed payload) nor reinject a message from a different session (e.g. by ensuring that there is a random component to the shared secret) nor somehow guess the right MAC code (e.g. by making sure that the wrong-MAC responses do not leak any information, neither in contents nor timing), and of course there's always the host identification problem (preventing a simple MITM where the attacker performs a key exchange with both sides and resigns/reencrypts traffic both ways). Honestly, your first choice should be to use an existing well-tested protocol, such as TLS (you can build your own host verification rules on top of it, you don't have to use the "well-known" root CA list). Failing that, consult a real crypto expert.
Slashdot Mirror
Did you actually read that article? It clearly describes exactly what I said: they use resistors on the data pins to signal the available current. There is no bidirectional negotiation going on. There are no extra pins or wires. The charger just has 4 resistors to create two voltage dividers for the D- and D+ pins.
This is incorrect. There is no bidirectional negotiation between chargers and devices, nor are there any magic extra pins (at least for pretty much all Android and Apple products - dunno about Zune).
What there is is one USB charging standard, that basically says one thing and one thing only (that matters): if the data pins are shorted together (but otherwise not connected to anything), then the port is a Dedicated Charging Port. A DCP must meet certain voltage/current curve ranges and may be engineered to supply anywhere from 500mA to 1.5A (or more), with the voltage dropping as the device exceeds the charger's maximum. Devices are simply supposed to regulate current draw upwards until the voltage drops below a threshold, indicating the charger's capability. No digital negotiation takes place. Devices are limited to 1.5A charging current, which is quite typical for modern devices (and significantly better than the 500mA of a non-charging port).
There is a newer USB Power Delivery specification that is much more recent, supports higher powers, probably uses more complex negotiation (I haven't read it), and nothing implements it yet.
Then there's what Apple does - they have an incompatible implementation that uses resistors on the data pins in the charger to signal its current capability. Different resulting voltages mean different current levels. This is completely incompatible with the USB charging standard. Recent Apple devices (since the iPhone 3G or so) do support DCP chargers (to some extent - some charge more slowly, and I don't know about larger iPads?), but non-Apple devices will only charge at 500mA or worse from Apple chargers.
This is false. Decoding for modern video formats is strictly defined, and all decoders must produce bit-perfect output. You can add as many filters as you want after that, but that's a postprocessing step in the video player and has nothing to do with the decoder. Things like in-loop filters are strictly defined as part of the decoding process and must be there for the decoder to be considered correct.
Nope, they just crash, lag, or play it with severe artifacts (the latter happens with some hardware codecs and 10bit files).
Basically no modern video codecs are designed to gracefully degrade given limited decoder features, because they rely on bit-perfect output to be used as a reference for future frames. Any error accumulates in the decoding loop and becomes significant artifacting until the next I frame.
0x80 is just a null byte with odd parity. What she apparently missed is that this is bog-standard Bell 202 AFSK (1200 baud) with 7 data bits and odd parity, and the data is ASCII. By throwing away the top nybble, she was throwing away the parity bit and the top 3 bits of the ASCII encoding of decimal digits. The fact that it was a parity bit should've been pretty obvious, since the top nybble flips between 0x3x and 0xbx in the pattern that you'd expect for a parity bit.
You can decode it with off the shelf software, throw away the top bit, and get back mostly ASCII:
./minimodem --rx 1200 -f ~/helicopter.wav | tr '\200-\377\r' '\000-\177\n'
$
### CARRIER 1200 @ 1200.0 Hz ###
282 0002.3
#L N390374 W09432938YJ
#AL #NA 282 0002.3
#L N390374 W09432938YJ
#AL #NA 283 0002.3
#L N390372 W09432928YJ
#AL #NA 283 0002.3
#L N390370 W09432918YJ
#AL #NA 283 0002.3
#L N390370 W09432918YJ
#AL #NA 283 0002.3
[...]
I'm actually surprised that she missed / didn't mention this, considering her experience with signals analysis and demodulation. This is pretty much as basic as telemetry data modulation gets! Then again, as a reverse engineer myself, sometimes we get caught up doing deep analysis of something that later turns out to be totally trivial :)
Meanwhile, I've been running the same Gentoo install for ~9 years now (having migrated through 5 different machines). Rolling upgrades are awesome.
(It would be >10 years, but I did have to reinstall early on to migrate from x86 to x86-64).
The MHz number on the box is the bandwidth, not the sample rate. The sample rate is measured in samples per second (GSps). A 100MHz scope is probably adequate for analog signals up to 100MHz. However, if you're debugging a digital signal, you want a scope that has 3x the bandwidth of your signal's base frequency or more, because square waves are composed of the base frequency and an infinite number of harmonics. If you only have bandwidth for the base frequency, your square wave will be distorted into a sine wave and you won't be able to accurately see ringing, glitching, and other artifacts.
I have a 1GSps, 100MHz scope. I wouldn't use it for serious digital signal debugging above 30MHz (which is 33x lower than the sample rate), due to the bandwidth constraint. It's adequate for seeing if stuff up to 100-150MHz is "there" though (and for reading the bits out if you just want to use it as a poor man's logic analyzer), just don't expect to diagnose signal integrity and timing issues at those speeds.
Low-speed 1.8V and high-speed 0.5V LVDS mode, 800MHz... a MIPI-DSI display? :-)
Or one of these (it also passes through USB 3.0, which is nice):
http://www.amazon.com/Centech-USB-Power-Meter/dp/B00DAR4ITE
This isn't new.
You can correct for chromatic aberration in software, to a varying degree. You can approximate it (so the aberration is ~1/3 of what it would normally be, by aligning the centers of the primary colors) for arbitrary inputs, e.g. a photograph captured with an imperfect lens (image editing software can do this). You can do it on the output side with perfect accuracy if you're displaying an image using three monochromatic light sources (e.g. a laser display), since the three wavelengths involved would then be distorted by three discrete amounts that are perfectly correctable. For RGB panels like LCDs and OLED displays the primaries aren't monochromatic, but they are more concentrated around the dominant wavelength than a natural light source with a uniform frequency distribution, so you get a result that's somewhere in between. This is what the Rift does to correct for chromatic aberration in software.
Uneven pixel density is only a problem if the pixel density at the sparsest point is too low. Today's displays already exceed visual acuity when viewed at a reasonable distance (e.g. a Nexus 10 or an iPad with a Retina display at a normal operation distance), though of course that is without covering a large fraction of the FOV. Give it a few more years and it'll only get better - once we have 8K phone-sized displays this will probably be a non-issue.
I wasn't concerned. I'm just a curious geek who happens to own a logging Geiger counter.
That is true. Ingesting radionuclides is definitely a much bigger problem than external exposure.
It's hard to get real data about these issues, as there is a ridiculous amount of fearmongering in the media. For example, there are plenty of articles talking about the spread of radiation in the Pacific Ocean from Fukushima to other countries, but a simple dilution argument shows that any claim of danger from that effect is nonsense - the ocean is ridiculously bigger than the quantity of radioactive water released, and even if you can measure the effect, it's going to be negligible in practice.
Locally produced food is another issue, and yes, the possibility for concerning contamination exists. Supposedly, food is tested in Japan, and the limits are stricter than in the US. Converting that into the probability that you will eat something that exceeds the limit (and by how much) is tricky. If you know of any serious studies attempting to calculate this, please do let me know.
FWIW, I do plan on moving to Japan in the not too distant future.
Interesting. I didn't stop at Fukushima station, but I went past it on the Shinkansen with my Onyx in the outer pocket of my backpack (obviously it won't be picking up any alpha radiation there, but still useful data). Looking closely at the logs it is possible that one spike correlates with roughly the time I'd have been in that area, though I really would have to check the times closely. The Onyx was set to log every 10 minutes so it's also possible that it just missed the interesting times. The peak readings were about 0.2uSv/h, and that wasn't near Fukushima. Tokyo averaged somewhere around 0.11 uSv/h, while Hakodate (where I stayed a couple of days) was around 0.07uSv/h.
Interestingly, my return flight hit 3.0uSv/h, higher than the first flight (I just dumped the last chunk of the log which I hadn't done yet).
These readings seem to be using the default calibration of the Onyx. I haven't delved into the details yet (the firmware is still WIP as far as I can tell), but AIUI they are supposed to come calibrated, so either the default calibration is spot on, or the firmware isn't using the calibration data, or my firmware upgrade wiped the calibration data, or the calibration data was never there. Either way, I assume the default conversion factor is good enough for rough measurements of background radiation.
Somewhat amusingly, he typoed the one relevant box in there - "Extra dose to Tokyo in weeks following Fukushima accident" should probably be 40uSv (not 40mSv) if he means per person (and even then it sounds a bit high), or be in the orange chart if he means the total dose delivered to all of Tokyo.
Using my Safecast Onyx (hi Safecast folks!) I measure ~0.32 uSv/h in Dublin, next to a granite wall (granite is everywhere around here, and naturally radioactive). The article speaks of of 0.484 uSv/h, not much higher than that. On an airplane at cruising altitude I get about 2.0uSv/h. At home I might see 0.08uSv/h, and in the middle of the street somewhere around 0.15uSv/h. *
I just visited japan and took the Safecast everywhere I went. At no point did it go significantly above what were normal background radiation readings in Dublin (not even when I was passing by Fukushima station, though admittedly that was on a high-speed train).
Radiation is everywhere. Unless you can identify the source as the Fukushima disaster, it might be perfectly normal. Even if the source is Fukushima, at low levels, at some point you have to stop worrying about it and realize that plenty of other places on Earth have higher naturally occurring background radiation.
* Rough numbers pulled from memory in CPM and converted to uSv/h using the conversion factor in the firmware source code, since my Onyx battery is dead at the moment. Take with a grain of salt.
I started doing this after getting a dozen Vodafone marketing calls. Except instead of just leaving the phone off-hook, I said "please hold while I transfer you" and then treated them to an endless random shuffle of Never Gonna Give you Up, Friday, Trololo, Caramelldansen, and Nyan Cat, played via a voice modem.
They stopped calling after they got that a couple of times.
EVE doesn't use IronPython. It uses Stackless Python. And yes, it is possible to decompile the code, and it has been done in the past.
http://evesupernerf.blogspot.co.uk/2012/05/decompiling-eve-client.html
https://github.com/wibiti/evedec/blob/master/evedec.py
Mod parent up. The 40% figure is bullshit claimed by a single stats agency.
Google uses ephemeral Diffie-Hellman key exchange for its SSL implementation, as long as the client is modern enough (i.e. everything except IE on Windows XP). That provides forward secrecy. Even if the NSA had the private keys, they wouldn't be able to snoop on anyone's traffic by passively sniffing - they'd have to mount an active MITM attack, and that is much harder to do, and even harder to do undetectably.
Yup.
There's two problems with the current crop of 3D printers. First, the printers are fiddly. It is possible to print out decent objects on a good printer (personally, I'm a fan of the Ultimaker). However, it requires tuning the printer and the software and maintaining them. It's a solution for tinkerers, not for Joe Average. Companies like MakerBot are deluding themselves when they think they've got a RepRap-class printer they can sell already assembled "for the masses". They still need too much maintenance.
Second, you can't just print anything and expect it to look good. If your object doesn't require support material (overhangs are all under a reasonable angle), and the slices don't contain more than one connected surface, then it will look beautiful on a decent printer. If you need support material though, then you have to deal with removing it, which is nontrivial. If you have more than one surface per slice, then you have to deal with stringing. That's not too bad if the surfaces are far apart (you can remove it easily), but it's difficult if they are close together. These are the limitations of plastic extrusion printers today, and you need to design models taking them into account.
On decent prints: http://www.flickr.com/photos/marcan42/8542507791/in/photostream/ . That's a gear, about 8cm across. You have to get up really close to be able to see those layers with the naked eye (they're 0.1mm tall). The roughness on the top and bottom surfaces is probably on the order of 50 microns. It is possible to go smaller on this printer.
On fiddling: http://www.flickr.com/photos/marcan42/8543920590/in/photostream/ . Left print is before tensioning belts, right print after. Of course, one of the cool aspects is that I was able to print the belt tensioners on the printer itself.
I'm very happy with my printer, but I would never recommend it to someone who isn't already a hardware hacker.
I've written DRM that is good for the "customer" (user). It's a bit bizarre, though. More like reverse DRM. It's purpose is to ensure that the software isn't "pirated" and sold for money, instead of downloaded for free, as it should be.
I'm one of the authors of BootMii and The Homebrew Channel for the Nintendo Wii. It's a free (as in beer) piece of software that you can use to run untrusted code on your console (what people like to call jailbreaking these days). Before it had any kind of security, we found out that scammers were selling it (in violation of our license) along with "piracy packs". We added a big "scam warning" to the installer to clue users into the fact that the software is free, and if they have paid for it they have been scammed. However, the scammers started telling users to use the same tools used to pirate WiiWare games to install The Homebrew Channel itself - this bypasses our installer and the scam warning. So we added DRM that ties each install to a given console (if you try to copy it, it still works, but then you get the scam warning every time you try to use the software instead, until you reinstall it using the proper installer). There's enough obfuscation to stop the (generally clueless) scammers from working around it.
I'm nominally very anti-DRM, but I've thought long and hard about this and I really can't see a significant downside for users. It doesn't affect normal users in the slightest, as far as I can tell. It doesn't actually prevent anything from working (sometimes, you can damage system firmware such that The Homebrew Channel is one of the few or the only option left to repair it, and you can't run the installer - we never want the DRM to accidentally close off a user's last hope for their console, so it's designed to be extremely annoying if the check fails, but not actually stop working). Of course, it doesn't prevent you from installing it on as many consoles as you want - just use the installer (which is a great idea for many other reasons anyway - it's so paranoid about system checks and safety that it has never bricked a single console in millions of installs) and you're fine.
As far as I can tell, this only adds support for using the nvidia card for everything (rendering the whole desktop) while sending its final framebuffer to the Intel for scanout. This is a strictly different use case from what bumblebee enables (rendering *specific apps* on the nvidia card while using the Intel for everything else).
Personally, since I only need the performance of the nvidia card one in a blue moon, the bumblebee approach is much more useful to me. Otherwise, I'd have to deal with tearing on everything (the current version of the nvidia RandR output provider does not support vsync) and increased power consumption.
I think what nvidia calls "render offload" in their README (which is currently not supported) is what would in fact replace bumblebee, if/when implemented. I'm curious as to how it would interact with power management, though. One of the very nice things about Bumblebee is that it doesn't even power up the nvidia card (via ACPI) until required, and that's easy because it starts up a background X server on demand to do the rendering. It's probably trickier to puil this off if you have to load the nvidia driver into your primary X server to take advantage of the direct integration.
The active noise cancellation indeed only works for low frequencies, but noise-cancelling headphones muffle higher frequency noise by design too. I find them quite acceptable in very noisy environments, and I suspect they will work well anywhere where there's a wall between you and the noisy human anyway. If you must, feed them white noise to drown out what remains.
Clicking a link to a page containing a textbox containing File:/// will. So this is also a remote DoS for Safari.
First of all, you mention the TCP/IP checkum, at the same time as key exchanges, long PSKs, and money transfer. Which is it, simple message integrity or message authentication? If you need authentication, you shouldn't even be mentioning TCP/IP checksums. If all you need is integrity, then just append an MD5.
Assuming you need authentication: I don't have any opinion on Blake2, but you should use an HMAC instead of just appending the shared secret key and taking the hash. HMAC can be built on top of any hash function, including Blake2. You should also make your MACs at leasts 128 bits long, preferably 192 or 256. 64 bits is definitely bruteforceable these days. I wouldn't settle for anything shorter than 256 for a protocol that involves money.
Keep in mind that a basic message authentication code is only one piece of a secure protocol. There are many possible attacks that might slip through (e.g. replay attacks, MITM, timing attacks, ...). For example, you need to ensure that an attacker can neither reinject a message from the current session back into it (e.g. by using a sequence number in the signed payload) nor reinject a message from a different session (e.g. by ensuring that there is a random component to the shared secret) nor somehow guess the right MAC code (e.g. by making sure that the wrong-MAC responses do not leak any information, neither in contents nor timing), and of course there's always the host identification problem (preventing a simple MITM where the attacker performs a key exchange with both sides and resigns/reencrypts traffic both ways). Honestly, your first choice should be to use an existing well-tested protocol, such as TLS (you can build your own host verification rules on top of it, you don't have to use the "well-known" root CA list). Failing that, consult a real crypto expert.