This week, Jonathan Bennett and Dan Lynch chat with Stefano Zacchiroli about Debian and Software Heritage!
Continue reading “FLOSS Weekly Episode 817: Incompatible With Reality”
Slider4509 Articles
Mining And Refining: The Halogens
I was looking at the periodic table of the elements the other day, as one does, when my eye fell upon the right-hand side of the chart. Right next to the noble gases at the extreme edge of the table is a column of elements with similar and interesting properties: the halogens. Almost all of these reactive elements are pretty familiar, especially chlorine, which most of us eat by the gram every day in the form of table salt. As the neighborhoods of the periodic table go, Group 17 is pretty familiar territory.
But for some reason, one member of this group caught my attention: iodine. I realized I had no idea where we get iodine, which led to the realization that apart from chlorine, I really didn’t know where any of the halogens came from. And as usual, that meant I needed to dig in and learn a little bit about the mining and refining of the halogens. At least most of them; as interesting as they may be, we’ll be skipping the naturally occurring but rare and highly radioactive halogen astatine, as well as the synthetic halogen tennessine, which lives just below it in the group.
Keebin’ With Kristina: The One With The Hardware-Layered Keyboard
You know (or maybe you didn’t), I get super excited when y’all use the links at the bottom of this round-up we call Keebin’ to communicate with your old pal Kristina about your various labors of love. So just remember that.
Case in point: I was typing up this very issue when I heard from [Jay Crutti] and [Marcel Erz]. Both are out there making replacement keyboards for TRS-80s — [Jay] for Models 3 and 4, and [Marcel] for the Model 1. Oooh, I said to myself. This is going at the top.
I think the TRS-80 is probably the one I miss the most. If I still had it, you can bet I would be using [Jay] and [Marcel]’s work to build my own replacement keyboard, which the 40-year-old machine would likely need at this point if the Model 4 is any indication with its failing keyboard contacts.
To create the replacements, [Jay] used Keyboard Layout Editor (KLE), Plate & Case Builder, and EasyEDA. Using the schematic from the maintenance manual, he matched the row/column wiring of the original matrix with Cherry MX footprints. Be sure to check out [Jay]’s site for a link to the project files, or to purchase parts or an assembled keyboard. On the hunt for TRS-80 parts in general? Look no further than [Marcel]’s site.
Continue reading “Keebin’ With Kristina: The One With The Hardware-Layered Keyboard”
Time-of-Flight Sensors: How Do They Work?
If you need to measure a distance, it is tempting to reach for the ubiquitous ultrasonic module like an HC-SR04. These work well, and they are reasonably easy to use. However, they aren’t without their problems. So maybe try an IR time of flight sensor. These also work well, are reasonably easy to use, and have a different set of problems. I recently had a project where I needed such a sensor, and I picked up a TF-MiniS, which is a popular IR distance sensor. They aren’t very expensive, and they work serial or I2C. So how did it do?
The unit itself is tiny and has good specifications. You can fit the 42 x 15 x 16 mm module anywhere. It only weighs about five grams — as the manufacturer points out, less than two ping-pong balls. It needs 5 V but communicates using 3.3 V, so integration isn’t much of a problem.
At first glance, the range is impressive. You can read things as close as 10 cm and as far away as 12 m. I found this was a bit optimistic, though. Although the product sometimes gets the name of LiDAR, it doesn’t use a laser. It just uses an IR LED and some fancy optics.
Continue reading “Time-of-Flight Sensors: How Do They Work?”
Hackaday Links: January 19, 2025
This week, we witnessed a couple of space oopsies as both Starship and New Glenn suffered in-flight mishaps on the same day. SpaceX’s Starship was the more spectacular, with the upper stage of the seventh test flight of the full stack experiencing a “rapid unscheduled disassembly” thanks to a fire developing in the aft section of the stage somewhere over the Turks and Caicos islands, about eight and a half minutes after takeoff from Boca Chica. The good news is that the RUD happened after first-stage separation, and that the Super Heavy booster was not only able to safely return to the pad but also made another successful “chopsticks” landing on the tower. Sorry, that’s just never going to get old.
On the Bezos side of the billionaire rocket club, the maiden flight of Blue Origin’s New Glenn ended with the opposite problem. The upper stage reached orbit, but the reusable booster didn’t make it back to the landing barge parked off the Bahamas. What exactly happened isn’t clear yet, but judging by the telemetry the booster was coming in mighty fast, which may indicate that the engines didn’t restart fully and the thing just broke up when it got into the denser part of the atmosphere.
Learn New Tools, Or Hone Your Skill With The Old?
Buried in a talk on AI from an artist who is doing cutting-edge video work was the following nugget that entirely sums up the zeitgeist: “The tools are changing so fast that artists can’t keep up with them, let alone master them, before everyone is on to the next.” And while you might think that this concern is only relevant to those who have to stay on the crest of the hype wave, the deeper question resounds with every hacker.
When was the last time you changed PCB layout software or refreshed your operating system? What other tools do you use in your work or your extra-curricular projects, and how long have you been using them? Are you still designing your analog front-ends with LM358s, or have you looked around to see that technology has moved on since the 1970s? “OMG, you’re still using ST32F103s?”
It’s not a simple question, and there are no good answers. Proficiency with a tool, like for instance the audio editor with which I crank out the podcast every week, only comes through practice. And practice simply takes time and effort. When you put your time in on a tool, it really is an investment in that it helps you get better. But what about that newer, better tool out there?
Some of the reluctance to update is certainly sunk-cost fallacy, after all you put so much sweat and tears into the current tool, but there is also a real cost to overcome to learn the new hotness, and that’s no fallacy. If you’re always trying to learn a new way of doing something, you’re never going to get good at doing something, and that’s the lament of our artist friend. Honing your craft requires focus. You won’t know the odd feature set of that next microcontroller as well as you do the old faithful – without sitting down and reading the datasheet and doing a couple finger-stretching projects first.
Striking the optimal balance here is hard. On a per-project basis, staying with your good old tool or swapping to the new hotness is a binary choice, but across your projects, you can do some of each. Maybe it makes sense to budget some of your hacking time into learning new tools? How about ten percent? What do you think?
Forgotten Internet: UUCP
What’s Forgotten Internet? It is the story of parts of the Internet — or Internet precursors — that you might have forgotten about or maybe you missed out on them. This time, we’re looking at Unix-to-Unix Copy, more commonly called UUCP. Developed in the late 1970s, UUCP was a solution for sending messages between systems that were not always connected together. It could also allow remote users to execute commands. By 1979, it was part of the 7th Edition of Unix.
Operation was simple. Each computer in a UUCP network had a list of neighbor systems. Don’t forget, they weren’t connected, so instead of an IP address, each system had the other’s phone number to connect to a dial up modem. You also needed a login name and password. Almost certainly, by the way, those modems operated at 300 baud or less.
If a computer could dial out, when someone wanted to send something or do a remote execution, the UUCP system would call a neighboring computer. However, some systems couldn’t dial out, so it was also possible for a neighbor to call in and poll to see if there was anything you needed to do. Files would go from one system to another using a variety of protocols.
