Linux Hacks

524 Articles

Linux Fu: Getting Started With Systemd

April 11, 2024 by 45 Comments

I will confess. I started writing this post about some stupid systemd tricks. However, I wanted to explain a little about systemd first, and that wound up being longer than the tricks. So this Linux Fu will be some very fundamental systemd information. The next one will have some examples, including how to automount a Raspberry Pi Pico. Of course, by the end of this post, you’ll have only scratched the surface of systemd, but I did want to give you some context for reading through the rest of it.

Like many long-time Unix users, I’m not a big fan of systemd. Then again, I’m also waiting for the whole “windows, icon, mouse, pointer” fad to die down. Like it or not, systemd is here and probably here to stay for the foreseeable future. I don’t want to get into a flame war over systemd. Love it or hate it, it is a fact of life. I will say that it does have some interesting features. I will also say that the documentation has gotten better over time. But I will also say that it made many changes that perhaps didn’t need to be made and made some simple things more complicated than they needed to be.

In the old days, we used “init scripts,” and you can still do so if you are really motivated. They weren’t well documented either, but it was pretty easy to puzzle out the shell scripts that would run, and we all know how to write shell scripts. The systemd way is to use services that are not defined by shell scripts. However, systemd tries to do lots of other things, too. It can replace cron and run things periodically. It can replace inetd, syslog, and many other traditional services. This is a benefit or a drawback, depending on your point of view.

(Editor’s note: And this logging functionality was exactly what was abused in last week’s insane liblzma / ssh backdoor.)

Configuring systemd requires you to create files in one of several locations. In systemd lingo, they are “units.” For the purpose of this Linux Fu, we’ll look at only a few kinds of units: services, mounts, and timers. Services let you run programs in response to something like system start-up. You can require that certain other services are already running or are not running and many other options. If the service dies, you can ask systemd to automatically restart it, or not. Timers can trigger a service at a particular time, much like cron does. Another unit you’ll run into are sockets that represent — you guessed it — a network socket.

Continue reading “Linux Fu: Getting Started With Systemd” →

Is Your Mental Model Of Bash Pipelines Wrong?

March 28, 2024 by 11 Comments

[Michael Lynch] encountered a strange situation. Why was compiling then running his program nearly 10x faster than just running the program by itself? [Michael] ran into this issue while benchmarking a programming project, pared it down to its essentials for repeatability and analysis, and discovered it highlighted an incorrect mental model of how bash pipelines worked.

Here’s the situation. The first thing [Michael]’s pared-down program does is start a timer. Then it simply reads and counts some bytes from stdin, then prints out how long it took for that to happen. When running the test program in the following way, it takes about 13 microseconds.

$ echo '00010203040506070809' | xxd -r -p | zig build run -Doptimize=ReleaseFast
bytes: 10
execution time: 13.549µs

When running the (already-compiled) program directly, execution time swells to 162 microseconds.

$ echo '00010203040506070809' | xxd -r -p | ./zig-out/bin/count-bytes
bytes: 10
execution time: 162.195µs

Again, the only difference between zig build run and ./zig-out/bin/count-bytes is that the first compiles the code, then immediately runs it. The second simply runs the compiled program. Continue reading “Is Your Mental Model Of Bash Pipelines Wrong?” →

a CH32V003 Linux-bearing PCB, single-sided, hand-etched, lovely

Bring Linux To CH32V003 Through, Yes, RISC-V Emulation

March 3, 2024 by 14 Comments

Like playing around with Linux on low-power devices? You’d be hard pressed to find a better example than the [tvlad1234]’s linux-ch32v003 project. It’s not just a one-off — it’s something you could build right now, since it requires hardly any extra parts.

With help of a 8 MB PSRAM chip for RAM supplementation purposes and an SD card, plus some careful tailoring of the Linux .config parameters, you get Linux on a chip never meant to even come close to handling this much power. The five minutes it takes to boot up to a prompt is part of the experience.

As usual with [tvlad1234]’s projects, there’s a fun twist to it! Running Linux on this chip is only possible thanks to [chlohr]’s mini-rv32ima project, which, as you might remember, is a RISC-V emulator. Yes, this runs Linux by running a RISC-V emulator on a RISC-V chip. The main reason for that is because the MCU can’t map the PSRAM chip into RAM, but if you use an emulator, memory mapping is only a matter of software. Having applied a fair amount of elbow grease, [tvlad1234] brings us buildroot and mainline Linux kernel configs you can compile to play with this — as well as a single-layer-ready KiCad board project on GitHub. Yep, you could literally etch a PCB for this project from single-sided copper-clad FR4 with a bit of FeCl3.

While the CH32V003 is undoubtedly a more impressive target for Linux, the RP2040 Linux project might be more approachable in terms of having most of the parts in your parts box. At least, up until we start valuing the CH32V003 for all the cool stuff it can do!

What Is X86-64-v3?

February 25, 2024 by 26 Comments

You may have heard Linux pundits discussing x86-64-v3. Can recompiling Linux code to use this bring benefits? To answer that question, you probably need to know what x86-64-v3 is, and [Gary Explains]… well… explains it in a recent video.

If you’d rather digest text, RedHat has a recent article about their experiments using the instructions set in RHEL10. From that article, you can see that most of the new instructions support some enhancements for vectors and bit manipulation. It also allows for more flexible instructions that leave their results in an explicit destination register instead of one of the operand registers.

Of course, none of this matters for high-level code unless the compiler supports it. However, gcc version 12 will automatically vectorize code when using the -O2 optimization flags.

Continue reading “What Is X86-64-v3?” →

Steampipe: All SQL All The Time

February 19, 2024 by 23 Comments

Although modern Linux has slightly shifted, the old Unix mantra was: everything’s a file. With Steampipe, a better saying might be: everything’s a SQL table. The official tagline is “select * from cloud” which also works. The open-source program relies on plugins, and there are currently 140 sources ranging from GitHub to Google Sheets and more.

There are command line interfaces for the major platforms. You can also add the system to PostgresSQL or SQLite for even more SQL goodness. Continue reading “Steampipe: All SQL All The Time” →

Linux Fu: Forward To The Past!

February 19, 2024 by 5 Comments

Ok, so the title isn’t as catchy as “Back to the Future,” but my guess is a lot of people who are advanced Linux users have — at least — a slight interest in retrocomputing. You’d like an Altair, but not for $10,000. You can build replicas of varying fidelities, of course. You can also just emulate the machine or a similar CP/M machine in software. There are many 8080 or Z80 emulators out there, ranging from SIMH to MAME. Most of these will run on Linux or — at the least — WINE. However, depending on your goals, you should consider RunCPM. Why? It runs on many platforms, including, of course, Linux and other desktop systems. But it also will work with the Arduino, Teensy, ESP32, or STM32 processors. There is also experimental support for SAM4S and Cyclone II FPGAs.

It’s pretty interesting to have one system that will work across PCs and embedded hardware. What’s more is that, at least on Linux, the file system is directly translated (sort of), so you don’t have to use tricks or special software to transfer files to and from CP/M. It is almost like giving Linux the ability to run CP/M software. You still have to have virtual disks, but they are nothing more than directories with normal files in them.

Goals

Of course, if your goal is to simulate a system and you want to have 180 kB floppies or whatever, then the direct file system isn’t a benefit. But if you want to use CP/M software for education, nostalgia, or cross-development, this is the way to go, in my opinion.

It isn’t just the file system, either. If you need a quick utility inside your bogus CP/M environment, you can write it in Lua, at least on desktop systems. On the Arduino, you can access digital and analog I/O. Theoretically, you could deploy an embedded Altair for some real purpose fairly cheaply. Continue reading “Linux Fu: Forward To The Past!” →

Linux Fu: Curling C

February 15, 2024 by 11 Comments

Sometimes, it pays to read the man pages of commands you use often. There might be a gem hidden in there that you don’t know about. Case in point: I’ve used curl (technically, cURL, but I’m going to stick with curl) many times to grab data from some website or otherwise make a web request. But what happens if you want to do the same thing from a C program? Well, you could be lazy and just spawn a copy of curl. But it turns out curl has a trick up its sleeve that can help you. If only I’d read the man page sooner!

First Things

The simplest use of curl is to just name a URL on the command line. For example, consider this session:

$ curl http://www.hackaday.com 
<html>
<head><title>301 Moved Permanently</title></head>
<body>
<center><h1>301 Moved Permanently</h1></center>
<hr><center>nginx</center>
</body>
</html>

This isn’t so useful because it is a 301 response (to send you to the https server, in this case). The -L option will make curl go get the page instead of the redirect. Try:

$ curl -L http://www.hackaday.com

Continue reading “Linux Fu: Curling C” →