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” →

Dear Ubuntu…

Dear Ubuntu,

I hope this letter finds you well. I want to start by saying that our time together has been one of creativity and entertainment, a time in which you gave me the tools to develop a new career, to run a small electronics business, make fun things, and to write several thousand articles for Hackaday and other publications, but for all that it’s sadly time for our ways to part. The magic that once brought us together has faded, and what remains is in danger of becoming a frustration.

In our early days as an item you gave me for the first time a Linux distro that was complete, fast, and easy to use without spending too much time at the CLI or editing config files to make things happen; you gave me a desktop that was smooth and uncluttered, and you freed me from all those little utilities that were required to make Windows usable. You replaced the other distros I’d been using, you dual-booted with my Windows machines, and pretty soon you supplanted the Microsoft operating system entirely.

Ubuntu and me and a trusty Dell laptop, Oxford Hackspace, 2017.
Me and Ubuntu in 2017, good times.

We’ve been together for close to two decades now, and in that time we’ve looked each other in the eye across a variety of desktop and laptop computers. My trusty Dell Inspiron 640 ran you for over a decade through several RAM, HDD, and SSD upgrades, and provided Hackaday readers with the first few years of my writing. Even the Unity desktop couldn’t break our relationship, those Linux Mint people weren’t going to tear us asunder! You captured my text, edited my videos and images, created my PCBs and CAD projects, and did countless more computing tasks. Together we made a lot of people happy, and for that I will always be grateful. Continue reading “Dear Ubuntu…” →

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” →

Four square, unpopulated purple PCBs sit in front of a tube of soldering flux on a light grey work surface. The PCBs are only 1"x1".

BeagleStamp Makes Soldering Linux Into Your Projects Easier

There are a lot of things you can do with today’s powerful microcontrollers, but sometimes you really need a full embedded Linux setup. [Dylan Brophy] wanted to make it easier to add Linux to his own projects and designed the BeagleStamp.

A populated purple PCB propped against a piece of wood on a light grey work surface. The bulk of the PCB is covered in an Ocatavo processor chip.Squeezed onto a 1″ square, the BeagleStamp puts the power of a PocketBeagle into an easy to solder module you can add to a project without all that tedious mucking about with individually soldering all the components of a tiny Linux computer every time. As a bonus, the 4 layer connections are constrained to the stamp as well, so you can use lower layer count boards in your project and have your Linux too.

The first run of boards was delivered with many of the pins unplated, but [Brophy] plans to work around it for the time being so he can spot any other bugs before the next board revision. Might we suggest a future version using RISC-V?

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.

Before You Sudo Rm -rf /, Take Some Precautions

Maintaining or administering a computer system remotely is a common enough task these days, but it’s also something that can go sideways on you quickly if you aren’t careful. How many of us are guilty of executing a command, having it fail, and only then realizing that we weren’t connected to the correct computer at all? [Callan] occasionally has this issue as well, but in at least one instance, he deleted all of the contents of the wrong server by mistake. To avoid that mistake again, he uses color codes in the command line in a fairly unique way.

The solution at first seems straightforward enough. Since the terminal he’s using allows for different colors to be displayed for the user and hostname on the bash prompt, different text and background colors are used for each server. The only problem with this is that his friends also have access to these servers, and one of them is red/green colorblind, which led to another near-catastrophic mix-up. To ensure no edge cases are missed, [Callan] built a script which runs on every new server he spins up which selects two random colors, checks that they contrast well with each other, don’t create problems for the colorblind, and then applies them to the bash prompt.

For a problem most of us have had at some point or another, it’s a fairly elegant solution that helps ensure we’re sending the right commands to the right computer. This adds a layer of automation to the process and, while some color combinations do look similar, there are enough to help out most of us in some way, especially since he has released the source code on his GitHub page. For other helpful server administration tips, we’d recommend the Linux-Fu article about deploying your own dynamic DNS.