Where were you looking? I can't find a usb to serial that doesn't support 1200 baud. And I work with them all day every day.

I program on niche embedded devices which have 16mb of ram and still cost a lot of money for what they are. C is the only way there. However through the development circle we have a lot of bugs which get attributed to improper memory management - null dereferencing, memory leaks and the like. This makes the development circle longer, which is acceptable.

Now on the mobile market, it is an implied that the consumer prefers a lot of relatively stable applications in a short period of time. The tradeoff for this is to pay $20 more (probably much less) for the cost of doubling the RAM.

I think in the end, the problem is talent. Talent is scarce. It needs talent to program in C and it needs talent to design RAM modules. However RAM modules are designed once and then produced in an ultra massive scale. On the other side, every little bit of code needs a developer to work on it. And I know from experience that there isn't enough talent in C to produce the loads and loads of software that is currently produced - and even if there was, it would cost. So in the end I think the way it is, is the only way.

I'm known to be a low level person and professionally a C programmer. And I agree with you on some stuff.

However...

No, I won't use C to do something in 1k memory and 3 weeks of coding, I will use python in 10mb memory and 1 day of coding. Simply because my time costs more than 10mb of memory. So stop demonising higher level languages and accept that they have their perfectly legit uses as long as their limitations are undestood. Keep in mind that if android used C and not java, we would have about 5 non crashing apps tops in the market.

Sooo, yeah...

It's not about stupidity, anonymous troll. It's about time having some actual value.

I have a raspi in front of me, with the embedded ethernet, 1 bluetooth, 2 wifi devices (1 master, 1 monitor), 1 gps, 2 usb sticks in raid, and it's charging my galaxy nexus through a powered hub. The usb problems have become such a chewing gum for the slammers, all I can say is: bullshit. You had a problem with an early revision of rpi and now you love bitching about it altough it is most probably resolved. You are welcome to post details though...

I am guessing you were going to use it for rocket control of the next mission to mars and the bugs destroyed your dreams? At least these people build/hack/destroy something. All I can see from you is bitching.

The bugs are fairly known, and there are a lot of differences between the revisions of the pi's. As I said, you had a bug and you just love to bitch about it till the end of time.

Again. Sorry for delaying your rocket control project.

Hackers hack. Bitches bitch. Choose wisely...

Sure it is. I don't see you bitching about your phone, pc, car, tv, microwave oven though. You do realise that after this announcement, videocore is the most open core on an ARM chip ever, right?

btw, http://www.broadcom.com/docs/support/videocore/VideoCoreIV-AG100-R.pdf here you go...hack away

At this point, I have concluded that many slashdotters are "hipster geeks"

Anything that gains traction and is widely known outside of the normal geek circles becomes "uncool" and is slammed down. As you can see for raspberry, although the things to bitch about are getting fewer and fewer, there are always things that slashdotters bitch about. I'm pretty sure that even if they resolve everything, slashdotters will bitch about its color.

Now think what would happen if only a couple of thousand raspis were sold and only part of the geek community knew about it. It would be all the rage!

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)