Trying A Vibe-Coded Operating System

If you were to read the README of the Vib-OS project on GitHub, you’d see it advertised as a Unix-like OS that was written from scratch, runs on ARM64 and x86_64, and comes with a full GUI, networking and even full Doom game support. Unfortunately, what you are seeing there isn’t the beginnings of a new promising OS that might go toe to toe with the likes of Linux or Haiku, but rather a vibe-coded confabulation. Trying to actually use the OS as [tirimid] recently did sends you down a vibe-coded rabbit hole of broken code, more bugs than you can shake a bug zapper at, and most of the promised features being completely absent.

[tirimid] is one of those people who have a bit of a problem, in that they like to try out new OSes, just to see what they’re like. The fun starts with simply making the thing run at all in any virtual machine environment, as apparently the author uses MacOS and there it probably ‘runs fine’.

After this the graphical desktop does in fact load, some applications also open, but it’s not possible to create new folders in the ‘file explorer’, the function keys simply switch between wallpapers, there’s no networking or Doom support despite the promises made, there’s no Python or Nano support at all, and so on.

Clearly it’s still got the hallmarks of a functioning OS, and it’s sort of nice that you don’t need to know what you’re doing to create a sort-of-OS, but it will not appease those who feel that vibe-coding is killing Open Source software.

Continue reading “Trying A Vibe-Coded Operating System”

Creating An Ultra-Stable Lunar Clock With A Cryogenic Silicon Cavity Laser

Phase-coherent lasers are crucial for many precision tasks, including timekeeping. Here on Earth the most stable optical oscillators are used in e.g. atomic clocks and many ultra-precise scientific measurements, such as gravitational wave detection. Since these optical oscillators use cryogenic silicon cavities, it’s completely logical to take this principle and build a cryogenic silicon cavity laser on the Moon.

In the pre-print article by [Jun Ye] et al., the researchers go through the design parameters and construction details of such a device in one of the permanently shadowed regions (PSRs) of the Moon, as well as the applications for it. This would include the establishment of a very precise lunar clock, optical interferometry and various other scientific and telecommunication applications.

Although these PSRs are briefly called ‘cold’ in the paper’s abstract, this is fortunately quickly corrected, as the right term is ‘well-insulated’. These PSRs on the lunar surface never get to warm up due to the lack of an atmosphere to radiate thermal energy, and the Sun’s warm rays never pierce their darkness either. Thus, with some radiators to shed what little thermal energy the system generates and the typical three layers of thermal shielding it should stay very much cryogenic.

Add to this the natural vacuum on the lunar surface, with PSRs even escaping the solar wind’s particulates, and maintaining a cryogenic, ultra-high vacuum inside the silicon cavity should be a snap, with less noise than on Earth. Whether we’ll see this deployed to the Moon any time soon remains to be seen, but with various manned missions and even Moon colony plans in the charts, this could be just one of the many technologies to be deployed on the lunar surface over the next few decades.

Inside SKALA: How Chornobyl’s Reactor Was Actually Controlled

Entering SKALA codes during RBMK operation. (Credit: Pripyat-Film studio)
Entering SKALA codes during RBMK operation. (Credit: Pripyat-Film studio)

Running a nuclear power plant isn’t an easy task, even with the level of automation available to a 1980s Soviet RBMK reactor. In their continuing efforts to build a full-sized, functional replica of an RBMK control room as at the Chornobyl Nuclear Power Plant – retired in the early 2000s – the [Chornobyl Family] channel has now moved on to the SKALA system.

Previously we saw how they replicated the visually very striking control panel for the reactor core, with its many buttons and status lights. SKALA is essentially the industrial control system, with multiple V-3M processor racks (‘frames’), each with 20k 24-bit words of RAM. Although less powerful than a PDP-11, its task was to gather all the sensor information and process them in real-time, which was done in dedicated racks.

Output from SKALA’s DREG program were also the last messages from the doomed #4 reactor. Unfortunately an industrial control system can only do so much if its operators have opted to disable every single safety feature. By the time the accident unfolded, the hardware was unable to even keep up with the rapid changes, and not all sensor information could even be recorded on the high-speed drum printer or RTA-80 teletypes, leaving gaps in our knowledge of the accident.

Continue reading “Inside SKALA: How Chornobyl’s Reactor Was Actually Controlled”

Exploring Security Vulnerabilities In A Cheap WiFi Extender

If all you want is just a basic WiFi extender that gets some level of network connectivity to remote parts of your domicile, then it might be tempting to get some of those $5, 300 Mbit extenders off Temu as [Low Level] recently did for a security audit. Naturally, as he shows in the subsequent analysis of its firmware, you really don’t want to stick this thing into your LAN. In this context it is also worrying that the product page claims that over a 100,000 of these have been sold.

Starting the security audit is using $(reboot) as the WiFi password, just to see whether the firmware directly uses this value in a shell without sanitizing. Shockingly, this soft-bricks the device with an infinite reboot loop until a factory reset is performed by long-pressing the reset button. Amusingly, after this the welcome page changed to the ‘Breed web recovery console’ interface, in Chinese.

Here we also see that it uses a Qualcomm Atheros QCA953X SoC, which incidentally is OpenWRT compatible. On this new page you can perform a ‘firmware backup’, making it easy to dump and reverse-engineer the firmware in Ghidra. Based on this code it was easy to determine that full remote access to these devices was available due to a complete lack of sanitization, proving once again that a lack of input sanitization is still the #1 security risk.

In the video it’s explained that it was tried to find and contact a manufacturer about these security issues, but this proved to be basically impossible. This leaves probably thousands of these vulnerable devices scattered around on networks, but on the bright side they could be nice targets for OpenWRT and custom firmware development.

Continue reading “Exploring Security Vulnerabilities In A Cheap WiFi Extender”

A Look Inside The Creative MB-10 MIDI Blaster

Before it became viable to distribute and play music tracks on home computers, the use of FM and Wavetable synthesis was very common, with MIDI Wavetable-based devices like the Roland MT-32 and SC-55 still highly sought after today. The Creative Midi Blaster MB-10 that [Yeo Kheng Meng] reviewed and tore down for an analysis isn’t quite as famous or sought after, but it provides a good example of what Creative Labs was doing at the time in this space.

Released in 1993, it definitely has more of a popular style vibe to it than the utilitarian Roland devices, even if this means highly impractical curves. In the list of features it claims Roland MT-32 emulation, which would have made it quite a bit more useful to the average user, including gamers of the era. Games like DOOM supported these MIDI devices for audio, for example.

In terms of price only the Roland SC-55ST comes close to the MB-10, similarly dropping a screen and a host of features. In terms of features the MB-10 claims far fewer instruments than the SC-55 variants, with even with the slightly higher priced SC-55ST massively outgunning it in raw specs. So would you ever buy the MB-10 back then and consider it a ‘good deal’? If $100 in 1990s money was worth losing full MIDI compatibility for, then it seems the answer was ‘yes’.

Continue reading “A Look Inside The Creative MB-10 MIDI Blaster”

NASA Uses Mars Global Localization As GNSS Replacement For The Perseverance Rover

Unlike on Earth there aren’t dozens of satellites whizzing around Mars to provide satellite navigation functionality. Recently NASA’s JPL engineers tried something with the Perseverance Mars rover that can give such Marsbound vehicles the equivalent of launching GPS satellites into Mars orbit, by introducing Mars Global Localization.

Although its remote operators back on Earth have the means to tell the rover where it is, it’d be incredibly helpful if it could determine this autonomously so that the rover doesn’t have to constantly stop and ask its human operators for directions. To this end the processor which was originally used to communicate with its Ingenuity helicopter companion was repurposed, reprogrammed to run an algorithm that compares panoramic images from the rover’s navigation cameras with its onboard orbital terrain maps.

Much like terrain-based navigation as used in cruise missiles back on Earth, this can provide excellent results depending on how accurate your terrain maps are. This terrain mapping process used to be done back on Earth, but for the past years engineers have worked to give the rover its own means to perform this task.

Continue reading “NASA Uses Mars Global Localization As GNSS Replacement For The Perseverance Rover”

SNES Controllers Are (Almost) SPI-Compatible

Considering that the Serial Peripheral Interface bus semi-standard has been around since the early 1980s, it’s perhaps not that shocking that the controllers of the Super Nintendo Entertainment System (SNES) would take at least some strong design hints for the used protocol. This does however raise the question of exactly how compatible a SNES controller is when connected to the SPI master peripheral of any random MCU. Recently [James Sharman] set out to answer this question decisively.

The impetus for answering this question came after [James] designed a separate SNES controller board for his homebrew computer system, which led to many comments on that video saying that he could just have hooked the controller up to the SPI board in said homebrew system.

Here the short answer is that the SNES controller protocol is very close to SPI Mode-1, with a similar arrangement of clock/data/chip select (latch) lines and clocking. If you think of the SNES controller as an SPI device with just a MISO line, you’re basically there already. The only niggle that popped up was that the ‘MISO’ line does not get pulled into a high-impedance state when the active-low latch connection is pulled high.

This was fixable by introducing a 74HC125 tri-state buffer IC, after which both the original SD card and twin SNES controllers could be used simultaneously.

Continue reading “SNES Controllers Are (Almost) SPI-Compatible”