Introduction
I have been fascinated with the Raspberry Pi for years, ever since my first days of college, watching someone wire up a simple robot with one.
However, whenever I started using one, I always ended up with the simple question; what do I do with this?
‘Make those cool robots and things! There’s tutorials everywhere!’
There was only one problem with that; I had no interest in making robots and things like that. They were cool, but I barely tinkered with electronics, besides fixing wires or replacing batteries. I had no interest in either the programming or the electronics.
So why were these things so fascinating to me?
Mini servers.
When I got my first Raspberry Pis, a pair of model B+, the first thing I did with them was set up DNS and DHCP servers. I used them as an excuse to buy my own domain and play around with DDNS, VPNs, and some very rudimentary automation.
As a kid, I had to travel between my parents houses, and the idea of grabbing my entire lab and taking it with me was the coolest thing I could think of. A toolbox of homelab in one hand, and a laptop in the other, and I could have everything I needed.
At the time, the only thing I could afford were small devices, like the Raspberry Pi. One board here, two there, and so on. Eventually, I had enough that I needed to design a custom case for them, and dedicate them their own network switch and router. I used it to re-learn all my 2D design from high school and create a small laser-cut chassis that worked shockingly well.
Somewhere out there is a paper published on the work I did in college. The paper is good, and full of interesting tidbits, but that project can’t be called anything but an abject failure. The available OSes were barely stable, and most of the hardware could barely be called functional.
Another failure was my method of automation. As a college student, my plan was to write a 5,000-line script that installed and set up every service. And by one script, I meant one single, monolithic script that identified systems, set up software, and generally turned a basic system into a fully customized server.
I’m still exceedingly proud of that script, but automation has become so much better in the years since. It’s comical to look back at it and think ‘oh that was where this came from’.
Since then, things have definitely stabilized, and SBCs have become a more usable group of devices as a whole. SSH-based automation has also become much more viable, with new utilities added constantly. Some larger companies have even started making devices, such as Nvidia and ASUS, and the old players like Raspberry and Odroid have figured their shit out.
However, there have also been failures as well. The demise of NTC and the crashing halt of almost all development of their former products, the massive security issues with Allwinner kernels, and some major design failures in several major SBCs, have caused issues for the entire group as a whole.
The SBCs
I’ve worked with a lot of SBCs, at several jobs now. However, what I’ve used is now either outdated, or just old. I’m going to cover them here, so that it’s at least documented somewhere.
The Leader - Raspberry Pi B, B+ and 2B
There is no competition for the top spot. Thesethree boards may have been some of the slowest ones that I owned, but they have something else that almost none of the others do; software stability. This is critical, since projects like Armbian and DietPi can only go so far before they have to start generalizing. With the Raspberry Pi Foundation laser focused on one product, and with backing from other communities like Ubuntu and FreeBSD, it becomes much easier for them to develop a fully fleshed out environment.
The Raspberry Pi and Raspbian aren’t perfect (more on that some other time) but it is the most widely recognized of the SBCs for a reason. It’s flexible, reasonably powerful, and cheap. Other devices copy its form factor for a reason.
The Powerhouse - Odroid XU4
When I was originally designing my lab, the XU4 was the heavy hitter, handling services that needed to stay up at all times. These didn’t have great GPIO, or great flexibility, or even low cost (at the time), but they had the most powerful and stable CPUs in the entire lab.
The Odroid boards are powerful, but with that power comes heat, and this is a major problem that the XU4 struggled with. The XU4 I had came with a low-profile active heatsink, which is completely inadequate.
The Brick - Udoo Quad
These were powerful boards, with good passive heatsinks and stable CPUs. They also had a built-in Arduino-compatible system.
However, I hated these things. They were massive compared to everything else I had, they didn’t have the same flexibility as a Raspberry or a Cubietruck, they required a 12V barrel where nearly everything else only needed 5V, and they were expensive.
The Generalist - Cubieboard 3
I love this little board. It was one of my favorite devices to play with. The only problem it had was that its CPU was on the weaker side, and the support was atrocious, since almost none of it was in English. Armbian agreed for a while, unsupporting it for a bit towards the end of my project, but support has been resumed since I wrote this.
What makes me like this board so much is that it has options. VGA and HDMI, SPDIF and a headphone jack, Ethernet and wireless, Embedded storage, SATA, and MicroSD, 12V or 5V power. There were so many ways to use this thing. It wasn’t cheap, but unlike the Udoo, it was worth it because of how much it offered.
The Jack of all Trades - Clearfog Pro
This was the biggest purchase I had ever made online at the time I bought this, and I do not regret it. Unlike the Udoos, however, I can quite easily justify a 12V outlet for this device. The sheer flexibility is worth it, since it has two mPCIe slots, an M.2 slot, USB 3, a ton of networking, and an easily accessible serial connection.
The only complaint I have is that my unit came with several bodges on the main board, and one of the switch ports doesn’t work. That’s a small price to pay for all that flexibility though.
I used this far beyond the end of my project, mostly to test drives. I bought two cheap mPCIe 4-port SATA cards and used it to wipe and check used drives, a task it still performs well.
The One Hit Wonder - PINE64
I bought the PINE64 at launch. It was a buggy mess, with no support and a broken OS. Shortly after I got mine, the wireless stopped working completely. It was an absolute mess, but I loved it.
The port layout was perfect to what I needed, but the software just wasn’t mature enough. Eventually, I had to stop using it and switch its services to another server, because the OS just couldn’t handle it.
The Exception - CHIP
The CHIP computer is quite possibly the most perfect story of why Open Source saves hardware. A year or two after launching the $9 CHIP computer, NextThingCo closed down, dropping their domain and their repositories.
Other groups popped up and saved the hardware from an unplanned obsolescence. Not that the hardware was anything special, but the fact that it was all open-sourced meant that others could come in and take the place of the company that built it.
These devices are… fine.
It was a $9 computer after all.
The Old Man - BananaPi M1
This was a board that never was a powerhouse. It was already old when I bought it, and it has since seemingly vanished along with the company that made it (now owned by a Chinese group). It’s still supported by Armbian, but it’s geriatric at this point. While it has Gigabit Ethernet and SATA II, the SATA port has poor physical support, meaning it’s extremely likely to break.
The Wierdos - NanoPi Neo and M1
These devices are… odd. I tried to find a purpose for them, but they just didn’t fit anywhere I tried to use them. The M1 lost support from Armbian, while the Neo was just too small. Both of them had weak CPUs and some deep issues with their basic layout.
Part of the problem with the Neo in particular was the CPU being on the bottom, which meant a heatsink made it too tall to fit in my little chassis, despite it being the smallest device I owned. It was close to what I needed, but it just barely didn’t make it. The lack of CPU power didn’t help. These were cheap devices that ended up being that; cheap.
The Even Weirder Weirdos - Orange Pi One and Zero
I don’t even know where to start with these.
The One launched with serious issues. I bought two a few months after they launched, and neither booted. The Zero had a similar if not more annoying problem; no wireless support for a few months. Just like the NanoPis, these were cheap devices, so cheapness was expected.
There’s not much more to say, really. Cheap device is cheap. Not recommended.
The Operating Systems
When I originally started this, there were two OSes; Raspbian or Armbian. Today, there are multiple options, but for the more modern Raspberry Pis, a massive one has appeared; Ubuntu. This is great for server operations, as Raspbian is a much more desktop-oriented OS, and had some odd issues with server-like packages.
One particular annoyance was Raspbian attempting to ‘secure’ their devices by disabling SSH out o the box, which I discovered the hard way while trying to set up a bunch of them over the network for a school. Another was an attempt to redefine the networking system using dhcpcd5, which caused issues when attempting to set a static IP.
Armbian, while it generally had better package support, covered such a wide gamut of devices that issues with Armbian’s packages could take a long time to correct. Also, Armbian had some issues with compatibility, since it was a custom kernel.
After dealing with the odd choices on Raspbian for a long time, the mitigations are well known (uninstall dhcpcd5 to fix networking, for example) but there are still issues. Also, the ability to use some of the automation utilities in Ubuntu are truly appealing.
Official Ubuntu ports haven’t made it to other devices yet, but we live in hope.
The only other OSes that are available now are Alpine Linux for the Raspberry Pi, CentOS 7 (but not 8) for the Raspberry Pi, FreeBSD 12.2 for the PINE64, Raspberry Pi, and Banana, although it’s only a Tier 2 platform (pkg not guaranteed), and DietPi for a limited selection of these devices. DietPi is more of an automated deployment platform though, which I was not partial to.
Where to go from here
After a bit of research, I’m going to try and pull in modern versions of my old devices; Odroid N2+/C4, ASUS Tinkerboard, PINE H64/RockPro64, Raspberry Pi 4. Along with that, and a different kind of automation (Salt instead of a script), I think I can try and accomplish what I tried to do several years ago.
Conclusion to this part
This is more of an overview of the past. I’ll write up little things about other SBCs or their OSes as I think of them. It’ll be interesting.
Afterthought - Links
https://github.com/chientaylor/arm-datacenter-paper - The original ARM SBC as Servers paper, written in LaTeX
https://github.com/chientaylor/containterized-arm-datacenter-paper - An updated one I started but never finished
