Illustration of author surveying the fruits of his labor by Bomberanian

Learning Linux Kernel Modules Using COM Binary Support

Have you ever felt the urge to make your own private binary format for use in Linux? Perhaps you have looked at creating the smallest possible binary when compiling a project, and felt disgusted with how bloated the ELF format is? If you are like [Brian Raiter], then this has led you down many rabbit holes, with the conclusion being that flat binary formats are the way to go if you want sleek, streamlined binaries. These are formats like COM, which many know from MS-DOS, but which was already around in the CP/M days. Here ‘flat’ means that the entire binary is loaded into RAM without any fuss or foreplay.

Although Linux does not (yet) support this binary format, the good news is that you can learn how to write kernel modules by implementing COM support for the Linux kernel. In the article [Brian] takes us down this COM rabbit hole, which involves setting up a kernel module development environment and exploring how to implement a binary file format. This leads us past familiar paths for those who have looked at e.g. how the Linux kernel handles the shebang (#!) and ‘misc’ formats.

On Windows, the kernel identifies the COM file by its extension, after which it gives it 640 kB & an interrupt table to play with. The kernel module does pretty much the same, which still involves a lot of code.

Of course, this particular rabbit hole wasn’t deep enough yet, so the COM format was extended into the .♚ (Unicode U+265A) format, because this is 2025 and we have to use all those Unicode glyphs for something. This format extension allows for amazing things like automatically exiting after finishing execution (like crashing).

At the end of all these efforts we have not only learned how to write kernel modules and add new binary file formats to Linux, we have also learned to embrace the freedom of accepting the richness of the Unicode glyph space, rather than remain confined by ASCII. All of which is perfectly fine.

Top image: Illustration of [Brian Raiter] surveying the fruits of his labor by [Bomberanian]

Hacking A Cheap Rechargeable Lamp With Non-Standard USB-C Connector

Recently [Dillan Stock] bought a $17 ‘mushroom’ lamp from his local Kmart that listed ‘USB-C rechargeable’ as one of its features. Unfortunately while this is technically true, there’s a pretty major asterisk. This Inaya-branded lamp comes with a USB-C cable with a rather prominent label attached to it that tells you that this lamp requires that specific cable. After trying with a regular USB-C cable, [Dillan] indeed confirmed that the lamp does not charge from a standard USB-C cable. So he did what any reasonable person would do: he bought a second unit and set about to hacking it.

The "USB C" cable that comes with the Inaya Portable Rechargeable Lamp. (Credit: The Stock Pot, YouTube)
The “USB C” cable that comes with the Inaya Portable Rechargeable Lamp. (Credit: The Stock Pot, YouTube)

[Dillan] also dug more into what’s so unusual about this cable and the connector inside the lamp. As it turns out, while GND & VCC are connected as normal, the two data lines (D+, D-) are also connected to VCC. Presumably on the lamp side this is the expected configuration, while using a regular USB-C cable causes issues. Vice versa, this cable’s configuration may actually be harmful to compliant USB-C devices, though [Dillan] did not try this.

With the second unit in hand, he started hacking in earnest. The changes include a regular USB-C port for charging, an ESP32 board with integrated battery charger for the 18650 Li-ion cell of the lamp, and an N-channel MOSFET to switch the power to the lamp’s LED. He’s made the full plans and schematics available on his website.

With all of the raw power from the ESP32 available, the two lamps got integrated into the Home Assistant network which enables features such as turning the lamps on when the alarm goes off in the morning. All of this took about $7 in parts and a few hours of work.

Although we commend [Dillan] on hacking his device instead of just returning it to the store, it’s worrying that apparently there’s now a flood of ‘USB C-powered’ devices out there that come with non-compliant cables. It brings back fond memories of hunting down proprietary charging cables, which was the issue that USB power was supposed to fix.

Continue reading “Hacking A Cheap Rechargeable Lamp With Non-Standard USB-C Connector”

Tracing The #!: How The Linux Kernel Handles The Shebang

One of the delights in Bash, zsh, or whichever shell tickles your fancy in your OSS distribution of choice, is the ease of which you can use scripts. These can be shell scripts, or use the Perl, Python or another interpreter, as defined by the shebang (#!) at the beginning of the script. This signature is followed by the path to the interpreter, which can be /bin/sh for maximum compatibility across OSes, but how does this actually work? As [Bruno Croci] found while digging into this question, it is not the shell that interprets the shebang, but the kernel.

It’s easy enough to find out the basic execution sequence using strace after you run an executable shell script with said shebang in place. The first point is in execve, a syscall that gets one straight into the Linux kernel (fs/exec.c). Here the ‘binary program’ is analyzed for its executable format, which for the shell script gets us to binfmt_script.c. Incidentally the binfmt_misc.c source file provides an interesting detour as it concerns magic byte sequences to do something similar as a shebang.

As a bonus [Bruno] also digs into the difference between executing a script with shebang or running it in a shell (e.g. sh script.sh), before wrapping up with a look at where the execute permission on a shebang-ed shell script is checked.

Creating A Somatosensory Pathway From Human Stem Cells

Human biology is very much like that of other mammals, and yet so very different in areas where it matters. One of these being human neurology, with aspects like the human brain and the somatosensory pathways (i.e. touch etc.) being not only hard to study in non-human animal analogs, but also (genetically) different enough that a human test subject is required. Over the past years the use of human organoids have come into use, which are (parts of) organs grown from human pluripotent stem cells and thus allow for ethical human experimentation.

For studying aspects like the somatosensory pathways, multiple of such organoids must be combined, with recently [Ji-il Kim] et al. as published in Nature demonstrating the creation of a so-called assembloid. This four-part assembloid contains somatosensory, spinal, thalamic and cortical organoids, covering the entirety of such a pathway from e.g. one’s skin to the brain’s cortex where the sensory information is received.

Such assembloids are – much like organoids – extremely useful for not only studying biological and biochemical processes, but also to research diseases and disorders, including tactile deficits as previously studied in mouse models by e.g. [Lauren L. Orefice] et al. caused by certain genetic mutations in Mecp2 and other genes, as well as genes like SCN9A that can cause clinical absence of pain perception.

Using these assembloids the development of these pathways can be studied in great detail and therapies developed and tested.

Using Integer Addition To Approximate Float Multiplication

Once the domain of esoteric scientific and business computing, floating point calculations are now practically everywhere. From video games to large language models and kin, it would seem that a processor without floating point capabilities is pretty much a brick at this point. Yet the truth is that integer-based approximations can be good enough to hit the required accuracy. For example, approximating floating point multiplication with integer addition, as [Malte Skarupke] recently had a poke at based on an integer addition-only LLM approach suggested by [Hongyin Luo] and [Wei Sun].

As for the way this works, it does pretty much what it says on the tin: adding the two floating point inputs as integer values, followed by adjusting the exponent. This adjustment factor is what gets you close to the answer, but as the article and comments to it illustrate, there are plenty of issues and edge cases you have to concern yourself with. These include under- and overflow, but also specific floating point inputs.

Unlike in scientific calculations where even minor inaccuracies tend to propagate and cause much larger errors down the line, graphics and LLMs do not care that much about float point precision, so the ~7.5% accuracy of the integer approach is good enough. The question is whether it’s truly more efficient as the paper suggests, rather than a fallback as seen with e.g. integer-only audio decoders for platforms without an FPU.

Since one of the nice things about FP-focused vector processors like GPUs and derivatives (tensor, ‘neural’, etc.) is that they can churn through a lot of data quite efficiently, the benefits of shifting this to the ALU of a CPU and expecting (energy) improvements seem quite optimistic.

Improving Magnetoplasmadynamic Ion Thrusters With Superconductors

Ion thrusters are an amazing spacecraft propulsion technology, providing very high efficiency with relatively little fuel. Yet getting one to produce more thrust than that required to lift a sheet of A4 paper requires a lot of electricity. This is why they have been only used for applications where sustained thrust and extremely low fuel usage are important, such as the attitude management of satellites and other spacecraft. Now researchers in New Zealand have created a prototype magnetoplasmadynamic (MPD) thruster with a superconducting electromagnet that is claimed to reduce the required input power by 99% while generating a three times as strong a magnetic field.

Although MPD thrusters have been researched since the 1970s – much like their electrostatic cousins, Hall-effect thrusters – the power limitations on the average spacecraft have limited mission profiles. Through the use of a high-temperature superconducting electromagnet with an integrated cryocooler, the MPD thruster should be able to generate a very strong field, while only sipping power. Whether this works and is as reliable as hoped will be tested this year when the prototype thruster is installed on the ISS for experiments.

FreeDOS 1.4 Released

Even in 2025 there are still many applications for a simple Disk Operating System (DOS), whether this includes running legacy software (including MS-DOS games & Windows 3.x), or (embedded) systems running new software where the overhead of a full-fat Linux or BSD installation would be patently ridiculous.

This is where the FreeDOS project provides a modern, fully supported DOS, with the recent 1.4 release adding a whole range of features and updates to existing components like the FreeCOM command shell. This is the first stable release since 1.3 was released in 2022.

FreeDOS saw its first release in 1994 and has become the de facto replacement for MS-DOS — featuring many improvements to make it work well on modern hardware and a package manager to manage installed software much like on Linux & BSD. The new kernel didn’t quite make it into this release, but it and some other items will be available in the monthly test builds.

You can download the new 1.4 release here, with live & installer CD images, a USB installer and even a Floppy Edition available. System requirements include an (Intel) x86 CPU, a BIOS (or legacy UEFI mode), 640 kB of RAM and 20 MB of storage.