Linux Fu: Moving /usr

Linux has changed. Originally inspired by Unix, there were certain well understood but not well enforced rules that everyone understood. Programs did small things and used pipes to communicate. X Windows servers didn’t always run on your local machine. Nothing in /usr contributed to booting up the system.

These days, we have systemd controlling everything. If you run Chrome on one display, it is locked to that display and it really wants that to be the local video card. And moving /usr to another partition will easily prevent you from booting up, unless you take precautions. I moved /usr and I lived to tell about it. If you ever need to do it, you’ll want to hear my story.

A lot of people are critical of systemd — including me — but really it isn’t systemd’s fault. It is the loss of these principles as we get more programmers and many of them are influenced by other systems where things work differently. I’m not just ranting, though. I recently had an experience that brought all this to mind and, along the way, I learned a few things about the modern state of the boot process. The story starts with a friend giving me an Intel Compute Stick. But the problems I had were not specific to that hardware, but rather how modern Linux distributions manage their start-up process.

Continue reading “Linux Fu: Moving /usr”

Beyond Printf(): Better Logging Practices For Faster Debugging

All of us who do some programming know that logging is a time-tested way to output messages about the internal state of our code. With varying degrees of adjustable granularity, these messages allow us to keep track of not only the state of the application, but also its overall health. When things do end up going FUBAR, these log messages are usually the first thing we look at as a software equivalent of a Flight Data Recorder in an airplane.

Spending some time and care in not only designing the logging system, but also in deciding what should be logged and at what level, can make our future self appreciate life a lot more. We’re all familiar with the practice of ‘printf-debugging’, where logging is added as part of the usual post-crash autopsy as one tries to figure out what exactly went wrong. It’s one way of doing it, and eventually it works, but we can do much better.

People are lazy, and you’re only going to stick to good logging practices if they are at least as easy if not easier than sprinkling printf() statement throughout the code. Yet at the same time we want to be able to handle things like log levels and newlines without too much extra typing. The most successful logging libraries are built with this

Continue reading “Beyond Printf(): Better Logging Practices For Faster Debugging”

Printed It: Print-in-Place PCB Gripper

The goal of Printed It is to showcase creations that truly embrace the possibilities offered by desktop 3D printing. The most obvious examples are designs that can be printed quickly and cheaply enough that they’re a valid alternative to commercially available products. But as previous entries into the series have shown, there are also technical considerations. Is it simply a duplicate of something that could be produced via traditional means, or does the design really benefit from the unique nature of 3D printing?

A perfect example is the Print-in-Place PCB Holder/Gripper created by SunShine. This design is able to hold onto PCBs (or really, whatever you wish) without any additional components. Just pull it off the bed, and put it to work. While having to add a rubber band or generic spring would hardly be an inconvenience, there’s always something to be said for a design that’s truly 100% printable.

The secret is the dual flat spiral springs integrated into the device’s jaws. While most of the common thermoplastics used in desktop 3D printing are relatively stiff, the springs have been designed in such a way that they can be printed in standard PLA. The backside of the jaws have teeth that mesh together, so the energy of the springs is combined to provide a clamping force. Serrations have been added to the jaws to catch the edge of the PCB and help stabilize it.

Visually, it’s certainly striking. The design largely eschews right angles, giving it an almost biological appearance. Many have compared it to the head of a mantis, or perhaps some piece of alien technology.

There’s no question that the design leverages the strengths of 3D printing either; there’s no other way to produce its intricate interlocking components, especially without the use of any sort of fasteners. In short, this design is an ideal candidate for Printed It. But there’s still one question to answer: does it actually work?

Continue reading “Printed It: Print-in-Place PCB Gripper”

A Beginner’s Guide To Lithium Rechargeable Batteries

Batteries were once heavy, awkward things, delivering only a limp amount of current for their size and weight. Thankfully, over time, technology has improved, and in 2020, we’re blessed with capable, high-power lithium polymer batteries that can provide all the power your mobile project could possibly need. There are some considerations one must make in their use however, so read on for a primer on how to properly use LiPos in your project!

So Many Types!

With the first commercial lithium-ion battery entering the market in 1991, the (nearly) 30 years since have seen rapid development. This has led to a proliferation of different technologies and types of battery, depending on construction and materials used. In order to treat your batteries properly, it’s important to know what you’ve got, so paying attention to this is critical. Continue reading “A Beginner’s Guide To Lithium Rechargeable Batteries”

Peeking Inside Executables And Libraries To Make Debugging Easier

At first glance, both the executables that a compiler produces, and the libraries that are used during the building process seem like they’re not very accessible. They are these black boxes that make an application go, or make the linker happy when you hand it the ‘right’ library file. There is also a lot to be said for not digging too deeply into either, as normally things will Just Work™ without having to bother with such additional details.

The thing is that both executables and libraries contain a lot of information that normally is just used by the OS, toolchain, debuggers and similar tools. Whether these files are in Windows PE format, old-school Linux a.out or modern-day .elf, when things go south during development, sometimes one has to break out the right tools to inspect them in order to make sense of what is happening.

This article will focus primarily on the Linux platform, though most of it also applies to BSD and MacOS, and to some extent Windows.

Continue reading “Peeking Inside Executables And Libraries To Make Debugging Easier”

Using Valgrind To Analyze Code For Bottlenecks Makes Faster, Less Power-Hungry Programs

What is the right time to optimize code? This is a very good question, which usually comes down to two answers. The first answer is to have a good design for the code to begin with, because ‘optimization’ does not mean ‘fixing bad design decisions’. The second answer is that it should happen after the application has been sufficiently debugged and its developers are at risk of getting bored.

There should also be a goal for the optimization, based on what makes sense for the application. Does it need to process data faster? Should it send less data over the network or to disk? Shouldn’t one really have a look at that memory usage? And just what is going on inside those CPU caches that makes performance sometimes drop off a cliff on a single core?

All of this and more can be analyzed using tools from the Valgrind suite, including Cachegrind, Callgrind, DHAT and Massif.

Keeping Those Cores Cool

Modern day processors are designed with low power usage in mind, regardless of whether they are aimed at servers, desktop systems or embedded applications. This essentially means that they are in a low power state when not doing any work (idle loop), with some CPUs and microcontrollers turning off power to parts of the chip which are not being used. Consequently, the more the processor has to do, the more power it will use and the hotter it will get.

Continue reading “Using Valgrind To Analyze Code For Bottlenecks Makes Faster, Less Power-Hungry Programs”

Using Valgrind To Track Down Known And Unknown Bugs In Your Code

We all know what bugs in code are. We don’t like them when they are in programs we use, and they’re even worse when they are in code which we have written. Clearly, the best code is bug-free, but how do we get there?

This isn’t a new question, of course, just one that has become ever more important as the total number of lines of code (LoC) that run modern day society keeps increasing and which is affecting even hobbyists more and more often now that everything has a microcontroller inside.

Although many of us know the smug satisfaction of watching a full row of green result markers light up across the board after running the unit tests for a project, the painful reality is that you don’t know whether the code really is functionally correct until it runs in an environment that is akin to the production environment.  Yet how can one test an application in this situation?

This is where tools like those contained in the Valgrind suite come into play, allowing us to profile, analyze and otherwise nitpick every single opcode and memory read or write. Let’s take a look, shall we?

Continue reading “Using Valgrind To Track Down Known And Unknown Bugs In Your Code”