Banana Backups

Tuesday, 21 November 2017 - 15:58 PM - (Hardware)

In the September 2016 issue, I wrote an article called "Papa's Got a Brand New NAS" where I described how I replaced my rackmounted gear with a small, low-powered ARM device—the Odroid XU4. Before I settled on that solution, I tried out a few others including a pair of Banana Pi computers—small single-board computers like Raspberry Pis only with gigabit networking and SATA2 controllers on board. In the end, I decided to go with a single higher-powered board and use a USB3 disk enclosure with RAID instead of building a cluster of Banana Pis that each had a single disk attached. Since I had two Banana Pis left over after this experiment, I decided to put them to use, so in this article, I describe how I turned one into a nice little backup server.

The Hardware

Although Raspberry Pis are incredibly popular and useful if you want a small, low-powered, cheap computer, they have their downsides as network backup servers. One of the main downsides is low-performance disk and network speeds. A Raspberry Pi maxes out at 100Mbit on the network and offers only USB2 ports if you want to add a hard drive. Those limitations are what drove me to look for other solutions for my home NAS in the first place, and it's one area where a Banana Pi has an edge. Even though the modern Raspberry Pi 3 has a faster CPU, the old Banana Pi still beats it on network and disk I/O. This makes it pretty ideal as a standalone system for home network backups, depending on your needs.

In my case, I'm not backing up terabytes of media; I just wanted bare-metal backups of my servers and workstations along with backups of important documents. The size of your backups is important, because the Banana Pi is limited to a single SATA2 port, and the board itself can power only a 2.5" laptop drive. So if you want to stick with local power, you are limited to 2.5" hard drive sizes. That said, if you were willing to splurge on an externally powered SATA2 enclosure, you could use a 3.5" drive instead. In my case, I happened to have an old 2.5" 500Gb laptop drive lying around that I had since replaced with an SSD. Note that you probably will need to order the appropriate SATA2 cable to connect your hard drive with your Banana Pi—it doesn't typically come with the board.

Although I imagine you could just have the board and a laptop drive sitting on a shelf, I wanted to protect it a bit more than that. Since I have a 3D printer, naturally I went to Thingiverse to see if it had any cases for a Banana Pi. It turns out someone made just the thing I needed—a Banana Pi case that also had mounting points for a 2.5" hard drive. I printed out the case (in yellow, naturally) and was able to mount the board and the laptop drive without any issues.


Raspberry Pi Alternatives

Monday, 22 January 2018 - 13:14 PM - (Hardware)

A look at some of the many interesting Raspberry Pi competitors.

The phenomenon behind the Raspberry Pi computer series has been pretty amazing. It's obvious why it has become so popular for Linux projects—it's a low-cost computer that's actually quite capable for the price, and the GPIO pins allow you to use it in a number of electronics projects such that it starts to cross over into Arduino territory in some cases. Its overall popularity has spawned many different add-ons and accessories, not to mention step-by-step guides on how to use the platform. I've personally written about Raspberry Pis often in this space, and in my own home, I use one to control a beer fermentation fridge, one as my media PC, one to control my 3D printer and one as a handheld gaming device.

The popularity of the Raspberry Pi also has spawned competition, and there are all kinds of other small, low-cost, Linux-powered Raspberry Pi-like computers for sale—many of which even go so far as to add "Pi" to their names. These computers aren't just clones, however. Although some share a similar form factor to the Raspberry Pi, and many also copy the GPIO pinouts, in many cases, these other computers offer features unavailable in a traditional Raspberry Pi. Some boards offer SATA, Wi-Fi or Gigabit networking; others offer USB3, and still others offer higher-performance CPUs or more RAM. When you are choosing a low-power computer for a project or as a home server, it pays to be aware of these Raspberry Pi alternatives, as in many cases, they will perform much better. So in this article, I discuss some alternatives to Raspberry Pis that I've used personally, their pros and cons, and then provide some examples of where they work best.

Banana Pi

I've mentioned the Banana Pi before in past articles (see "Papa's Got a Brand New NAS" in the September 2016 issue and "Banana Backups" in the September 2017 issue), and it's a great choice when you want a board with a similar form factor, similar CPU and RAM specs, and a similar price (~$30) to a Raspberry Pi but need faster I/O. The Raspberry Pi product line is used for a lot of home server projects, but it limits you to 10/100 networking and a USB2 port for additional storage. Where the Banana Pi product line really shines is in the fact that it includes both a Gigabit network port and SATA port, while still having similar GPIO expansion options and running around the same price as a Raspberry Pi.


FOSS Project Spotlight: LinuxBoot

Thursday, 15 February 2018 - 15:12 PM - (Hardware)

Linux as firmware. more>>


Best Laptop

Monday, 12 March 2018 - 15:02 PM - (Hardware)

What's the favorite LJ reader laptop?

The top three winners are: more>>


Linux Mint Announces New MintBox Mini 2, Mozilla Plans to Add Ad Blocking to Firefox, Slax New Version and More

Monday, 26 March 2018 - 12:17 PM - (Hardware)

News briefs for March 26, 2018. more>>


Product Review: GitStorage

Wednesday, 28 March 2018 - 14:46 PM - (Hardware)

Petros reviews the GitStorage server appliance, which emphasizes data privacy and security.

By profession, I'm a software developer. Aside from a preferred editor, what matters most to a developer is the use of a Source Code Manager (SCM). So, when a new product comes along featuring my favorite SCM, Git, I had no choice but to spend some time using it. more>>


Subutai Blockchain Router v2.0, NixOS New Release, Slimbook Curve and More

Thursday, 05 April 2018 - 13:59 PM - (Hardware)

News briefs for April 5, 2018. more>>


Working around Intel Hardware Flaws

Monday, 30 April 2018 - 12:07 PM - (Hardware)

Working around Intel Hardware Flaws

Zack Brown Mon, 04/30/2018 - 07:07

Efforts to work around serious hardware flaws in Intel chips are ongoing. Nadav Amit posted a patch to improve compatibility mode with respect to Intel's Meltdown flaw. Compatibility mode is when the system emulates an older CPU in order to provide a runtime environment that supports an older piece of software that relies on the features of that CPU. The thing to be avoided is to emulate massive security holes created by hardware flaws in that older chip as well.

In this case, Linux is already protected from Meltdown by use of PTI (page table isolation), a patch that went into Linux 4.15 and that was subsequently backported all over the place. However, like the BKL (big kernel lock) in the old days, PTI is a heavy-weight solution, with a big impact on system speed. Any chance to disable it without reintroducing security holes is a chance worth exploring.

Nadav's patch was an attempt to do this. The goal was "to disable PTI selectively as long as x86-32 processes are running and to enable global pages throughout this time."

One problem that Nadav acknowledged was that since so many developers were actively working on anti-Meltdown and anti-Spectre patches, there was plenty of opportunity for one patch to step all over what another was trying to do. As a result, he said, "the patches are marked as an RFC since they (specifically the last one) do not coexist with Dave Hansen's enabling of global pages, and might have conflicts with Joerg's work on 32-bit."

Andrew Cooper remarked, chillingly:

Being 32bit is itself sufficient protection against Meltdown (as long as there is nothing interesting of the kernel's mapped below the 4G boundary). However, a 32bit compatibility process may try to attack with Spectre/SP2 to redirect speculation back into userspace, at which point (if successful) the pipeline will be speculating in 64bit mode, and Meltdown is back on the table. SMEP will block this attack vector, irrespective of other SP2 defenses the kernel may employ, but a fully SP2-defended kernel doesn't require SMEP to be safe in this case.

And Dave, nearby, remarked, "regardless of Meltdown/Spectre, SMEP is valuable. It's valuable to everything, compatibility-mode or not."

SMEP (Supervisor Mode Execution Protection) is a hardware mode, whereby the OS can set a register on compatible CPUs to prevent userspace code from running. Only code that already has root permissions can run when SMEP is activated.

Andy Lutomirski said that he didn't like Nadav's patch because he said it drew a distinction between "compatibility mode" tasks and "non-compatibility mode" tasks. Andy said no such distinction should be made, especially since it's not really clear how to make that distinction, and because the ramifications of getting it wrong might be to expose significant security holes.

Andy felt that a better solution would be to enable and disable 32-bit mode and 64-bit mode explicitly as needed, rather than guessing at what might or might not be compatibility mode.

The drawback to this approach, Andy said, was that old software would need to be upgraded to take advantage of it, whereas with Nadav's approach, the judgment would be made automatically and would not require old code to be updated.

Linus Torvalds was not optimistic about any of these ideas. He said, "I just feel this all is a nightmare. I can see how you would want to think that compatibility mode doesn't need PTI, but at the same time it feels like a really risky move to do this." He added, "I'm not seeing how you keep user mode from going from compatibility mode to L mode with just a far jump."

In other words, the whole patch, and any alternative, may just simply be a bad idea.

Nadav replied that with his patch, he tried to cover every conceivable case where someone might try to break out of compatibility mode and to re-enable PTI protections if that were to happen. Though he did acknowledge, "There is one corner case I did not cover (LAR) and Andy felt this scheme is too complicated. Unfortunately, I don't have a better scheme in mind."

Linus remarked:

Sure, I can see it working, but it's some really shady stuff, and now the scheduler needs to save/restore/check one more subtle bit.

And if you get it wrong, things will happily work, except you've now defeated PTI. But you'll never notice, because you won't be testing for it, and the only people who will are the black hats.

This is exactly the "security depends on it being in sync" thing that makes me go "eww" about the whole model. Get one thing wrong, and you'll blow all the PTI code out of the water.

So now you tried to optimize one small case that most people won't use, but the downside is that you may make all our PTI work (and all the overhead for all the _normal_ cases) pointless.

And Andy also remarked, "There's also the fact that, if this stuff goes in, we'll be encouraging people to deploy 32-bit binaries. Then they'll buy Meltdown-fixed CPUs (or AMD CPUs!) and they may well continue running 32-bit binaries. Sigh. I'm not totally a fan of this."

The whole thread ended inconclusively, with Nadav unsure whether folks wanted a new version of his patch.

The bottom line seems to be that Linux has currently protected itself from Intel's hardware flaws, but at a cost of perhaps 5% to 30% efficiency (the real numbers depend on how you use your system). And although it will be complex and painful, there is a very strong incentive to improve efficiency by adding subtler and more complicated workarounds that avoid the heavy-handed approach of the PTI patch. Ultimately, Linux will certainly develop a smooth, near-optimal approach to Meltdown and Spectre, and probably do away with PTI entirely, just as it did away with the BKL in the past. Until then, we're in for some very ugly and controversial patches.

Note: If you're mentioned above and want to post a response above the comment section, send a message with your response text to ljeditor@linuxjournal.com.


Linux Gets Loud

Wednesday, 13 June 2018 - 13:08 PM - (Hardware)

Exploring the current state of musical Linux with interviews of developers of popular packages.

Linux is ready for prime time when it comes to music production. New offerings from Linux audio developers are pushing creative and technical boundaries. And, with the maturity of the Linux desktop and growth of standards-based hardware setups, making music with Linux has never been easier.

Linux always has had a place for musicians looking for inexpensive rigs to record and create music, but historically, it's been a pain to maintain. Digging through arcane documentation and deciphering man pages is not something that interests many musicians.

Loading up Linux is not as intimidating as it once was, and a helpful community is going strong. Beyond tinkering types looking for cheap beats, users range in experience and skill. Linux is still the underdog when it comes to its reputation for thin creative applications though.

Recently, musically inclined Linux developers have turned out a variety of new and updated software packages for both production and creative uses. From full-fledged DAWs (Digital Audio Workstations), to robust soft-synths and versatile effects platforms, the OSS audio ecosystem is healthy.

A surge in technology-focused academic music programs has brought a fresh crop of software-savvy musicians into the fold. The modular synth movement also has nurtured an interest in how sound is made and encouraged curiosity about the technology behind it.

One of the biggest hurdles in the past was the lack of core drivers for the wide variety of outboard gear used by music producers. With USB 2.0 and improvements in ALSA and JACK, more hardware became available for use. Companies slowly have opened their systems to third-party developers, allowing more low-level drivers to be built.


In terms of raw horsepower, the ubiquity of multicore processors and cheap RAM has enabled Linux to take advantage of powerful machines. Specifically, multithreaded software design available to developers in the Linux kernel offer audio packages that offload DSP and UI to various cores. Beyond OS multithreading, music software devs have taken advantage of this in a variety of ways.

A well known API called Jack Audio Connection Kit (JACK) handles multiple inter-application connections as well as audio hardware communication with a multithreaded approach, enabling low latency with both audio DSP and MIDI connections.

Ardour has leveraged multithreaded processing for some time. In early versions, it was used to distribute audio processing and the main interface and OS interaction to separate cores. Now it offers powerful parallel rendering on a multitude of tracks with complex effects.


Open Hardware: Good for Your Brand, Good for Your Bottom Line

Wednesday, 20 June 2018 - 12:15 PM - (Hardware)

With the rise of IoT, we're inside a short window where "open" is a strong differentiator for hardware products. Is your company ready to take advantage of it?

I don't know how to put this, but Hardware is kind of a Big Deal, and thanks to the Internet of Things (aka IoT), it's getting bigger every year. The analyst firm IDC expects spending on IoT to reach nearly $800 billion USD by the end of 2018. A study by Intel shows that by 2025, the global worth of IoT technology might be as high as more than $6 trillion USD; whereas Forbes reports that the global market could be nearly $9 trillion USD in 2020.

These statistics are based on the traditional model of closed design and development of the chips, boards and objects that will make these devices a reality. However, what if hardware developers were to learn from and leverage the popularity of free and open-source software (aka FOSS)? What if the future of IoT were Open? It's my belief that the device developers who apply the lessons of FOSS to hardware development will be those best positioned to become the powerhouses of that $9 trillion market. Similarly to software, open hardware will be seen first as a differentiator (rather than an eccentricity) and later, as the industry matures, as the default operating mode for hardware development.


Removing Support for Dead Hardware

Thursday, 05 July 2018 - 12:00 PM - (Hardware)

Arnd Bergmann submitted a patch to remove the Linux ports for a variety of architectures, including blackfin, cris, frv, m32r, metag, mn10300, score and tile. To do this, he worked directly with the former maintainers of each port to make sure the code removal was done right and didn't break anything in the mainline kernel or anywhere else.

The bottom line was that no one used those architectures anymore. He offered his analysis of why this had happened, saying:

It seems that while the eight architectures are extremely different, they all suffered the same fate: There was one company in charge of an SoC line, a CPU microarchitecture and a software ecosystem, which was more costly than licensing newer off-the-shelf CPU cores from a third party (typically ARM, MIPS, or RISC-V). It seems that all the SoC product lines are still around, but have not used the custom CPU architectures for several years at this point. In contrast, CPU instruction sets that remain popular and have actively maintained kernel ports tend to all be used across multiple licensees.

Linus Torvalds had no objection to ripping those architectures out of the kernel, but he did say, "I'd like to see that each architecture removal is independent of the others, so that if somebody wants to resurrect any particular architecture, he/she can do so with a revert."

Linus pulled the patch into the main kernel tree and noted with glee that it took a half-million lines of code out of the kernel.

Linus was not the only one who wanted to ensure the possibility of easily resurrecting those architectures. Geert Uytterhoeven wanted to know exactly what would be required, since he had an interest in the formerly removed and later resurrected arch/h8300 architecture, currently still in the kernel and going strong. And he pointed out, "In reality, a resurrection may not be implemented as a pure revert, but as the addition of a new architecture, implemented using modern features."

To which Pavel Machek complained, "By insisting on new features instead of pure revert + incremental updates, you pretty much make sure resurrection will not be possible."

But Arnd pointed out, "now that the other architectures are gone, a lot of changes can be done more easily that will be incompatible with a pure revert, so the more time passes, the harder it will get to do that."

And he added, "Some of the architectures (e.g. tile or cris) have been kept up to date, but others had already bitrotted to the point where they were unlikely to work on any real hardware for many releases, but a revert could still be used as a starting point in theory."