Sometimes we do things because “that’s the way we’ve always done them.” Screws, for example, had slotted heads in the 1500s and slotted heads are notoriously bad, but despite Robertson in 1907 and Phillips in the 1930s, it took decades for slotted screw heads to become uncommon and they still lurk in a few areas. Many Linux tools we use every day are direct descendants from Unix tools that have been around for almost half a century. We’ve looked at a few more modern alternatives before, and [ibraheemdev] has a GitHub collection of many such tools that’s worth checking out.
Of course, modern doesn’t always mean better. However, the tools in the list do have great features including things that were uncommon in the old days such as the use of color, text-based graphics, and things like git integration.
It is funny how exotic computer technology eventually either fails or becomes commonplace. At one time, having more than one user on a computer at once was high tech, for example. Then there are things that didn’t catch on widely like vector display or content-addressable memory. The use of mass storage — especially disk drives — in computers, though has become very widespread. But at one time it was an exotic technique and wasn’t nearly as simple as it is today.
However, I’m surprised that the filesystem as we know it hasn’t changed much over the years. Sure, compared to, say, the 1960s we have a lot better functionality. And we have lots of improvements surrounding speed, encoding, encryption, compression, and so on. But the fundamental nature of how we store and access files in computer programs is stagnant. But it doesn’t have to be. We know of better ways to organize data, but for some reason, most of us don’t use them in our programs. Turns out, though, it is reasonably simple and I’m going to show you how with a toy application that might be the start of a database for the electronic components in my lab.
You could store a database like this in a comma-delimited file or using something like JSON. But I’m going to use a full-featured SQLite database to avoid having a heavy-weight database server and all the pain that entails. Is it going to replace the database behind the airline reservation system? No. But will it work for most of what you are likely to do? You bet. Continue reading “Linux Fu: Databases Are Next-Level File Systems”→
For most of us who didn’t do well in high school English class, spell checkers are a real game-changer. Sure, you can still swap a “to” and a “too,” but a spell checker will catch a lot of typos. But what about in your source code? You usually don’t spell check source code and even if you did, the rules are funny. After all, “my_proejct” is a perfectly fine variable name, but you probably meant “my_project.” That’s where a program called typos comes in. It aims to be a spell checker for source code that is fast enough and with a low enough false positive rate that you can run it against changed code and reject spelling problems.
Sure, if “my_proejct” is a one-time typo, the compiler or interpreter will probably catch it. But it won’t catch comments and it also won’t catch something you spell wrong consistently. For that you need something like typos.
There was a time when booting Linux from a floppy disk was the norm, but of course, those days are long gone. Even if you still had a working 3.5 inch drive, surely the size of the modern kernel alone would far exceed the 1.44 MB capacity of the disks, to say nothing of all the support software required to create a usable operating system. Well that’s what we thought, anyway.
But then [Krzysztof Krystian Jankowski] dropped Floppinux, a live Linux OS that boots from just a single floppy. There’s even a few hundred KB left over on the disk, allowing the user to tuck a few of their own programs and scripts onboard before booting it up. But most impressively, the project doesn’t rely on ancient software releases like so many other embedded systems do. Every component of Floppinux is pulled directly from the cutting edge, including version 5.13.0-rc2 of the Linux kernel which is literally just a few days old.
Floppinux running on the Asus Eee PC
Of course some concessions had to made in order cram the latest Linux kernel and build of BusyBox into slightly north of 1 MB, so Floppinux certainly isn’t what anyone would call a daily driver. The kernel is stripped down the absolute minimum, and is targeted for the decidedly poky i486. [Krzysztof] had to be very selective about which programs actually made the cut as well, so once the system is booted, there’s not a whole lot you can do with it outside of writing some shell scripts. But then, that was sort of the goal to begin with.
If you’re wondering how [Krzysztof] pulled it off, you don’t have to. He walks you though the entire process, down to the commands he used to do everything from pull down and compile the source code to creating the final disk image. Even if you don’t own a floppy drive, it’s well worth following his guide and booting the image up in QEMU just to say you’ve officially built a Linux system from scratch. It’s good for more than just bragging rights; learning how all the components of a minimal install like this fits together will no doubt come in handy the next time you find yourself poking around inside an embedded Linux device.
Writing a command line program that needs a little more pizzaz? Ncurses just not colorful or high res enough? Or maybe you want to bring the demo scene to the command line. Notcurses has your back. The demo is great, and looks like it can push out enough detail to pull off silliness like pushing an SNES game’s output straight to the console. What might be the most impressive element of the library is that while it can blit high res graphics through a terminal emulator with graphical support, it will also work on the basic Linux console, with no graphical system installed, by using some very old tricks. I know what you’re wondering: That’s all well and good, but can it run Doom? Yep. Come back after the break for a demo. Continue reading “Terminal Magic With Notcurses”→
Although bash scripts are regularly maligned, they do have a certain simplicity and ease of creation that makes them hard to resist. But sometimes you really need to do some heavy lifting in another language. I’ll talk about Python, but actually, you can use many different languages with this technique, although you might need a little adaptation, depending on your language of choice.
Of course, you don’t have to do anything special to call another program from a bash script. After all, that’s what it’s mainly used for: calling other programs. However, it isn’t very handy to have your script spread out over multiple files. They can get out of sync and if you want to send it to someone or another machine, you have to remember what to get. It is nicer to have everything in one file.
These days, embedded systems often have networks and that can make them significantly more complex. Networks are usually pretty nondeterministic and there are a variety of oddball conditions. For example, when your public-access pick and place machine gets written up on Hackaday and you suddenly get a 50X surge in traffic, how does your network stack handle it? While there’s no silver bullet for network testing, there are some tricks that can make it easier and one of those is the tcpreplay utilities that allow you to record complex network traffic and then play it back in a variety of ways. This has many benefits, especially if you manage to capture that one thing that triggers bad behavior sporadically. Being able to play it back on demand can speed up diagnostics considerably.
General Idea
You probably know that tcpdump allows you to grab packet captures from a network interface and save them to a file. If you prefer a GUI, you probably use Wireshark, which uses the same underlying library (libpcap) to grab the data. In fact, you can capture data using tcpdump and look at it with Wireshark, although there are other tools like tcptrace or Ngrep that can work with the output, also.
While the output of the command can be a little cryptic without tool support, a program called tcpreplay can take that data and feed it back in a variety of ways. Of course, you can modify the file first — there are tools to make that easier and — if you need to — you can craft your own network traffic by hand or using one of a variety of tools. This process is often called “packet crafting.”
