PEDs (pin entering devices) are heavily regulated and certified by visa and mastercard (PCI standards) so it's nearly impossible to intercept the pin before being encrypted. It is done in hardware by special purpose cryptoprocessors. Track2 data however can be stolen.

The problem lies that issuing banks should not accept transactions which are not authenticated by the chip as genuine. This is usually hard because of legacy infrastructure that can't handle it, or that they don't want to lose the transaction. After all, lost revenue might be higher than the fraud loses.

If all measures are applied as they are specified, fraud should be very close to zero. Believe me, the people who specified these standards and protocols are quite smart. However banks are very slow moving beasts and replacing all the infrastructure and re-training everyone to hard to understand concepts is costly enough that some fraud can be tolerated

No. Please don't spread FUD

You have a point that the liability is moved from the merchant (If he didn't verify the signature) to the cardholder. You also have a point that you can bypass a check with a MITM attack (not exactly practical)

However magstripes are copiable. Chips are not. The are personalised with a PKI which starts from the card system (visa/master) and the terminal always authenticates that the card is authentic against public keys. Properly configured issuers do not allow a transaction if it is not accompanied by a crypto signature by the card containing the amount, merchant ID etc. so you can't just copy the magstripe and do a transaction like this

These are just some of the _technical_ points why chip is more secure. Now, I know you want to bitch about how the banks are screwing us over, and you may be right about it, but your reasoning isn't

Have you realised that you posted the official raspberry pi foundation github account as a reverse engineering proof? They are doing many things, but reverse engineering is not one of them.

Also, I don't think anybody needs proof. It is common knowledge...

Sure. Could you please send us a reference of the SGX530 which is the GPU in beagleboard? And the kernel drivers that interface with the blob doesn't count, obviously.

I mean, I like a good argument, but pleeease try to check your facts first.

Fair enough.

However, you are talking about bare metal programming which is a completely different matter. I completely agree with you on this, but these are things that are normally abstracted by the OS.

If you want to talk in this point of view, for me the problem is purely availability. If I was to develop bare metal, again I would select the raspi because once I learn how to program it and get my applications stable on it, I can be fairly certain that I can get it easily in large quantities and probably for a long time.

However I would like to hear more about why did go with arch programming (as in armv7) and not platform programming (as in raspi/bbb/whatever) and also, why not an OS on it in order to delegate the burden of arch specific stuff to the os devs?

Ha. Nice one. Indeed I try to deceive the readers of slashdot by lying in order to get them to agree with me.

I don't consider reverse engineered drivers as proper drivers because they usually they lack support and are some generations behind. Also that doesn't change the fact that GPUs come with blobs. Having said that, I have never used the lima ones. Seeing the x86 landscape though, I believe that the move of valve with steambox, the cooperation of canonical and redhat with nvidia and amd and Torvalds cursing everyone progressed linux graphics much more than some noble but nevertheless half-assed (not because the developers are incompetent, but because it is near impossible) reverse engineering.

And honestly, I would prefer all these developers to work in progressing projects like wayland which will get linux desktop out of the stone age, and some killer apps like XBMC, and the graphics companies will line up to give proper support

It works doesn't it? I'm not planning on making a bitcoin miner with raspi so I don't care if there is an implementation bug that has a 10% performance hit and anyone who buys the raspi (or any embedded arm device) to work on GPU hacking is a bit wacky. What I care about is that power issues are fixed, all the devices are initialized correctly (I had an embedded linux device not properly initing the usb because a capacitor was not big enough so you had to manually change an smd cap), the GPIOs work as they should, I have an API of the GPIO in almost every normal language, I already have drivers (and tutorials) on how to drive LCD screens, loads of digital chips, I have plug n play ADC boards specifically designed for the pi.

I have a realtime operating system if I wish to do real time processing.

Wishful thinking. Although I personally don't care about GPU hacking, I'd love to see GPU hackers have access to the real hardware. That doesn't change the fact that there is no open GPU.

Although it's common sense that v4->v7 is a huge change, care to post some examples?

I'll grant you the media center thing, although I still use a proper x86 for media center in order not to be limited on anything.

However...
The chinese thingies you talk about. What distributions can they run? Can they run java? Is there any documentation about the GPIO? Is there any GPIO? Can you overclock/undeclock them? Do you have any community documented hardware hacks you can follow? Is there a hardware compatibility list you can check before buying peripherals? Can you find packages (as in .deb) specifically targeted towards them in the wild?

You see, although I agree with you that if you want a "fire and forget" type of device, sure there are much better alternatives. But when you want a platform to hack, you want to have some things granted. I don't want to compile packages from scratch only to find out they don't work for some obscure reason. I need to know all the hardware bugs and errata before starting a project and finding that I cannot finish it halfway.
The RPi is a stable and mature platform thanks to its community. And no matter how much people shout about it, this is the way it is and anyone who is serious about hacking and realises all the time consuming hurdles will agree with me.

The rest of the "moral" or "philosophical" issues are just noise from people who prefer to shout than hack (not implying that you are one of them, just saying)

Thanks. I try...

Stallman is predicting that the world will end and is making a living off of it. And even broken clocks are correct 2 times a day.

Aaah, the conspiracy theorist....
Sure, no problem. But can you actually back your claim up with actual facts or at least a plausible theory? I mean even if it the blob keeps data in the silicon itself about how many times I masturbated, how does it send it to NSA undetected? Ethernet/wifi seems a little hard to go undetected. Maybe the processor itself acts as an antenna and sends data?

The same way you are not paying for your TV, car, furniture, washing machine? I am pretty sure that you don't drink coca-cola because they don't release the recipe.

I don't mind open source purists, but the only purist is Stallman (and he is a fucking psycho). All the rest - you included of course - are lame hypocrites.

I undestand the aversion from locked platforms with the sole purpose of vendor lock-in or for example making money for stuff I could fix myself - see apple, oracle, microsoft products. But the development of the videocore never had that intent and this makes you an absolutist hypocrite.

Cheers

You. Still. Don't. Get IT!

It is not about the power! You have a cheap ass device that has a massive community that have solved almost all the bugs in the thing so any problem you have is a google search away. The foundation pays for ports of software to it. When you buy a new peripheral you can find quickly if it works with the pi and how to make it work. You can find lots of different enclosures and almost any other wacky thing you can think about.

Also...All modern GPU have binary blobs. On pcs, on phones, on tablets, on embedded. Get over it.

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.