Simultaneous Invention, All The Time?

February 25, 2023 by Elliot Williams 20 Comments

As Tom quipped on the podcast this week, if you have an idea for a program you’d like to write, all you have to do is look around on GitHub and you’ll find it already coded up for you. (Or StackOverflow, or…) And that’s probably pretty close to true, at least for really trivial bits of code. But it hasn’t always been thus.

I was in college in the mid 90s, and we had a lab of networked workstations that the physics majors could use. That’s where I learned Unix, and where I had the idea for the simplest program ever. It took the background screen color, in the days before wallpapers, and slowly random-walked it around in RGB space. This was set to be slow enough that anyone watching it intently wouldn’t notice, but fast enough that others occasionally walking by my terminal would see a different color every time. I assure you, dear reader, this was the very height of wit at the time.

With the late 90s came the World Wide Web and the search engine, and the world got a lot smaller. For some reason, I was looking for how to set the X terminal background color again, this time searching the Internet instead of reading up in a reference book, and I stumbled on someone who wrote nearly exactly the same random-walk background color changer. My jaw dropped! I had found my long-lost identical twin brother! Of course, I e-mailed him to let him know. He was stoked, and we shot a couple funny e-mails back and forth riffing on the bizarre coincidence, and that was that.

Can you imagine this taking place today? It’s almost boringly obvious that if you search hard enough you’ll find another monkey on another typewriter writing exactly the same sentence as you. It doesn’t even bear mentioning. Heck, that’s the fundamental principle behind Codex / CoPilot – the code that you want to write has been already written so many times that it will emerge as the most statistically likely response from a giant pattern-matching, word-word completion neural net model.

Indeed, stop me if you’ve read this before.

Copyright Data, But Do It Right

February 4, 2023 by Elliot Williams 33 Comments

Copyright law is a triple-edged sword. Historically, it has been used to make sure that authors and rock musicians get their due, but it’s also been extended to the breaking point by firms like Disney. Strangely, a concept that protected creative arts got pressed into duty in the 1980s to protect the writing down of computer instructions, ironically a comparatively few bytes of BIOS code. But as long as we’re going down this strange road where assembly language is creative art, copyright law could also be used to protect the openness of software as well. And doing so has given tremendous legal backbone to the open and free software movements.

So let’s muddy the waters further. Looking at cases like the CDDB fiasco, or the most recent sale of ADSB Exchange, what I see is a community of people providing data to an open resource, in the belief that they are building something for the greater good. And then someone comes along, closes up the database, and sells it. What prevents this from happening in the open-software world? Copyright law. What is the equivalent of copyright for datasets? Strangely enough, that same copyright law.

Data, being facts, can’t be copyrighted. But datasets are purposeful collections of data. And just like computer programs, datasets can be licensed with a restrictive copyright or a permissive copyleft. Indeed, they must, because the same presumption of restrictive copyright is the default.

I scoured all over the ADSB Exchange website to find any notice of the copyright / copyleft status of their dataset taken as a whole, and couldn’t find any. My read is that this means that the dataset is the exclusive property of its owner. The folks who were contributing to ADSB Exchange were, as far as I can tell, contributing to a dataset that they couldn’t modify or redistribute. To be a free and open dataset, to be shared freely, copied, and remixed, it would need a copyleft license like Creative Commons or the Open Data Commons license.

So I’ll admit that I’m surprised to have not seen permissive licenses used around community-based open data projects, especially projects like ADSB Exchange, where all of the software that drives it is open source. Is this just because we don’t know enough about them? Maybe it’s time for that to change, because copyright on datasets is the law of the land, no matter how absurd it may sound on the face, and the closed version is the default. If you want your data contributions to be free, make sure that the project has a free data license.

Speak To The Machine

January 28, 2023 by Elliot Williams 16 Comments

If you own a 3D printer, CNC router, or basically anything else that makes coordinated movements with a bunch of stepper motors, chances are good that it speaks G-code. Do you?

If you were a CNC machinist back in the 1980’s, chances are very good that you’d be fluent in the language, and maybe even a couple different machines’ specialized dialects. But higher level abstractions pretty quickly took over the CAM landscape, and knowing how to navigate GUIs and do CAD became more relevant than knowing how to move the machine around by typing.

a Reprap Darwin — Reprap Darwin: it was horrible, but it was awesome.

Strangely enough, I learned G-code in 2010, as the RepRap Darwin that my hackerspace needed some human wranglers. If you want to print out a 3D design today, you have a wealth of convenient slicers that’ll turn abstract geometry into G-code, but back in the day, all we had was a mess of Python scripts. Given the state of things, it was worth learning a little G-code, because even if you just wanted to print something out, it was far from plug-and-play.

For instance, it was far easier to just edit the M104 value than to change the temperature and re-slice the whole thing, which could take an appreciable amount of time back then. Honestly, we were all working on the printers as much as we were printing. Knowing how to whip up some quick bed-levelling test scripts and/or demo objects in G-code was just plain handy. And of course the people writing or tweaking the slicers had to know how to talk directly to the machine.

Even today, I think it’s useful to be able to speak to the machine in its native language. Case in point: the el-quicko pen-plotter I whipped together two weekends ago was actually to play around with Logo, the turtle language, with my son. It didn’t take me more than an hour or so to whip up a trivial Logo-alike (in Python) for the CNC: pen-up, pen-down, forward, turn, repeat, and subroutine definitions. Translating this all to machine moves was actually super simple, and we had a great time live-drawing with the machine.

So if you want to code for your machine, you’ll need to speak its language. A slicer is great for the one thing it does – turning an STL into G-code, but if you want to do anything a little more bespoke, you should learn G-code. And if you’ve got a 3D printer kicking around, certainly if it runs Marlin or similar firmware, you’ve got the ideal platform for exploration.

Does anyone else still play with G-code?

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!