A Deep Dive On Battery Life

There are all kinds of old wives’ tales surrounding proper battery use floating around in the popular culture. Things like needing to fully discharge a battery every so often, unplugging devices when they’re fully charged, or keeping batteries in the fridge are all examples that have some kernel of truth to them but often are improperly applied. If you really want to know the truth about a specific battery, its behavior, and its features, it helps to dig in and actually take some measurements directly like [Tyler] has done with a vast array of embedded batteries in IoT devices.

[Tyler] is a firmware engineer by trade, so he is deeply familiar with this type of small battery. Battery performance can change dramatically under all kinds of scenarios, most important among them being temperature. But even the same type of battery can behave differently to others that are otherwise identical, which is why it’s important to have metrics for the batteries themselves and be able to measure them to identify behaviors and possible problems. [Tyler] has a system of best practices in place for monitoring battery performance, especially after things like firmware upgrades since small software changes can often have a decent impact on battery performance.

While working with huge fleets of devices, [Tyler] outlines plenty of methods for working with batteries, deploying them, and making sure they’re working well for customers. A lot of it is extremely useful for other engineers looking to develop large-scale products like this but it’s also good knowledge to have for those of us rolling out our own one-off projects that will operate under battery power. After all, not caring for one’s lithium batteries can have disastrous consequences.

Suc Aims To Replace Slack In Five Lines Of Bash

The design philosophy of Unix is fairly straightforward. Software should do one thing as simply as possible, and do that one thing only. As a design principle this is sound advice even well outside of the realm of Unix, and indeed software in general, but that doesn’t stop modern software packages from being too large for their own good. So, if you’re tired of bloated chat programs like Slack or Mattermost with their millions of lines of code, you might instead favor something like Simple Unix Chat (suc).

The idea is that suc can perform almost all modern chat functions in only five lines of Bash, supporting rich-text chat, file sharing, access control, and encryption. These five lines, though, only perform the core function of suc — which is to write text to a file on the system. Indeed, suc makes liberal use of plenty of other Unix services which do not add to the line counts, such as the use of SSH to handle authentication. It also relies on some other common Unix system features to handle things like ownership and access for the text files that host the text for the chat.

As channels are simply text files, it makes writing bots or other tools exceptionally simple. You can also easily pipe the output of commands directly into suc with one-liners that can do things like dump the output of make into a specific channel if compilation fails.

While it’s not likely that everyone will ditch tools like Slack to switch to something like this, it’s still an impressive demonstration of what can be done when designing around the Unix philosophy and taking advantage of system tools that already exist rather than reinventing the wheel and re-programming all of those tools into the application. Practices like this might decrease development time and increase the ease of developing cross-platform applications but they often also produce a less than desirable user experience.

The Other Way To Fight Software Rental

It’s been a distressing trend over the last decade, that of taking commercial software from a paid-for licence model and moving into the cloud and onto a rental model. In out line, we’ve seen this with CAD packages and notably with EAGLE PCB CAD, but it’s hit other sectors in exactly the same way. The art and design communities, in particular, are feeling the pinch from Adobe Suite going towards a rental model, and now the artist and perennial thorn in the side of anyone who seeks to own a colour, [Stuart Semple] is doing something about it. He’s launching a competing suite called provocatively, Abode, which will follow an affordable paid-for licence model. It’s a development that raises interesting questions for the open source community, so it’s definitely worth a second look from that perspective.

Taking on software rental can only be a good thing, and we hope that the new package gains a foothold for that reason. But since we’re sure that there will be open-source enthusiasts asking the question: why are the established open-source equivalents such as GIMP and Inkscape not the obvious alternatives to the Adobe suite? In there may be some uncomfortable moments of soul searching for the software libre world around usability and interfaces.

Whatever your take on open source versus paid software, it’s extremely encouraging to have somebody mount a high-profile challenge to the software rental model. We hope that Abode makes it to market and that it succeeds in making the graphics software market a little more open. Meanwhile, we’ve mentioned [Stuart Semple] before for his colour activism over the blackest of blacks, and for previously taking on Adobe over Pantone pricing.

Computer Speed Gains Erased By Modern Software

[Julio] has an older computer sitting on a desk, and recorded a quick video with it showing how fast this computer can do seemingly simple things, like open default Windows applications including the command prompt and Notepad. Compared to his modern laptop, which seems to struggle with even these basic tasks despite its impressive modern hardware, the antique machine seems like a speed demon. His videos set off a huge debate about why it seems that modern personal computers often appear slower than machines of the past.

After going through plenty of plausible scenarios for what is causing the slowdown, [Julio] seems to settle on a nuanced point regarding abstraction. Plenty of application developers are attempting to minimize the amount of development time for their programs while maximizing the number of platforms they run on, which often involves using a compatibility layer, which abstracts the software away from the hardware and increases the overhead needed to run programs. Things like this are possible thanks to the amount of computing power of modern machines, but not without a slight cost of higher latency. For applications developed natively, the response times would be expected to be quite good, but fewer applications are developed natively now including things that might seem like they otherwise would be.  Notepad, for example, is now based on UWP.

While there are plenty of plausible reasons for these slowdowns in apparent speed, it’s likely a combination of many things; death by a thousand cuts. Desktop applications built with a browser compatibility layer, software companies who are reducing their own costs by perhaps not abiding by best programming practices or simply taking advantage of modern computing power to reduce their costs, and of course the fact that modern software often needs more hardware resources to run safely and securely than equivalents from the past.

Exploring The Anatomy Of A Linux Kernel Exploit

A lot of talk and discussion happens anytime a hardware manufacturer releases a new line of faster, more powerful, or more efficient computers. It’s easy to see better and better specifications and assume that’s where all the progress is made. But without improved software and algorithms, often the full potential of the hardware can’t be realized. That’s the reason for the creation of io_uring, an improved system call interface in the Linux kernel. It’s also where [chompie] went to look for exploits.

The reason for looking here, in a part of the kernel [chompie] had only recently learned about, was twofold. First, because it’s a place where user space applications interact with the kernel, and second because it’s relatively new and that means more opportunities to find bugs. The exploit involves taking advantage of a complicated asynchronous buffer system, specifically at a location where the code confuses a memory location being used by the kernel with one which is supposed to be used for user space.

To actually get this to work as an exploit, though, a much more involved process is needed to make sure the manipulation of these memory addresses results in something actually useful, but it is eventually used to gain local privilege escalation. More about it can be found in this bug report as well. Thanks to the fact that Linux is open-source, this bug can quickly be fixed and the patch rolled out to prevent malicious attackers from exploiting it. Open-source software has plenty of other benefits besides being inherently more secure, though.

Too Much Git? Try Gitless

Git has been a powerful tool for software development and version control since the mid ’00s, gaining widespread popularity since then. Originally built by none other than Linus Torvalds for handling Linux kernel development, it’s branched out for use with all kinds of other projects. That being said, it is not the easiest thing to learn how to use, with tons of options, abstract ideas, and non-linear workflows to keep track of. So if you’re new to the system or don’t need all of its vast swath of features, you might want to try out an alternative like Gitless.

Thanks to the fact that the original Git is open source, it’s free to modify and use as any user sees fit, and there are plenty of options available. This one aims to simplify many of the features found in the original Git, implementing a tracking system which somewhat automates commits. It also includes a simplified branching system, making it easier to switch between branches and keep better track of all that’s happening in a project. The command line interface is simplified as well, and the entire system is backwards-compatible with Git which means that if you find yourself needing some of the more advanced tools it’s possible to switch between them with relative ease.

For those of us keeping track of our own software projects, who don’t necessarily need the full feature set that the original Git has to offer, this could be a powerful tool that decreases the steep learning curve that Git is known for. It’s definitely a system work diving into, though, regardless of whichever implementation you choose. It’s an effective tool for everything from complex, professional projects to small hobby projects on the Arduino.

Using Excel To Manage A Commodore 64

The “save” icon for plenty of modern computer programs, including Microsoft Office, still looks like a floppy disk, despite the fact that these have been effectively obsolete for well over a decade. As fewer and fewer people recognize what this icon represents, a challenge is growing for retrocomputing enthusiasts that rely on floppy disk technology to load any programs into their machines. For some older computers that often didn’t have hard disk drives at all, like the Commodore 64, it’s one of the few ways to load programs into computer memory. And, rather than maintaining an enormous collection of floppy discs, [RaspberryPioneer] built a way to load programs on a Commodore using Microsoft Excel instead.

The Excel sheet that manages this task uses Visual Basic for Applications (VBA), an event-driven programming language built into Office, to handle the library of applications for the Commodore (or Commodore-compatible clone) including D64, PRG, and T64 files. This also includes details about the software including original cover art and any notes the user needs to make about them. Using VBA, it also communicates to an attached Arduino, which is itself programmed to act as a disk drive for the Commodore. The neceessary configuration needed to interface with the Arduino is handled within the spreadsheet as well. Some additional hardware is needed to interface the Arduino to the Commodore’s communications port but as long as the Arduino is a 5V version and not a 3.3V one, this is fairly straightforward and the code for it can be found on its GitHub project page.

With all of that built right into Excel, and with an Arduino acting as the hard drive, this is one of the easiest ways we’ve seen to manage a large software library for a retrocomputer like the Commodore 64. Of course, emulating disk drives for older machines is not uncommon, but we like that this one can be much more dynamic and simplifies the transfer of files from a modern computer to a functionally obsolete one. One of the things we like about builds like this, or this custom Game Boy cartridge, is how easy it can be to get huge amounts of storage that the original users of these machines could have only dreamed of in their time.