For as long as there have been machines, there have been fears of machines taking your job. One of the latest incarnations of this phenomenon is the fast-food ordering kiosk. No longer will you have some teenager asking you if you want fries with that. These days, you are more likely going to find the question on a touch screen. So, are those poor kids out of an entry-level job? Apparently not, according to a recent CNN story.
According to McDonald’s, a business that embraces the kiosks, the new technology increases sales and creates more jobs, albeit more jobs further behind the counter. Part of the reason is that while “Do you want fries with that” is a cliche, it is also a sound business practice. Cashiers should try to upsell but don’t always do so. The kiosk always remembers to offer you an apple pie or whatever else they want to move today.
Raw network sockets are a curious beasts, as unless you have a strong urge to implement your own low-level network protocol, it’s a topic that is probably best left to the (well-paid) experts. That said, you can totally use raw sockets in virtually every operating system, but one should be aware of a few things, the lack of portability being one of them. This is what tripped [Swagnik] up while trying to write a low-level network ping (ICMP) utility, by reading the Linux socket documentation while testing on MacOS. It’s all BSD-style sockets, after all, right?
As it turns out, the network stacks in Linux and MacOS have some subtle differences, which become apparent when you read the friendly manuals. For Linux, the raw(7) man entry for IPv4 sockets make it clear that the IP_HDRINCL socket option is default by default for IPPROTO_RAW sockets. This is different from MacOS, which is effectively FreeBSD with glossy makeup. Like FreeBSD, the MacOS man page makes it clear that the IP_HDRINCL option is not set by default.
So that’s easy, right? Just fire off a setsockopt() call on the raw socket and that’s done. Not quite. The Linux man page notes that it cannot receive all IP protocols, while the FreeBSD/MacOS version makes no such exceptions. There is also the issue of endianness, which is where [Swagnik]’s blog post seems to err. The claim is that on MacOS the received IPv4 raw socket header is in host (little endian) order, while the documentation clearly notes that these are in network (big endian) order, which the blog post also shows.
Where things get really fun is when moving from IPv4 raw sockets to IPv6 raw sockets, as [Michael F. Schönitzer] covered for Linux back in 2018 already. IPv6 raw sockets drop IP_HDRINCL and requires a whole different approach. The endianness also changes, as IPv6 raw sockets under Linux must send and will receive data in network byte order, putting it in line with FreeBSD raw sockets.
Although Linux runs almost every supercomputer, most of the web, the majority of smart phones, and a few writers’ ancient Macbooks, there’s one major weak point in the Linux world that will almost always have developers reaching for a different operating system. Linux is not a real-time operating system (RTOS), meaning that it can’t respond to requests in the real world within a set timeframe. This means that applications needing computer control in industry, medicine, robotics, and other real-world situations generally need a purpose-built RTOS. At least, that was true until recently when an update to the Linux kernel added real-time capabilities.
The feature, called PREEMPT_RT, forces the Linux kernel to respond to certain request within a set limit of time. This means that a system with this support built into the kernel can “preempt” any current task, stopping everything else a computer is doing in order to execute that task right away. There are some existing solutions to getting a functional equivalent system working with Linux now, but they can be clunky or inelegant, requiring the user to install patches or other software to get it to work. With the support built directly into the kernel this will become much less of a pain point for anyone who needs this functionality going forward.
When are jumper wires on a breadboard entirely optional? When it’s the latest version of [Kevin Santo Cappuccio]’s Jumperless, which uses a bunch of analog crosspoint switches (typically used for handling things like video signals) to create connections instead of physical wires. There’s even an RGB LED under each hole capable of real-time visualization of signals between components.
If this looks a bit familiar, that’s because an earlier version took second place in the 2023 Hackaday Prize. But things have evolved considerably since then. There are multiple programmable power rails, ADC channels, a rotary encoder, and much more. The PCB design itself is fantastic, including the probe which acts like a multi-function tool for interacting with the whole thing. The newest version will make its debut on Crowd Supply in just a few days.
It’s open source and made to be hackable, so give the GitHub repository a look if you want a closer peek. You can watch it in action in a brief video posted to social media, embedded below.
A while back we got an anonymous complaint that Hackaday was “elitist”, and that got me thinking. We do write up the hacks that we find the coolest, and that could lead to a preponderance of gonzo projects, or a feeling that something “isn’t good enough for Hackaday”. But I really want to push back against that notion, because I believe it’s just plain wrong.
One of the most important jobs of a Hackaday writer is to find the best parts of a project and bring that to the fore, and I’d like to show you what I mean by example. Take this post from two weeks ago that was nominally about rescuing a broken beloved keyboard by replacing its brain with a modern microcontroller. On its surface, this should be easy – figure out the matrix pinout and wire it up. Flash in a keyboard firmware and you’re done.
Of course we all love a good hardware-rescue story, and other owners of busted Sculpt keyboards will be happy to see it. But there’s something here for the rest of us too! To figure out the keyboard matrix, it would take a lot of probing at a flat-flex cable, so [TechBeret] made a sweet breakout board that pulled all the signals off of the flat-flex and terminated them in nicely labelled wires. Let this be your reminder that making a test rig / jig can make these kind of complicated problems simpler.
Checking the fit with a 3D printed PCB
Once the pinout was figured out, and a working prototype made, it was time to order a neat PCB and box it up. The other great trick was the use of 3D-printed mockups of the PCBs to make sure that they fit inside the case, the holes were all in the right places, and that the flat-flex lay flat. With how easily PCB design software will spit out a 3D model these days, you absolutely should take the ten minutes to verify the physical layout of each revision before sending out your Gerbers.
So was this a 1337 hack? Maybe not. But was it worth reading for these two sweet tidbits, regardless of whether you’re doing a keyboard hack? Absolutely! And that’s exactly the kind of opportunity that elitists shut themselves off from, and it’s the negative aspect of elitism what we try to fight against here at Hackaday.
This article is part of the Hackaday.com newsletter, delivered every seven days for each of the last 200+ weeks. It also includes our favorite articles from the last seven days that you can see on the web version of the newsletter.
Want this type of article to hit your inbox every Friday morning? You should sign up!
Nothing can ruin a restoration project faster than broken knobs. Sure, that old “boat anchor” ham rig will work just fine with some modern knobs, but few and far between are the vintage electronics buffs that will settle for such aesthetic affrontery. But with new old stock knobs commanding dear prices, what’s the budget-conscious restorationist to do? Why, fix the cracked knobs yourself, of course.
At least that’s what [Level UP EE Lab] tried with his vintage Heahkit DX60 ham transmitter, with pretty impressive results. The knobs on this early-60s radio had all cracked thanks to years of over-tightening the set screws. To strengthen the knobs, he found some shaft collars with a 1/4″ inside diameter and an appropriate set screw. The backside of the knob was milled out to make room for the insert, which was then glued firmly in place with everyone’s go-to adhesive, JB Weld. [Level UP] chose the “Plastibonder” product, which turns out not to be an epoxy but rather a two-part urethane resin, which despite some initial difficulties flowed nicely around the shaft collar and filled the milled-out space inside the knob. The resin also flowed into the channels milled into the outside diameter of the shaft collars, which are intended to grip the hardened resin better and prevent future knob spinning.
It’s a pretty straightforward repair if a bit fussy, but the result is knobs that perfectly match the radio and still have the patina of 60-plus years of use. We’ll keep this technique in mind for our next restoration, or even just an everyday repair. Of course, for less demanding applications, there are always 3D printed knobs.
It’s not uncommon for a new distro version to come out, and a grudging admission that maybe a faster laptop is on the cards. Perhaps after seeing this project though, you’ll never again complain about that two-generations-ago 64-bit multi-core behemoth, because [Dimitri Grinberg] — who else! — has succeeded in booting an up-to-date Linux on the real most basic of processors. We’re not talking about 386s, ATmegas, or 6502s, instead he’s gone right back to the beginning. The Intel 4004 was the first commercially available microprocessor back in 1971, and now it can run Linux.
So, given the 4004’s very limited architecture and 4-bit bus, how can it perform this impossible feat? As you might expect, the kernel isn’t being compiled to run natively on such ancient hardware. Instead he’s achieved the equally impossible-sounding task of writing a MIPS emulator for the venerable silicon, and paring back the emulated hardware to the extent that it remains capable given the limitations of the 1970s support chips in interfacing to the more recent parts such as RAM for the MIPS, an SD card, and a VFD display. The result is shown in the video below the break, and even though it’s sped up it’s clear that this is not a quick machine by any means.
