The DeDeterminator Uses Quantum Physics To Make Decisions So You Don’t Have To

Are you making your own decisions and mainlining causality like a sucker? Why go through the agony, when you could hand over the railway switch of determinism to a machine that can decide things for you! Enter the DeDeterminator, a decision machine from [Oliver Child].

The construction is simple enough, being built inside a small tin. One kind of wishes it had a secret third “PERHAPS” bulb that illuminates only when the universe’s continued existence has been called into question.

The idea is simple. At the press of a button, the DeDeterminator illuminates a bulb—indicating either yes or no. The decision for which bulb to illuminate is truly random, as it’s determined by the radioactive decay of a Americium-241 alpha particle source. A Geiger-Muller tube is used to detect alpha particles, with the timing between detections used to determine the yes-or-no output of the device.

It’s a neat concept, and it’s kind of fun knowing that your decision is both out of your hands and as random as it could possibly be. Would the universe guide you wrong? Who could possibly question the reasoning of the particles? The only rational move could be to comply with whatever directive the box hath given. Just don’t ask it to make any decisions with dangerous outcomes.

We’ve featured other projects using radioactive decay for random number generation before, though they weren’t quite as philosophically intriguing as the DeDeterminator. Mostly they’re just about cryptographic security and such, but some do deal with causality in imaginary spaces, which has its own magic about it.

Meanwhile, if you’ve untangled the quantum chains of cause and effect, or you’ve just found a way to break RSA encryption using a Pi Pico, do drop us a line, won’t you?

Suc Aims To Replace Slack In Five Lines Of Bash

The design philosophy of Unix is fairly straightforward. Software should do one thing as simply as possible, and do that one thing only. As a design principle this is sound advice even well outside of the realm of Unix, and indeed software in general, but that doesn’t stop modern software packages from being too large for their own good. So, if you’re tired of bloated chat programs like Slack or Mattermost with their millions of lines of code, you might instead favor something like Simple Unix Chat (suc).

The idea is that suc can perform almost all modern chat functions in only five lines of Bash, supporting rich-text chat, file sharing, access control, and encryption. These five lines, though, only perform the core function of suc — which is to write text to a file on the system. Indeed, suc makes liberal use of plenty of other Unix services which do not add to the line counts, such as the use of SSH to handle authentication. It also relies on some other common Unix system features to handle things like ownership and access for the text files that host the text for the chat.

As channels are simply text files, it makes writing bots or other tools exceptionally simple. You can also easily pipe the output of commands directly into suc with one-liners that can do things like dump the output of make into a specific channel if compilation fails.

While it’s not likely that everyone will ditch tools like Slack to switch to something like this, it’s still an impressive demonstration of what can be done when designing around the Unix philosophy and taking advantage of system tools that already exist rather than reinventing the wheel and re-programming all of those tools into the application. Practices like this might decrease development time and increase the ease of developing cross-platform applications but they often also produce a less than desirable user experience.

Learning Obsolete Technology

Tom Nardi and I were talking about his trip to the Vintage Computer Festival on the podcast, and he admitted to not having been a retrocomputer aficionado before his first trip. But he ended up keying some binary machine code into some collection of archaic silicon, and he got it. In the same episode, the sound of the week was a Strowger switch — the old electromechanical “brain” of telephone switching centers of old. The sample I used was from Sam of Look Mum No Computer on YouTube, who got one for his museum and thinks it’s just awesome.

Why do people like this kind of old (obsolete?) tech? It’s certainly not because it’s overwhelmingly capable — the giant old switch is replaced easily by a stack of silicon, and don’t even get me started on the old blinkenlights computer that Tom was keying on. In both of these cases, the people are significantly younger than the tech they’re playing around with, so that rules out nostalgia. What’s left?

I think it’s that sometimes the older technology is more immediate, more understandable, more tangible, and that resonates with people. In a time when we all have wonder devices that can do anything, programmed in languages that are pleasant, using libraries that are nothing short of magical in terms of making difficult things easy, understanding how things work down to the ground is a rare commodity.

But it’s a strange position to find ourselves in, technologically, where there’s almost necessarily a trade-off between the usefulness and functionality of a device with the ability to understand fundamentally how it works.

Beginning The Machine Shop Journey With A DIY CNC

Building a good quality machine shop may seem to present a chicken-and-egg problem, at least for anyone not willing to mortgage their home for the money needed to buy all of these tools new. Namely, that building good tools often requires good tools. To help solve this problem, [Ryan] designed and built this CNC machine which can be built with nothing other than common tools, hardware store supplies, and some readily available parts from the internet.

Since it’s being built from consumer-grade material, [Ryan] has the design philosophy of “buying precision” which means that most of the parts needed for this build are precise enough for their purpose without needing to be worked in any way before incorporation into the mill. For example, he uses a granite plate because it’s hard, flat, heavy, and sturdy enough at the time of purchase to be placed into the machine right away. Similarly, his linear guides do not need to be modified before being put to work with a high degree of precision and minimal calibration. From there, he applies the KISS principle and uses the simplest parts available. With this design process he is able to “bootstrap” a high quality mill for around $1500 USD without needing any extra tools than the ones you likely already have.

The RIG-CNC as it is known has also been made completely open source which further cements its bootstrapability, and there is a lot more detail on the project page and in the video linked below. This project is unique not simply for the mill build from common parts and tools, but because this design philosophy is so robust. Good design goes a lot farther in our builds than a lot of us might realize, and good design often results in more maintainable, hackable things that work for more uses than the original creators may have even thought about.

Continue reading “Beginning The Machine Shop Journey With A DIY CNC”

Hackability Matters

The Unix Way™ provides extreme hackability. The idea is that software should be written as tools to accomplish discrete tasks, and that it should be modular, extensible, and play well with others. It’s like software as a LEGO set — you can put the blocks together however you want, within limits, and make stuff that’s significantly cooler than any of the individual blocks alone.

Clearly this doesn’t work for all applications — things like graphics editors and web browsers don’t really lend themselves to being elegant tools that integrate well with others, right? It’s only natural that they’re bloaty walled gardens. What happens in the browser must stay in the browser, right?

But how sad is it that the one piece of software you use all day, your window into cyberspace, doesn’t play well with the rest of your system? I’d honestly never really been bothered by that fact until stumbling on TabFS. It’s an extension to Chrome that represents the tabs on your browser as if they were files on your local system — The Unix Way™. And what this means is that any other program that can read from or write to a file can open tabs, collect them, change webpages on the fly, and so on. It opens up the browser to you.

This is tremendously powerful. Don’t like the bookmarking paradigm of your particular browser? Writing your own would be a snap in Python — and you could do cleverer things like apply a little machine learning to handle putting them in categories. Want to pop open (or refresh) a set of webpages at a particular time every day? Cron, or its significantly more complicated counterpart systemd, and a couple lines of code will do that. Want to make a hardware button that converts dark mode to light mode and vice-versa for every website starting with “H”? Can do.

I’m picking on browsers, but many large pieces of software are inaccessible in the same way — even if they’re open source, they don’t open up channels for interaction with user code or scripts. (Everything “in the cloud” or “as a service”, I’m looking at you! But that’s a further rant for another day.) And that’s a shame, because most of these “big” pieces of software actually do the coolest things.

So please, if you’re working on a big software package, or even just writing a plug-in for one, do think about how you can make more of its abilities available to the casual scripter. Otherwise, it’s just plastic blocks that don’t fit with the rest of the set.

Kipp Bradford Discusses The Entanglement Of Politics And Technology

Kipp Bradford wrapped up his keynote talk at the Hackaday Remoticon with a small piece of advice: don’t built bridges in the middle of the ocean. The point is that a bridge must connect two pieces of land to be useful and if technology isn’t useful to humanity, does it matter at all?

In reality we build bridges in the middle of the ocean all the time as each of us finds nonsensical reasons to learn new skills and try things out. But when it comes time to sit down and make an organized end goal, Kipp wisely asks us to consider the impact we’d like that work to have on the world. Equally importantly, how will we make sure completed work actually gets used? This is where the idea of politics in technology comes to play, in the sense that politics is a major mechanism for collective decision-making within a society.

Currently the CTO of Treau, and a Lecturer and Researcher at Yale, Kipp delivered this keynote live on November 7th. Kipp was an expert judge for the Hackaday Prize in 2017 and 2018. The video of his talk, and a deeper look at the topics, are found below.

Continue reading “Kipp Bradford Discusses The Entanglement Of Politics And Technology”

Brute-Forced Copyrighting: Liberating All The Melodies

Bluntly stated, music is in the end just applied physics. Harmony follows — depending on the genre — a more or less fixed set of rules, and there  are a limited amount of variation possible within the space of music itself. So there are technically only so many melodies possible, making it essentially a question of time until a songwriter or composer would come up with a certain sequence of notes without knowing that they’re not the first one to do so until the cease and desist letters start rolling in.

You might well argue that there is more to a song than just the melody — and you are absolutely right. However, current copyright laws and past court rulings may not care much about that. Aiming to point out these flaws in the laws, musician tech guy with a law degree [Damien Riehl] and musician software developer [Noah Rubin] got together to simply create every possible melody as MIDI files, releasing them under the Creative Commons Zero license. While their current list is limited to a few scales of fixed length, with the code available on GitHub, it’s really just a matter of brute-forcing literally every single possible melody.

Admittedly, such a list of melodies might not have too much practical use, but for [Damien] and [Noah] it’s anyway more about the legal and philosophical aspects: musicians shouldn’t worry about getting sued over a few overlapping notes. So while the list serves as a “safe set of melodies” they put in the public domain, their bigger goal is to mathematically point out the finite space of music that shouldn’t be copyrightable in the first place. And they definitely have a point — just imagine where music would be today if you could copyright and sue over chord progressions.
Continue reading “Brute-Forced Copyrighting: Liberating All The Melodies”