What's "purely digital" about a LCD? For a start, there's nothing in this article talking about VGA. I'm talking about DisplayPort (as is the linked article) which has a signal path from the GPU to the monitor (and if you want to be pedantic about it, the DisplayPort interface on the rear of the monitor) that is purely digital. However, if you really want to take it to it's illogical extreme, even the digital signalling used by DisplayPort is, at it's heart, analogue voltages travelling down a bunch of copper wires.

Either way, the signal path, the communications channel, that still has things like a vertical blanking interval and runs between the GPU and the electronics in the monitor is purely digital.

Yeah, I always found it strange that even a purely digital flat panel monitor still "emulates" a vertical refresh interval signal...

I haven't RTFA, but from what I understand of it, it's not syncing the output from the graphics card to the vertical blanking interval on the monitor, it's the other way around. It's running the monitor at a variable frame rate so that if you're running at (say) 60Hz refresh and the next frame takes 1/60th second + a tiny bit, the monitor can hold off painting the new frame until the data is there to paint it, rather than waiting for 2/60th second before displaying an updated frame. Or, if the next frame is ready early, and the monitor can do so, it can paint the new frame early - so the monitor isn't running at 60Hz, it's running in sync with the output of the graphics card.

For some reason I can't get to that page (DDOS'd? Taken offline?)

Here's the results on their blog:
http://blog.cloudflare.com/the...

Private key grabbed. Game over.
One successful attempt took >2.5M requests over a day. Second successful attempt was something like 100k requests.

http://blog.cloudflare.com/the...

It's all in the luck of the draw. When you don't have any logging of this, you've got no idea how long people have been poking at this and literally no idea what anyone has made off with.

Yes, I thought that was the case, but I still got all sorts of junk subdomains registered... Maybe there was a problem with the way my domains were registered, I don't know. Either way, I moved them away...

Yep, I found that too. I had a privately registered domain with afraid.org that still allowed other people to create their own hostnames in that domain. These hostnames were then used to spread malware with the result that I was receiving notices from Google saying my web site was compromised.

I had, say, www.example.com and then others were making asd34ghjb5fbs.example.com and using that to spread malware. Google saw that I owned example.com and so I received the notifications. I'd log into afraid.org and shut down all the hostnames that I didn't create, but they kept getting made even though I had private registration on my domain name.

I've had problems with afraid.org where a privately registered domain I held allowed other people to create their own hostnames in that domain. These hostnames were then used to spread malware with the result that I was receiving notices from Google saying my web site was compromised.

I had, say, www.example.com and then others were making asd34ghjb5fbs.example.com and using that to spread malware. Google saw that I owned example.com and so I received the notifications. I'd log into afraid.org and shut down all the hostnames that I didn't create, but they kept getting made even though I had private registration on my domain name.

No, of course not. Old, known-bad versions of TOR that have numerous exploits active in the wild are removed. Not Chrome browser as it's not malicious software.

To quote another poster a few threads down

On any Mac in your office, running 10.8 (Mountain Lion) or 10.9 (Mavericks) purchase (for $20 or so), download and install the OS X Server app.
Turn on the Caching service. Problem solved for Apple devices.

The server then registers itself with Apple, they see the registration coming from your IP, so when further devices from that IP address request a software update, these machines are pointed to your internal Caching server. Then, when a device (or a Mac) tries to download an update or purchase something from the App store, it will come from the persistent cache in preference to the WAN.

And how should it be decrypted?

This is a huge part of the problem. Just about all security researchers (white or black hat) will have an account with Adobe - even if it's using a throwaway email address. They know what the email address is, they know what their password is, so can begin to mount a known-plaintext attack against the data in the database.

Unless Adobe are using a different encryption key for every password in the database (unlikely as if they were this careful, they'd not encrypt them and instead hash and salt them) then discovering the key for one password will reveal the rest.

You are probably either the victim of a malware infection, or you're torrenting too much. If a machine on your network has been properly pwned (and this is a lot more likely than you being the target of a DDOS) then running AV on top of the OS most likely won't find the malware...
Download and burn the Kaspersky Rescue CD, boot off that (a known-good OS) and scan your machines. Report back how much malware it found that everything else missed.
If you're participating in a DDOS (or otherwise maxing out your upstream bandwidth - eg torrents) then uploading at the maximum throughput will have the side effect of dropping your download speed to the same as your upload speed.

There's one area where renewables can win out, and the space they take up doesn't make any difference.
If a law were to be passed where every new house had to have, say, a 5kW photovoltaic system on the roof, it would take up zero additional space, would be cheaper to implement at the design stage of a new house and all new houses would be largely self-sufficient for power, with the ability to feed extra power into the grid.
As a bonus, on those really hot (and, coincidentally, sunny) days where everyone has their AC on, they are the kinds of days where a distributed power generation system like this will easily be able to cope with the additional load.

Whilst the execution engine in an x86 chip may be RISC (or RISC-like) code running on the chip is well and truly CISC - programs running on x86 have no access to the low-level RISC features.