When we talk about programming in “bare metal,” it basically means writing software that runs right on the hardware with no operating system or abstraction layers in between. This gives the program the most direct possible access to peripherals and memory, with the tradeoff being that you don’t get the protection and ancillary features that come with an OS.
Sylvain Huet came down to Hackaday Europe 2026 to talk about making bare metal easy. Not just by ignoring operating systems and ever-bloating dependencies, but by rethinking the way we approach software development and by building a transparent platform from the ground up.
Down To Brass Tacks
Sylvain begins the talk with a look at where his own computing journey began. Back in 1982, he got his hands on a Thomson TO7, with just 8 kilobytes of user RAM and a 6809 CPU. The best way to have fun with the hardware was to work straight in assembly. “It was easy to understand everything about your computer,” notes Sylvian of the simplicity of the platform. “There was almost no hidden side in this computer.” Of course, change was fast in that era, and a bit over a decade later, Sylvain was working on a Metaverse-like product called Second World, before moving on to work on Nabaztag in the early 2000s—a charming Wi-Fi enabled rabbit launched just as wireless networking was hitting the mainstream.
The through-line across all these projects was that much of the work was done at the bare metal level—often useful when it’s desirable to work as close as possible to the hardware peripherals or to maximise performance. Sylvain then contrasts this with how things are often done in this modern era.
A poignant example was showing pictures from an airport during the CrowdStrike outage of 2024. Where once upon a time a flight schedule display might have been a purpose built device running on very simple hardware, these days it’s common to just kit out flat screen monitors with entire Windows computers behind them. It’s a convenient way to build, but as Sylvain explains, this complexity sometimes comes at a cost.
He then shows that such a display can be very easily built with a Raspberry Pi running a bare-metal program with no operating system at all—with no automated security updates enforced by an outside OS provider, or any such heavy-handed management required. Since it’s coded to do one job from the ground up, it’s much less likely that the software falls apart due to some outside update or the collapse of some obscure dependency that nobody on the development team was even aware was included.
Sylvain talks about a “new minimalism”—where “all you need to understand should fit in your single brain.” It’s not just about working at the bare metal level, but about creating systems where a single developer actually understands the project from top to bottom. Of course, there are limits to the size of a project any one person can completely understand, but for some applications, this can be a useful guiding principle. The talk also explores how we use things like outside libraries. Sylvain calls this the “low-level paradox”— wherein the more sophisticated a task is, the more we rely on black boxes to do parts of the work for us. It’s a fast way to develop, but quickly adds thousands of lines of code to a project and enables us to avoid understanding some of what’s actually going on under the hood.
To this end, Sylvain has created the Minimacy language. It’s intended to enable development with fewer dependencies, black boxes, and operating systems, while maximising the capacity for understanding. It’s concise, linear, and safe, with strong static typechecking and type inference. You can work with it using the Minimacy virtual machine, which combines an instant compiler and a virtual processor that can run the code. It’s 100% open source, and is written in less than 900 kB of C—both which support the ideal of being within the realms of a developer’s ability to understand the whole stack. Indeed, Sylvain demonstrates just how light it is by running a Minimacy game off a floppy disk on a modern UEFI laptop. The idea is that a Minimacy VM could run on a variety of different hardware, allowing near-bare-metal access for Minimacy code while still maintaining some level of portability across systems.
Sylvain also demonstrates the Minimacy Machine. It’s powered by a Raspberry Pi RP2350, running at 150 MHz, with lots of useful peripherals, including Ethernet connectivity, an OLED display, an SD card reader, and a real time clock. Armed with all that, it’s a platform that can run Minimacy code and allow the development of devices that run without relying on lots of outside dependencies or a heavy OS built for more general purpose tasks. It exists as a transparent software and hardware stack for developers to build upon.
Overall, though, Sylvain’s talk isn’t just about Minimacy or programming in bare metal. It’s about finding simplicity where it makes sense. Working in bare metal isn’t for everything of course, and the vast majority of us will continue to use operating systems across all sorts of applications where they’re necessary and useful. However, in the advanced age we live in, it’s sometimes good to remember that stripping away unnecessary layers of abstraction often makes a lot of sense, because they can distract us from the simple tasks we’re trying to achieve in the first place.
So it’s a VM with a specific purpose in mind. Think Zork machine, minus game-specific elements, plus elements to virtualize common hardware, plus it’s intended to run on bare metal.
Yes, that appears to be the size of it. I’m skeptical that such a VM (even on bare metal) will ever approach native code on bare metal in terms of performance. It would be interesting if it built native binaries, but with the VM it looks like an update for the 2020s of the UCSD pSystem =:-/
The philosophy and logic of ‘minimacy’ is good; no, it’s freaking outstanding. It all sounds great until you read the docs and see the use of yet another application-specific programming language.
I suppose it could be avoided and use this with straight ANSI C/assembly and a lo-pwr device. Oh wait, being doing that with stuff such as TI 430 or Atmel 2313 with a few well-documented support ICs, but only recently, like for the last 30 years.
Sorry about the snark, but that’s just me giving up in my declining years.
I dreamt about getting rid of all the compilers, abstractions, libraries etc except nasm and boot to an os written in Assembly. The user then programs it using plain English. That’s bare metal I guess. Thank you for your passion and this article. Is the OS I am talking about too good to be true? Check it out at https://github.com/IndyWH/germos
Interesting approach. I´m curious where it will head. Keep on chatting.
Thank you Iman! An update, two days on, last night it booted on real hardware, an old HP Compaq Elite 8300 from 2012. The whole boot image is 36,864 bytes (the Ubuntu ISO on the same USB drive is 6.5 GB) and it goes from the firmware handing over to a prompt in 0.64 seconds, timed on the serial line. The photo is at the top of the README now. The network card is the last thing still fighting back.
Network card is resolved. We wrote a little story on how it was done. You can read it on Repo Readme->The metal, 17 and 18 September 2026 — Stage 7 closed 18 September 2026 ( https://github.com/IndyWH/germos ). The the most fun available per kilobyte indeed!
I finally got the creator status, thank you hackaday.io : https://hackaday.io/project/206748-germos
When someone discusses a novel software project/approach and its presentation or a poster contains those “modern-style” cliparts as if ripped from some Android app UI, my spidey senses are tingling… no, no, they are outright telling me to GTFO, because it’s a trap.
24 years in embedded engineering (of which 17 years was automotive) does that to a man.
i guess i’m happy that there are such a diversity of tools available today but this one seems to me like a contradiction.
i hate overly-complicated systems…i have many times struggled to find the 10-100 lines of logic buried under thousands or millions of lines of wrapper / boilerplate / structure / extraneous features. i wrote my own assembler for pic18, my own braindead ‘compiler’ for stm32, and my own c runtime / bootloader for rp2040. and on my todo list is building my own ‘from scratch’ usb device stack for rp2040, but it’s pretty low priority at the moment.
like, it drives me crazy that when i was debugging marlin (3D printer firmware), one of the things i ran into was a difference in behavior between the avr sdk that debian apt installed for me, and the arduino avr sdk that other people use. i think of marlin as ‘to the metal’, why am i in dependency hell? on the other hand, using all those layers of abstraction has allowed marlin to remain relevant across a lot of different boards / chips!
so the last thing i want is a little boutique OS that provides a ton of features like networking. my desire to get to the metal is in tension with my desire to have a network stack ready-made for me, and as a developer / project manager, i have to decide which side will win. they can’t both win!
a lot of times in these projects, i do invent a domain-specific language…but i do not want to learn someone else’s! defeats the whole purpose of holding the whole problem in my mind.
Don’t use Debian unless you’re into doing Larecroftian IT archeology.
eh, there’s genuine challenges but in this case debian’s avr sdk was correct (standard-conforming) and arduino’s was wrong (standard non-conforming), and marlin developers had been misled by the flaws in the arduino sdk.
i mean, the debian packages often reflect poor choices (systemd) but in general i would rather use just about anything than arduino :) in fact, a lot of my ‘bare metal’ programming habits come from a reactionary revulsion to the arduino sdk.
(not to say arduino doesn’t have its uses…just talking about my taste)
Well, my friends, I have a question for you:
If we’re using HALs (Hardware Abstraction Layers) for developing on our favourite MCUs, is this still a bare-metal development or not? And what if we have to use an RTOS?
True… I guess it depends on what one means by “bare metal”: is it you or your program that’s talking directly to the hardware?
i don’t even understand why there’s this social pressure to describe things as ‘bare metal’ that aren’t. there’s nothing wrong with using a HAL / RTOS / small kernel / etc. why wouldn’t people just describe what they’re doing using the words that match what they’re doing? why is it so undesirable to eschew the phrase ‘bare metal’ when you’re using abstractions?
abstractions are a mixed bag but there’s no question that a lot of my bare metal predilection is dysfuctional, a disease i have. why are people pretending to have my disease if they don’t?
bare-metal is anywhere lower than the previous or expected level of abstraction.
Vulkan was bare-metal cause it was lower than OpenGL.
Your case appears not bare-metal because HALs and RTOS are already the default for microcontrollers. Same type of tools and libraries on a full-fat UEFI platform would be bare metal, though.
Same for beaglebone black and the PRU subsystem. The main CPU leaves you at the mercy of the preemptive process & IO schedulers of the kernel, but you have the option to leave a 2MB program running on the PRU cores. no cache misses, no scheduler, code talks directly to peripherals.
Btw, 900 Kb of C code is quite a lot, what makes you think this is small?
Because that includes the high-level language he wrote, that allows him to program ON this device FOR this device, instead of having to reflash from Arduino IDE or some other toolchain that needs a big computer to run on. And that’s 900 kB of source code – he says it’s about a 500 kB binary. And it does include some libraries that he mentions.
Why do everyone that says “let’s get close to the metal”, always immediately follow that up with “here is a new programming language”?
If you want to be on the metal, code in assembler. If you don’t want to do your own variable or memory-management, code in something higher-level. You cannot do bare-metal, AND not be concerned with memory and variable management. I think by now, the number of programming languages must be approaching the number of stars in out galaxy…each one of them doing (or claiming to) exactly the same as every other language before them. Microproccesors have all been working according to the same basic principals for over half a century…a new language is not goint to change the way they operate.
As far as higher-level languages go, C has been with us for decades now. It is obiously very effective, otherwise it would have been dropped long ago…
Imagine his position: he wants to be able to write code on his minimal system, which pretty much rules out C. And he wants to be able to port it to different machines and have his code run on any of them. Which means he needs an interpreter. It seems to me like it’s the same approach that all of the “home computers” in the late 1970s to 80s did: write an OS that’s basically a BASIC interpreter with a few added keywords (peek and poke, for example) that give you access to hardware, and to be able to load machine code functions. But his new programming language is more like C or Pascal than BASIC, so I don’t think it was a bad idea to write a SIMPLE language that HE likes, that fits with the way he likes to develop code. And don’t say “Micro Python”, because that barely fits on a Pi Pico, and does NOT fit on many platforms that he might want to use this on. I’m in a similar position and have considered writing an abridged C interpreter for this very reason.
…yes, and because your new little language has uniqueness to it (like say a custom ‘peek’ and ‘poke’), it starts off not being portable to other platforms to begin with…unless you first sit down and write similar interpreters for all of them as well. You are not making anything easier by throwing in a new language into the mix. If you want to do bare-metal, just do assembler, and port the assembler to other platforms (which in any case will have wildly varying memory handling requirements to contend with). The only way currently to make porting platform-agnostic, is to have an OS…something that is almost impossible on most MCUs. When you have to live close to the hardware for performance reasons, this is unfortunately something that you have to accept.
Micro Python?
Not to worry…there is a special place behind my bathroom door for anything Python related…
“an OS…something that is almost impossible on most MCUs.”
ZephyrOS and FreeRTOS, just to name two, run on respectively on STM32L0 and ATMEGA32U4. Most MCUs nowadays are more powerful than this. There are even some very basic OSes for more anemic MCUs than that.
You are right. If you want to do anything that’s outside the reach of his virtual machine, this just adds a layer of abstraction. The fact that it HAS firmware implementing his virtual machine very definitely takes you away from the bare metal. You can’t have it both ways – you can either have portable software or you can have bare metal. If your software is portable, then it must rely on a translation layer to work the same with different hardware architectures.
I’m not sure why he’s so anti-wireless. I can agree with him, that the Raspberry Pi Linux SBCs are so full of code blobs, you don’t know what they’re doing behind your back, but there is another alternative that I’ve seen a number of times: include an ESP32-C3 or -C5, just as the networking and Bluetooth device, and have that chip powered through a MOSFET that you only turn on when you’re intending to use either WiFi or Bluetooth. These are easy to interface with, so you can treat them like black boxes, and don’t have to fit their inner workings into your limited head, unless you want to. Which is what he’s doing for Ethernet, anyway – using a separate MCU that just handles the network stack, and connects to the main MCU over SPI, I’m guessing using PPPoE.
As someone who has lived through ethernet from inception, right through to where it is today, I have to agree. Jumping into a network stack is not for the faint of heart. Even if you decide to re-engineer the “wheel” from scracth, you are not going to have a stable stack for years (of learning) to come.
As to the ESP32…the name escapes me now, but there is a project on github that is reversing the ESP32 wireless, and providing header files. This is for those that want to do their own networking stacks.
I am also not a fan of proprietary blobs in my “stuff”…
Without trying to sound like a rust cultist, I think rust has some advantages for embedded bare metal platforms. Not the memory safety angle, but instead the traits, build system (cargo) and namespacing which makes things a lot more modular and plug and play.
First you can define a standard interface / trait for something like an i2c or spi interface in a library (which has already been done).
Then you then define something platform specific (such as for an esp32 or rp2040) that uses the same trait but provides a bus you can connect to.
Then you have the thing you’ve written (driver or otherwise) that connects to the bus using the trait, meaning it can work across different platforms using a predefined standard.
Downloading building and linking all of the above is then just a case of a couple of lines in a cargo configuration file (with maybe a couple of small tweaks for the platform specific stuff). So building is also a lot easier.
To avoid MMU related stuff such as vectors and the like you can use the “nostd” feature so as long as your library is nostd compatible it can work on non MMU micro controllers.
This makes slotting in libraries such as “nut-shell” for a cli shell or ratatui super easy on bare metal.
The downsides are which processor’s the compiler will support and dealing with the borrow checker
I disagree with his definition of bare metal because if I understood the parts that I watched correctly ¹ he is basically running a virtual machine like Java. How many levels of abstractions are below does not really matter. The moment your application is not tied to a certain architecture you are not running bare metal anymore. Containers like Docker are more bare metal than any VM language.
I fully agree though with his quest to reduce dependencies for long term stability, simple development and overall reduced mental overload.
¹) the audio quality plus his accent is almost incomprehensible to me