What Every Geek Must Know

How is it possible that there’s a geek culture? I mean, it’s one thing to assume that all folks of a nerdy enough bent will know a little Ohm’s law, can fake their way through enough quantum mechanics to at least be interesting at a cocktail party, and might even have a favorite mnemonic for the resistor colors or the angles involved in sine, cosine, and tangents. But how is it that we all know the answer to life, the universe, and everything?

Mike and I were podcasting a couple of weeks back, and it came out that he’d never played Starcraft. I was aghast! Especially since he’s into video games in general, to have not played the seminal 3-way-without-being-rock-scissors-paper game! My mind boggled. But then again, there was a time in my life when I hadn’t actually read all of Dune or Cryptonomicon, which would have left Mike’s jaw on the floor.

Whether you prefer Star Trek or Star Wars, the Matrix or the Hobbit, it’s even more surprising that we have so much in common! And thinking about it, I’m pretty sure that exactly our interchange is the reason — it’s a word of mouth culture thing. Some folks at the hackerspace are talking about Cthulu, and chances are you’re going to be reading some Lovecraft. An argument about the plausibility of the hacks in The Martian has sent at least a couple of geeks to the cinema or the library. And so it goes.

So do your part! Share your geek-culture recommendations with us all in the comments. If you were stranded on a desert island, with a decent bookshelf and maybe even a streaming video service, what’s on your top-10 list? What do you still need to see, read, or hear?

Wreck Your Mail Before You Check Your Mail

Every five years or so, I think it’s time to review my e-mail flow. (Oh no!) I run my own mail server, and you should too, but this means that I get to figure out managing and searching and archiving and indexing it all by myself. (Yippee!)

And I’ll be honest — sometimes I’m a bit of a luddite. I actually, literally have been using Mutt, or its derivative NeoMutt for maybe fifteen years, after a decade or so of mouse-intensive graphical mail readers. If e-mail is about typing words, and maybe attaching the occasional image, nothing beats a straight-up text interface. But what a lot of these simple mail clients lack is good search. So I decided to take that seriously.

Notmuch is essentially an e-mail database. It’s an e-mail searcher, tagger, and indexer, but it’s not much else. The nice thing is that it’s brutally fast. Searches and extraction of tagged subsets are faster than sending the same data back and forth to the Big G, and I have a ton more flexibility. It’s awesome. Of course good ol’ Mutt can work with Notmuch. Everything can. It’s Linux/UNIX. Continue reading “Wreck Your Mail Before You Check Your Mail”

Living Robots: Revisiting BEAM

You’re hit by the global IC shortage, reduced to using stone knives and bearskins, but you still want to make something neat? It’s time to revisit BEAM robots.

Biology, electronics, aesthetics, and mechanics — Mark Tilden came up with the idea of minimalist electronic creatures that, through inter-coupled weak control systems and clever mechanical setups, could mimic living bugs. And that’s not so crazy if you think about how many nerves something like a cockroach or an earthworm have. Yet their collection of sensors, motors, and skeletons makes for some pretty interesting behavior.

My favorite BEAM bots have always been the solar-powered ones. They move slowly or infrequently, but also inexorably, under solar power. In that way, they’re the most “alive”. Part of the design trick is to make sure they stay near their food (the sun) and don’t get stuck. One of my favorite styles is the “photovore” or “photopopper”, because they provide amazing bang for the buck.

Back in the heyday of BEAM, maybe 15 years ago, solar cells were inefficient and expensive, circuits for using their small current were leaky, and small motors were tricky to come by. Nowadays, that’s all changed. Power harvesting circuits leak only nano-amps, and low-voltage MOSFETs can switch almost losslessly. Is it time to revisit the BEAM principles? I’d wager you’d put the old guard to shame, and you won’t even need any of those newfangled microcontroller thingies, which are out of stock anyway.

If you make something, show us!

IRC Will Never Die

The big kerfuffle in the open source world this week surrounds the biggest IRC server operator, Freenode. Wherever the dust settles, myriad important open source projects use Freenode’s IRC servers for their main channel of user feedback, and a number of vibrant communities call or called Freenode home. What you would call a 3D printer, and most of the software that drives it, for instance, was brainstormed up in Freenode’s #reprap. If you want help with a Linux distribution, you’ll be set straight within a few minutes in the relevant channel, because the people who wrote, packaged, or maintain it are probably on Freenode waiting to chat.

But suppose Freenode burns to the ground tomorrow, as some are suggesting. So what? My take is that is doesn’t matter. Freenode doesn’t own IRC, setting up an IRC server is essentially trivial, and what’s really important is the online community — they can just pick up and move somewhere else with very little hassle.

This is not to say that we don’t all benefit from the diligence that Freenode’s volunteer administrators and operators have donated to the cause over the years. IRC servers don’t run themselves, and Freenode’s admins fought and won an epic battle with spammers a couple years back. Keeping IRC running at scale is a different thing than setting up something for your friends, and so the Freenode folks definitely deserve our thanks.

But look, IRC is an old protocol and it’s a simple protocol. It’s so simple, in fact, that writing an IRC bot is just a few dozen lines in Python, using no external libraries. All you need to do is send plain text over a socket. You can do this — it makes a great networking hello world.

IRC is fun for hackers, but if you want a user-friendly GUI client, you ridiculously many to choose from. There are even no-install web clients if you just want to dip your toes in. Heck, you could install your own server in an hour or so.

So saying that the demise of Freenode is the end of IRC is a lot like saying that the end of Hotmail was the end of e-mail. In the grand scheme of things, almost nobody actually uses IRC — Freenode has 78,000 users while Slack has 10 million — and IRC users are very savvy, if not full-on geeky. These are the sort of people who can probably find the server field in a menu and change it from irc.freenode.net to irc.whatever.org.

In addition to our traditional #hackaday channel on irc.freenode.net, there’s also a channel set up on irc.libera.chat as well. There isn’t much action in either — IRC tends to be a slow conversation, so don’t freak out if someone responds to you an hour later — but if you want to swing by, we’re there. IRC will never die!

2021 Hackaday Prize Begins!

If you missed our announcement, this year’s Hackaday Prize is on! We’ve all had a rough year and a half, and it’s lead a lot of us to think seriously about our world. How would you want to change it going forward? Fifty entrants will rethink, refresh, and rebuild their way into $500, and the Grand Prize is $25,000. Get hacking!

Should I Automate This?

The short answer to the question posed in the headline: yes.

For the long answer, you have to do a little math. How much total time you will save by automating, over some reasonable horizon? It’s a simple product of how much time per occurrence, times how many times per day it happens, times the number of days in your horizon. Or skip out on the math because there’s an XKCD for that.

What’s fun about this table is that it’s kind of a Rorschach test that gives you insight into how much you suffer from automatitis. I always thought that Randall was trying to convince himself not to undertake (fun) automation projects, because that was my condition at the time. Looking at it from my current perspective, it’s a little bit shocking that something that’ll save you five seconds, five times a day, is worth spending twelve hours on. I’ve got some automating to do.

To whit: I use pass as my password manager because it’s ultimately flexible, simple, and failsafe. It stores passwords on my hard drive, and my backup server, encrypted with a GPG key that I have printed out on paper in a fireproof safe. Because I practice good cookie hygiene, I end up re-entering my passwords daily. Because I keep my passwords separate from my browser, that means entering username and password by cut-and-paste. There’s your five seconds, five times per day. Maybe two seconds, ten times, but it’s all the same. It shouldn’t take me even as long as twenty minutes to whip up a script that puts username and password into selection and clipboard for one-click pasting. Why haven’t I done this yet? I’m going to get on it as soon as I’m done with this newsletter.

But the this begs the question. If you spend up to twelve hours on every possible 25-second-per-day savings, when will you ever get your real work done? Again, math gives us the answer. One eight-hour workday * 25 seconds * 12 hours (pessimistically) of labor = 1.58 years before everything that needs automating will be. Next week’s newsletter might be a little bit delayed.

What do you see in the XKCD “Is it worth the time” table? Automate more, or step back from the cliff edge?

Reinventing The Wheel

You’ve got a perfectly working software library to do just exactly what you want. Why aren’t you using it? Some of you are already yelling something about NIH syndrome or reinventing the wheel — I hear you. But at least sometimes, there’s a good enough reason to reinvent the wheel: let’s say you want to learn something.

Mike and I were talking about a cool hack on the podcast: a library that makes a floppy drive work with an Arduino, and even builds out a minimalistic DOS for it. The one thing that [David Hansel] didn’t do by himself was write the FAT library; he used the ever-popular FatFS by [Elm-ChaN]. Mike casually noted that he’s always wanted to write his own FAT library from scratch, just to learn how it works at the fundamental level, and I didn’t even bat an eyelash. Heck, if I had the time, I’d want to do that too!

Look around on Hackaday, and you’ll see tons of hacks where people reinvent the wheel. In this superb soundbar hack, [Michal] spends a while working on the IR protocol by hand until succumbing to the call of IRMP, a library that has it all done for you. But if you read his writeup, he’s not sad; he learned something about IR protocols. This I2C paper tape reader is nothing if not a reinvention of the I2C wheel, but isn’t that the best way to learn?

Yes it is. Think back to the last class you took. The teacher or professor certainly explained something to you in reasonable detail — that’s the job after all. And then you got some homework to do by yourself, and you did it, even though you were probably just going over the same stuff that the prof and countless others have gone through. But by doing it yourself, even though it was “reinventing the wheel”, you learned the material. And I’d wager that you wouldn’t have learned it without.

Of course, when the chips are down and the deadline is breathing hot down your neck, that might be the right time to just include that tried-and-true library. But if you really want to learn something yourself, you have every right to reinvent the wheel.

If You Can Measure It, You Must Display It

When can you be sure that you’re logging enough data? When you’re logging all of the data! Of course there are exceptions to the above tongue-in-cheek maxim, but it’s certainly a good start. Especially since data storage on, for instance, an SD card is so easy and cheap these days, there’s almost no reason to not record most every little bit of data that your project can produce. Even without an SD card, many microcontrollers have enough onboard flash, or heck even RAM, to handle whatever you throw at them. The trick, then, is to make sense out of that data, and for me at least, that often means drawing pretty pictures.

I was impressed this week by a simple but elegant stepper motor diagnosis tool hacked together by [Zapta]. Essentially, it’s a simple device: it’s a “Black Pill” dev board, two current sensors, an EEPROM for storing settings, and a touchscreen. Given that most of us with 3D printers rely on stepper motors to get the job done, it’s certainly interesting to do some diagnostics.

By logging voltage and current measurement on each phase of a stepper motor, you can learn a lot about what’s going on, at least if you can visualize all that data. And that’s where [Zapta]’s tool shines. It plots current vs motor speed to detect impedance problems. Tuning the current in the first place is a snap with Lissajous patterns, and it’ll track your extruder’s progress or look out for skipped steps for you across an entire print job. It does all this with many carefully targeted graphs.

I was talking to [Niklas Roy] about this, and he said “oh check out my hoverboard battery logger“. Here we go again! It sits inline with the battery and logs current and voltage, charging or discharging. Graphs let you visualize power usage over time, and a real-time-clock lets you sync it with video of using the hoverboard to help make even more sense of the data.

So what are you waiting for? Sensors are cheap, storage is cheap, and utilities to graph your data after the fact are plentiful. If you’re not logging all the relevant data, you’re missing out on some valuable insights. And if you are, we’d love to see your projects! (Hint, hint.)