Actually, the cheaper Olimex A20 boards are cheaper than a RPi and superior in basically every aspect. Go figure.

Oh, because it is low cost, and targeted at kids, that makes regarding the customers as stupid o.k. in your book?

Well, first I have not found any "large parts they leave out" so far, and second, the RPi datasheet "excerpts" are missing things as fundamental as the full GPIO specs. TI does no such utter BS.

That is just my point: They FAILED to publish the full GPIO specs! How demented is that?

Anything that has the full MCU datasheet published is significantly superior. Get a Beagle Bone Black for example.

Get a Beagle Bone Black. It is about $10 more, but you get a good design, the full specs and nobody is lying to you and you have none of the reliability issues the RPi suffers from.

Dream on. The Beagle Board, for example is from 2008 and fas fully open from the start. The Cubieboard is from 2012, same time as the RPi.

That explains a lot. Really, "targeted at education" and "full datasheet not available" do not go together, except for the most stupid or most corrupt of players. I have been wondering how this incredibly stupid choice was made.

Indeed. And if you look at the competing chips, for example from Ti (e.g. on the Beagle Bone black), you have the full, detailed datasheet after a minute of web-searching. Broadcom chips have no place in "open" hardware.

Indeed. The choice by the RPi-team was utterly stupid and can only be attributed to incompetence. I mean, a computer aimed at education, and then you cannot publish the full datasheet? That is just insane!

Personally, I also found the official forum overrun with people with big egos and small skills and a lot more techno-mysticism than actual engineering. It is no surprise that the RPi is such a badly designed device. Basically all competitors are significantly superior.

Some cretins dreaming about bio-weapons does not give them any real capability. And no, they are neither easy to make nor cheap nor easy to use. This is just the usual exceedingly unethical fear mongering used to sell more copy and to keep the population docile.

It is also not a new tactics, but most people are still cretins that fall for it every time:

The whole aim of practical politics is to keep the populace alarmed (and hence clamorous to be led to safety) by menacing it with an endless series of hobgoblins, all of them imaginary. -- H.L. Mencken

While that certainly plays a role, it is a minor one. It does stand in the way of solving things, but if you do not have developers that can do secure software engineering competently (and that is the normal case), then giving them too little time and money to do secure software engineering does not matter. The other thing is that people that actually understand software security are much less likely to declare something finished or secure than those with only a superficial understanding of things. Software security really is an additional, and exceedingly hard to obtain, qualification. That most "programmers" these days struggle even with simple things (see http://blog.codinghorror.com/t... , for example) is not the root cause.

Sorry, but no. For example, one of the most important threats these days in the banking industry is data leakage. No amount of input data validation is going to help one bit there. These aspects are all critical. Mess up one, and all is lost. That is what makes software security so difficult: You have to master the whole problem space before you can produce good solutions. Incidentally, there are rules "11: Always consider the business case" and "12: Do a conclusive risk and exposure-analysis and rate and document your findings" which are the make-or-break aspects and it are completely missing from the list.

You can. But you need to be aware that 99.9% of people doing PHP or Java or the JVM do not have what it takes to make anything that may see real attacks secure. People that can secure things in this particular problem space are exceedingly rare and exceedingly expensive. One problem is that you cannot use most/all libraries for security critical functions, and may well have to augment the JVM via JNI for secure input validation. Most Java folks are not capable of doing that at all.

While the brochure referenced is nice, anybody that needs it has zero business building anything security-critical. It does take a lot of experience and insights to apply the described things in practice in a way that is reliable, efficient and secure and respects business aspects and the user. Personally, I have more than 20 years of experience with software security and crypto, and looking back, I think I became a competent user, designer and architect only after 10 years on this way. The problem here is that as software security is very hard, a specialized form of the Dunning-Kruger effect applies. The things I have seen people do that though they understood software security are staggering. Unless you have achieved a holistic view of the problem-space, do not even try to design any security critical software.