Maybe a crypto person would know more, but couldn't some DAO be incentivized to verify the authenticity of current known historical documents/images and create a block chain of agreed upon authentic historical imagery? The longer it takes for us to do that, maybe the more likely falsifications can slip in, but I have a feeling that the real world nature of many history books and libraries means we can have a pretty strong head start.
As a crypto person, I don't think a DAO would really add anything here. Individuals or traditional organization "signing" their endorsements of contents authenticity will become a bigger thing in the future. It's not that different from SSL. When you access a website using modern cryptography the content is effectively endorsed by that organization as authentic.
you still have the issue of "junk in, junk out". Being on a block chain does absolutely nothing to ensure that the information on the chain is correct. There isn't really any reason to use a DAO for this vs a standard database.
The corporation would actualize the income as profit at some <=1Yr period, where it would be subject to corporate tax. Not saying your idea wouldn't work out best tax-wise, but that you'd still need to run the numbers. I'm pretty amateur at accounting, so I don't know.
I do get a kick out of the idea that these guys basically revolve a lot of their life around developing DF. I wonder how much of their lifestyle could be legitimately expensed from a corporate account without any IRS hassle.
I'm skeptical. I don't know the exact breakpoint, but pushing enough power through the small (and very dense) circuits of a processor can't go beyond a certain level based on our current CPU cooling technology. The heat at that density just becomes too high and too localized.
Liquid nitrogen or helium. But if someone went to the trouble to use these substances, they'd likely show it in action instead of some computer screen.
Late reply, I know :( - Actually, it's not even the cooling outside the CPU that's the real problem, it's moving heat away at a microscopic level near each transistor. With enough power going through enough circuits nearby, the material the CPU is made out of becomes the issue.
Consider a block of metal submerged in a (hypothetical) liquid at near 0 degrees K. Despite how much heat this liquid can draw out of the block, if heat is being generated too quickly at the very center of the block, it's possible that the heat conductivity of the metal block itself limits the efficacy of outside cooling, resulting in an "overheating" center.
The asynchronous aspect of this is a big deal. It makes life both easier (because components can continue to run without blocking on data) but introduces complexity (sometimes you /need/ to synchronize). I've recently been working on a research project where this difference became very apparent. If you're working with wall-clock time (and especially any deadlines) the synchronization between different processes can subject you to needing a real-time operating system. At the very least (without deadlines) you're going to be doing some semaphore coding which can be difficult to scale.
On a related note: I look forward to the new Intel Haswell architecture. Built in HW Transactional Memory!!! Hurray!
>It's also really fun to write complex networking apps from scratch
I agree and disagree. It definitely is fun to write awesome complex code, in general, but I'm currently in the middle of developing a network application and the most frustrating part was the socket handling. Everything riding on top of these connections was fun, but actually working out the TCP logic was un-fun.
That said, diff'rent strokes for diff'rent folks, I'm sure you're not the only one to love TCP coding, and I'm glad you guys exist to write tutorials for people like me :)
I write modules to decode network protocols for fun. So yeah, maybe i'm not quite right in the head.
On the other hand, it taught me about perverted networking standards like 802.1Q which is more common than you'd expect, and helps when you're trying to figure out why tcpdump isn't returning results you expected.
