space-based would be closer to 24/7 sunlight (depending on orbit), would suffer less from atmospheric absorption (presumably, the light would always be coming directly "down" on the target receiver - not obliquely through the atmosphere), etc.

At least in the article it says you can disable it (which I'd do in a nanosecond), but if not I'd return my product as defective and force the issue.

But - I won't buy a smart TV in the first place. I have streaming devices that do what I want it to do, and they're way better than built-in crap in TV's. However, I'm not sure how long the option of "dumb" TV's will last... especially if they see more opportunity in advertising than just sales.

We are the product, not the consumer. :(

yep - as a "public shaming" deterrent from viewing that content... i.e. censorship.

Sites that sell/promote alcohol just have a "are you over 21?" checkbox... why is that sufficient for alcohol and not porn? It's an attempt at censorship, cloaked in "think of the children".

But this is hardly ground-breaking work... I've been doing this commercially with the RPi for over 7 years. Anecdotally, based on almost a thousand systems, the MTBF I've seen is over 73 YEARS for the RPi, and even then most of the failures were due to external factors like shorts and lightning strikes, etc. It's a solid system, and rock solid. Having a full Linux stack to work with is nice too - there's nothing we haven't been able to do.

Funny... embedded systems is my area too, and I'm the OP on this thread. Hammer vs. screwdriver... know when to use which, but have both in your tool belt.

And if you knew anything about Python, you'd know that for use cases where speed is the primary factor, you can stub out to C and back. That's exactly how some of the more powerful libraries run - I've done a lot of code for the Python Imaging Library for example where that's done, including true multi-threading support.

So - bash all you want, it just shows you don't know when to use a hammer versus a screwdriver.

Interesting... care to share your data to support that opinion?

Actually I am using SD. However, the software stack ensures that anything that's being read/written often is done on a Ramdisk instead, and only written to disk when necessary. We haven't had a single SD card failure yet... in ~4 years of systems being out there (oldest ones still running fine).

Well, either that's poorly written software, or a poorly configured environment for what you're trying to do. Python is solid... but any language can look "bad" if you're using it wrong.

Pi's are a lot more reliable than you may think...

I have about 600 currently running in the field (for the last ~3 years), and the failure/lockup rate is about 1 system every 3-4 months. That's an MTBF (calculated, of course) of about 200 years. Of course that won't hold up over time, but it's impressive.

Basically all of the failures I've had are attributable to external events - either electrical storms/surges, or people physically shorting out GPIO pins when installing things or doing other service work.

I've designed hardware-based watchdog systems into my future control board that these plug into, but based on the data they're not really needed. But, the extra security is always a good thing.

Well, the paranoid part of me says that if the XML response of Rick could be a configuration setting. "Rick" results in just the application information being sent to analytics, but maybe "Bob" results in more nefarious info being collected. It's an unknown, and unacceptable for a company to be collecting data like this. It's done all the time, but that doesn't make it right!

www.boxcarcentral.com - look me up

It pays to be paranoid. :)

The systems we run don't need real-time timing... I get latency under 0.02 seconds worst case (from analysis) which is orders of magnitude more than required for these applications.

The GPIO shorting issue is a real hardware issue - they should be opto-isolated on the Pi board itself, however we take care of most of that in our board where the Pi plugs into it (the Pi is almost a "hat" for our system, in the end). Most of the times we've had that as a problem it was due to simple human carelessness when installing, or when attaching sensors/etc.

My biggest issue is actually with the USB bus on the Pi. There's an extreme edge case where if I'm using a GPIO pin at the exact same time as certain things happen on the USB bus, the system will freeze. It's worst when I'm bit-banging the GPIO's to do serial on pins other than the built-in UARTS. We tend to avoid using USB devices due to this, and I've implemented a hardware-based watchdog into our board to reset the pi if this ever happens. On 400+ systems in the field, it may happen once every three months or so... so it's rare, but significant when it happens.