Too Many Pixels

January 14, 2023 by Elliot Williams 39 Comments

Sometimes simpler is more impressive than complicated, and part of this is certainly due to Arthur C. Clarke’s third law: “Any sufficiently advanced technology is indistinguishable from magic.”. It’s counter-intuitive, though, that a high-tech project would seem any less amazing than a simpler one, but hear me out.

I first noticed this ages ago, when we were ripping out the blue laser diodes from Casio XJ-A130 laser projectors back when this was the only way to get a powerful blue laser diode. Casio had bought up the world’s supply of the 1.5 W Nichias, and was putting 24 of them in each projector, making them worth more dead than alive, if you know what I mean. Anyway, we were putting on a laser show, and the bright blue diode laser was just what we needed.

RGB Laser show — A sweeter setup than mine, but you get the idea.

Color laser setups take three or more different lasers, combine the beams, and then bounce them off of mirrors attached to galvos. Steer the mirrors around, and you can project vector images. It’s pretty cool tech, and involves some serious fine-tuning, but the irony here is that we were tearing apart a device with 788,736 microscopic DLP mirrors to point the lasers through just two. And yet, a DIY laser show is significantly cooler than just putting up your powerpoint on the office wall.

The same thing goes for 2D plotting machines like the AxiDraw. The astonishing tech behind any old laser printer is mind-numbing. Possibly literally. Why else would we think that art drawn out by a pen in the hands of a stepper-powered robot is cooler than the output of a 1600 DPI unit coming from HP’s stable? I mean, instead of running an hours-long job to put ink on paper with a pen, my Laserjet puts out an image in ten seconds. But it’s just not as much fun.

So here we are, in an age where there’s so darn much magic all around us, in the form of sufficiently advanced technology, that comprehensible devices are actually more impressive. And my guess is that it’s partly because it’s not surprising when a device that’s already magic does something magical. I mean, that’s just what it’s supposed to do. Duh!

But when something beautiful emerges from a pair of mirrors epoxied to shafts on springs turned by copper coils, that’s real magic.

Happy New Year, Hackaday!

January 7, 2023 by Elliot Williams 4 Comments

[Tom Nardi] and I were talking on the podcast about 2022, and how it went from the hacker’s perspective. As the global chip shortage entered its second full year, we both thought back on the ways that we all had to adapt and work around the fact that we just couldn’t get the parts we were accustomed to picking up with ease.

What had previously been an infinite supply of knockoff Arduino clones and STM32 Blue Pill boards all of a sudden just dried up. Sometimes you just couldn’t get the DAC chip you wanted, or at least not without many weeks’ lead time, and even then, it’d cost you. Raspberry Pi single-board computers became hard to find. PCB designs had to change and new SDKs needed to be learned. I know I had to grab twice for unfamiliar microcontroller platforms this year.

We hacked around the problems. It would be absurd to say that the chip shortage wasn’t a pain in the posterior, but in the end we all managed to carry on and keep creating. We created more flexible footprints, learned to design around what we could get, and definitely had to do more planning. We pulled parts for projects out of the junk box or shelf stock. Or, as Tom noted, we did what everyone in the parts of the world who aren’t as fortunate to get free expedited shipping does – we made do.

Making do often meant learning new environments, questioning old habits, and double-checking pinouts. But if you’re like me, not all of that time was wasted. Sometimes it’s good to get shaken out of comfy workflows, even if by force. So while we wish you parts-in-stock and easy availability for 2023, don’t forget the lessons learned from 2022. Stay scrappy, Hackaday!

In Praise Of “Just Because” Hacks

December 31, 2022 by Elliot Williams 25 Comments

Sometimes you pick a project because the world needs it to be done. Or maybe you or a friend need it. Or maybe you don’t really need it, but it fulfills a longstanding dream. In my mind, the last stop before you reach “why am I doing this” is the “just because” hack.

The ideal “just because” hack is limited in scope. You don’t want to spend years on a whimsical project, and because of this a “just because” hack isn’t usually motivating enough to keep you going that long anyway, except for the tenacious few. A “just because” doesn’t necessarily have to be an easy win, but it makes sense for you to see your way out before you get in too deep.

I’m not sure if it’s the Baader-Meinhof phenomenon or not, but in the last week or so in the Hackaday universe, a lot of people have been singing the praises of “just because” hacks. (Check out this one discussion, for instance.) Mostly, it’s a combination of them turning out better than initially thought, or it’s about the learning that came along for the ride. Of course, many of them spin off into longer, serious projects even if they didn’t start that way.

Not everything in life can be frivolous, of course. But that makes the “just because” hack that much sweeter, and you should try to make mental room for them if you can. When the stakes are low, creativity can be high. You might still want to impose a deadline, lest you fall into eternal yak shaving, but take it easy. You don’t need a justification all the time: the journey can be the destination.

Yesterday’s Future Is Brighter Today

December 17, 2022 by Elliot Williams 31 Comments

The demoscene never ceases to amaze. Back in the mid-80s, people wouldn’t just hack software to remove the copy restrictions, but would go the extra mile and add some fun artwork and greetz. Over the ensuing decade the artform broke away from the cracks entirely, and the elite hackers were making electronic music with amazing accompanying graphics to simply show off.

Looked at from today, some of the demos are amazing given that they were done on such primitive hardware, but those were the cutting edge home computers at the time. I don’t know what today’s equivalent is, with CGI-powered blockbusters running in mainstream cinemas, the state of the art in graphics has moved on quite a bit. But the state of the old art doesn’t rest either. I’ve just seen the most amazing demo on a ZX Spectrum.

Simply put, this demo does things in 2022 on a computer from 1982 that were literally impossible at the time. Not because the hardware was different – this is using retro gear after all – but because the state of our communal knowledge has changed so dramatically over the last 40 years. What makes 2020s demos more amazing than their 1990s equivalents is that we’ve learned, discovered, and shared enough new tricks with each other that we can do what was previously impossible. Not because of silicon tech, but because of the wetware. (And maybe I shouldn’t underestimate the impact of today’s coding environments and other tooling.)

I love the old demoscene, probably for nostalgia reasons, but I love the new demoscene because it shows us how far we’ve come. That, and it’s almost like reverse time-travel, taking today’s knowledge and pushing it back into gear of the past.

Fossil Files: My .Emacs

December 10, 2022 by Elliot Williams 63 Comments

Last week, I wrote about cargo culting in a much more general context, so this week I’m going to come clean. The file that had me thinking about the topic was the worst case you’ve probably ever seen: I have a .emacs file kicking around that I haven’t really understood since I copied it from someone else – probably Ben Scarlet whose name is enshrined therein – in the computer lab in 1994! Yes, my .emacs file is nearly 30, and I still don’t really understand it, not exactly.

Now in my defence, I switched up to vim as my main editor a few years ago, but this one file has seen duty on Pentiums running pre-1.0 versions of Linux, on IBM RS/6000 machines in the aforementioned computer lab, and on a series of laptops and desktops that I’ve owned over the years. It got me through undergrad, grad school, and a decade of work. It has served me well. And if I fired up emacs right now, it would still be here.

For those of you out there who don’t use emacs, the .emacs file is a configuration file. It says how to interpret different files based on their extensions, defines some special key combos, and perhaps most importantly, defines how code syntax highlighting works. It’s basically all of the idiosyncratic look-and-feel stuff in emacs, and it’s what makes my emacs mine. But I don’t understand it.

Why? Because it’s written in LISP, for GNU’s sake, and because it references all manner of cryptic internal variables that emacs uses under the hood. I’m absolutely not saying that I haven’t tweaked some of the colors around, or monkey-patched something in here or there, but the extent is always limited to whatever I can get away with, without having to really learn LISP.

This ancient fossil of a file is testament to two things. The emacs codebase has been stable enough that it still works after all this time, but also that emacs is so damn complicated and written in an obscure enough language that I have never put the time in to really grok it – the barriers are too high and the payoff for the effort too low. I have no doubt that I could figure it out for real, but I just haven’t.

So I just schlep this file around, from computer to computer, without understanding it and without particularly wanting to. Except now that I write this. Damnit.

Featured image: “A Dusty Old Book” by Marco Verch Professional.

Cargo Culting And Buried Treasure

December 3, 2022 by Elliot Williams 55 Comments

I have no idea how true the stories are, but legend has it that when supplies were dropped on some Melanesian islands during WWII, some locals took to replicating runway signs in order to further please the “gods” that were dropping them. They reportedly thought that making landing strips caused laden airplanes to visit. Richard Feynman later turned this into a metaphor about scientific theory – that if you don’t understand what you’re doing deeply, you may be fooling yourself.

I’d like to be a little bit more forgiving of adherents of technological cargo cults. Because the world around us is very complicated, we often just take things as they are rather than understanding them deeply, because there’s simply only so deep you can go into so many fields.

Is someone who doesn’t know the i386 machine language cargo-culting their way through a job as a web backend developer? Probably not. But from the perspective of an assembly-language programmer, any of us who write in compiled or interpreted programming languages are cargo-culting coding. You don’t need to understand a cell phone to dial home, but can you really say that you understand everything about how one works? Or are you just going through the motions?

So while some reliance on metaphor and “well, it worked last time” is perfectly normal, I think noticing when you cargo-cult is also healthy. It should also be a warning sign, or at least a flag to remind yourself that there may be dragons here. Or maybe just a buried learning opportunity, the X that marks the spot where digging deeper might be productive.