Getting a home music streaming system off the ground is typically a straightforward task. Using Apple devices with Airplay makes this task trivial, but if you’re a computing purist like [Connor] who runs a Linux machine and wants to keep it light on extra packages, the task gets complicated quickly. His goal is to bring audio streaming to all Linux platforms without the need to install a lot of extra software. This approach is friendly to light-footprint devices like the Raspberry Pi that he used in his proof of concept.
[Connor] created a set of scripts which allow streaming from any UNIX (or UNIX-like) machines, using only dependencies that a typical OS install would already have. His Raspberry Pi is the base station and streams to his laptop, but he notes that this will work between virtually any UNIX or Linux machine. The only limitation is what FFmpeg can or can’t play.
We definitely can appreciate a principled approach to software and its use, although it does seem that most people don’t have this issue at the forefront of their minds. This results in a lot of software that is bulky, making it difficult to maintain, use, or even know what it does, and also makes it harder for those of us that don’t want to use that type of software to find working solutions to other problems. It’s noble that [Connor] was able to create something without sacrificing any principles.
Audio systems in Linux are terrible. You’ve never known true pain until you’ve tried to set up a recording or broadcasting workstation running Linux. I did, twenty years ago, and nothing has changed since. This wasn’t really a problem when Linux was either used in server spaces or some nerd’s battle station, but now we have small single board computers that everyone uses and wants to turn into a modular synth. Welcome to paintown, because the Linux audio stack is terrible.
For the past ten years, [Dynobot] has been working on improving audio in Linux. This is a decade of reading manuals from IBM and Oracle, and a deep knowledge of how to adjust settings so audio actually works. All of this work is now combined into a single script that improves everything. This means the priority of the Audio group is changed, the thread priority is better, the latency is better, and for anyone who wants to set up a local streaming service, the network latency is better. It’s not everything, and there’s no mention of recording multitrack audio, but we’ll accept the baby steps here.
There are two relevant Github repositories for this, the first containing audio adjustments for Debian-based systems, including the Raspberry Pi. This should work on any single board computer running Debian, and has been tested on all the Raspberry Pis, the Allo Sparky, ASUS Tinkerboard, and the Odroid C2. There’s also a version for TinyCore-based Linux systems that improves the priority of the audio threads, changes the thread scheduling from ‘whatever’ to FIFO, and improves the latency. If you’re running Linux, and you’re doing something with audio, this is what you need.
The fragility of SD cards is the weak link in the Raspberry Pi ecosystem. Most of us seem to have at least one Pi tucked away somewhere, running a Magic Mirror, driving security cameras, or even taking care of a media library. But chances are, that Pi is writing lots and lots of log files. Logging is good — it helps when tracking down issues — but uncontrolled logging can lead to problems down the road with the Pi’s SD card.
[Erich Styger] has a neat way to avoid SD card logging issues on Raspberry Pi, he calls it a solution to reduce “thrashing” of the SD card. The problem is that flash memory segments wear out after a fairly low number of erase cycles, and the SD card’s wear-leveling algorithm will eventually cordon off enough of the card to cause file system issues. His “Log2Ram” is a simple Unix shell script that sets up a mount point for logging in RAM rather than on the SD card.
The idea is that any application or service sending log entries to /var/log will actually be writing them to virtual log files, which won’t rack up any activity on the SD card. Every hour, a cron job sweeps the virtual logs out to the SD card, greatly reducing its wear. There’s still a chance to lose logging data before it’s swept to disk, but if you have relatively stable system it’s a small price to pay for the long-term health of a Pi that’s out of sight and out of mind.
One thing we really like about [Erich]’s project is that it’s a great example of shell scripting and Linux admin concepts. If you need more information on such things, check out [Al Williams’] Linux-Fu series. It goes back quite a way, so settle in for some good binge reading.
If you grew up with Unix systems like we did, you’ll be sorry to hear the news: vi, the noble text editor that has served us so well these 40 years, is going away — from many GNU/Linux systems, anyway. As of this writing, GNU/Linux Mint, Debian, Ubuntu, and OpenSUSE — four of the five most popular GNU/Linux distributions — have all announced that they will no longer ship the ‘vi’ editor as part of their base installs. For those of us who got our start in the punched-card era and still think of files as a collection of lines instead of a stream of bytes, this is a major blow. But, we can all take some comfort in the fact that, at least for now, the stripped-down version of vim synonymous with vi on these systems will continue to be available from package repositories.
The reasons for the move aren’t entirely clear to us, but from what we can see on the GNU/Linux mailing lists, the confusing modal interface and the fact that novice (and many seasoned) users can’t figure out how to save a file and exit the program seem to have influenced the decision. Also cited were support changes expected as GNU/Linux gains in popularity. As the user base expands to include less technically-savvy individuals, fewer people will be able to fix their constant boot issues, which is the primary use-case for vi. Replacing the self-help model will be a support infrastructure where users can take their machines to “GNU/Linux Geniuses” who will solve the problems for them.
Continue reading “Bye Bye vi: GNU/Linux Distros Drop Support”
[Marek Gibney] poses an interesting puzzle. What does the following bash command line print?
( echo red ; echo green 1>&2 ) | echo blue
You’d like to think it prints three lines: red, green, and blue. But would you be surprised to find out that it can sometimes output “blue green” and sometimes just output blue. The first surprise is that it isn’t deterministic. But the second thing that is surprising is the sometimes the entire left-hand part of the line doesn’t do anything. [Chris Siebenmann] did the analysis and explains what’s going on in a recent blog post.
Before you click the link or read further, you might want to see if you can deduce what’s going on. Give up? Here’s a hint: Part of the solution hinges on the fact that echo is built into the shell.
Continue reading “Bash Pipeline Puzzle: Green, Blue, or Blue Green?”
Although many people think of Linux-based operating systems as graphical, really that GUI is just another application running over the bare operating system. Power users, remote administrators, and people running underpowered computers like a Raspberry Pi have a tendency to do more with command line tools. [Igor] did a FOSDEM19 presentation you can see below about how he’s providing web-like services to the command line using web servers and curl as a client.
This is subtly different from just accessing an ordinary web server via curl. The output is meant for display in the terminal. Of course, you could also hit them with a web browser, if you wanted — at least, for some of them. [Igor’s] tools include a weather reporter, a QR code encoder, information and graphs for currency and cybercurrency rates, and an online help system for programmers.
Continue reading “Command Line Utilities… in the Cloud?”
When we first saw [Ben Jojo’s] post about the Internet inside EvE Online, we didn’t think we’d be that interested. We don’t play EvE — a massively multiplayer game. But it turns out, the post is really about understanding BGP (Border Gateway Protocol) and how it helps route traffic in large networks. The best part? He actually simulates a network with 8,000 nodes to test out what he’s talking about.
Obviously, you wouldn’t want to fire up 8,000 Raspberry Pi computers for such an experiment. Using Buildroot, he set up a very small Linux image that had the bare minimum required to run the tests. The qemu provided virtualization, including an obscure feature that allows you to transfer data between virtual machines using UDP. The whole thing ran on some pretty beefy hardware in the cloud. Sure, you could have provisioned 8,000 cloud instances, but that would run into some serious money pretty fast, we imagine. As a wrap-up, he even uses BGP to model his local mass transit system.
Continue reading “Learn About BGP With The Internet Of EvE”