When attempting to secure something, whether it’s a computer, sensitive data, or valuables, there’s always going to be a way to break that security. It might be impossibly hard, like taking centuries to brute-force an encryption algorithm, but it’s weakness is still there. And, like the future might make certain encryption obsolete, modern electronics has made security of the past somewhat obsolete as well. [Startup Chuck] has been using tools the creators of safes from the late 1800s could probably not have imagined.

The tool that [Startup Chuck] has come up with is known as an autodialer in the safe-cracking world, and as its name suggests it automates the process of opening the safe by trying as many combinations as possible. The autodialer attaches to the safe with three magnetic feet and couples to the dial through a chuck attached to a magnetic clutch, which allows the autodialer to disengage as soon as the correct combination is found. It’s driven with a stepper motor which can test out combinations so fast that [Startup Chuck] needed to take 240 fps video and slow it down to make sure that the mechanism was behaving properly.

The autodialer itself can’t actually open the safe, though. The last step of the process is taken care of by a bungie cord, attached to the safe handle to pre-tension it enough so that when the correct combination is finally entered the safe pops open automatically. For anyone looking to duplicate the project, [Startup Chuck] has added the program code to a GitHub page. If you’re looking at a more modern safe, though, there are of course ways to crack their security systems as well.

Plastic has been a revolutionary material over the past century, with an uncountable number of uses and an incredibly low price to boot. Unfortunately, this low cost has led to its use in many places where other materials might be better suited, and when this huge amount of material breaks down in the environment it can be incredibly persistent and harmful. This has led to many attempts to recycle it, and one of the more promising efforts recently came out of a lab at Northwestern University.

Plastics exist as polymers, long chains of monomers that have been joined together chemically. The holy grail of plastic recycling would be to convert the polymers back to monomers and then use them to re-make the plastics from scratch. This method uses a catalyst to break down polyethylene terephthalate (PET), one of the more common plastics. Once broken down, the PET is exposed to moist air which converts it into its constituent monomers which can then be used to make more PET for other uses.

Of course, the other thing that any “holy grail” of plastic recycling needs is to actually be cheaper and easier than making new plastic from crude oil, and since this method is still confined to the lab it remains to be seen if it will one day achieve this milestone as well. In the meantime, PET can also be recycled fairly easily by anyone who happens to have a 3D printer around.

By some estimates, the English language contains over a million unique words. This is perhaps overly generous, but even conservative estimates generally put the number at over a hundred thousand. Regardless of where the exact number falls between those two extremes, it’s certainly many more words than could fit in the 64 kB of memory allocated to the spell checking program on some of the first Unix machines. This article by [Abhinav Upadhyay] takes a deep dive on how the early Unix engineers accomplished the feat despite the extreme limitations of the computers they were working with.

Perhaps the most obvious way to build a spell checker is by simply looking up each word in a dictionary. With modern hardware this wouldn’t be too hard, but disks in the ’70s were extremely slow and expensive. To move the dictionary into memory it was first whittled down to around 25,000 words by various methods, including using an algorithm to remove all affixes, and then using a Bloom filter to perform the lookups. The team found that this wasn’t a big enough dictionary size, and had to change strategies to expand the number of words the spell checker could check. Hash compression was used at first, followed by hash differences and then a special compression method which achieved an almost theoretically perfect compression.

Although most computers that run spell checkers today have much more memory as well as disks which are orders of magnitude larger and faster, a lot of the innovation made by this early Unix team is still relevant for showing how various compression algorithms can be used on data in general. Large language models, for one example, are proving to be the new frontier for text-based data compression.

Lithium technology has ushered in a new era of batteries with exceptionally high energy density for a reasonably low cost. This has made a lot possible that would have been unheard of even 20 years ago such as electric cars, or laptops that can run all day on a single charge. But like anything there are tradeoffs to using these batteries. They are much more complex to use than something like a lead acid battery, generally requiring a battery management system (BMS) to keep the cells in tip-top shape. Generally these are standalone systems but [CallMeC] integrated this one into the buswork for a battery pack instead.

The BMS is generally intended to make sure that slight chemical imbalances in the battery cells don’t cause the pack to wear out prematurely. They do this by maintaining an electrical connection to each cell in the battery so they can charge them individually when needed, making sure that they are all balanced with each other. This BMS has all of these connections printed onto a PCB, but also included with the PCB is the high-power bus that would normally be taken care of by bus bar or nickel strips. This reduces the complexity of assembling the battery and ensures that any time it’s hooked up to a number of cells, the BMS is instantly ready to go.

Although this specific build is meant for fairly large lithium iron phosphate batteries, this type of design could go a long way towards making quick battery packs out of cells of any type of battery chemistry that typically need a BMS system, from larger 18650 packs or perhaps even larger cells like those out of a Nissan Leaf.

In theory, any piece of software could be built out of discrete pieces of hardware, provided there are enough transistors, passive components, and time available. In general, though, we’re much more likely to reach for a programmable computer or microcontroller for all but the simplest tasks for several reasons: cost, effort, complexity, economics, and sanity. [Igor Brichkov] was working with I2C and decided that he wanted to see just where this line between hardware and software should be by implementing this protocol itself directly with hardware.

One of the keys to “programming” a communications protocol in hardware is getting the timing right, the first part of which is initializing communications between this device and another on the bus. [Igor] is going to be building up the signal in parts and then ORing them together. The first part is a start condition, generated by one oscillator and a counter. This also creates a pause, at which point a second oscillator takes over and sends data out. The first data needed for I2C is an address, which is done with a shift register and a counter pre-set to send the correct bits out on the communications lines.

To build up the rest of the signal, including data from the rotary encoder [Igor] is using for his project, essentially sets of shift registers and counters are paired together to pass data out through the I2C communications lines in sequence. It could be thought of that the main loop of the hardware program is a counter, which steps through all the functions sequentially, sending out data from the shift registers one by one. We saw a similar project over a decade ago, but rather than automating the task of sending data on I2C it allowed the user to key in data manually instead.

The Etch A Sketch is a classic children’s toy resembling a picture frame where artwork can be made by turning two knobs attached to a stylus inside the frame. The stylus scrapes off an aluminum powder, creating the image which can then be erased by turning the frame upside down and shaking it, adding the powder back to the display. It’s completely offline and requires no batteries, but in our modern world those two things seem to be more requirements than when the Etch A Sketch was first produced in the 1960s. Enter the Tilt-A-Sketch, a modern version of the classic toy.

Rather than use aluminum powder for the display, the Tilt A Sketch replaces it with an LED matrix and removes the stylus completely. There are no knobs on this device to control the path of the LED either; a inertial measurement unit is able to sense the direction that the toy is tilted while a microcontroller uses that input to light up a series of LEDs corresponding to the direction of tilt. There are a few buttons on the side of the device as well which allow the colors displayed by the LEDs to change, and similar to the original toy the display can be reset by shaking.

The Tilt-A-Sketch was built by [devitoal] as part of an art display which allows the visitors to create their own art. Housed in a laser-cut wooden enclosure the toy does a faithful job of recreating the original. Perhaps unsurprisingly, the Etch A Sketch is a popular platform for various projects that we’ve seen before including original toys modified with robotics to create the artwork and electronic recreations that use LED displays instead in a way similar to this project.

A few years ago, [Jeremy Makes Things] built a rope tow in his back yard so his son could ski after school. Since the lifts at the local hill closed shortly after schools let out, this was the only practical way for his son to get a few laps in during the week. It’s cobbled together from things that [Jeremy] had around the house, and since the original build it’s sat outside for a few years without much use. There’s been a lot more snow where he lives this year though, so it’s time for a rebuild.

The power source for the rope tow is an old gas-powered snowblower motor, with a set of rollers and pulleys for the rope made out of the back end of a razor scooter. Some polyurethane was poured around the old wheel hub so that the rope would have something to grip onto. The motor needed some sprucing up as well, from carburetor adjustment, fuel tank repairs, and some other pieces of maintenance before it could run again. With that out of the way it could be hoisted back up a tree at the top of the hill and connected to the long rope.

This isn’t the first time [Jeremy] has had to perform major maintenance on this machine either. Three years ago it needed plenty of work especially around the polyurethane wheel where [Jeremy] also had to machine a new wheel bearing in addition to all the other work that had to go into repairing it that time. From the looks of things though it’s a big hit with his son who zips right back up the hill after each ski run. Getting to the tops of ski runs with minimal effort has been a challenge of skiers and snowboarders alike for as long as the sport has been around, and we’ve seen all kinds of unique solutions to that problem over the years.

In many ways, living here in the future is quite exiting. We have access to the world’s information instantaneously and can get plenty of exciting tools and hardware delivered to our homes in ways that people in the past with only a Sears catalog could only dream of. Lasers are of course among the exciting hardware available, which can be purchased with extremely high power levels. Provided the proper safety precautions are taken, that can lead to some interesting builds like this laser harp which uses a 3W laser for its strings.

[Cybercraftics]’ musical instrument is using a single laser to generate seven harp strings, using a fast stepper motor to rotate a mirror to precise locations, generating the effect via persistence of vision. Although he originally planned to use one Arduino for this project, the precise timing needed to keep the strings in the right place was getting corrupted by adding MIDI and the other musical parts to the project, so he split those out to a second Arduino.

Although his first prototype worked, he did have to experiment with the sensors used to detect his hand position on the instrument quite a bit before getting good results. This is where the higher power laser came into play, as the lower-powered ones weren’t quite bright enough. He also uses a pair of white gloves which help illuminate a blocked laser. With most of the issues ironed out, [Cybercraftics] notes that there’s room for improvement but still has a working instrument that seems like a blast to play. If you’re still stuck in the past without easy access to lasers, though, it’s worth noting that there are plenty of other ways to build futuristic instruments as well.

Electricity can be a pretty handy tool when it stays within the bounds of its wiring. It’s largely responsible for our modern world and its applications are endless. When it’s not running in wires or electronics though, things can get much more complicated even for things that seem simple on the surface. For example, measuring moisture in soil seems straightforward, but corrosion presents immediate problems. To combat the problems with measuring things in the natural world with electricity, [David] built this capacitive soil moisture sensor which also has the benefit of using an extremely small amount of energy to operate.

The sensor is based on an STM32 microcontroller, in this case one specifically optimized for low-power applications. The other low-power key to this build is the small seven-segment e-ink display. The segments are oriented as horizontal lines, making this a great indicator for measuring a varying gradient of any type. The microcontroller only wakes up every 15 minutes, takes a measurement, and then updates the display before going back to sleep.

To solve the problem resistive moisture sensors have where they’re directly in contact with damp conditions and rapidly corrode, [David] is using a capacitive sensor instead which measures a changing capacitance as moisture changes. This allows the contacts to be much more isolated from the environment. The sensor has been up and running for a few months now with the coin cell driving the system still going strong and the house plants still alive and properly watered. Of course if you’re looking to take your houseplant game to the next level you could always build a hydroponics system which automates not only the watering of plants but everything else as well.

GPS is an incredible piece of modern technology. Not only does it allow for locating objects precisely anywhere on the planet, but it also enables the turn-by-turn directions we take for granted these days — all without needing anything more than a radio receiver and some software to decode the signals constantly being sent down from space. [Chris] took that last bit bit as somewhat of a challenge and set off to write a software-defined GPS receiver from the ground up.

As GPS started as a military technology, the level of precision needed for things like turn-by-turn navigation wasn’t always available to civilians. The “coarse” positioning is only capable of accuracy within a few hundred meters so this legacy capability is the first thing that [Chris] tackles here. It is pretty fast, though, with the system able to resolve a location in 24 seconds from cold start and then displaying its information in a browser window. Everything in this build is done in Python as well, meaning that it’s a great starting point for investigating how GPS works and for building other projects from there.

The other thing that makes this project accessible is that the only other hardware needed besides a computer that runs Python is an RTL-SDR dongle. These inexpensive TV dongles ushered in a software-defined radio revolution about a decade ago when it was found that they could receive a wide array of radio signals beyond just TV.

On paper, electricity behaves in easy-to-understand, predictable ways. That’s mostly because the wires on the page have zero resistance and the switching times are actually zero, whereas in real life neither of these things are true. That’s what makes things like switch-mode power supplies (SMPS) difficult to build and troubleshoot. Switching inductors and capacitors tens or hundreds of thousands of times a second (or more) causes some these difficulties to arise when these devices are built in the real world. [FesZ Electronis] takes a deep dive into some of the reasons these difficulties come up in this video.

The first piece of electronics that can generate noise in an SMPS are the rectifier diodes. These have a certain amount of non-ideal capacitance as well as which causes a phenomenon called reverse current, but this can be managed by proper component choice to somewhat to limit noise.

The other major piece of silicon in power supplies like this that drives noise are the switching transistors. Since the noise is generally caused by the switching itself, there is a lot that can be done here to help limit it. One thing is to slow down the amount of time it takes to transition between states, limiting the transients that form as a result of making and breaking connections rapidly. The other, similar to selecting diodes, is to select transistors that have properties (specifically relating to inherent capacitances) that will limit noise generation in applications like this.

Of course there is a lot more information as well as charts and graphs in [FesZ]’s video. He’s become well-known for deep dives into practical electrical engineering topics like these for a while now. We especially like his videos about impedance matching as well as a more recent video where he models a photovoltaic solar panel in SPICE.

Astrophotography, and astronomy in general, takes some fairly specialized tools and a high amount of precision. Setting up the equipment can also take a lot of time, especially for amateurs traveling to various locations with their equipment, so anything that can reduce the amount of time spent looking for objects and increasing the amount of time looking at them is a welcome addition, especially since nights where conditions are ideal for these activities can be rare. [Anton] developed this real-time tracking tool for deep sky objects (DSOs) to keep tabs on most of the interesting things out there a telescope can be pointed at.

[Anton] calls his tool the Nova DSO Altitude Tracker and gets its information from SIMBAD, updating every minute for a given location on the planet. With that location data, the program calculates altitude and azimuth for various objects and also helps the user keep track of other important variables like moon illumination and angle above the horizon. It also allows the user to highlight specific objects of interest, making sure they are front and center throughout the session. Each DSO can be selected from a list to display detailed information about it such as its path, time visible in the sky, and other properties.

To get the program running, essentially all that’s required is a computer capable of running Python and a display of some sort. From there it provides a quick view of the best objects to point one’s telescope or camera at without any guesswork. With all of the code available it shouldn’t be too much of a leap to do other things with the underlying software, either, such as tying it into a tracker of some sort like this DIY telescope tracking device we featured a while back.

Perhaps every gardener to attempt to grow a tomato, lettuce, or bean has had to contend with animals trying to enjoy the food before the gardener themselves can, whether it’s a groundhog, rabbit, mouse, crow, or even iguana. There are numerous ways to discourage these mischievous animals from foraging the garden beds including traps, but these devices have their downsides as well. False alarms can be a problem as well as trapping animals that will be overly aggravated to be inside the trap (like skunks) and while the latter problem can’t easily be solved by technology, the former can with the help of Meshtastic.

[Norman Jester]’s problem was an errant possum, but these nocturnal animals generally come out while humans are asleep, and other nighttime animals like rats can activate the trap and then escape. To help with this, a Meshtastic node was added to the San Diego mesh using a 3.5mm audio jack as a detector. When the trap is activated, the closing door yanks a plug out of the jack, alerting the node that the trap has been closed. If it’s a false alarm the trap can be easily and quickly reset, and if a possum has found its way in then it can be transported to a more suitable home the next day.

It’s worth noting that American possums (distinct from the Australian animals of the same name) are an often-misunderstood animal that generally do more good than harm. They help to control Lyme disease, eat a lot of waste that other animals won’t, don’t spread rabies, and don’t cause nearly as much disruption to human life as other animals like feral cats or raccoons. But if one is upsetting a garden or another type of animal is causing a disturbance, this Meshtastic solution does help solve some of the problems with live traps. For smaller animals, though, take a look at this Arudino-powered trap instead.

Thanks to [Dadsrcworkbench] for the tip!

The Enigma machine is perhaps one of the most legendary devices to come out of World War II. The Germans used the ingenious cryptographic device to hide their communications from the Allies, who in turn spent an incredible amount of time and energy in finding a way to break it. While the original Enigma was a complicated electromechanical contraption, [DrMattRegan] recently set out to show how its operation can be replicated with an EPROM.

The German Enigma machine was, for the time, an extremely robust way of coding messages. Earlier versions proved somewhat easy to crack, but subsequent machines added more and more complexity rendering them almost impenetrable. The basis of the system was a set of rotors which encrypted each typed letter to a different one based on the settings and then advanced one place in their rotation, ensuring each letter was encrypted differently than the last. Essentially this is a finite-state machine, something perfectly suited for an EPROM. With all of the possible combinations programmed in advance, an initial rotor setting can be inputted, and then each key press is sent through the Enigma emulator which encrypts the letter, virtually advances the rotors, and then moves to the next letter with each clock cycle.

[DrMattRegan]’s video, also linked below, goes into much more historical and technical detail on how these machines worked, as well as some background on the British bombe, an electromechanical device used for decoding encrypted German messages. The first programmable, electronic, digital computer called Colossus was also developed to break encrypted Enigma messages as well, demonstrating yet another technology that came to the forefront during WWII.

Thanks to [Clint] for the tip!

Modern e-readers such as the Amazon Kindle are incredible pieces of engineering, but that doesn’t mean there’s no room for improvement. A device custom-built to your own specifications is always going to provide a more satisfying experience than something purchased off the shelf. That’s why [fel88] put together this custom e-reader which offers a number of unique features, such as a solar panel on the back and button-free operation.

One issue with modern e-readers, at least as [fel88] sees it, is that they have a lot of unnecessary features. This project removes most of them, stripping down the device to its core functionality: a straightforward menu for selecting books and gesture-sensing for navigating the menu as well as changing the pages. The only physical input on the device is a small reed switch to turn the device on. A 3D printed case holds the e-ink display and encloses the inner workings, driven by an Arduino Mega 2560 and powered by three lithium-ion capacitors (LICs) and a small solar panel.

By dropping all of the unnecessary features, the device doesn’t need to waste energy with things like WiFi or Bluetooth and can get around 880 pages on a single charge, not counting any extra energy coming in through the solar panel while it’s operating. The LICs will also theoretically improve its life cycle as well. If you’re still stuck with a paperweight when you formerly had a working e-reader, though, there are plenty of ways to bring old devices back to life as well.

Despite a general lack of real-world experience, many teenagers are overly confident in their opinions, often to the point of brashness and arrogance. In the late 90s and early 00s I was no different, firmly entrenched in a clichéd belief that Apple computers weren’t worth the silicon they were etched onto—even though I’d never actually used one. Eventually, thanks to a very good friend in college, a bit of Linux knowledge, and Apple’s switch to Intel processors, I finally abandoned this one irrational belief. Now, I maintain an array of Apple laptops for my own personal use that are not only surprisingly repairable and hacker-friendly but also serve as excellent, inexpensive Linux machines.

Of course, I will have ruffled a few feathers suggesting Apple laptops are repairable and inexpensive. This is certainly not true of their phones or their newer computers, but there was a time before 2016 when Apple built some impressively high quality, robust laptops that use standard parts, have removable batteries, and, thanks to Apple dropping support for these older machines in their latest operating systems, can also be found for sale for next to nothing. In a way that’s similar to buying a luxury car that’s only a few years old and letting someone else eat the bulk of the depreciation, a high quality laptop from this era is only one Linux install away from being a usable and relatively powerful machine at an excellent bargain.

The History Lesson

To be fair to my teenage self though, Apple used to use less-mainstream PowerPC processors which meant there was very little software cross-compatibility with x86 PCs. It was also an era before broadband meant that most people could move their work into cloud and the browser, allowing them to be more agnostic about their operating system. Using an Apple when I was a teenager was therefore a much different experience than it is today. My first Apple was from this PowerPC era though; my ThinkPad T43 broke mid-way through college and a friend of mine gave me an old PowerBook G4 that had stopped working for her. Rather than have no computer at all, I swallowed my pride and was able to get the laptop working well enough to finish college with it. Part of the reason this repair was even possible was thanks to a major hacker-friendly aspect of Apple computers: they run Unix. (Note for commenters: technically Apple’s OS is Unix-like but they have carried a UNIX certification since 2007.)

I had used Unix somewhat in Solaris-based labs in college but, as I mentioned in a piece about installing Gentoo on one of my MacBooks, I was also getting pretty deep into the Linux world at the time as well. Linux was also designed to be Unix-like, so most of the basic commands and tools available for it have nearly one-to-one analogs in Unix. The PowerBook’s main problem, along with a battery that needed a warranty replacement, was a corrupted filesystem and disk drive that I was able to repair using my new Linux knowledge. This realization marked a major turning point for me which helped tear down most of my biases against Apple computers.

Over the next few years or so I grew quite fond of the PowerBook, partially because I liked its 12″, netbook-like form factor and also because the operating system never seemed to crash. As a Linux user, my system crashes were mostly self-inflicted, but they did happen. As a former Windows user as well, the fact that it wouldn’t randomly bluescreen itself through no fault of my own was quite a revelation. Apple was a few years into their Intel years at this point as well, and seeing how easily these computers did things my PowerBook could never do, including running Windows, I saved up enough money to buy my first MacBook Pro, a mid-2009 model which I still use to this day. Since then I’ve acquired four other Apple laptops, most of which run Linux or a patched version of macOS that lets older, unsupported machines run modern versions of Apple’s operating system.

So if you’ve slogged through my coming-of-age story and are still curious about picking up an old Mac for whatever reason—a friend or family member has one gathering dust, you’re tired of looking at the bland styling of older ThinkPads while simultaneously growing frustrated with the declining quality of their newer ones, or just want to go against the grain a bit and do something different—I’ll try and help by sharing some tips and guidelines I’ve picked up through the years.

What to Avoid

Starting with broad categories of older Apple laptops to avoid, the first major red flag are any with the butterfly keyboard that Apple put on various laptops from 2015 to 2019 which were so bad that a number of lawsuits were filed against them. Apple eventually relented and instituted a replacement program for them, but it’s since expired and can cost hundreds of dollars to fix otherwise. The second red flag are models with the T2 security chips. It’s not a complete dealbreaker but does add a lot of hassle if the end goal is a working Linux machine.

Additionally, pay close attention to any laptops with discrete graphics cards. Some older MacBooks have Nvidia graphics, which is almost always going to provide a below-average experience for a Linux user especially for Apple laptops of this vintage. Others have AMD graphics which do have better Linux support, but there were severe problems with the 15″ and 17″ Mac around the 2011 models. Discrete graphics is not something to avoid completely like laptops with butterfly keyboards, but it’s worth investigating the specific model year for problems if a graphics card is included. A final note is to be aware of “Staingate” which is a problem which impacted some Retina displays between 2012 and 2015. This of course is not an exhaustive list, but covers the major difficult-to-solve problems for this era of Apple laptop.

What to Look For

As for what specific computers are the best from this era for a bit of refurbishment and use, in my opinion the best mix of performance, hackability, and Linux-ability will be from the 2009-2012 Unibody era. These machines come in all sizes and are surprisingly upgradable, with standard SODIMM slots for RAM, 2.5″ laptop drives, an optical drive (which can be changed out for a second hard drive), easily replaceable batteries if you can unscrew the back cover, and plenty of ports. Some older models from this era have Core 2 Duo processors and should be avoided if you have the choice, but there are plenty of others from this era with much more powerful Core i5 or Core i7 processors.

After 2012, though, Apple started making some less-desirable changes for those looking to maintain their computers long-term, like switching to a proprietary M.2-like port for their storage and adding in soldered or otherwise non-upgradable RAM, but these machines can still be worthwhile as many had Core i7 processors and at least 8 GB of RAM and can still run Linux and even modern macOS versions quite capably. The batteries can still be replaced without too much hassle as well.

Of course, a major problem with these computers is that they all have processors that have the Intel Management Engine coprocessor installed, so they’re not the most privacy-oriented machines in existence even if Linux is the chosen operating system. It’s worth noting, though, that some MacBooks from before the unibody era can run the open-source bootloader Libreboot but the tradeoff, as with any system capable of running Libreboot, is that they’re a bit limited in performance even compared to the computers from just a few years later.

Out of the five laptops I own, four are from the pre-butterfly era including my two favorites. Topping the list is a mid-2012 13″ MacBook Pro with Intel graphics that’s a beast of a Debian machine thanks to upgrades to a solid state drive and to 16 GB of RAM. It also has one of the best-feeling laptop keyboards I’ve ever used to write with, and is also the computer I used to experiment with Gentoo.

Second place goes to a 2015 11″ MacBook Air which is a netbook-style Apple that I like for its exceptional portability even though it’s not as upgradable as I might otherwise like. It will have 4 GB of RAM forever, but this is not much of a problem for Debian. I also still have my 2009 MacBook Pro as well, which runs macOS Sonoma thanks to OpenCore Legacy Patcher. This computer’s major weakness is that it has an Nvidia graphics card so it isn’t as good of a Linux machine as the others, and occasionally locks up when running Debian for this reason. But it also has been upgraded with an SSD and 8 GB of RAM so Sonoma still runs pretty well on it despite its age. Sequoia, on the other hand, dropped support for dual-core machines so I’m not sure what I will do with it after Sonoma is no longer supported.

My newest Apple laptop is an M1 MacBook Air, which I was excited about when it launched because I’m a huge fan of ARM-based personal computers for more reasons than one. Although the M1 does have essentially no user-repairability unless you want to go to extremes, I have some hope that this will last me as long as my MacBook Pros have thanks to a complete lack of moving parts and also because of Asahi Linux, a version of Fedora which is built for Apple silicon. Whenever Apple stops providing security patches for this machine, I plan to switch it over to this specialized Linux distribution.

Why Bother?

But why spend all this effort keeping these old machines running at all? If repairability is a major concern, laptops from companies like System76 or Framework are arguably a much better option. Not to mention that, at least according to the best Internet commenters out there, Apple computers aren’t supposed to be fixable, repairable, or upgradable at all. They’re supposed to slowly die as upgrades force them to be less useful.

While this is certainly true for their phones and their more modern machines to some extent, part of the reason I keep these older machines running is to go against the grain and do something different, like a classic car enthusiast who picks a 70s era Volkswagen to drive to and from the office every day instead of a modern Lexus. It’s also because at times I still feel a bit like that teenager I was. While I might be a little wiser now from some life experiences, I believe some amount of teenage rebellion can be put to use stubbornly refusing to buy the latest products year after year from a trillion-dollar company which has become synonymous with planned obsolescence. Take that, Apple!

Unless you handle the backups for a large corporation, bank, or government entity, you likely haven’t stored much data to tape recently. But magnetic storage used to be fairly mainstream back in the 1980s for all kinds of computer programs. Plenty of computers used standard cassette tapes for this too but you couldn’t just copy them with standard audio equipment. You’d need something like this 1560 datasette from [Jan].

The core problem with using Hi-Fi equipment to copy tapes storing data instead of audio is that data tapes need to be much more precise in order to avoid losses that might not be noticeable in an audio recording. In the 80s computer companies like Commodore built tape drives specifically for their computers, so [Jan]’s project uses two of these 1530 drives to build this “1560” datasette. (No working 1530 hardware was harmed in this build.) An inverter circuit in one tape deck is used to provide the signal to write the data to the other tape, reliably copying data from these data tapes in a way Hi-Fi never could.

[Jan] does lament not having something like this back in the 80s when the Commodore was in its heyday, but there’s still a dedicated retrocomputing scene for these machines that will get plenty of use out of projects like this. If you need to go the other direction in time, there are also interfaces that allow data tapes from old Commodores to be read by modern computers with USB.

In the rush to always have the latest and greatest, it’s not uncommon that perfectly serviceable hardware ends up collecting dust in a drawer somewhere. If you’ve got an old Kindle laying around, you may be interested in this write-up from [Hemant] that shows a practical example of how the popular e-reader can be pushed into service as a weather dashboard.

The first step is to jailbreak the Kindle, providing the user with root access to the device. From there the Kindle Unified Application Launcher (KUAL) is installed along with USBNetwork which allows you to connect to the reader over SSH. With root access and a network connection, the real project of converting it to a weather dashboard begins. [Hemant] split the project into two parts here, a Node.js server that scrapes weather data from the internet and converts it into an image, and a client for the Kindle that receives this image for display.

The Kindle has a number of quirks and issues that [Hemant] covers as well, including handling image ghosting on the e-ink display as well as a problem where the device will hang if the Internet connection is lost. For those with jailbroken Kindles that want to put their devices back into useful service, this is an excellent guide for getting started and [Hemant] also provided all of the source code on the project’s GitHub page.

There has been a long tradition of using Kindles for things other than e-readers, and even devices with major hardware problems can still have useful life in them thanks to this project which allows the e-ink display to have a second life on its own.

Every few years or so, a development in computing results in a sea change and a need for specialized workers to take advantage of the new technology. Whether that’s COBOL in the 60s and 70s, HTML in the 90s, or SQL in the past decade or so, there’s always something new to learn in the computing world. The introduction of graphics processing units (GPUs) for general-purpose computing is perhaps the most important recent development for computing, and if you want to develop some new Python skills to take advantage of the modern technology take a look at this introduction to CUDA which allows developers to use Nvidia GPUs for general-purpose computing.

Of course CUDA is a proprietary platform and requires one of Nvidia’s supported graphics cards to run, but assuming that barrier to entry is met it’s not too much more effort to use it for non-graphics tasks. The guide takes a closer look at the open-source library PyTorch which allows a Python developer to quickly get up-to-speed with the features of CUDA that make it so appealing to researchers and developers in artificial intelligence, machine learning, big data, and other frontiers in computer science. The guide describes how threads are created, how they travel along within the GPU and work together with other threads, how memory can be managed both on the CPU and GPU, creating CUDA kernels, and managing everything else involved largely through the lens of Python.

Getting started with something like this is almost a requirement to stay relevant in the fast-paced realm of computer science, as machine learning has taken center stage with almost everything related to computers these days. It’s worth noting that strictly speaking, an Nvidia GPU is not required for GPU programming like this; AMD has a GPU computing platform called ROCm but despite it being open-source is still behind Nvidia in adoption rates and arguably in performance as well. Some other learning tools for GPU programming we’ve seen in the past include this puzzle-based tool which illustrates some of the specific problems GPUs excel at.