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.

For an AC that clearly knows NOTHING about our particular system (nor the Raspberry Pi in general, it seems), you're making some pretty ludicrous accusations.

Of course I've built in redundancy, fail-safes, watchdogs (hardware and software), etc., to ensure things are exceedingly safe and reliable. I'd be more worried drinking beer at any brewery that DOESN'T have our system... they couldn't tell you what's happened to their beer whatsoever over the 2-3 weeks it ferments, other than maybe what a little red LED said the temp was once or twice a day when they happened to look, if you're lucky. I can tell you the (calibrated and redundant) temperature for every minute it was in the tank, and send you alerts the moment anything goes out of spec.

We also work VERY closely with the USDA and have achieved some of the highest certifications for food safety possible - being the first in this state for several types of certification at ALL.

So, before you spout off paranoia and technical ineptitude, do your research. I'm not some closet hack, this is a properly engineered and supported industrial platform... yes, running around a Raspberry Pi. It's a LOT more than just the Pi though, which is lost on you.

MTBF so far on them has been on the order of >50 years... depending on how you calculate that (based on a sample of >400). The only failures I've had have been attributable to physical or electrical damage from external sources. They're easy to swap out, and our systems have all kinds of reporting and alerting - the software is all cloud based, and if a system doesn't report in I know about it within 30 minutes.

They also self monitor... the one indicator I have of a Pi thats going to fail is CPU temperature. I find if a GPIO is shorted out, the CPU will start climbing in temp - possibly over days or weeks - before it freezes. Anything over 65C is enough for me to proactively address the situation.