morrad

> This includes the thing boxers put in their mouth to protect their teeth

FYI, the English word is "Mouthguard"

https://en.wikipedia.org/wiki/Mouthguard

The first radiation exposure related death was reported a few weeks ago from one of the plant's workers.

https://www.bbc.co.uk/news/world-asia-45423575

Still, your point that nuclear is significantly safer from a community health perspective is correct.

Interestingly, according to that link Mr./Mrs. Firstname Lastname left them a reply indicating his or her support for strong net neutrality. :)

> First, 10^11 P/E cycle and "practically infinite" aren't really two concepts I would associate with each other when discussing RAM.

I think their point of comparison for this statistic is NAND flash. 10^11 is much better than current NAND P/E cycles ( < 10^9 I believe).

Would it be possible to use this to identify people running Tor relays?

As someone who regularly writes RTL for FPGAs during their day job, I like the idea, but am skeptical about the follow through.

For years now, various companies have tried to make cross compilers to be able to synthesize C style code into RTL. The name for this basic idea is "High Level Synthesis" (HLS). For applications like digital signal processing, HSL is actually decent. Having a stream of data moving through some transform is easy to express in C (and OpenCL), and easy to translate into a relatively efficient data pipeline in RTL when compared with making one "by hand". But this isn't the only thing that is going on within the FPGA. It is clunky and inefficient to create state machines or controllers, interact with inbuilt memory blocks, or interface with other modules not built in the HLS language.

Since inefficiencies cost resources, you end up trading your decreased development time through using HLS for possibly increased device costs, and some ambiguity in terms of the architecture of the hardware your synthesize. Since these tools haven't been broadly embraced by the FPGA coding community, the support for them doesn't tend to last long either.

The shepherd of Jekyll [1] is also one of the lead developers of Octopress.

[1]: https://github.com/parkr

Thanks for the correction. I'm on the hardware side of things, so my understanding was that the "allowed" algorithms were actually required, and I'm relieved to hear that's not the case.

Good luck convincing your competitors to not take the business you're leaving on the table with that. :(

My understanding is the FIPS requires that the SSL library implements a certain suite of protocols (including the Dual EC DRBG discussed in the linked mailing list post) which have known cryptographic weaknesses.

I have TWC and have had a lot of success in speeding up Youtube by blocking access to the caching servers that TWC uses.

If I block 206.111.0.0/16, I can stream at full speed.

See: http://www.reddit.com/r/technology/comments/13kmvd/have_time...

> it has an incredibly sophisticated and powerful content-matching engine that does monitor what's being uploaded, and automatically checks new videos against a giant corpus of known copyrighted works

This is above and beyond the requirements of the DMCA though. Doing this isn't what makes Youtube legal, it just attempts to appease copyright holders.

> automation is intended to eliminate [jobs]

Automation has the potential to eliminate jobs, but also has the potential to allow much more work to be done by a single person, or allowing that person to do the same work with less effort.

Perhaps I'm overly simplifying your words, but I don't think automation is inherently "evil". Like all tools or techniques, they may be used toward good or bad ends.

There are better (less expensive) ways to build credit than car loans.

While I don't remember the name, my wife and I built credit getting some sort of secured loan from our local credit union. The process was something along the lines of making an account with them, putting $X into the account, and then getting a 6 or 12 month loan from them for the same $X dollars at a really low interest rate. Overall I think we paid $30 to $50 dollars over that period in interest.

Tiberius.

https://en.wikipedia.org/wiki/James_T._Kirk

Seeing as this is the military, I would guess that they have triple redundant systems for some things, but that still is a decent amount of computing power there.

I'm late to this discussion, but as a "real pro" VHDL coder, I can at least sate your curiosity.

At my company, we abstract the vendor specific implementations to have a common interface that we can then use to keep the rest of our code vendor neutral.

For example, within the "Dual Port RAM" section of our revision control system, we have separate files that instanciate memory control blocks for Xilinx Spartan and Altera's Cyclone FPGAs, and generalize the interfaces so that all I see when creating a design is a vendor agnostic "dpram" component interface. When I need to use one in our design, I just need to import the correct file into my build corresponding to the actual FPGA that will be used. Migrating to another vendor involves changing which file gets during synthesis.

Cheers.