I think you are missing some points here.
1. The pi runs linux. You can use c/c++, python, perl, bash scripts, almost anything else you want
(1a). You have hundreds of libraries to go with that. Also thousands of programs to pipe info.
2. You can connect a 3g, wifi stick or anything USB instantly
3. You lose absolutely no time on hardware design. It might just be me but I like have my hardware done and just worry about software
4. The community will point out almost all the hardware/software limitations or bugs of the pi and you know in advance what you are getting yourself into
5. You have portable code. If you program for linux, it runs on most hardware that runs linux (some recompilation required)
6. The community has started building addons (see arduino shields) which can achieve much more

As a software developer who used embedded linux and arduino class hardware, I love the pi because it solves all the problems I don't want to worry about. I also love that I don't have to test it on different hardware/software configurations. My target will always be raspberry/debian. I undestand that this is not what some people want/like but for "rapid" embedded development the pi is number one and because of its community I think it will be for a long time to come.

In passwords you can one way encrypt them (meaning, no key is kept) because you know that a person will remember and enter the password everytime.

The reason companies keep credit card data is so they can charge recurring fees automatically or the well known one click buy, so a computer must be able decrypt and use accordingly. If you don't keep the key, you defeat the purpose of the whole scheme. The only way to protect the data (without being truly secure) is to use a hardware security module along with high physical security (something along PCI-DSS standards)

To sum it up: There is NO true security. If you can't protect cardholder data, don't keep it

btw, somewhere in their website I read that the cards were encrypted but it suggested that the key was trivial to find.

Let's say you encrypt them with the highest standard encryption algorithms. Where are you planning to keep the encryption key?

Ok, Let me clarify this.

It is possible to span a filesystem on multiple drives (see various LVMs, RAID etc) but is offtopic to the problem at hand (you cannot have 1 filesystem on your hard drive and your USB stick).

Given that hardlinks exist on the filesystem level, anything that is on a lower layer and transparent to this level (consider a driver for example that can handle hard disks, network paths, RAM etc. as 1 block device) can be on 1 filesystem and have hardlinks span across. But this purely theoretical, and a bit offtopic.

mmmmm no.

Mounting a drive to a folder has nothing to do with hardlinks (or inodes). This is on a much higher level. In order to span hardlinks on different drives, you should have 1 filesystem on 2 drives, which is not possible.

Apache doesn't serve https by default either, I think this has to do more with the configuration of the keys than the life of the *s protocols. Dying or not, it's secure, isn't it?

Although I agree with most of your post, mail servers have TLS support and if the client uses pop3s/imaps then the message is encrypted end to end. Although I don't have any real statistics from the corporate mail server from where I work, the admin is pretty confident that most mail is encrypted.

The main problem with OpenPGP on mail for me is that due to the unique key per recipient, if you add more than one recipient or cc, you have to encrypt the mail for each and every one of them. If you add some attachments it's pretty sure that you will hit the maximum allowed mail size of some mail server along the way.

Also, don't forget that at least I can easily setup thunderbird/enigmail. I don't even want to know the admin's response if he is ever asked to install/support a company wide openpgp installation

Although I would like this to work, I'm familiar with PCI-DSS and I'm pretty sure that it's your fault for keeping this data on a cell phone which is not PCI-DSS compliant and not the carrier's/CarrierIQ's

If you concentrate on the UI then you might have a point. However don't forget that firefox (and the other browsers) is average user oriented so phishing/spoofing etc are serious threats and the warning has the purpose to discourage the average user as much as possible. Considering that from an expert's point of view, unverified encryption doesn't make any sense, IMO nothing is lost by this warning anyway. I doubt that any malicious user could get a legitimate certificate to use for mitm, mainly because CAs that issue certificates do some background check. (Some social engineering might do the trick but that's a different subject)
Don't get me wrong this warning was annoying me too at first, but then I just got into the habit of having my self signed certs on a flash drive and installing them on PCs that I use to connect to my secure sites. That is true for SSH as well.

Back in the days when this warning didn't exist I was in the habit of doing mitm on co-workers computers (who are IT professionals) as a prank. They just accepted the different certificate because of the habit of pressing OK to all the dialog boxes. From the day this big warning started appearing, they knew it was me in no time

Seriously? What are you, 10? Your answer doesn't even make any sense

Ok.
Sorry If I upset you.
After all the fucking, I finally understand that you are correct. No seriously. It's all about the UI. I will have a fingerprint and you will have a fingerprint and all of us will have fingerprints. And I will collect your fingerprint from the mail, oops not mail, as it is insecure. But wait you can put another fingerprint in your mail which will be near your email address. and all of that will go to your business card. Yes, a side effect will be that your business card will be like a billboard, but who cares? Come on fuck science, let's stick it the man!

On a more serious tone, I give up, I'm going out for beers. You can try it too, it might chill you out

Agreed. But self signed certificates are not the answer. A non-profit CA could be the answer, although it has its drawbacks because if there isn't at least some paperwork in order to issue a certificate then people will just certify their mitm keys. I think the only way for HTTPS to be widely used securely is a internet-wide PKI scheme the same way dnssec is starting to be deployed, but these are just wishful thoughts.

Don't get me wrong, I want to see HTTPS widely deployed as much as you but only if it's deployed correctly. And all this is just details because right now, not even the sites that have the budget to buy a certificate use HTTPS, I cannot expect from someone who doesn't to use it

Dude, first of all chill. You are gonna have a heart attack by the time you are 40.

That is not an argument, that is a statement. An argument is that they cannot be treated the same because they are not the same. And actually, there is absolutely no reason for the latter to exist as I mentioned in most of my replies above. SSH for example displays a message the same way, but it's oriented towards at least power users and not average people, it's implied that it is dangerous

Interestingly enough, you still don't have any Computer Science arguments, but you still rely heavily on insulting. As I mentioned before HTTPS without PKI is useless because it's security through obscurity. You think that by encrypting, you are safe, but sooner or later everybody will undestand how this thing works and ettercap will be a common program, which needs about 2 or 3 clicks to do a successful SSL mitm. If that happens, then HTTPS will be as useful as WEP, it will be only useful against passive sniffing, but guess what? If you do man in the middle you can go past that.

So in conclusion you still don't have any serious argument. Can you please try again?

Your comment, except from the purpose of insulting (which is irrelevant) has no meaning. Please try to answer again after reading about public keys, PKI, CAs. After that please try to read my comment again. After you comprehended the previous, please try to explain wtf is the relation of http which is insecure by design and https which is supposed to be secure, only if it is implemented correctly.