Ask Hackaday: Vibe Coding

Vibe coding is the buzzword of the moment. What is it? The practice of writing software by describing the problem to an AI large language model and using the code it generates. It’s not quite as simple as just letting the AI do your work for you because the developer is supposed to spend time honing and testing the result, and its proponents claim it gives a much more interactive and less tedious coding experience. Here at Hackaday, we are pleased to see the rest of the world catch up, because back in 2023, we were the first mainstream hardware hacking news website to embrace it, to deal with a breakfast-related emergency.

Jokes aside, though, the fad for vibe coding is something which should be taken seriously, because it’s seemingly being used in enough places that vibe coded software will inevitably affect our lives.  So here’s the Ask Hackaday: is this a clever and useful tool for making better software more quickly, or a dangerous tool for creating software nobody quite understands, containing bugs which could cause a disaster?

Our approach to writing software has always been one of incrementally building something from the ground up, which satisfies the need. Readers will know that feeling of being in touch with how a project works at all levels, with a nose for immediately diagnosing any problems that might occur. If an AI writes the code for us, the feeling is that we might lose that connection, and inevitably this will lead to less experienced coders quickly getting out of their depth. Is this pessimism, or the grizzled voice of experience? We’d love to know your views in the comments. Are our new AI overlords the new senior developers? Or are they the worst summer interns ever?

FreeDOS 1.4 Released

Even in 2025 there are still many applications for a simple Disk Operating System (DOS), whether this includes running legacy software (including MS-DOS games & Windows 3.x), or (embedded) systems running new software where the overhead of a full-fat Linux or BSD installation would be patently ridiculous.

This is where the FreeDOS project provides a modern, fully supported DOS, with the recent 1.4 release adding a whole range of features and updates to existing components like the FreeCOM command shell. This is the first stable release since 1.3 was released in 2022.

FreeDOS saw its first release in 1994 and has become the de facto replacement for MS-DOS — featuring many improvements to make it work well on modern hardware and a package manager to manage installed software much like on Linux & BSD. The new kernel didn’t quite make it into this release, but it and some other items will be available in the monthly test builds.

You can download the new 1.4 release here, with live & installer CD images, a USB installer and even a Floppy Edition available. System requirements include an (Intel) x86 CPU, a BIOS (or legacy UEFI mode), 640 kB of RAM and 20 MB of storage.

Golang On The PS2

A great many PlayStation 2 games were coded in C++, and there are homebrew SDKs that let you work in C. However, precious little software for the platform was ever created in Golang. [Ricardo] decided this wouldn’t do, and set about making the language work with Sony’s best-selling console of all time. 

Why program a PS2 in Go? Well, it can be easier to work with than some other languages, but also, there’s just value in experimenting in this regard. These days, Go is mostly just used on traditional computery platforms, but [Ricardo] is taking it into new lands with this project.

One of the challenges in getting Go to run on the PS2 is that the language was really built to live under a full operating system, which the PS2 doesn’t really have. However, [Ricardo] got around this by using TinyGo, which is designed for compiling Go on simpler embedded platforms. It basically takes Go code, turns it into an intermediate representation, then compiles binary code suitable for the PS2’s Emotion Engine (which is a MIPS-based CPU).

The specifics of getting it all to work are quite interesting if you fancy challenges like these. [Ricardo] was even able to get to an effective Hello World point and beyond. There’s still lots to do, and no real graphical fun yet, but the project has already passed several key milestones. It recalls us of when we saw Java running on the N64. Meanwhile, if you’re working to get LOLCODE running on the 3DO, don’t hesitate to let us know!

Help Propel The Original ARM OS Into The Future

We use ARM devices in everything from our microcontroller projects to our laptops, and many of us are aware of the architecture’s humble beginnings in a 1980s Acorn Archimedes computer. ARM processors are not the only survivor from the Archimedes though, its operating system has made it through the decades as well.

RISC OS is a general purpose desktop operating system for ARM platforms that remains useful in 2025, as well as extremely accessible due to a Raspberry Pi port. No software can stand still though, and if RISC OS is to remain relevant it must move with the times. Thus RISC OS Open, the company behind its development, have launched what they call a Moonshots Initiative, moving the OS away from incremental development towards much bolder steps. This is necessary in order for it to support the next generation of ARM architectures.

We like RISC OS here at Hackaday and have kept up to date with its recent developments, but even we as fans can see that it is in part a little dated. From the point of view of RISC OS Open though, they identify support for 64-bit platforms as their highest priority, and to that end they’re looking for developers, funding partners, and community advocates. If that’s you, get in touch with them!

ReactOS 0.4.15 Released With Major Improvements

Recently the ReactOS project released the much anticipated 0.4.15 update, making it the first major release since 2020. Despite what might seem like a minor version bump from the previous 0.4.14 release, the update introduces sweeping changes to everything from the kernel to the user interface and aspects like the audio system and driver support. Those who have used the nightly builds over the past years will likely have noticed a lot of these changes already.

Japanese input with MZ-IME and CJK font (Credit: ReactOS project)
Japanese input with MZ-IME and CJK font (Credit: ReactOS project)

A notable change is to plug-and-play support which enables more third party drivers and booting from USB storage devices. The Microsoft FAT filesystem driver from the Windows Driver Kit can now be used courtesy of better compatibility, there is now registry healing, and caching and kernel access checks are implemented. The latter improvement means that many ReactOS modules can now work in Windows too.

On the UI side there is a much improved IME (input method editor) feature, along with native ZIP archive support and various graphical tweaks.

Meanwhile since 0.4.15 branched off the master branch six months ago, the latter has seen even more features added, including SMP improvements, UEFI support, a new NTFS driver and improvements to power management and application support. All of this accompanied by many bug fixes, which makes it totally worth it to regularly check out the nightly builds.

Simulating Embedded Development To Reduce Iteration Time

There’s something that kills coding speed—iteration time. If you can smash a function key and run your code, then watch it break, tweak, and smash it again—you’re working fast. But if you have to first compile your code, then plug your hardware in, burn it to the board, and so on… you’re wasting a lot of time. It’s that problem that inspired [Larry] to create an embedded system simulator to speed development time for simple projects.

The simulator is intended for emulating Arduino builds on iPhone and Mac hardware. For example, [Larry] shows off a demo on an old iPhone, which is simulating an ESP32 playing a GIF on a small LCD display. The build isn’t intended for timing-delicate stuff, nor anything involving advanced low-level peripherals or sleep routines and the like. For that, you’re better off with real hardware. But if you’re working on something like a user interface for a small embedded display, or just making minor tweaks to some code… you can understand why the the simulator might be a much faster way to work.

For now, [Larry] has kept the project closed source, as he’s found that it wouldn’t reasonably be possible for him to customize it for everyone’s unique hardware and use cases. Still, it’s a great example of how creating your own tools can ease your life as a developer. We’ve seen [Larry]’s great work around here before, like this speedy JPEG decoder library.
Continue reading “Simulating Embedded Development To Reduce Iteration Time”

C+P: Combining The Usefulness Of C With The Excellence Of Prolog

In a move that will absolutely not over-excite anyone, nor lead to any heated arguments, [needleful] posits that their C Plus Prolog (C+P for short) programming language is the best possible language ever. This is due to it combining the best of the only good programming language (Prolog) with the best of the only useful programming language (C). Although the resulting mash-up syntax that results may trigger Objective-C flashbacks, it’s actually valid SWI-Prolog, that is subsequently converted to C for compilation.

Language flamewars aside, the motivation for C+P as explained in the project’s README was mostly the exploring of macros in a system programming language. More specifically, by implementing a language-within-a-language you can add just about any compile-time feature you want including – as demonstrated in C+P – a form of generics. Even as a way to have a bit of fun, C+P comes dangerously close to being a functional prototype. Its main flaw is probably the lack of validation and error messages, which likely leads to broken C being generated.

Also mentioned are the Nim and Haxe languages which can be compiled (transpiled) to C or C++, which is somewhat of a similar idea as C+P, as well as cmacro (based on Common Lisp) and the D language.