Linux Fu: Easy And Easier Virtual Networking

One of the best things about Linux is that there are always multiple ways to do anything you want to do. However, some ways are easier than others. Take, for example, virtual networking. There are plenty of ways to make a bunch of Internet-connected computers appear to be on a single private network. That’s nothing new, of course. Linux and Unix have robust networking stacks. Since 2018, though, Wireguard has been the go-to solution; it has a modern architecture, secure cryptography, and good performance.

There’s only one problem: it is relatively difficult to set up. Not impossible, of course. But it is a bit difficult, depending on what you want to accomplish.

How Difficult?

You must set up a wireguard server and one or more clients. You’ll need to pick a range of IP addresses. You might need to turn on routing. You have to generate keys. You might need to configure DNS and other routing options. You’ll certainly need to modify firewall rules. You’ll also need to distribute keys.

None of these steps are terribly difficult, but it is a lot to keep straight. The wg program and wg-quick script do most of the work, but you have a lot of decisions and configuration management to keep straight.

Browse the official “quick start,” and you’ll see that it isn’t all that quick. The wg-quick script is better but only handles some use cases. If you want really limited use cases, there are third-party tools to do a lot of the rote work, but if you need to change anything, you’ll still need to figure it all out.

That being said, once you have it set up, it pretty much works without issue and works well. But that initial setup can be very frustrating. Continue reading “Linux Fu: Easy And Easier Virtual Networking”

Hyundai Is Doomed: Porting The 1993 Classic To A Hyundai Head Unit

In the natural order of the world, porting DOOM to any newly unlocked computing system is an absolute given. This a rule which [greenluigi1] understands all too well, leading to presumably the first Hyundai to be equipped with this all-time classic on its infotainment system. This follows hot on the trail of re-hacking said infotainment system and a gaggle of basic apps being developed for and run on said head unit (being the part of the infotainment system on the front dashboard). Although it is a Linux-based system, this doesn’t mean that you can just recompile DOOM for it, mostly because of the rather proprietary system environment.

To make life easy, [greenluigi1] picked doomgeneric as the version to port. The main selling point of this project is that it only requires the developer to implement five functions to support a new platform, which then ‘just’ left figuring out how to do this on a head unit. Two of these (DG_SleepMs() and DG_GetTicksMS()) could be copied verbatim from the X11/xlib port, but the remaining three required a bit of sleuthing.

Where things go sideways is with keeping the head unit’s Helix window manager happy, and stick to the limited ways a GUI application can be launched, including the way arguments are passed. For the PoC, it was decided to just hardcode these arguments and only register the game with Helix using an .appconf configuration file. When it came to drawing pretty graphics on the screen, this was decidedly easier since the system uses Qt5 and thus offers the usual ways to draw to a QPixmap, which in this case maps to the framebuffer.

After a few playful sessions with the head unit’s watchdog timer, [greenluigi1] found himself staring at a blank screen, despite everything appearing to work. This turned out to be due to the alpha channel value of 0 that was being set by default, along with the need for an explicit refresh of the QPixmap. Up popped DOOM, which left just the implementation of the controls.

In order to start the game, you have to literally buckle up, and the steering wheel plus media control buttons are your inputs, which makes for a creative way to play, and perhaps wear some bald spots onto your tires if you’re not careful. If you’d like to give it a shot on your own ride, you can get the project files on GitHub.

Continue reading “Hyundai Is Doomed: Porting The 1993 Classic To A Hyundai Head Unit”

Bye Bye Ubuntu, Hello Manjaro. How Did We Get Here?

Last week I penned a cheesy fake relationship breakup letter to Ubuntu, my Linux distribution of choice for the last 15 years or so. It had well and truly delivered on its promise of a painless Linux desktop for most of that time, but the most recent upgrades had rendered it slow and bloated, with applications taking minutes to load and USB peripherals such as my film scanner mysteriously stopping working. I don’t have to look far to identify the point at which they adopted Snap packages as the moment when it all went wrong. I’d reached the point at which I knew our ways must part, and it was time to look for another distro.

Continue reading “Bye Bye Ubuntu, Hello Manjaro. How Did We Get Here?”

Linux Fu: Making Progress

The computer world looks different from behind a TeleType or other hardcopy terminal. Things that tend to annoy people about Unix or Linux these days were perfectly great when you were printing everything the computer said to you. Consider the brevity of most basic commands. When you copy a file, for example, it doesn’t really tell you much other than it returns you to the prompt when it is done. If you are on a modern computer working with normal-sized files locally, not a big deal. But if you are over a slow network or with huge files, it would be nice to have a progress bar. Sure, you could write your own version of copy, but wouldn’t it be nice to have some more generic options?

One Way

The pv program can do some of the things you want. It monitors data through a pipe or, at least through its standard output. Think of it as cat with a meter. Suppose you want to write a diskimage to /dev/sdz:

cat diskz.img >/dev/sdz

But you could also do:

pv diskz.img >/dev/sdz

By default, pv will show a progress bar, an elapsed time, an estimated end time, a rate, and a total number of bytes. You can turn any of that off or add things using command line options. You can also specify things like the size of the terminal if it should count lines instead of bytes, and, in the case where the program doesn’t know what it is reading, the expected size of the transfer.

Continue reading “Linux Fu: Making Progress”

Linux Fu: C On Jupyter

If you are a Pythonista or a data scientist, you’ve probably used Jupyter. If you haven’t, it is an interesting way to work with Python by placing it in a Markdown document in a web browser. Part spreadsheet, part web page, part Python program, you create notebooks that can contain data, programs, graphics, and widgets. You can run it locally and attach to it via a local port with a browser or, of course, run it in the cloud if you like. But you don’t have to use Python.

You can, however, use things with Jupyter other than Python with varying degrees of success. If you are brave enough, you can use C. And if you look at this list, you’ll see you can use things ranging from Javascript, APL, Fortran, Bash, Rust, Smalltalk, and even MicroPython.

Continue reading “Linux Fu: C On Jupyter”

Linux Fu: Supercharge Bash History

Having a history of shell commands is a great idea. It is, of course, enormously handy when you have to run something repetitively or you make a simple mistake that needs correction. However, as I’ve mentioned in the past, bash history isn’t without its problems. For one thing, by default, you don’t get history in one window from typing in another window. If you use a terminal multiplexer or a GUI, you are very likely to have many shells open. You can make them share history, but that comes with its own baggage. If you think about it, we have super fast computers with tons of storage compared to the “old days,” yet shell history is pretty much the same as it has been for decades. But [Rcaloras] did think about it and created Bashhub, a history database for bash, zsh, and probably some other shells, too.

Command detail screen

You might think you don’t need anything more than what you have, and, of course, you don’t. However, Bashhub offers privately stored and encrypted history across machines. It also provides context about commands you’ve executed in the past. In other words, you can see the directory you were in, the exact time and date, the system you were on, and the last return code of the command.

Continue reading “Linux Fu: Supercharge Bash History”

Run Linux By Emulating RISC-V On A RISC-V Microcontroller

For years it was a given that it was impossible to run a Linux based operating system on a less powerful computer whose architecture lacked a memory management unit. There were projects such as uCLinux which sought to provide some tidbits to low computing power Linux users, but ultimately they came to naught. It is achievable after a fashion though, by using the limited architecture to emulate a more powerful one. It’s been done on AVR chips emulating ARM, on ARM chips, and now someone’s done it on an ESP32-C3 microcontroller, a RISC-V part running a RISC-V emulator. What’s going on?

RISC-V is an architecture specification that can be implemented at many levels from a simple microcontroller or even a pile of 74 logic to a full-fat application processor. The ESP32-C3 lies towards the less complicated end of this curve, though that’s not the whole reason for the emulation. The PSRAM storage is used by the C3 as data storage and can’t be used to run software, so to access all that memory capacity an emulator is required that in turn can use the PSRAM as its program memory. It’s a necessary trick for Espressif’s implementation of the architecture.

Surprisingly it’s not as slow as might be expected, with a boot-up time under two minutes. It’s not what we’d expect from our desktop powerhouses, but it’s not so long ago that certain lower-power full-fat processors could be just as lethargic. For past glories, see the AVR running Linux, and the RP2040.