It seems to be becoming a bit of a theme that consumer electronics are dying not due to some critical fault, but due to Cooked Capacitor Syndrome (CCS). Case in point, Dyson handheld vacuums and the capacitors on its driver board. After having his $800 Dyson V15 handheld vacuum die after two and a half years of regular use, [LeftyMaker] found himself elbows-deep in the dusty innards of the vacuum just to replace some capacitors.
As unloved as IBM’s PCjr was, with only a one-year production run, it’s hard to complain about the documentation available for it. This includes the x86 assembly listing for the BIOS, which [dbalsom] recently used this print version to create an ASM project that can be built into a byte-identical copy of the PCjr BIOS.
In order to build the BIOS image, a ZIP file has been made available that contains the requisite assembler and linker tools, all of which can be run in DOS (or DOSBox) using the provided build.bat file. This creates an executable file, which can then be converted into a BIN file using the provided exe2bin.py Python script, or of course, manually.
A lot has been made about a post-quantum computer future in which traditional encryption methods have suddenly been rendered obsolete. With this terrifying idea in mind, it’s reassuring to see some recent pushback to the idea with some factual evidence. In a recent blog post by [Filippo Valsorda] – a cryptography engineer – the point is raised that 128-bit symmetric keys like AES-128 and hashing algorithms like SHA-256 are not at risk of being obliterated in a post-quantum future.
Rather than just taking [Filippo]’s word for it, he takes us through a detailed explanation of the flawed understanding of Grover’s algorithm that underlies much of the panic. While it’s very true that this quantum search algorithm can decrease the amount of time required to find a solution, the speed-up with a single thread is quadratic, not exponential. While asymmetric cryptography systems like ECDH, RSA, and kin are very much at risk courtesy of Shor’s algorithm, the same is not true for symmetric systems.
An interesting detail with Grover’s is also that you cannot simply run a search in parallel to get a corresponding speed-up, as it’s not a parallel problem. Barring a breakthrough that replaces Grover’s with something that lends itself better to such a parallel search, it would seem that we won’t have to abandon classical encryption any time soon.
Incidentally, even for Shor’s algorithm, there are still some hold-ups. Current quantum computers are not even able to factor 21 yet. Meanwhile, supposed quantum computing breakthroughs are being trolled with a Commodore 64.
One of the nice things about magnetic storage is that as long as the magnetic layer remains intact, the data it contains should stay readable pretty much indefinitely. That raises the prospect of recovering data from really old computer systems featuring magnetic memory, such as the 63-year old LGP-21 that [David Lovett] of Usagi Electric is currently restoring. Its magnetic memory disk is nothing amazing by modern standards, but after initial testing it seems to spin up and read data just fine, raising the question of what was left on the drive when it was last used, meaning what was in memory at the time.
The read/write head side of the LGP-21’s magnetic memory. (Credit: Usagi Electric, YouTube)
Non-invasive data recovery here involves writing a program that will simply read the entire disk from beginning to end. Tracks 0 and 1 were found to be unreadable due to some kind of hardware issue, but track 2 could be backed up by looking at the output on the CRT, thus providing a track to use. Fascinatingly the LGP-21’s memory disks uses interleaved tracks to reduce the number of read/write heads as part of the overall cost-saving measures relative to the more expensive LGP-30. As you might expect, this slows down memory access a lot over its big brother.
Before any recovery attempt could begin, the Flexowriter typewriter that forms the user interface to the computer had to be given some serious maintenance, along with a few other components like a switch and the paper tape reader. This restored the ability to even properly enter data and receive output instructions.
The subsequent effort to recover the stored data involved a bootstrap program that got loaded into memory, after which the remainder of the program was loaded from paper tape. Following this everything worked swimmingly, though with the caveat that with not even a floppy drive to use, the raw hexadecimal data was hammered out on paper with the Flexowriter over the course of 1.5 hours.
This data will now be scanned in and OCR-ed into something that can hopefully be easily analyzed. Hopefully we’ll know before long what this system was last used for.
Recently Haiku has become a bit of a popular subject of articles and videos, owing perhaps to how close it currently is to be a daily-driver OS and fulfilling the dream that BeOS set out with. That said, there are still quite a few hurdles before that glorious era can fully commence, with a video by [Ex-IT guy] on YouTube demonstrating some of the major hurdles by installing Haiku on Ryzen 3-based MiniPC that only supports UEFI boot.
Installing the UEFI bootloader is still a very much manual process with the user required to create UEFI boot and OS partitions before copying the bootloader into UEFI boot partition. After this Haiku can be installed as normal. The other variation of multi-boot is demonstrated in the video, with Haiku installed alongside Windows and Linux. This requires a more complex directory layout in the UEFI boot partition.
The other major hurdle with Haiku comes after the system boots into the OS following installation, with no driver available for the Vega-based iGPU as AMD GPU support peters out around the GCN 2 era for now. Without accelerated graphics the utility of an OS is quite diminished, but fortunately this seems to be a fixable issue considering that Linux has the appropriate GPU support.
Meanwhile features like sound worked out of the box, which makes it arguably a more pleasant experience than installing Haiku on a 2009 Mac Mini. It’s also very easy to port software from Linux to Haiku, often with very few changes since it has all the typical POSIX things.
As part of the effort to push Large Language Model (LLM) ‘AI’ into more and more places, Anthropic’s Model Context Protocol (MCP) has been adopted as the standard to connect LLMs with various external tools and systems in a client-server model. A light oversight with the architecture of this protocol is that remote command execution (RCE) of arbitrary commands is effectively an essential part of its design, as covered in a recent article by [OX Security].
The details of this flaw are found in a detailed breakdown article, which applies to all implementations regardless of the programming language. Essentially the StdioServerParameters that are passed to the remote server to create a new local instance on said server can contain any command and arguments, which are executed in a server-side shell.
Considering that Windows NT has the concept of so-called ‘subsystems’ whereby you can run different systems side-by-side, starting with the POSIX subsystem and later the Windows Subsystem for Linux (WSL), it was probably only a matter of time before someone figured that doing this with Windows 9x was also completely reasonable. Ergo we now got [Hailey Somerville]’s Linux Subsystem for Windows.
To make running Linux inside Windows 9x work, it was necessary to heavily patch a Linux kernel, as normally there are no provisions for such a subsystems in Windows 9x’s kernel unlike the NT kernel. Correspondingly, the Linux kernel is based on user-mode Linux and hacked to call Windows 9x kernel APIs instead of the POSIX ones.
In order to use WSL9x you thus need to build said modified Linux kernel – currently at version 6.19 – along with a disk image containing an installed copy of Windows 9x. From there WSL9x can be loaded with the wsl command and you’re then free to cooperatively run the Win9x and Linux kernel side-by-side. This is reminiscent of Cooperative Linux (coLinux), which did something similar except with Windows NT and Linux kernels running side-by-side, and of course we have WSL2 with Windows 10+.
