Choosing the perfect Linux distribution that satisfies your personal needs and likings can be an impossible task, and oftentimes requires a hint of Stockholm syndrome as compromise. In extreme cases, you might end up just rolling your own distro. But while frustration is always a great incentive for change, for [Josh Moore] it was rather curiosity and playful interest that led him to create snakeware, a Linux distribution where the entire user space not only runs on Python, but is Python.
Imagine you would boot your Linux system, and instead of the shell of your choice, you would be greeted by an interactive Python interpreter, and everything you do on the system will be within the realms of that interpreter — that’s the gist of snakeware. Now, this might sound rather limiting at first, but keep in mind we’re talking about Python here, a language known for its versatility, with an abundance of packages that get things done quick and easy, which is exactly what [Josh] is aiming for. To get an idea of that, snakeware also includes snakewm, a graphical user interface written with pygame that bundles a couple of simple applications as demonstration, including a terminal to execute Python one-liners.
Note that this is merely a proof of concept at this stage, but [Josh] is inviting everyone to contribute and extend his creation. If you want to give it a go without building the entire system, the GitHub repository has a prebuilt image to run in QEMU, and the window manager will run as regular Python application on your normal system, too. To get just a quick glimpse of it, check the demo video after the break.
Sure, die-hard Linux enthusiasts will hardly accept a distribution without their favorite shell and preferable language, but hey, at least it gets by without systemd. And while snakeware probably won’t compete with more established distributions in the near future, it’s certainly an interesting concept that embraces thinking outside the box and trying something different. It would definitely fit well on a business card.
It seems to me there are two camps when it comes to the Raspberry Pi. Some people use them as little PCs or even laptops with a keyboard and screen connected. But many of us use them as cheap Linux servers. I’m in the latter camp. I have probably had an HDMI plug in a Pi only two or three times if you don’t count my media streaming boxes. You can even set them up headless as long as you have an Ethernet cable or are willing to edit the SD card before you boot the machine for the first time.
However, with the Raspberry Pi 4, I wanted to get to a desktop without fishing up a spare monitor. I’ll show you two ways to get a full graphical KDE desktop running with nothing more than a network connection.
The same principle applies to most other desktop environments, but I am using KDE and Ubuntu on the Pi, even though something lighter would probably perform better. But before we get there, let’s talk about how X11 has had a big identity crisis over the years.
There are many ways to remotely access X programs, many of which are rarely used today. However, for this purpose, we are going to use SSH tunneling along with some special tricks to get the entire desktop running. It is easy to just run a single X program over SSH, and you’ve probably done that often. If so, you can skip to the next section.
For most people, adding WiFi to a project means grabbing something like an ESP8266 or an ESP32. But if you are developing your own design on an FPGA, that means adding another package. If you are targeting Linux, the OpenWifi project has a good start at providing WiFi in Verilog. There are examples for many development boards and advice for porting to your own target on GitHub. You can also see one of the developers, [Xianjun Jiao], demonstrate the whole thing in the video below.
The demo uses a Xilinx Zynq, so the Linux backend runs on the Arm processor that is on the same chip as the FPGA doing the software-defined radio. We’ll warn you that this project is not for the faint of heart. If you want to understand the code, you’ll have to dig into a lot of WiFi trivia.
On Unix — the progenitor of Linux — there was /bin/sh. It was simple, by comparison to today’s shells, but it allowed you to enter commands and — most importantly — execute lists of commands. In fact, it was a simple programming language that could make decisions, loop, and do other things to allow you to write scripts that were more than just a list of programs to run. However, it wasn’t always the easiest thing to use, so in true Unix fashion, people started writing new shells. In this post, I want to point out a few shells other than the ubiquitous bash, which is one of the successors to the old sh program.
Since the 7th Edition of Unix, sh was actually the Bourne shell, named after its author, Stephen Bourne. It replaced the older Thompson shell written in 1971. That shell had some resemblance to a modern shell, but wasn’t really set up for scripting. It did have the standard syntax for redirection and piping, though. The PWB shell was also an early contender to replace Thompson, but all of those shells have pretty much disappeared.
You probably use bash and, honestly, you’ll probably continue to use bash after reading this post. But there are a few alternatives and for some people, they are worth considering. Also, there are a few special-purpose shells you may very well encounter even if your primary shell is bash.
Linux is a two-edged sword. On the one hand, there’s so much you can configure. On the other hand, there’s so much you can configure. It is sometimes hard to know just what you should do to get the best performance, especially on a small platform like the Raspberry Pi. [Hayden James] has a suggestion: enable ZRAM and tweak the kernel to match.
Although the post focuses on the Raspberry Pi 4, it applies to any Linux system that has limited memory including older Pi boards. The idea is to use a portion of main memory as a swap file. At first, that might seem like a waste since you could use that memory to, you know, actually run programs. However, the swap devices are compressed, so you get more swap space and transfers from these compressed swap devices and main memory are lightning-fast compared to a hard drive or solid state disk drive.
Panasonic’s Grid-EYE sensor is essentially a low-cost 8×8 thermal imager with a 60 degree field of view, and a nice breakout board makes it much easier to integrate into projects. [Pure Engineering] has created an updated version of their handy breakout board for the Grid-EYE and are currently accepting orders. The new breakout board is well under an inch square and called the GridEye2 (not to be confused with the name of the main component, the AMG8833 Grid-EYE by Panasonic.)
A common way to interface with the Grid-EYE is over I2C, but to make connecting and developing on a PC more straightforward, [Pure Engineering] has made sure the new unit can plug right into their (optional) CH341A development board to provide a USB interface. Getting up and running on a Linux box is then as simple as installing the Linux drivers for the CH341A, and using sample C code to start reading thermal data from an attached GridEye2 board.
It is no secret that most Linux power users use the shell for many tasks, as for people who know what they are doing, it can be quite efficient. In addition, there are some tasks that can only be carried out from the command line, although their number shrinks every year. However, these days we are spoiled because you can have one X session running lots of terminals at once. If you log into a server, it might not have X. Or you might log into a computer over a slow connection where X is painful to use. What then? The modern answer is the tmux terminal multiplexer, and [zserge] has a thoughtful introduction to how you can use tmux for improved productivity at the command line.
In particular, he shares some configuration and offers sound advice. For example, do you really need a status bar that shows you CPU load at all times? Cool, yes, but not always a practical win.