Networking History Lessons

January 25, 2025 by Elliot Williams 34 Comments

Do they teach networking history classes yet? Or is it still too soon?

I was reading [Al]’s first installment of the Forgotten Internet series, on UUCP. The short summary is that it was a system for sending files across computers that were connected, intermittently, by point-to-point phone lines. Each computer knew the phone numbers of a few others, but none of them had anything like a global routing map, and IP addresses were still in the future. Still, it enabled file transfer and even limited remote access across the globe. And while some files contained computer programs, others files contained more human messages, which makes UUCP also a precursor to e-mail.

What struck me is how intuitively many of this system’s natural conditions and limitations lead to the way we network today. From phone numbers came the need for IP addresses. And from the annoyance of having know how the computers were connected, and to use the bang notation to route a message from one computer to another through intermediaries, would come our modern routing protocols, simply because computer nerds like to automate hassles wherever possible.

But back to networking history. I guess I learned my networking on the mean streets, by running my own Linux system, and web servers, and mail servers. I knew enough networking to get by, but that mostly focused on the current-day application, and my beard is not quite grey enough to have been around for the UUCP era. So I’m only realizing now that knowing how the system evolved over time helps a lot in understanding why it is the way it is, and thus how it functions. I had a bit of a “eureka” moment reading about UUCP.

In physics or any other science, you learn not just the status quo in the field, but also how it developed over the centuries. It’s important to know something about the theory of the aether to know what special relativity was up against, for instance, or the various historical models of the atom, to see how they inform modern chemistry and physics. But these are old sciences with a lot of obsolete theories. Is computer science old enough that they teach networking history? They should!

Learn New Tools, Or Hone Your Skill With The Old?

January 18, 2025 by Elliot Williams 42 Comments

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?

In Praise Of Simple Projects

January 11, 2025 by Elliot Williams 34 Comments

Hackaday was at Chaos Communication Congress last week, and it’s one of those big hacker events that leaves you with so much to think about that I’m still processing it. Just for scope, the 38th CCC is a hacker event with about 15,000 attendees from all around Europe, and many from even further. If I were to characterize the crowd on a hardware-software affinity scale, I would say that it skews heavily toward the software side of the hacker spectrum.

What never ceases to amaze me is that there are a couple of zones that are centered on simple beginner soldering and other PCB art projects that are completely full 20 hours of the day. I always makes me wonder how it is possible to have this many hackers who haven’t picked up a soldering iron. Where do all these first-timers come from? I think I’m in a Hackaday bubble where not only does everyone solder at least three times a day, some of us do it with home-made reflow ovens or expensive microscopes.

But what this also means is that there’s tremendous reach for interesting, inviting, and otherwise cool beginner hardware projects. Hands-on learning is incredibly addictive, and the audience for beginner projects is probably ten times larger than that for intermediate or advanced builds. Having watched my own son putting together one of these kits, I understand the impact they can have personally, but it’s worth noting that the guy next to him was certainly in his mid-30s, and the girl across the way was even a few years younger than my son.

So let’s see some cool beginner projects! We’d love to feature more projects that could lure future hackers to the solder-smoky side.

Hacker Tools, Hacked Tools

December 14, 2024 by Elliot Williams 2 Comments

We just love a good DIY tool project, and more so when it’s something that we can actually use cobbled together from stuff in our closet, or hacked out of cheap “toys”. This week we saw both a superb Pi Pico-based logic analyzer and yet another software frontend for the RTL-SDR dongle, and they both had us thinking of how good we have it.

If you don’t already have a logic analyzer, or if you have one of those super-cheap 8-channel jobbies, it might be worth your while to check out the Pico firmware simply because it gets you 24 channels, which is more than you’ll ever need™. At the low price of $4, maybe a little more if you need to add level shifters to the circuit to allow for 5 V inputs, you could do a lot worse for less than the price of a fancy sweet coffee beverage.

And the RTL dongle; don’t get us started on this marvel of radio hacking. If you vaguely have interest in RF, it’s the most amazing bargain, and ever-improving software just keeps adding functionality. The post above adds HTML5 support for the RTL-SDR, allowing you to drive it with code you host on a web page, which makes the entire experience not only cheap, but painless. Talk about a gateway drug! If you don’t have an RTL-SDR, just go out and buy one. Trust me.

What both of these hacker tools have in common, of course, is good support by a bunch of free and open software that makes them do what they do. This software enables a very simple piece of hardware to carry out what used to be high-end lab equipment functions, for almost nothing. This has an amazing democratizing effect, and paves the way for the next generation of projects and hackers. I can’t think of a better way to spend $20.

Tis The Season

December 7, 2024 by Elliot Williams 16 Comments

’Tis the season for soldering! At least at my house. My son and I made some fairly LED-laden gifts for the immediate relatives last year, and he’s got the blinky bug. We were brainstorming what we could make this year, and his response was “I don’t care, but it needs to have lots of LEDs”.

It’s also the season for reverse engineering, apparently, because we’re using a string of WS2812-alike “fairy lights”. These are actually really neat, they look good and are relatively cheap. It’s a string of RGB LEDs with drivers, each dipped in epoxy, and run on a common three-enameled-wire bus. Unlike WS2812s, which pass the data on to the next unit in the line and then display them with a latching pulse at the end of a sequence, these LED drivers seem to count how many RGB packets have been sent down the wire, and only respond to their own number.

This means that if you cut up a string of 200 LEDs, it behaves like a string of 200 WS2812s. But if you cut say 10 LEDs off the string, where you cut them matters. If you cut it off the front of the string, you only have to send 10 color packets. If you cut them off the other end, you need to send 290 dummy packets before they even start listening. Bizarre, but ’tis the season for bizarre hacks.

And finally, ’tis the season for first steps into “software architecture”. Which is to say that my son is appreciating functions for the first time in his life. Controlling one LED is easy, but making a light show is about two more abstraction layers on top of that. We’ve been having fun making them dim, twinkle, and chase so far. We only have two more weekends, though, and we don’t have a final light show figured out yet, but after all, ’tis the season for last minute present hacking.