duckintheface didn't say it wasn't being used in court.

the statement was that it can't [LEGALLY] be used in court.

Dude. Some shit ain't going to get upgraded no matter how many times you taze that dead horse.

Hell, I've still got SunOS 4.0 in production.

The entry for "Alpha Particles" was updated from "Harmless." to "Mostly Harmless." quite some time ago. Because it is... AS LONG AS the emitter is *OUTSIDE* the body.

An alpha particle is going to steal electrons from the first molecule it comes in contact with, and become a helium atom. If you're exposed to alpha radiation from the outside, it's going to hit and react with the layer of already dead skin cells called the epidermis.

So yes, as long as you don't swallow, inhale, inject, or otherwise insert the alpha-emitting radioisotope, you're probably going to be just fine.

The fact that Google Play is run by an American company is not the issue.

Whether or not your app is available to be downloaded in the US is. Because you're importing your app into the US to be used by Americans.

But that's a side issue. EVEN BY AUSTRALIA'S STANDARDS your app likely qualifies as a medical device. If you're not already registered with the Ministry of Health as a medical device manufacturer, I would highly recommend contacting someone to confirm with them whether your app should be regulated under Australian law, and whether you're breaking the law by distributing it (or allowing it to be distributed) in Australia without registration.

And then do the same thing with every other country your app is downloadable in. Because every country's regulations may be somewhat different.

DISCLAIMER: I am, (among other hats) a software developer for a medical device manufacturer in the United States.

Seriously, people. The FDA's stance has *ALWAYS* been that if something has a medical purpose or is an accessory to a medical device, then it *IS* a medical device, even with software. See: Guidance for the Content of Premarket Submissions for Software Contained in Medical Devices, dated 2005.

For the purposes of this document, we refer to devices that contain one or more software components, parts, or accessories, or are composed solely of software as “software devices,” including:

• firmware and other means for software-based control of medical devices
• stand-alone software applications
• software intended for installation in general-purpose computers
• dedicated hardware/software medical devices.
• accessories to medical devices when those accessories contain or are composed of software.

This guidance applies to software devices regardless of the means by which the software is delivered to the end user, whether factory-installed, installed by a third-party vendor, or field-installed or -upgraded.

So, yes, apps with a medical purpose are medical devices, just like any other piece of software.

Which means they *ARE* subject to the "Obamacare Tax" -- Which is *NOT* a "sales tax" to be paid by the consumer. It's an "income tax" to be paid by the manufacturer / developer.

This also means that if your app is categorized as a medical device, you (the developer) have to register with the FDA as a device manufacturer, which costs a couple thousand dollars a year, and means that every few years, the FDA sends someone out to review your quality control system, which includes your testing methodologies, what complaints you've received and how you've handled them, how you document your development process, etc.

AND what your software does determines what kind of medical device the FDA calls it. And the kind of medical device determines whether you are required to get the FDA's permission before you distribute it. (even if you distribute it for free) And yes, applying for that permission costs money, whether it's approved or not.

And, by the way: Each country makes its own rules about what makes a medical device and what you're required to do to be able to legally distribute it in that country. And in most countries that includes software.

I can see the argument that if you're limited in any way as to what you can do with your connection then it's not strictly neutral. I disagree with it completely, especially if the connection was sold under a "residential, not publicly accessible" contract. If this were about what content I could access via that connection, or how traffic from different providers / protocols is prioritized, THAT would be a neutrality issue.

If your connection is behind a NAT (carrier grade or otherwise) where you're sharing an IP with multiple other users, that's going to prevent you from being able to run a server that can accept connections from the outside world. -- unless your ISP adds rules to their router to ensure that certain ports on your connection are always available to the outside world. And if you want access to the standard ports (80, 53, 443, 25, 22, etc) they have to ensure that "your IP" is unique, at least among the subset of customers that want that ability.

Carrier grade NAT is only necessary because of widespread refusal (including among carriers) to adopt IPv6. But even without NAT, I still wouldn't have a problem with the ISP saying you can't run a server on a residential connection. Because IP space isn't the only limited resource in play.

Actually, the guy DIDN'T go to the police on his own. The police came to his house and started asking him questions, then they brought him to the station.

The differences between what happened and "an arrest" are that he was not mirandized and (presumably) was not handcuffed. It's still possible that the officers led him to believe he didn't have much choice in the matter.

Actually, I think it is YOU who are missing the point. Because if an Arduino will satisfy your needs, then by god, use the Arduino! If your project's small enough that a $30 Arduino UNO will be ample for what you want it to do, you'd be downright silly to build your project around one of these, instead.

But you're falling into the same trap that a lot of other people are -- thinking that all embedded systems have the same needs. Not all embedded systems need to be low-power, battery operated, or have no need for a display or a disk controller. Some robots need a lot more processing power than you can cram in an 8-bit micro, especially if you're dabbling in machine vision and autonomous systems. A document scanner (not to be confused with a document camera), laser printer, blu-ray player, and an XBOX 360 are all examples of "embedded systems", too.

The above list showcases another misconception about embedded systems: Not all embedded systems can stand alone. Sure, you could probably build a scanner around an Arduino -- I've certainly had scanners in the last 30 years that were built around much less capable microcontrollers -- but you'd need an external computer to drive the thing and to stitch the images coming off the sensor together into one single page and save that as whatever document format you want. If you just want to connect it to your desktop computer or you've already got a spare PC that you want to dedicate to controlling your project, that's fine. But you can save a lot of space and power if everything were able to be integrated into a single system.

I'm not trying to say that you should go out and buy a stack of these and use 'em everywhere you'd use an Arduino. That wouldn't make any sense. It's entirely possible that you, personally, are never going to contemplate a project that would ever need more than an Arduino UNO, or maybe you'll eventually upgrade to a DUE. And that's okay. Really, it is. But just because YOU don't have a need for something like this, doesn't change the fact that some of the rest of us might.

The $110 UDOO Dual core is most comparable to : RPi x 2 + Arduino DUE = $130 (using your numbers)

The $130 UDOO Quad core is most comparable to : RPi x 4 + Arduino DUE = $210

So yes, if you're just going to compare one embedded board to another, without taking into account their relative capabilities, the UDOO is more expensive. If instead, you compared the boards based on BOTH cost AND capabilities, things look very different.

Sure, for some things an Arduino mini is going to be plenty. But some projects make more sense with a multicore system processor and an I/O subprocessor.