A man standing next to a log holds a wooden mallet and a grey froe with a wooden handle. The froe's long straight blade sits atop the end of the log. Several cuts radiate out from the center of the log going through the length of the wood.

Making Wooden Shingles With Hand Tools

While they have mostly been replaced with other roofing technologies, wooden shingles have a certain rustic charm. If you’re curious about how to make them by hand, [Harry Rogers] takes us through his friend [John] making some.

There are two primary means of splitting a log for making shingles (or shakes). The first is radial, like one would cut a pie, and the other is lateral, with all the cuts in the same orientation. Using a froe, the log is split in progressively smaller halves to control the way the grain splits down the length of the log and minimize waste. Larger logs result in less waste and lend themselves to the radial method, while smaller logs must be cut laterally. Laterally cut shingles have a higher propensity for warping and other issues, but will work when larger logs are not available.

Once the pieces are split out of the log, they are trimmed with an axe, including removing the outer sapwood which is the main attractant for bugs and other creatures that might try eating your roof. Once down to approximately the right dimensions, the shingle is then smoothed out on a shave horse with a draw knife. Interestingly, the hand-made shingles have a longer lifespan than those sawn since the process works more with the grain of the wood and introduces fewer opportunities for water to seep into the shingles.

If you’re looking for something more solarpunk and less cottagecore for your house, maybe try a green solar roof, and if you’ve got a glass roof, try cleaning it with the Grawler.

Continue reading “Making Wooden Shingles With Hand Tools”

Linux Fu: Forward To The Past!

Ok, so the title isn’t as catchy as “Back to the Future,” but my guess is a lot of people who are advanced Linux users have — at least — a slight interest in retrocomputing. You’d like an Altair, but not for $10,000. You can build replicas of varying fidelities, of course. You can also just emulate the machine or a similar CP/M machine in software. There are many 8080 or Z80 emulators out there, ranging from SIMH to MAME. Most of these will run on Linux or — at the least — WINE. However, depending on your goals, you should consider RunCPM. Why? It runs on many platforms, including, of course, Linux and other desktop systems. But it also will work with the Arduino, Teensy, ESP32, or STM32 processors. There is also experimental support for SAM4S and Cyclone II FPGAs.

It’s pretty interesting to have one system that will work across PCs and embedded hardware. What’s more is that, at least on Linux, the file system is directly translated (sort of), so you don’t have to use tricks or special software to transfer files to and from CP/M. It is almost like giving Linux the ability to run CP/M software. You still have to have virtual disks, but they are nothing more than directories with normal files in them.

Goals

Of course, if your goal is to simulate a system and you want to have 180 kB floppies or whatever, then the direct file system isn’t a benefit. But if you want to use CP/M software for education, nostalgia, or cross-development, this is the way to go, in my opinion.

It isn’t just the file system, either. If you need a quick utility inside your bogus CP/M environment, you can write it in Lua, at least on desktop systems. On the Arduino, you can access digital and analog I/O. Theoretically, you could deploy an embedded Altair for some real purpose fairly cheaply. Continue reading “Linux Fu: Forward To The Past!”

Illustrated Kristina with an IBM Model M keyboard floating between her hands.

Keebin’ With Kristina: The One With The 200% Typewriter

Image by [jefmer] via Hackaday.IO
You know, the really sad truth about cyberdecks and cyberdeck-adjacent builds is that many of them just end up on the shelf, collecting dust while waiting for the dystopian future. Well, not this one. No, [jefmer] says their Portable Pi sees daily use, and even comes along on the go.

Since [jefmer] is “temperamentally unsuited to 3D printing”, the Pi 4B and its accessories are nestled in a rugged, splash-proof case under some acrylic sheets. One of those accessories, the keyboard, is a KPrepublic BM40 with Gateron Yellows. In order to get used to the number and symbols layer, [jefmer] laid down some great-looking labels above the keyboard.

Although the build started with an SD card for storage, [jefmer] has since upgraded to a 120 GB SSD. This required a beefy battery pack, but the difference is that it gets around four hours of power versus five hours when using an SD card.

Continue reading “Keebin’ With Kristina: The One With The 200% Typewriter”

Hackaday Links Column Banner

Hackaday Links: February 18, 2024

So it turns out that walking around with $4,000 worth of hardware on your head isn’t quite the peak technology experience that some people thought it would be. We’re talking about the recently released Apple Vision Pro headset, which early adopters are lining up in droves to return. Complaints run the gamut from totally foreseeable episodes of motion sickness to neck pain from supporting the heavy headset. Any eyeglass wearer can certainly attest to even lightweight frames and lenses becoming a burden by the end of the day. We can’t imagine what it would be like to wear a headset like that all day. Ergonomic woes aside, some people are feeling buyer’s remorse thanks to a lack of apps that do anything to justify the hefty price tag. The evidence for a wave of returns is mostly gleaned from social media posts, so it has to be taken with a grain of salt. We wouldn’t expect Apple to be too forthcoming with official return figures, though, so the ultimate proof of uptake will probably be how often you spot one in the wild. Apart from a few cities and only for the next few weeks, we suspect sightings will be few and far between.

Continue reading “Hackaday Links: February 18, 2024”

Wireless All The Things!

Neither Tom Nardi nor I are exactly young anymore, and we can both remember a time when joysticks were actually connected with wires to the computer or console, for instance. Back then, even though wireless options were on the market, you’d still want the wired version if it was a reaction-speed game, because wireless links just used to be too slow.

Somehow, in the intervening years, and although we never even really noticed the transition as such, everything has become wireless. And that includes our own hacker projects. Sure, the ESP8266 and other WiFi-capable chips made a big difference, but I still have a soft spot in my heart for the nRF24 chipset, which made at least point-to-point wireless affordable and easy. Others will feel the same about ZigBee, but the point stands: nothing has wires anymore, except to charge back up.

The reason? As this experiment comparing the latency of many different wireless connections bears out, wireless data links have just gotten that good, to the point that the latency in the radio is on par with what you’d get over USB. And the relevant software ecosystems have made it easier to go wireless as well. Except for the extra power requirement, and for cases where you need to move a lot of data, there’s almost no reason that any of your devices need wires anymore.

Are you with us? Will you throw down your chains and go wireless?

Hackaday Podcast Episode 258: So Much Unix, Flipper Flip-out, And The Bus Pirate 5

Hackaday Editors Elliot Williams and Tom Nardi discuss all the week’s best and most interesting hacks and stories, starting with Canada’s misguided ban on the Flipper Zero for being too spooky. From there they’ll look at the state-of-the-art in the sub-$100 3D printer category, Apple’s latest “Right to Repair” loophole, running UNIX on the NES (and how it’s different from Japan’s Famicom), and the latency of various wireless protocols.

After singing the praises of the new Bus Pirate 5, discussion moves on to embedded Linux on spacecraft, artfully lifting IC pins, and the saga of the blue LED. Finally you’ll hear the how and why behind electrical steel, and marvel at a Mach 10 missile that (luckily) never needed to be used.

Grab a copy for yourself if you want to listen offline.

Continue reading “Hackaday Podcast Episode 258: So Much Unix, Flipper Flip-out, And The Bus Pirate 5”

This Week In Security: Filename Not Sanitized, MonikerLink, And Snap Attack!

Reading through a vulnerability report about ClamAV, I came across a phrase that filled me with dread: “The file name is not sanitized”. It’s a feature, VirusEvent, that can be enabled in the ClamnAV config. And that configuration includes a string formatting function, where the string includes %v and %s, which gets replaced with a detected virus name and the file name from the email. And now you see the problem, I hope: The filename is attacker supplied input.

Where this really gets out of hand is what ClamAV does with this string. execle("/bin/sh", "sh", "-c", buffer_cmd, NULL, env). So let’s talk defensive program design for a minute. When it comes to running a secondary command, there are two general options, system() and the exec*() family of system calls. system() is very simple to use. It pauses execution of the main process and asks the operating system to run a string, just as if the user had typed that command into the shell. While this is very convenient to use, there is a security problem if any of that command string is user-supplied. All it takes is a semicolon or ampersand to break assumptions and inject a command.

To the rescue comes exec(). It’s a bit more complicated to use, requiring the programmer to manually call fork() and wait(). But it’s not running the command via the shell. exec() executes a program directly, totally eliminating the potential for command injection! Except… oops.

Yeah, exec() and related calls don’t offer any security protections when you use them to execute /bin/sh. I suspect the code was written this way to allow running a script without specifying /bin/sh in the config. The official fix was to disable the filename format character, and instead supply it as an environment variable. That certainly works, and that fix is available in 1.0.5, 1.2.2, and 1.3.0.

The real danger here is that we have another case where some hardware appliance manufacturer has used ClamAV for email filtering, and uses this configuration by default. That’s how we get orders from CISA to unplug your hardware, because it’s already compromised. Continue reading “This Week In Security: Filename Not Sanitized, MonikerLink, And Snap Attack!”