More RAM than the Raspberry Pi 3 and gigabit ethernet for a lower cost. However, my experience with ODroid and CHIP has shown me that having a large developer community is super important. Anybody can whip up a single-board computer using cheap smartphone SoCs, but getting a solid, reliable kernel with open source drivers is far from easy.
For example, I was unable to use V4L with my webcam on CHIP. The install was simple on my RPi. Another - I recently tried to build the dmx_usb kernel driver on an ODroid C1. Nope, their sources are missing a bunch of headers.
Both of these things were absolutely trivial on an RPi. Just install some packages and go.
> large developer community is super important ... solid, reliable kernel with open source drivers is far from easy.
I agree -- I think a corollary is that a larger installed base of users will yield overall better quality.
If you're using a very small subset of the accessory features, you might find that this is a good value. I've had good luck with ODROID XU3 but I only use it for ssh-ing and building/testing code.
The RPi is often worth the additional money for the quality and community benefits.
I have a Hackberry A10 board. The company behind it, Miniand, just disappeared from the web at one point, along with their website and the discussion forum it had hosted. So yes, user and developer community and sustainable backing is very important.
Agreed. You can save money, or time buying some of the other ARM-based dev boards, and I would prefer to save time, in most cases. If none of the Pi-s suit your needs, Beagleboards are a good alternative that are well-supported and much-used.
> my experience with ODroid and CHIP has shown me that having a large developer community is super important
Did you have a bad experience with these? I was thinking of buying either an ODroid or Raspberry Pi 3, now I'm curious to hear what your experiences are.
It can be a good or bad experience, depending on what exactly you want to do. specs-wise, there are many options that beat the Pi. But getting certain things done will be harder (or impossible) on non-Pis, unless you're an experienced kernel hacker (and even then)...
See my review of the ODROID-C2 / compared to Pi 3 for more thoughts[1]
I have an ODROID X2 and it was beyond faff - needed its own special PSU (not MicroUSB), wouldn't boot with any USB drives plugged in (power issues), would occasionally just not boot at all, corrupted the SD card a few times, etc.
Was a lovely powerful platform -when it worked-. The Pis are woeful when you compare them for raw power but they're orders of magnitude less dicking about and that's important.
Thats way oversimplified. These chip vendors have all supplied source dumps for their drivers. The reason the RPi works so well is all the work they're doing integrating their distributions (Raspbian is particularly good) and upstreaming stuff into the kernel.
There's actually a fairly productive community-driven effort to upstream support for Allwinner boards: http://linux-sunxi.org/Linux_mainlining_effort I'm running Debian stable with a vanilla 4.5 kernel on my Cubieboard at the moment; the official Debian kernel works too but doesn't support audio out. Unfortunately, it's been somewhat slow going.
I'm not disagreeing about the work that RPi is doing. I was addressing this part: "getting a solid, reliable kernel with open source drivers is far from easy."
If the chip vendor doesn't provide the drivers then the integrator can't either.
Anecdote : allwinner (or mediatek, cant remember now) developers that showed up at Linaro (last or 2 years ago) all sported iphones - this is all you need to know about support level of chinese SoC vendors.
> The image will be archived in .rar format. RAR is used because it has a higher compression ratio than .zip, and .rar files can store full file permissions while compressed.
What is this, 1995?!
(Oh, and it's super important to preserve the permissions of the ISO file you're dd'ing over the SD card…)
On the other hand, what is the purpose of comparing the default installed packages on the distribution image? I thought there would be some useful performance comparisons, but there's none.
Does the hardware require special driver to run Linux? So some distro would have the DMA bug and others don't? Or is it just those people are too lazy to upgrade their buggy drivers?
More archaic are systems that don't support booting from installation media. I've noticed this is common on all the low-end boards like this. Why don't any of them support, say, booting installation media off a USB stick?
Because these kinds of boards don't typically have BIOS/firmware chips, the booting options are limited to what is provided by the SoC's boot ROM. An USB host stack is immensely complicated and as such something that manufacturers wouldn't want to put in their ROMs (although I recall some Cortex-M0 chips actually implement this).
Many (maybe even most?) SoCs, including at least all previous Allwinner chips do support booting directly from SD cards, though.
No, the boot ROM supports from booting an SD card. Though not in the sense of booting any OS like Linux, but booting a board-specific second stage bootloader like U-Boot.
I ordered (and fully paid for) my 2GB back in January and I'm still waiting for the order state to change (it's currently unfulfilled). If you look at the boards, I'm not alone. Apparently it'll arrive in May, so be aware if you order now, it may be some time.
Also, the images being stored in .rar format is a little crazy. I'm not sure why that's the case when there are a plethora of other compression formats more generally used for binary image compression.
Yeah - this is my complaint. I really want a Pi-zero. Or ten, really. I want to be able to put these in all sorts of places where a $40 board wouldn't make sense. But you can't get a Pi-zero for love or for money right now.
The excuse that's given on the Pi foundation forums is that they're prioritizing education production? But what exactly is the hold-up? Is it really that hard to get time on a pick-and-place machine in China? Is order fulfillment scaling badly somehow? Is the supply of the Broadcom chip low right now?
I want the Pi-zero, and right now it's nothing but vapor-ware!
The Raspberry Pi Zero has been available intermittently since it's release, and as of today it is in stock on Adafruit[0]. Many motivated people have been able to obtain it and build a few projects [1].
I put money into the Pine64 Kickstarter campaign back in December and have yet to receive the unit. Part of the delay was adding on peripherals, but there wasn't really an indication that there would be much of delay.
Raspberry Pi announced the Raspberry Pi 3 on Leap Day (I think); I ordered it, it came within 2 weeks (on Pi Day!). Installed the Recalbox OS and the Pi 3 works like a champ! it streams videos from an external hard drive and handles ROM's and emulators really well. I highly recommend this if you want a media center and more.
I hope playing with the Pine64 will make up for the wait time, but the execution on the campaign was a bit lacking (not that I could have done better). Still pretty excited, just was hoping to have it on time.
There's a big difference between backing a project on Kickstarter and buying a product that's already on sale. Kickstarter is not a shop. I also backed it on Kickstarter, and as with everything I back I treat the shipping dates as a very optimistic estimate. I bought the Pi 3 on launch day too and it came next day, but that was buying from a shop. I had different expectations. The crap that the project creators have been getting is completely out of proportion. In a recent backer update, they said that they've had death threats, including one guy who actually turned up at their office to threaten them over a $22 pledge.
They asked for $31k and took $1.7 million. It's hardly surprising it's taken longer than predicted. I'm looking forward to receiving mine but I'm not stressing over getting it quickly. I'll play with the Pi in the meantime.
I totally agree with you on the point that the hate the creators are receiving is ridiculous.
I had never backed a Kickstarter project before but had heard of stories of projects not delivering on time (or at all). I was (naively) hoping that this would not be the case. Just thought it was interesting that Raspberry Pi Foundation was able to come out with a 64 bit single board computer without a hitch, but I chalk that up to having much more experience to consumer demand in this space.
I am loving the Pi 3 and can't wait to get the Pine64! Do you have any specific plans for it?
I've backed lots of hardware projects on Kickstarter and run one myself [1], and ones that deliver on time are a small minority. Most are at least 2-3 months late (including mine).
I haven't decided what I'll use it for yet. Right now I'm making a robot with my 4 year old daughter using a Pi Zero.
As a heads up, like the commenter on your blog mentioned, you can write to `/dev/rdisk?` to speed up your transfer. You can also view dd's progress by using pv (available in Homebrew) like: `pv /path/to/image.iso | sudo dd of=/dev/rdisk? bs=?M`
That aside, interesting article. All these new ultra-cheap computers are exciting.
I'm not the parent commenter and I'm not on a Mac, but I assume it's the bash glob for a single character match (much like * matches multiple characters, ? matches a single character).
Which means the actual file path should be something like `/dev/rdisk0`.
Edit: oh, I guess you meant the ? in `bs=?M`, in which case I don't know. Probably damurdock's way of not committing to a particular value in their post.
I was one of the Kickstarter backers for the Parallella a few years back. The 64 cores are in the Epiphany IV coprocessor, while the board itself has two ARM cores and would behave a lot like the RPi and similar if the Epiphany wasn't taken advantage of, assuming you were able to get your hands on one of the early 64-core boards.
The 16-core Epiphany III-based Parallella is available at Amazon.
As my sibling poster mentioned, 64 (or 16) cores is for the coprocessor. The coprocessor has an architecture halfway between a traditional CPU and a GPU.
Linux does not run on the coprocessor itself, so your coprocessor code runs on the bare metal and has no access to the POSIX APIs, or any existing libraries, really.
Finally (this was the deal-breaker for my project, after I bought a bunch of Parallellas!) the Epiphany has only something like 8mb (not gb!) of RAM. All 16 cores have to share that. (The main CPU has access to something like a gig, but the bandwidth bottleneck between the two processors is unacceptable for trying to randomly access main memory from the Epiphany.)
If anyone is still not scared off, I have two extra Parallellas lying around still in the original packaging. Ping me at [email protected] if you're interested.
Ridiculous core counts typically find workloads that saturate the memory controller or I/O, which is why so few are made. They typically bring with them a non-uniform memory space, cache-incoherent/rings, etc. All of that makes software teams groan and decide to spend a few thousand USD on a multi-socket Xeon or a GPU.
Their display spec is a bit funny: "PINE64 features Allwinner’s SmartColor2.0 Technology with integrated display engine up to 1920×1200 HDMI v1.4 supported up to 4K." - which one is it, 1920x1200 or 4K?
I received mine last week. I've been concerned over the linux development as that was the primary reason I bought the board. It's coming along nicely due to a few key members of the community. If I had the ability to do it over again, I'd still probably buy it. If the Pi 3 had a 2GB RAM option, I'd reverse that decision.
Ordered mine after seeing Ray speak at Ancient City Ruby conf last week explaining parallelism and its benefits. I have no idea what I want to do with it but I'm excited to have a tiny computer. Maybe I'll make a custom case for it and use it as a DSP computer.
>> Spurious. dd was always named after JCL dd cards.
>
> Alright, I'll bite: What did that "dd" stand for?
I hesitate to leap in front of Dennis Ritchie, but ...
On IBM mainframes, programs are started by "submitting" them in JCL ("Job
Control language") to JES, the Job Entry System.
One of the most important statements in JCL is the DD statement. DD stands
for "Data Definition". It is used to define the data (duh ;-) that is used
when the job is run - input files, output files etc.
JCL has a "unique" flavour; it is utterly unlike normal programming
languages and is archane, cryptic, obscure, complex and rude. It is also
ugly and stupid. However there is so much JCL in the world that, hell, we
still have to live with it - even after thirty years of Unix ;-).
The Unix dd command copies data from one place to another, rather like a
typical DD card in a JCL stack.
The "if=", "of=", "bs=", etc, parameters to the Unix dd command retain some
of the characteristic syntactic idioms of JCL (not to say that the dd
command is as ugly as JCL - it just has a faint echo of the JCL syntax).
For a mainframe guy, the dd command on Unix gives a nice homely touch.
I just received mine last week, and installed Remix OS without much problem (other than having to dig out a Windows netbook so as to use the Phoenix SD card burning app).
I am going to try mine out as a multimedia/game box for my den TV for starters, as there are lots of fun little games the kids & teens like to play on Android. I've had no issues with hooking up dongle-based wireless keyboards and game controllers.
For example, I was unable to use V4L with my webcam on CHIP. The install was simple on my RPi. Another - I recently tried to build the dmx_usb kernel driver on an ODroid C1. Nope, their sources are missing a bunch of headers.
Both of these things were absolutely trivial on an RPi. Just install some packages and go.