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+.
With MCUs becoming increasingly more powerful it was only a matter of time before they would enable some more serious audio-processing tasks. [Danilo Gabriel]’s ESP32Synth library is a good example here, which provides an ESP-IDF based 80+ voice mixing and synthesis engine. If you ever wanted to create a pretty impressive audio synthesizer, then all you really need to get started is an ESP32, ESP32-S3 or similar dual-core Espressif MCU that has the requisite processing power.
Audio output goes via I2S, requiring only a cheap I2S DAC like the UDA1334A or PCM5102 to be connected, unless you really want to use the internal DAC. With this wired up you get 80 voices by default, with up to 350 voices demonstrated before the hardware cannot keep up any more. You can stream multiple WAV files from an SD card for samples along with the typical oscillators like sinewave, triangle, sawtooth and pulse, as well as noise, wavetables and more.
In order to make this work in real-time a number of optimizations had to be performed, such as the removal of slow floating-point and division operations in the audio path. The audio rendering task is naturally pinned to a single core, leaving a single core for application code to use for remaining tasks. While the code is provided as an Arduino project, it uses ESP-IDF so it can likely be used for a regular ESP-IDF project as well without too much fuss.
There’s little point in setting up your own shed-based clean room for semiconductor purposes if you don’t try to do something practical with it. Something like responding to the RAMpocalypse by trying to make your own RAM, for example.
Testing the DRAM cells. (Credit: Dr. Semiconductor, YouTube)
After all, what could be so hard about etching the same repeating structures over and over? In a recent video, [Dr. Semiconductor]’s experience doing exactly this are detailed, with actual DRAM resulting at the end.
We covered the construction of the clean room shed previously, which should provide at least the basic conditions to produce semiconductors without worrying about contaminating dies. From here the process is reminiscent of etching PCBs, with a prepared surface coated with photoresist. Using UV exposure through a mask, the pattern is etched into the photoresist and from there the pattern is subsequently etched into the wafer’s surface.
With the patterns formed, the next step is doping of the silicon in order to create the active structures, i.e. the transistors and capacitors. Doping can be done in a variety of ways, with ion implantation being the industry standard method, but a bit too expensive and bulky for a shed fab. Instead a spin-on-glass method was used. After this the remaining functional structures can be built up.
If anyone was expecting to see a DDR5 DRAM die pop out at the end, they’re bound to be disappointed. The target here was to create a 5×4 array of DRAM cells, for a dizzying 20 bits. Still, the fact that it’s possible to DIY DRAM like this at home is already pretty awesome, with clearly plenty of room to push it towards and past fabrication nodes of the 1990s and beyond.
Although the produced DRAM cells have fairly leaky capacitors, they’re good enough for their purpose, and the plan is to scale up to a large DRAM array from here. Whether the DRAM control logic will also be implemented in hardware like this remains to be seen, but the video’s ending makes it clear that the goal is to attach it to a PC somehow.
In the ongoing development of cancer immunotherapy, as well as our still developing understanding of the human immune system, there’s always been a bit of massive elephant in the room. The thing about human bodies is that they’re not just human cells, but also consist of trillions of bacteria that mostly live in the intestines. What effect these bacteria have on the immune system’s functioning and from there on immunotherapies was recently investigated by [Tariq A. Najar] et al., with an article published in Nature.
The relevant topic here is that of antigenic mimicry, involving microbial antigens that resemble self-antigens. Since these self-antigens are a crucial aspect of both autoimmune diseases and cancer immunotherapy there is considerable room for interaction with their microbial mimics. Correspondingly these mimics can have considerable negative as well as positive implications, ranging from potentially triggering an autoimmune condition to hindering or boosting cancer immunotherapy.
In this study mice were used to investigate the effect of such microbial interference, in particular focusing on immune checkpoint blockade (ICB), which refers to negative feedback responses within the immune system that some cancers use to protect themselves. In some immunotherapy patients ICB inhibiting using e.g. anti programmed cell death protein (anti-PD-1) treatment does not provoke a response for some reason.
For the study mice had tumors implanted and the effect of a particular microbe (segmented filamentous bacteria, SFB) on it studied, with the presence of it markedly improving the response to anti-PD-1 treatment due to anti-gens expressed by SFB despite the large gut-skin distance. Whether in humans similar mechanisms play a similarly strong role remains to be investigated, but it offers renewed hope that cancer immunotherapies like CAR T-cell immunotherapy will one day make cancer an easily curable condition.
When [OGS Mechanics] got a Mercedes EQC 300 battery-electric car in for repair, it was found to have a bit of a weird issue: after sitting in a garage for a while, its range on battery had suddenly reduced significantly without clear cause. Although the typical response here is to just mark the battery pack as ‘faulty’ and replace the whole unit, [OGS] decided to dig into the pack to see what was going on.
The short version is that this particular battery pack consists of two individual batteries, each with its own BMS, one of which had reported a condition to the master BMS that triggered the ‘replace battery module’ error observed with the scan tool. From this it could also be seen that the first battery was at a 10% state-of-charge (SoC), and the second at 95%, making them incredibly unbalanced. Unfortunately the dealer procedure to rebalance did not work here, with only the second battery wanting to charge even after draining both to the same initial level.
To diagnose the underlying issue in earnest required gently prying open the battery pack like a massive glued-shut smartphone. Going by the theory that it is a software glitch, since the first battery was still at a healthy voltage level, it was decided to manually charge it. With both batteries now fully charged, the BMS for the first battery was then removed to have its memory overwritten with that of a known good BMS module, clearing the ‘replace battery module’ error.
Although in the preview for the next video it’s hinted that there’s also an internal balancing issue in the first battery pack, this could be another symptom of its BMS glitching out. Either way, it would seem that BEVs battery modules are both heavily dependent on software, as well as afflicted by the same throw-away culture that has people just buying a new smartphone when the battery fails.
The Angle Computer of the B-52, opened. (Credit: Ken Shirriff)
In the ages before convenient global positioning satellites to query for one’s current location military aircraft required dedicated navigators in order to not get lost. This changed with increasing automation, including the arrival of increasingly more sophisticated electromechanical computers, such as the angle computer in the B-52 bomber’s star tracker that [Ken Shirriff] recently had a poke at.
We covered star trackers before, with this devices enabling the automation of celestial navigation. In effect, as long as you have a map of the visible stars and an accurate time source you will never get lost on Earth, or a few kilometers above its surface as the case may be.
The B-52’s Angle Computer is part of the Astro Compass, which is the star tracker device that locks onto a star and outputs a heading that’s accurate to a tenth of a degree, while also allowing for position to be calculated from it. Inside the device a lot of calculations are being performed as explained in the article, though the full equations are quite complex.
Not burdening the navigator of a B-52 with having to ogle stars themselves with an instrument and scribbling down calculations on paper is a good idea, of course. Instead the Angle Computer solves the navigational triangle mechanically, essentially by modelling the celestial sphere with a metal half-sphere. The solving is thus done using this physical representation, involving numerous gears and other parts that are detailed in the article.
In addition to the mechanical components there are of course the motors driving it, feedback mechanisms and ways to interface with the instruments. For the 1950s this was definitely the way to design a computer like this, but of course as semiconductor transistors swept the computing landscape, this marvel of engineering would before long find itself too replaced with a fully digital version.
