Yeah it's an interesting question. Reading through their twitter etc. they claim they did actually transmit all keys for decoding their transmissions, and the transaction was "demonstration" and "experimental" rather than an actual commercial transaction (whatever that means). So I suppose they are attempting to follow the *spirit* of the laws as best they can while still conducting the proof-of-concept experiment. Whether the folks at ISEC and FCC would agree or not is another question, but I doubt anyone will even notice.

Really the only thing that makes this at all questionable is the fact that they're sending bitcoin, which nominally has some value. If they're transmitting the encryption keys and the protocol is also not secret, they're likely in the clear on the "codes" part of it.

Anyway I think it's a worthwhile experiment, and seems to be exactly the sort of thing the amateur bands should be used for, bitcoin transaction notwithstanding. Now.... should this actually become an actual transaction system, it would obviously have to move off to some other non-amateur band.

Also, to address the license/patent issues, Dart is provided under a BSD-like license and includes a patent grant.

Dart was submitted for ECMA standardization early this year and is now ECMA-408.
[Disclaimer: I work on the Dart team]

To allow for the widest possible cross-browser app compatibility today. Dart currently support all modern browsers (back to IE9) - forcing users to use Chrome would divide the web, which is the last thing we want to do. That said, we're working on getting the VM into Chrome, but really that comes down to an added performance boost. We expect most developers will target JS to ensure cross-browser compatibility. It's entirely possible (encouraged, even) to deploy both.

The good news is that you can write and debug purely in Dart and test in Dartium (Chromium + DartVM) with no compile step today. The dart2js step is a deployment step. Obviously, you'd want to do the usual testing of the final compiled output in a few browsers just like you'd do with a JS app today, but for development you can live entirely in Dart.

There's really no possible satisfying answer to that question without knowing the reasons for the hypothetical future loss of interest/support on Google's part. One could ask similar questions about any language with equally unsatisfying answers.

The project is open source and headed for ECMA standardization - both of those are both very positive from the point of view of future continuity. The best anyone can answer is that if such a situation ever should come to pass, the project is in the best possible position to have the community/someone else pick up the torch. If that's not satisfying enough, then waiting and watching is perhaps the best strategy.

It's started the process of ECMA standardization.

Dart team member here. The Dart project, like Chromium, is being run as a fully open source project accepting patches from Googlers and non-Googlers alike. We've also begun the ECMA Standardization process, meaning that like JavaScript we'll have a open standard that anyone can implement to. In terms of Dart users, here's a list of some. Hope that answers your questions!

Y'all are missing out on a good time.

I have a gmail account with the first name dot last name set up. As you can imagine I get quite a few messages for people who forget to tell their friends about their middle initial. However from context, I can often tell which of my name-sharing buddies the email was intended for. Over the years I have actually gotten to know a couple of them, which is fun.

I don't bother trying to tell the senders about the mistakes, they usually do nothing, oddly. The recipient, however, tends to get on it effectively.

It's quite interesting do talk to them. What's in a name?

Actually, I'll take that back about the emphasis bit. Boswell pretty well nails it right on the head. Now I'm looking through some of his other articles, and they're excellent.

Well, ok. Though there's not much more that I could have written in that short of a space that can teach the subject.

I linked the Calgary Herald / Postmedia News article because it's an astonishingly well-written bit of science journalism that lays it all out superbly – kudos to Randy Boswell. He didn't put *exactly* the same emphasis on exactly the same things that Proemse (the principal author) would have, but it's minor. That's the "public" piece, and it's full of tons of great information.

I also linked the official research article. Unfortunately it's behind a paywall. However, if that's the kind of thing that really turns your crank you probably already have access to it one way or another (in the worst case: via a physical trip to your local university). If you can't, well, correspondence with an author is a time-honored method for obtaining your own copy.

Nah, he's not wrong. But neither are you.

Seismic processing is about as embarrassingly parallel as it comes. Just about every processing step can be split up into e.g. single shot record steps, taking advantage of assumed linearity in wave equations. Furthermore, most production industrial imaging codes weren't actually using my original example of a full finite difference solution until quite recently, and instead they were using algorithms that have been developed for decades under the limitations of very old computers. Sure, some of the big shops have full blown "proper" HPC, shared-ram setups, etc. However, it's common to see much more simplistic parallelization with very ad-hoc clusters being used.

In short, there are loads of processing shops that run off-the-shelf servers on gigabit ethernet, and they do a good business with it. Heck, there are loads of processing shops out there that do a good business running relatively crude time migrations.

Seismic imaging. Imagine solving a wave equation (acoustic, elastic, or worse) over a 3D grid many kilometers on a side with grid spacing on the order of meters. Imagine you're doing it with a strong high-order finite-difference code. Calculate for tens of thousands of timesteps. Now repeat that entire thing thousands of times for a given full survey.

No matter how much computer you have, it's never nearly enough for seismic imaging.

No, the public won't see these results as a rule, at least not right away (while it's still commercially valuable to protect as a secret), though strictly speaking it depends on the countries involved. Nor would it matter for property value, as the "land owners" usually don't own the mineral rights in most places. Furthermore, this setup will be used probably mostly for marine/offshore seismic imaging, ie not much land involved.

The fact that Facebook and Apple are Google's competitors in certain markets -- namely advertising and mobile eco-system -- doesn't diminish his point that a walled-garden, unsearchable web (Facebook) is a poor substitute for what we had 10 years ago, and that a walled-garden mobile eco-system that ties you to a single hardware vendor (Apple) is similarly no good. Google+ posts are searchable on Bing or any other search engine and if you don't link your Samsung Galaxy SII, you can replace it with an HTC Rezound or a Motorola Razr Maxx without losing your apps or data.

You haven't addressed the points he makes about Facebook and Apple, nor his concern about governments imposing restrictions on use of the internet and surveillance legislation that affects internet users' privacy. Stating that Facebook and Apple are competitors isn't insightful - it's obvious, and it doesn't invalidate his argument.