Saying that it was finally time for the community to bid a “fond but firm farewell to Python 2”, core developer Benjamin Peterson marked the release of Python 2.7.18 on April 20th; officially ending support for the 2.x branch of the popular programming language. It was hardly a snap decision. Python 3.0 was released all the way back in December 2008, and it was never a secret that the newer branch was not only incompatible with the earlier version, but that it would eventually superseded it to become the standard.
But migrating the incredible amount of Python code in the wild over to the latest and greatest was easier said than done. Millions upon millions of lines of code used in everything from Linux distributions to virtually every major web service needed to be reviewed and migrated over to Python 3. In many cases the changes were relatively minor, but when code is being used in mission critical applications, even the smallest of changes are often avoided unless it’s absolutely necessary. The voluntary migration took far longer than expected, and the end-of-life (EOL) for Python 2 was pushed back by years to accommodate developers who hadn’t made the necessary changes yet.
Given the somewhat fluid nature of the Python 2 EOL date, it seems fitting that this last final release would come several months after the “official” January 2020 deadline. The intention was for it to coincide with PyCon 2020, but just like so many of the events planned for the first half of the year, the in-person conference had to be canceled in favor of a virtual one due to the COVID-19 epidemic. That might have stymied the celebration somewhat, but the release of Python 2.7.18 will still be looked on as a special moment for everyone involved.
The particular part shown is the Lascar EM32-4-LED, which up and died in a unique piece of equipment. The trouble is that the EM32-4-LED is out of production and unobtainable, and the Programmable Logic Controller (PLC) that drives the whole thing is a black box that cannot be modified. It’s very good news that a datasheet exists, but that’s often just a starting point. To create a one-off, drop-in solution requires a combination of research, troubleshooting, and design work.
To do this, [JGlass] starts off by walking through datasheet elements and explains that it’s important to build a high level understanding of function first, then drill down into details, and always be ready to verify, challenge, or throw out one’s assumptions. After establishing a high level understanding comes matching physical evidence to things like block and functional diagrams, then cracking open the faulty component to see if anything else can be learned. Only then are multimeters and probes taken out for more active research. All of this sleuthing must always be done with the end goal firmly in mind: creating a new device that acts like the one being replaced. Without focus, one can easily get lost in details and unknowns.
Reverse Engineering is a process, and the more tools, the better. If you missed our earlier post about a hacker’s guide to JTAG, here’s your chance to check it out and be all the more prepared for the next time you need to do some electron detective work of your own.
An old laptop or desktop computer that’s seen better days might still have a little bit of use left in it for a dedicated task. Grabbing a lightweight flavor of Linux and running a web server, firewall, or Super Nintendo emulator might get a few more years out of it. You can also get pretty creative repurposing obsolete single purpose machines, as [Kristjan] did with some old Cisco server equipment.
The computer in question isn’t something commonly found, either. It’s an intrusion detection system meant to mount in a server rack and protect the server itself from malicious activity. While [Kristjan] mentions that Cisco equipment seems to be the definition of planned obsolescence, we think that this Intel Celeron machine with an IDE hard drive may have gone around the bend quite some time ago. Regardless, it’s modern enough to put back to work in some other capacity.
To that end, a general purpose operating system was installed, and rather than use Linux he reached for BSD to get the system up and running. There’s one other catch, though, besides some cooling issues. Since the machine was meant to be used in a server, there’s no ACPI which means no software shutdown capability. Despite all the quirks, you can still use it to re-implement a network security system if you wanted to bring it full-circle.
The common belief is that big companies are out to get the little people by making products that break after a short period, or with substantially new features or accessories that make previous models obsolete, requiring the user to purchase a new model. This conspiracy theory isn’t true; there’s a perfectly good explanation for this phenomenon, and it was caused by the consumers, not the manufacturers.
When we buy the hottest, shiniest, smallest, and cheapest new thing we join the wave of consumer demand that is the cause of what often gets labelled as “Planned Obsolescence”. In truth, we’re all to blame for the signals our buying habits send to manufacturers. Dig in and get your flamewar fingers fired up.
Inspired by [James Houston]’s remix of Radiohead’s Nude on obsolete hardware, [bd594] put together this mix of Lipps Inc.’s Funkytown. No sampling was used, but he had to loop the footage of the Avaya dot matrix printer’s drum part because it shook the table too much. The guitar and bass line are performed by a Commodore 64. An Intel 14.4 external modem uses DTMF tones for the first part of of the lead and a TI-99/4A beeps out the rest. The TI is also used as a speech synthesizer and a Maxtor harddrive plays the the vocal track.