rdw

The biggest turnoff to me is the sheer quantity of code (regardless of the fact that it can all be crammed into a single header file). It seems much more difficult to fix a bug in it than in something like UnitTest++.

That said, inline setup/teardown and parsing expressions in asserts seem like such natural ideas, I can't believe I haven't run across frameworks doing them before. I guess the shadow of JUnit is extremely long.

This looks hella good, I particularly am intrigued by the nested setup/teardown system. The natural assert syntax is interesting, too, amazing what macros can accomplish.

Appropriately, the first question that came to mind was, "what's the catch?" :)

This is the basis of the Voxel Farm engine, which Miguel talks about in this early blog post: http://procworld.blogspot.com/2010/11/opencl-first-iteration...

Posing him as an opposition to Snowden is not right, because Tye was only able to blow the whistle himself because of Snowden's leaks. "Tye said he never would have even learned about 12333 and NSA capabilities short of Snowden’s own actions." He's a part of a new generation of whistleblowers and leakers, none of which could have done what they do without Snowden. Not to overly lionize Snowden, but it just goes to show that once the dam develops a crack, it's not long before it's gushing.

Won't take off in the marketplace? Seems plausible. Doesn't produce novel experiences? Already false but maybe this can be spun convincingly. But the technology can't possibly work? That just seems silly.

Thanks for the gracious reply! I'm sure that you and everyone working with you at Joyent is a fantastic individual.

And yeah, just illustrating how even the best-laid plans of the best of us can't always work out great for all customers.

Really appreciate the open source software, but I recently had some trust issues with Joyent the service. Cloud servers switched from tiered transfer rates (with a generous free tier) to on-demand pricing, with only a month of notice. It wasn't possible to monitor one's own bandwidth usage before the switch, so we were caught off guard by our bill jumping by nearly 30%. It would have been more trustworthy to grandfather in servers started under the old pricing plan.

I think that there wasn't as much demand for batteries in the past as there has been this decade. Think of all the things that need batteries now that didn't exist in quite as large numbers 10 years ago. Laptops, phones, tablets, household devices, cars, power utility energy balancing, UPSes, personal sensors. Usage of these things in a battery-powered context has grown by several orders of magnitude, a really truly huge amount, and that level of demand is driving battery research forward. There also seems to be a shift from disposable to rechargeable.

It's also the other way around, too, of course. I would have thought it ludicrous in the 90s to have my primary vacuum cleaner be battery powered. But this year, I didn't even think twice about it.

Doesn't this defeat one of the purposes of Javascript CDNs, that the user already has the exact url cached on their machine?

I realized recently that the reason that there is no way of mocking C is because of a weakness in the language implementation/design. In Python, it's easy to mock and unit test globals, because in the test you can just overwrite them in the test's setup, and restore them in the test's teardown.

You could argue that it's a static vs dynamic typing thing, and I don't know enough to really dispute that, but it seems to me that there's no inherent reason that a static type system can't handle using a different concrete implementation. I think you can do this with Java/C# by doing some library loading trickery, but it'd be inconvenient.

And that's the whole point of all this, isn't it? Automated testing is a convenience that saves you from doing manual testing. Unit testing is a convenience that catches test failures before commit rather than during the automated testing phase. Creating the unit test, well, is it more convenient to create 8 interfaces and completely change the way the code is structured, or is it more convenient to mock out the singleton? It depends on the circumstance, I've done both in various languages. It's good to have the option.

Whether or not it can buy happiness, money can buy adulation.

Hah, I guess I bought into their marketing, then!

That is an excellent explanation! What it suggests to me is that the problem with patent trolls is perhaps not so much with the patent system itself but with the specific mechanisms through which patent lawsuits proceed.

Kind of like how software security most often fails in the implementation rather than the theory. :)

Intellectual Ventures actually does create the patents. We think they're for obvious, trivial ideas, but they definitely create them. (I guess they don't actually sue other companies directly, either.)

My understanding was that it's likely that some of the people who work at Rockstar are the inventors of some of the held patents. Maybe not the key patents, but it's a company holding a lot of patents and employing a bunch of engineers, there's almost certainly some overlap.

I agree that the transfer of ownership of patents is a potential aspect of a dividing line, that seems to be a common theme. But it seems like it wouldn't be too difficult for a patent troll to skirt this by "employing" an inventor, or somehow wedging the name of one of their employees into the inventors list for every patent.

What's interesting to me about this story in light of current events is that Johnson Research and Development Co., seems in many ways like an NPE. He doesn't make products directly, he simply licenses the patents to other companies that do make the products, and sometimes sues them.

Obviously, he's not a patent troll, but what's the bright line between what he does and what a patent troll does? This is a critical question in the patent troll discussion, because it is absolutely the case that every Intellectual Ventures, Lodsys, and Rockstar thinks of themselves as being innovative inventors like Lonnie Johnson. They'll hold independent inventors like him up whenever legislation is proposed and say that it'll hurt good old-fashioned American invention, and maybe they'll even be right.

It's critical that there be a clear division there, or else reform will never go through, or worse, end up hurting actual inventors. How can that line be drawn?

Ah, my brain was somehow not seeing that in the article, but I see it now that I'm looking for it. Thanks!

"you can't have more than 64,000 objects in a folder in S3 - even though S3 doesn't have folders." Is this for real, or are these stories made up? All documentation I've read about S3 suggests that it does not have any file count limitations. The timeline of Togetherville suggests that this story took place between 2008 and 2010. Did S3 have a limit back then that they lifted?

Also of note: there is the Nordic Game Program, which encourages the development of original game projects. http://www.nordicgameprogram.org/?id=23 (for all Nordic countries, not just Sweden)

How can you not be calling them "whackages"? You're sitting on a gold mine!

It's either reflected or turned into heat within the panel.

I really appreciate they have a "reproduce the results" section. We need a lot more of that kind of thing in CS research.

That's a clever idea, but I think that most users would be disconcerted by the sheer amount of information that's collected by most web sites already. It would raise the question, "why do you need to collect all that?" before anything else. Which is a good question to be sure, but probably not the one that most companies want to be answering.

Interesting, that surprises me as well. Thanks for sharing!

How would you compare this to LiveLoop?(http://www.getliveloop.com/) It looks like a very similar approach, is it just sans the real-time aspect?

(I know the LiveLoop folks, so this caught my eye.)

Thanks for the supplementary links, they really clarify things for me. I think the key high-level decision they made is to ignore per-transaction latency in pursuit of higher throughput. A consequence of that decision is that the application logic of the transaction must be executed by the coordinator.

A while back coworkers and I developed a system that made similar tradeoffs, and was capable of linear throughput scaling as well, but never made it into production for various reasons. The per-transaction latencies were in practice "good enough", though they theoretically could grow quite large. The necessity of combining the application logic with the transaction coordinator was a lot more difficult in practice than I'd expected, especially since we required completely lock-free logic. It turned out to be a real brainteaser for some applications. It's going to be much easier to write logic for Calvin, because locks are somewhat more intuitive and map more closely to existing systems.

Great news for the folks working at Makani! I hope Google continues to develop the product. Every time I've spoken to anyone at Makani, about tether materials, motor design, carbon fiber manufacturing, whatever, they've known their shit very deeply. They've really beaten a path through a lot of untrodden ground to get to where they are, I hope the product gets off the ground (literally!)

asm.js is translated into native code before it's run, which is exactly the same as PNaCL, which is delivered in a non-executable format that has to be translated to the native architecture before it's run. The two technologies are just different standards for the exact same underlying idea.

Fantastic. It's amazing how attached I become to the good ones, it's like I've discovered a precious truth.

So here's some driving rain: http://wry.me/hacking/Turing-Drawings/#4,3,1,2,2,0,2,0,3,1,2...

The reason that this is so is because of regulations.

Double Fine has their own engine, they don't use Unreal.