Making The Osmo Pocket 4 A More Serious Camera

The Osmo Pocket 4 is a handheld gimballed camera that’s perfect for shooting running content on the go. However, it’s got a weird sort of form factor and is limited when it comes to things like fitting filters or recording quality sound. To that end, [Byron Seven] whipped up an upgrade kit that turns the Pocket 4 into more of a “real” camera.

The idea is simple enough—the Osmo Pocket 4 is packaged in a 3D printed shell that expands its capabilities. It’s tucked into the structure with a USB power bank that greatly increases how long you can shoot before the batteries run out. In front of the gimbal head, there’s a fitting that allows attaching standard camera filters for visual effect. Topside there’s a handle for better physical control of the camera, along with a rail mount for a DJI wireless mic and a phone to act as a monitor. Down below, there’s a quick-connect fitting so the camera can be slammed on and off a tripod with ease. What’s great is that you can slot a Pocket 4 into this rig when you need, and pull it back out and use it as normal when you’re done.

If you’ve enjoyed the Osmo Pocket 4 but wished you could throw a polarizer on it or chuck it around more, this is a great build to explore. We’ve seen some fun stuff done with non-traditional cameras before, too.

Continue reading “Making The Osmo Pocket 4 A More Serious Camera”

Jenny’s Daily Drivers: Going 32-Bit With SliTaz In 2026

We’re used to seeing technologies move with the times, and it’s likely among Hackaday readers are the group who spend the most time doing that and are most aware of it. There’s one which we’ll all be aware of which has quietly slipped away for most of us almost without a word, I speak of course of 32-bit computing. For most of us that means 32-bit computing on x86 machines, and since the 64-bit x86 instruction set we all now use has been around for nearly a quarter century, its 32-bit ancestor is now ancient history.

In the world of software that means we’re now in an era of operating systems and browsers dropping 32-bit support, so increasingly keeping a 32-bit machine up to date will become a challenge. That sounds like something just painful and difficult enough to subject to a Daily Drivers piece, so just how practical is it to use a 32-bit machine for my daily work in 2026?

2005 Just Gave Me A Computer

My trusty Dell, showing the SliTaz desktop
Not looking too bad for a 21 year old laptop.

On my desk I have a Dell Latitude D610. It was made in about 2005 in the days when Dells were solidly made, and with its 1.6GHz Pentium M and 2Gb of memory it represents roughly the final throw of the dice for a 32-bit Intel laptop. Just over a year later it would have been replaced by one of the Intel Core series with the 64-bit instructions grudgingly adopted from AMD, but at the time it was a respectably useful machine.

It came into my possession about eight years ago when I used it to test the Revbank bar tab software for my hackerspace, and for the past six years it’s languished unloved in my box there. It’s got an ancient Ubuntu distro on it, so my first task is to pick a 32-bit replacement from 2026. That’s now a dwindling selection, so it’s time to start digging though some minimalist distros. With the supply of those based on mainstream distros drying up as they drop 32-bit support, it’s time to look into more esoteric offerings. This fits well with the ethos of this series, we’re all about the unusual here.

Cutting out the mainstream based distros certainly narrows the field, and out of the promising contenders in the minimalist field, I went for SliTaz. It uses Busybox and the Openbox desktop, that runs from RAM. I was looking for good application support in the repos, and this distro has the things I need. Download it, stick it on a USB stick, and let’s see what it can do. I know one thing, I wouldn’t have been able to download that ISO in five seconds with the internet connection I had in 2005. Continue reading “Jenny’s Daily Drivers: Going 32-Bit With SliTaz In 2026”

A Tractor From A Small Town Might Just Be The Catalyst For Ousting Machinery DRM

Odd things sometimes pop up in the feed of a Hackaday scribe, not hacks as such, but stories with a meaning in our community. One such that’s come our way from a variety of sources over the last week features Ursa Ag, a small machinery manufacturer based in Alberta, Canada. The reason they’re in the news is because they have gained bulging order books by taking on the likes of John Deere with a tractor more like the one their customers’ parents bought back in the ’80s or ’90s. It’s a basic machine without much in the way of electronics, and certainly without all the DRM lockdown that has made those big manufacturers so unpopular.

It’s clear that Hackaday isn’t in the business of shilling Canadian tractors, but it should be of interest to readers because it represents an alternative route to challenge the DRM lockdowns than the legal and consumer routes we’ve previously reported on. The Ursa Ag tractor may be as niche Albertan as a Corb Lund CD, but it’s not the tractor itself but the idea which matters. We doubt much sweat will be shed by John Deere execs over a tiny company out on the prairies making a basic spec tractor, but given that Ursa Ag customers are reported as buying them because they have no DRM, the prospect of larger upstart competitors taking note and offering machines without it may cause them some sleep loss. The free market is held up to outsiders as perhaps the most American of ideals, and for it to eventually prove to be the means by which something intended to limit it might be defeated, is sweet justice indeed.

We’ve reported extensively on the Deere tractor saga over the years, but perhaps the best illustration of the self-inflicted damage the brand has suffered through DRM comes in their older products being worth considerably more than their newer ones.

How TTY Opened Up The Phones For The Hard Of Hearing

The telephone was an invention that revolutionized human communication. No more did you have to physically courier a letter from one place to another, or send a telegram, or have a runner carry the message for you. Instead, you could have a direct conversation with another person a great distance away. All well and good if you can speak and hear, of course, but rather useless if you happen to be deaf.

Those hard of hearing were not left entirely out of the communication revolution, however. Well before IP switched networks and the Internet became a thing, there was already a way for the deaf to communicate over the plain old telephone network—thanks to the teletypewriter!

Over The Wires

The teletypewriter (TTY) has been around for a long time. The first device came into being in 1964, developed by James C. Marsters and Robert Weitbrecht, both deaf. Their idea was to create a method for deaf individuals to communicate over the phone network in a textual manner. To this end, the group sourced teleprinters formerly used by the US Department of Defense, and hooked them up with acoustic couplers that would allow them to mate with the then-ubiquitous AT&T Model 500 telephone. Thus, the TTY was born. A user could dial another TTY machine, and key in a message, which would print out at the other end. The receiving user could then respond in turn in the same manner.

Continue reading “How TTY Opened Up The Phones For The Hard Of Hearing”

Transcribing The Source Of The First DOS For The IBM PC

Doing software archaeology can be a harrowing task, as rarely do you find complete snapshots of particular versions of software. Case in point the development of MS-DOS – also known as IBM PC DOS – from 86-DOS, which recently got a lucky break in the form of printed source listings. These printouts come courtesy of [Tim Paterson], the creator of 86-DOS and of MS-DOS during his time working for Microsoft.

These code listings contain the sources of the 86-DOS 1.00 kernel, multiple development snapshots, and also listings for utilities like CHKDSK. These printed listings additionally contain many handwritten notes, making transcribing it into working source code somewhat of a chore. The results can be found on the GitHub project page, with the original scans available on Archive.org.

Of the ten bundles of continuous feed paper prints all but two have been transcribed so far, though with the various DOS kernels and the Seattle Computer Products (SCP) assembler source already ready for compilation. This includes 86-DOS 1.00, MS-DOS 1.25 and PC-DOS 1.00-dev, requiring the same SCP assembler to create a binary.

In the project page README a number of blog posts are also linked that add even more technical detail. Anyone who wants to pitch in with transcribing and/or testing recovered source code is welcome to do so.

Building An X86 Gaming PC Without Intel, NVIDIA Or AMD Parts

This is an interesting challenge from the “why not?” files — [GPUSpecs] over on YouTube built a gaming PC without using a single component from NVIDIA, Intel, or AMD. That immediately makes us think of the high-power ARM workstations or perhaps even perhaps the new “AI workstations” coming available with RISC V architecture, but the challenge here was specifically “gaming PC,” not workstation. A gaming PC, without a GPU by one of those three? To make it even more interesting, the x86 CPU isn’t Intel or AMD either.

If you’re of a certain vintage, you may remember Cyrix. Cyrix reverse-engineered the x86 ISA and made their own compatible chips in the 90s, before being bought out by National Semiconductor, and then VIA Technologies. VIA partnered with the Government of Shanghai to found Zhaoxin, and it is from Zhaoxin that the KaiXian KX 7000 CPU hails — an x86-64 device, that isn’t Intel or AMD. We’ve actually covered the company before. This particular chip benchmarks like an old i5, so not spectacular, but usable. 

Continue reading “Building An X86 Gaming PC Without Intel, NVIDIA Or AMD Parts”

Network Scanner Finds Every Raspberry Pi

DHCP is great for getting machines on the network with a minimum of fuss. However, it can also make remote administration a pain because you never know which IP you’re supposed to be SSHing into. [Philipp] ran into this problem quite often, so decided to whip up an app to make things easier. 

At it’s heart, the app is a simple network scanner—of which many already exist. However, [Philipp] had found that many options on Android were peppered with ads that made them highly undesirable to use. Thus, he whipped up his own, with a particular eye to working with the Raspberry Pi. It’s not uncommon for a hacker to have a few scattered around the home network, and it can be a real chore keeping track of where they all end up in IP land. The scanner can specifically single out the Raspberry Pi boards on the network via MAC-OUI and mDNS detection. Plus, just in case you need it, [Philipp] threw in some GPIO pinouts and electronics calculators just to make the app more useful.

If you’ve been looking for an open-source network scanner without all the ugly junk, this project might just be for you. You can also check out the source over on Github if that’s relevant to your interests. We’ve seen some interesting custom network scanners before, too. If you’re whipping up some fun packet-flinging software of your own, don’t hesitate to notify the tipsline!