Ask Hackaday: Do You Have A Dead Man’s Switch?

During the Cold War, the specter of a nuclear “dead man’s switch” was central to the concept of Mutually Assured Destruction (MAD). In the event that one side was annihilated by the other, an automated system would be triggered to deliver a revenge strike that would ultimately destroy the attacker. It was the ultimate defense, as your enemy will never attack if they know doing so will inevitably lead to their own destruction.

The same idea has occasionally been employed by whistleblowers and journalists as well. Should the individual fail to check in regularly, a series of predetermined events will be set into motion. Again, the idea is defensive in nature. If somebody is in possession of information so damning that they could be abducted or even killed to keep it quiet, making arrangements to have that information be released to the public in the event anything should happen to them is a great way to stay safe.

A nuclear dead man’s switch is a key plot point in Dr. Strangelove.

But what about for the average person? In the past, there was no need for most people to think about something as elaborate as a dead man’s switch. But we live in interesting times, to say the least. In an information society such as ours, whistleblowers have never been more common, and the Internet has significantly blurred the definition of what it means to be a journalist.

For those living under a repressive regime or in a war zone, simply posting to social media can provide the outside world with an unfiltered look at what’s actually happening on the ground. A teenager with a cell phone has the potential to reach a wider audience than the legacy media — a powerful, but dangerous, proposition.

Even if you’re not in the middle of political upheaval, there are still reasons you might want to have previously secret information made available in the event of your death or incapacitation. Perhaps you’d like to send your loved ones a final personal message, or make sure the passwords for all your accounts get in the hands of whoever will be handling your estate.

Of course, one could argue that could be accomplished with little more than a notebook hidden in your sock drawer. But this is Hackaday, and over-engineering is the name of the game. So do you have a dead man’s switch? How is it implemented? Or is the whole idea just a bit too out there for you?

Continue reading “Ask Hackaday: Do You Have A Dead Man’s Switch?”

The Requirements Of AI

The media is full of breathless reports that AI can now code and human programmers are going to be put out to pasture. We aren’t convinced. In fact, we think the “AI revolution” is just a natural evolution that we’ve seen before. Consider, for example, radios. Early on, if you wanted to have a radio, you had to build it. You may have even had to fabricate some or all of the parts. Even today, winding custom coils for a radio isn’t that unusual.

But radios became more common. You can buy the parts you need. You can even buy entire radios on an IC. You can go to the store and buy a radio that is probably better than anything you’d cobble together yourself. Even with store-bought equipment, tuning a ham radio used to be a technically challenging task. Now, you punch a few numbers in on a keypad.

The Human Element

What this misses, though, is that there’s still a human somewhere in the process. Just not as many. Someone has to design that IC. Someone has to conceive of it to start with. We doubt, say, the ENIAC or EDSAC was hand-wired by its designers. They figured out what they wanted, and an army of technicians probably did the work. Few, if any, of them could have envisoned the machine, but they can build it.

Does that make the designers less? No. If you write your code with a C compiler, should assembly programmers look down on you as inferior? Of course, they probably do, but should they?

If you have ever done any programming for most parts of the government and certain large companies, you probably know that system engineering is extremely important in those environments. An architect or system engineer collects requirements that have very formal meanings. Those requirements are decomposed through several levels. At the end, any competent programmer should be able to write code to meet the requirements. The requirements also provide a good way to test the end product.

Continue reading “The Requirements Of AI”

Ancient Ice Production

Today, we take ice for granted. But having ice produced in your home is a relatively modern luxury. As early as 1750 BC, ancient people would find ice on mountains or in cold areas and would harvest it. They’d store it, often underground, with as much insulation as they could produce given their level of technology.

A yakhchāls in Yazd province (by [Pastaitkaen] CC BY-SA 3.0).
By 500 BC, people around Egypt and what is now India would place water in porous clay pots on beds of straw when the night was cold and dry. Even if the temperature didn’t freeze, the combination of evaporation and radiative cooling could produce some ice. However, this was elevated to a high art form around 400 BC by the Persians, who clearly had a better understanding of physics and thermodynamics than you’d think.

The key to Persian icemaking was yakhchāls. Not all of them were the same, but they typically consisted of an underground pit with a conical chimney structure. In addition, they often had shade walls and ice pits as well as access to a water supply.

Solar Chimney

The conical shape optimizes the solar chimney effect, where the sun heats air, which then rises. The top was typically not open, although there is some thought that translucent marble may have plugged the top to admit light while blocking airflow. yakhchālThe solar chimney produces an updraft that tends to cool the interior. The underground portion of the yakhchāl has colder air, as any hot air rises above the surface.

Continue reading “Ancient Ice Production”

Real LED TVs Are Finally Becoming A Thing

Once upon a time, the cathode ray tube was pretty much the only type of display you’d find in a consumer television. As the analog broadcast world shifted to digital, we saw the rise of plasma displays and LCDs, which offered greater resolution and much slimmer packaging. Then there was the so-called LED TV, confusingly named—for it was merely an LCD display with an LED backlight. The LEDs were merely lamps, with the liquid crystal doing all the work of displaying an image.

Today, however, we are seeing the rise of true LED displays. Sadly, decades of confusing marketing messages have polluted the terminology, making it a confusing space for the modern television enthusiast. Today, we’ll explore how these displays work and disambiguate what they’re being called in the marketplace.

Continue reading “Real LED TVs Are Finally Becoming A Thing”

The Engineering Of The Falkirk Wheel

We live in an age where engineering marvels are commonplace: airplanes crisscross the sky, skyscrapers grow like weeds, and spacecraft reach for the stars. But every so often, we see something unusual that makes us take a second look. The Falkirk Wheel is a great example, and, even better, it is functional art, as well.

The Wheel links two canals in Scotland. Before you click away, here’s the kicker: One canal is 35 meters higher than the other. Before 1933, the canals were connected with 11 locks. It took nearly a day to operate the locks to get a boat from one canal to the other. In the 1930s, there wasn’t enough traffic to maintain the locks, and they tore them out.

Fast Forward

In the 1990s, a team of architects led by [Tony Kettle] proposed building a wheel to transfer boats between the two canals. The original model was made from [Tony’s] daughter’s Lego bricks.

The idea is simple. Build a 35-meter wheel with two caissons, 180 degrees apart. Each caisson can hold 250,000 liters of water. To move a boat, you fill the caissons with 500 tonnes of water. Then you let a boat into one of them with its weight displacing an equal amount of water, so the caissons stay at the same weight.

Once you have a balanced system, you just spin the wheel to make a half turn. There are 10 motors that require 22.5 kilowatts, and each half-turn consumes about 1.5 kilowatt-hours.

Continue reading “The Engineering Of The Falkirk Wheel”

Practice Makes Perfect: The Wet Dress Rehearsal

If you’ve been even casually following NASA’s return to the Moon, you’re likely aware of the recent Wet Dress Rehearsal (WDR) for the Artemis II mission. You probably also heard that things didn’t go quite to plan: although the test was ultimately completed and the towering Space Launch System (SLS) rocket was fully loaded with propellant, a persistent liquid hydrogen leak and a few other incidental issues lead the space agency to delay further testing for at least a month while engineers make adjustments to the vehicle.

This constitutes a minor disappointment for fans of spaceflight, but when you’re strapping four astronauts onto more than five million pounds of propellants, there’s no such thing as being too cautious. In fact, there’s a school of thought that says if a WDR doesn’t shake loose some gremlins, you probably weren’t trying hard enough. Simulations and estimates only get you so far, the real thing is always more complex, and there’s bound to be something you didn’t account for ahead of time.

Continue reading “Practice Makes Perfect: The Wet Dress Rehearsal”

PROFS: The Office Suite Of The 1980s

Today, we take office software suites for granted. But in the 1970s, you were lucky to have a typewriter and access to a photocopier. But in the early 1980s, IBM rolled out PROFS — the Professional Office System — to try to revolutionize the office. It was an offshoot of an earlier internal system. The system would hardly qualify as an office suite today, but for the time it was very advanced.

The key component was an editor you could use to input notes and e-mail messages. PROFS also kept your calendar and could provide databases like phonebooks. There were several key features of PROFS that would make it hard to recognize as productivity software today. For one thing, IBM terminals were screen-oriented. The central computer would load a form into your terminal, which you could fill out. Then you’d press send to transmit it back to the mainframe. That makes text editing, for example, a very different proposition since you work on a screen of data at any one time. In addition, while you could coordinate calendars and send e-mail, you could only do that with certain people.

A PROFS message from your inbox

In general,  PROFS connected everyone using your mainframe or, perhaps, a group of mainframes. In some cases, there might be gateways to other systems, but it wasn’t universal. However, it did have most of the major functions you’d expect from an e-mail system that was text-only, as you can see in the screenshot from a 1986 manual. PF keys, by the way, are what we would now call function keys.

The calendar was good, too. You could grant different users different access to your calendar. It was possible to just let people see when you were busy or mark events as confidential or personal.

You could actually operate PROFS using a command-line interface, and the PF keys were simply shorthand. That was a good thing, too. If you wanted to erase a file named Hackaday, for example, you had to type: ERASE Hackaday AUT$PROF.

Styles

PROFS messages were short and were essentially ephemeral chat messages. Of course, because of the block-mode terminals, you could only get messages after you sent something to the mainframe, or you were idle in a menu. A note was different. Notes were what we could call e-mail. They went into your inbox, and you could file them in “logs”, which were similar to folders.

Continue reading “PROFS: The Office Suite Of The 1980s”