The fact that there are significant reverse-engineering efforts going on
https://github.com/raspberrypi/firmware/wiki
https://github.com/hermanhermitage/videocoreiv/
is proof that the Broadcom chip in the Raspberry Pi is anything but open.
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...
TI fully documents their system on chip (SOC) chips.
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?
Don't lie Maevius, LIMA is getting better and better and is Opensource. So no, not all modern GPU's need binary blobs.
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
that have solved almost all the bugs in the thing
How can you be sure that you "solved" bugs in the closed part of the hardware? Oh, you can't.
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.
All modern GPU have binary blobs.
As I said, a not-so-beefy, but open GPU would be my preference. This way, you can personally experiment with all kinds of creative ways of using, misusing and abusing the computing power in the GPU.
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.
I've personally made the step from an ARMv4TDMI to an ARMv7 core and it was amazing how practically relevant the improvements were. It's not just a few new instructions here and there, but changes that made my work easier.
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
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)
I think you are an a$$hole.
Thanks. I try...
Stallmann's predictions have been realized again and again.
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.
The enormous blob in the processor and the USB driver is indeed a real problem for the RPI. We don't know what they have stuck into the blobs for their friends from N.S.A.
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.
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?
Recent investments will yield a slight profit.