Linux Hacks

552 Articles

SSH Is Magic, But Tunnels Are Even Better

April 24, 2022 by 17 Comments

Once upon a time, I was doing on-site support for a hardware install at a hotel a few years ago. The remote tech’s remote desktop software didn’t want to play with my Linux laptop, so he couldn’t get into the switch he needed to configure, to make the install work. I asked if it had an SSH port he could use, were he were in the room with me. Of course it did, but that didn’t do him much good. I ran a reverse SSH tunnel out to my public server, and pointed it at the switch on the local side. I convinced him to SSH to my server on the given port, and he was magically connected to his switch. He was literally in awe of that trick, and demanded to know how it could be done. SSH is magical, but tunneling traffic over SSH is straight-up wizardry. [Shawn Powers] agrees, and decided to help the rest of us understand the process.
Continue reading “SSH Is Magic, But Tunnels Are Even Better” →

Linux Fu: An Odd Use For Fork()

April 21, 2022 by 46 Comments

If you are a Star Trek fan, you’ll probably remember the phrase “You have to learn why things work on a starship.” The truth is, in most episodes, knowing how to override another ship’s console or make gunpowder didn’t come in very handy, but boy when it did, it really saved the day. Linux is a lot like that. There are a few things you probably don’t need to know very often, but when you do need to know, it makes a huge difference. In this particular post, I want to look at an odd use of the fork system call. For many purposes, you’ll never need to know this particular irregular use. But when you need it, you are really going to need it.

This is actually based on an old client of mine who used Unix to run a massive and very critical report every day.  The report had a lot of math since they were trying to optimize something and then generate a lot of reports. In those days, the output of the report was on old green-bar paper on a line printer. The problem was that the report took something like 14 hours to run including the printouts. If someone discovered something wrong, there was no time to run the report again because the next day’s report would have to start before the second run would finish.

The client had a bunch of Windows programmers and — at that time — there wasn’t anything really analogous to a real fork call in Windows. I looked at the code and realized that probably most of the code was spending time waiting to print the output. The computer had multiple CPUs and there were multiple printers, but that one program was hanging on the one printer. There was a lot of data, so writing it to a database and then running different reports against it wasn’t a great option. The answer was to use the power of fork. With a change in the code that took less than 30 minutes, the report ran in five hours. They were very pleased.

So how did I do it? The answer lies in how fork works. Just about every time you see a fork, you see some sort of exec call to start a new program. So if you think about fork at all, you probably think it is part of how you start a new program and, most of the time, that’s true. Continue reading “Linux Fu: An Odd Use For Fork()” →

A Power Button For Raspberry Pi, Courtesy Of Device Tree Overlays

April 4, 2022 by 11 Comments

As a standard feature of the Linux kernel, device tree overlays (DTOs) allow for easy enabling and configuration of features and drivers, such as those contained within the standard firmware of a Raspberry Pi system. Using these DTOs it’s trivial to set up features like as a soft power-off button, triggering an external power supply and enable drivers for everything from an external real-time clock (RTC) to various displays, sensors and audio devices, all without modifying the operating system or using custom scripts.

It’s also possible to add your own DTOs to create a custom overlay that combines multiple DTO commands into a single one, or create a custom device tree binary (DTB) for the target hardware. Essentially this DTB is loaded by the Linux kernel on boot to let it know which devices are connected and their configuration settings, very similar to what the BIOS component with x86-based architectures handles automatically.

Ultimately, the DTB concept and the use of overlays allow for easy configuration of such optional devices and GPIO pin settings, especially when made configurable through a simple text file as on the Raspberry Pi SBC platform.

Continue reading “A Power Button For Raspberry Pi, Courtesy Of Device Tree Overlays” →

An 128x64 OLED display with a weird image on it, showing a mouse cursor, date and time in the bottom right corner, and a whole lot of presumably dithered dots

Making Your Own Technically-HDMI OLED Monitor

April 1, 2022 by 17 Comments

One day, [mitxela] got bored and decided to build his own HDMI monitor – the unconventional way. HDMI has a few high-speed differential pairs, but it also has an I2C interface used for detecting the monitor’s resolution and issuing commands like brightness control. In fact, I2C is the backbone for a lot of side channels like these – it’s also one of our preferred interfaces for connecting to cool sensors, and in this case, an OLED display!

[mitxela] describes his journey from start to end, with all the pitfalls and detours. Going through the pinout with a broken hence sacrificial HDMI cable in hand, he figured out how to probe the I2C lines with Linux command-line tools and used those to verify that the display was recognized on the HDMI-exposed I2C bus. Then, he turned to Python and wrote a short library for the display using the smbus bindings – and, after stumbling upon an FPS limitation caused by SMBus standard restrictions, rewrote his code to directly talk to the I2C device node, raising FPS from 2 to 5-10.

From there, question arose – what’s the best software route to take? He tried making a custom X modeline on the HDMI port the display was technically attached to, but that didn’t work out. In the end, he successfully employed the Linux capability called “virtual monitors”, and found out about an interesting peculiarity – there was no mouse cursor to be seen. Turns out, they’re typically hardware-accelerated and overlaid by our GPUs, but in [mitxela]’s case, the GPU was not involved, so he added cursor support to the picture forwarding code, too.

With partial refresh, the display could be redrawn even faster, but that’s where [mitxela] decided he’s reached a satisfactory conclusion to this journey. The write-up is a great read, and if videos are more your forte, he also made a video about it all – embedded below.

We first covered the ability to get I2C from display ports 14 years ago, and every now and then, this fun under-explored opportunity has been popping up in hackers’ projects. We’ve even seen ready-to-go breakouts for getting I2C out of VGA ports quickly. And if you go a bit further, with your I2C hacking skills, you can even strip HDCP!

We thank [sellicott] and [leo60228] for sharing this with us!

Continue reading “Making Your Own Technically-HDMI OLED Monitor” →

Hacked GDB Dashboard Puts It All On Display

March 22, 2022 by 20 Comments

Not everyone is a fan of GUI interfaces. But some tasks really lend themselves to something over a bare command line. Very few people enjoy old command line text editors like edlin or ed. Debugging is another task where showing source files and variables at all times makes sense. Of course, you don’t absolutely have to have a GUI per se. You can also use a Text User Interface (TUI). In fact, you can build gdb — the GNU Debugger — with a built-in TUI mode. Try adding –tui to your gdb command line and see what happens. There are also many GUI frontends for gdb, but [cyrus-and] has an easy way to get a very useful TUI-like interface to gdb that doesn’t require rebuilding gdb or even hacking its internals in any way.

The secret? The gdb program runs a .gdbinit file on startup. By using Python and some gdb commands, [cyrus-and] causes the debugger to have a nice dashboard interface for your debugging sessions. If you install a helper script, you can even get syntax highlighting.

The system uses modules and you can even add your own custom modules and commands, if you like. You can also control what modules appear on each dashboard display. Normally, the dashboard shows when the program stops. For example, on each breakpoint. However, gdb has a hook system that allows you to trigger a dashboard using the appropriately-named dashboard command on other commands, too. Using the layout option to the dashboard command, you can even trigger different modules at different times.

Installation is simple. Just put the .gdbinit file in your home directory. If you want syntax highlights, you need to install Pygments, too. We understand you can even use his under Windows, if you like.

We don’t always take full advantage, but gdb is actually amazing. The flexible architecture makes all sorts of interesting things possible.

Linux Fu: Simple Pipes

March 16, 2022 by 15 Comments

In the old days, you had a computer and it did one thing at a time. Literally. You would load your cards or punch tape or whatever and push a button. The computer would read your program, execute it, and spit out the results. Then it would go back to sleep until you fed it some more input.

The problem is computers — especially then — were expensive. And for a typical program, the computer is spending a lot of time waiting for things like the next punched card to show up or the magnetic tape to get to the right position. In those cases, the computer was figuratively tapping its foot waiting for the next event.

Someone smart realized that the computer could be working on something else while it was waiting, so you should feed more than one program in at a time. When program A is waiting for some I/O operation, program B could make some progress. Of course, if program A didn’t do any I/O then program B starved, so we invented preemptive multitasking. In that scheme, program A runs until it can’t run anymore or until a preset time limit occurs, whichever comes first. If time expires, the program is forced to sleep a bit so program B (and other programs) get their turn. This is how virtually all modern computers outside of tiny embedded systems work.

But there is a difference. Most computers now have multiple CPUs and special ways to quickly switch tasks. The desktop I’m writing this on has 12 CPUs and each one can act like two CPUs. So the computer can run up to 12 programs at one time and have 12 more that can replace any of the active 12 very quickly. Of course, the operating system can also flip programs on and off that stack of 24, so you can run a lot more than that, but the switch between the main 12 and the backup 12 is extremely fast.

So the case is stronger than ever for writing your solution using more than one program. There are a lot of benefits. For example, I once took over a program that did a lot of calculations and then spent hours printing out results. I spun off the printing to separate jobs on different printers and cut like 80% of the run time — which was nearly a day when I got started. But even outside of performance, process isolation is like the ultimate encapsulation. Things you do in program A shouldn’t be able to affect program B. Just like we isolate code in modules and objects, we can go further and isolate them in processes.

Doubled-Edged Sword

But that’s also a problem. Presumably, if you want to have two programs cooperate, they need to affect each other in some way. You could just use a file to talk between them but that’s notoriously inefficient. So operating systems like Linux provide IPC — interprocess communications. Just like you make some parts of an object public, you can expose certain things in your program to other programs.

Continue reading “Linux Fu: Simple Pipes” →

Run Your Own Server For Fun (and Zero Profit)

March 15, 2022 by 125 Comments

It seems there’s a service for everything, but sometimes you simply learn more by doing it yourself. If you haven’t enjoyed the somewhat anachronistic pleasures of running your own server and hosting your own darn website, well, today you’re in luck!

Yes, we’re going to take an old computer of some sort and turn it into a web server for hosting all of your projects at home. You could just as easily use a Raspberry Pi –even a Zero W would work — or really anything that’ll run Linux, but be aware that not all computing platforms are created equally as we’ll discuss shortly.

Yes, we’re going to roll our own in this article series. There are a lot of moving parts, so we’re going to have to cover a lot of material. Don’t worry- it’s not incredibly complicated. And you don’t have to do things the way we say. There’s flexibility at every turn, and you’re encouraged to forge your own path. That’s part of the fun!

Note: For the sake of space we’re going to skip over some of the most basic details such as installing Linux and focus on those that have the greatest impact on the project. This article gives a high level overview of what it takes to host your project website at home. It intentionally glosses over the deeper details and makes some necessary assumptions.

Continue reading “Run Your Own Server For Fun (and Zero Profit)” →