Obviously vibecoded but interesting nevertheless. The agent left everything marked as untested in the README but the output snippets toward the bottom imply that it got something working enough to log in and run some commands.
Nobody is going to mistake this for a carefully crafted port of Linux but it at least serves as a proof of concept.
The real downside of the vibecoding is that we don’t get any helpful information about what it took to get it done with thoughtful analysis from a human. Just a chunk of code in a GitHub repo with some half-coherent README. There’s a docs folder, but the documentation about the MMU part just says that there are two MMUs across a couple lines of notes. Okay, great.
The responses all seem a little harsh. If you poke through the user's history, this kind of thing isn't new for them, going back to pre-LLM-could-do-this days.
I think the docs are light because the primary goal for them is not to provide everyone with a well documented linux on esp-32-s31 guide, but rather this that they shared:
"I'm currently working on a hackable music player and I used to prototype with the OG esp32, and tbh if I wasn't for Bluetooth audio I'd move on to S3 already" ( from the links in this comment https://news.ycombinator.com/item?id=49134987 )
The responses to agent-aided dev seem a little over the top to me.
The derisive "vibe-coded" label is one thing, but the least compelling argument or complaint of them all is the truly worn out one about barriers to entry that you and I and so many others worked soooo hard to climb over are now being obliterated, allowing any casual Moe to stroll into your domain. How many professionals -- djs, photographers ... hell, SEO experts -- pretty much anyone technical and possibly creative have watched technology make work and the accumulation of competitors almost too easy.
If you just remember that no one in this time-space or anyother AFAICT is forcing you to consume or even read about projects like this, you'll find life goes on and you're actually still an expert who people who need experts will value materially (which should be your thing, otherwise wth are you complaining about?)
In fact, if you keep your mind open you might -- not definitely but _just_ _might_ -- find a piece of something useful amidst the slop. One fellow's trash ...
>Espressif's radio firmware blobs are closed source, and must run within ESP-IDF's FreeRTOS framework. It's near impossible to reverse-engineer them (not to mention legal risks.)
It's not nearly impossible, it has already been done :)
- Yes it is vibe coded. It do work on real S31 dev boards (there's console output and binary releases to prove that.) I understand the esp32 microcontroller architecture to some extent, but I barely know how to port Linux to other RISC-V platforms; what I did is to tell the agent something like "Go implement an IPC transport that uses a shared SRAM buffer and an IPC interrupt doorbell" or "sdmmc uses designware ip; search esp-idf usage and port the existing Linux driver over." An AI agent on its own would never discover S31's bespoke hardware behavior without my guidance, for example, that the register `mcliccfg` has writable bits, despite esp-idf saying otherwise. However I admit that AI assistance is the direct reason why I am able to progress this fast, and I did learn a lot about kernel development during the process. If you're bothered by AI code, move on.
- Untested is a bit misleading: per the README, means "seems working; not thoroughly tested." They do seem to work at the time when their drivers are being built. Three weeks into this project I can't have everything stress-tested already.
- I built this more as a proof of concept intending for my own use; I did not expect it to gain popularity anytime soon, so the docs are very bad for now.
13 comments
[ 0.19 ms ] story [ 7.3 ms ] threadThe author has more details in this reddit post: https://eddrit.com/r/esp32/comments/1vait52/mmu_linux_on_the... And the docs section of the repo: https://github.com/GrieferPig/esp32-s31-linux/tree/main/docs...
Doesn't that put it in an awkward position relying on a dead end feature?
Nobody is going to mistake this for a carefully crafted port of Linux but it at least serves as a proof of concept.
The real downside of the vibecoding is that we don’t get any helpful information about what it took to get it done with thoughtful analysis from a human. Just a chunk of code in a GitHub repo with some half-coherent README. There’s a docs folder, but the documentation about the MMU part just says that there are two MMUs across a couple lines of notes. Okay, great.
I think the docs are light because the primary goal for them is not to provide everyone with a well documented linux on esp-32-s31 guide, but rather this that they shared:
"I'm currently working on a hackable music player and I used to prototype with the OG esp32, and tbh if I wasn't for Bluetooth audio I'd move on to S3 already" ( from the links in this comment https://news.ycombinator.com/item?id=49134987 )
The derisive "vibe-coded" label is one thing, but the least compelling argument or complaint of them all is the truly worn out one about barriers to entry that you and I and so many others worked soooo hard to climb over are now being obliterated, allowing any casual Moe to stroll into your domain. How many professionals -- djs, photographers ... hell, SEO experts -- pretty much anyone technical and possibly creative have watched technology make work and the accumulation of competitors almost too easy.
If you just remember that no one in this time-space or anyother AFAICT is forcing you to consume or even read about projects like this, you'll find life goes on and you're actually still an expert who people who need experts will value materially (which should be your thing, otherwise wth are you complaining about?)
In fact, if you keep your mind open you might -- not definitely but _just_ _might_ -- find a piece of something useful amidst the slop. One fellow's trash ...
It's not nearly impossible, it has already been done :)
Slides: https://fahrplan.events.ccc.de/congress/2024/fahrplan/media/...
Video: https://www.youtube.com/watch?v=r8IqkUTGjlA
- Yes it is vibe coded. It do work on real S31 dev boards (there's console output and binary releases to prove that.) I understand the esp32 microcontroller architecture to some extent, but I barely know how to port Linux to other RISC-V platforms; what I did is to tell the agent something like "Go implement an IPC transport that uses a shared SRAM buffer and an IPC interrupt doorbell" or "sdmmc uses designware ip; search esp-idf usage and port the existing Linux driver over." An AI agent on its own would never discover S31's bespoke hardware behavior without my guidance, for example, that the register `mcliccfg` has writable bits, despite esp-idf saying otherwise. However I admit that AI assistance is the direct reason why I am able to progress this fast, and I did learn a lot about kernel development during the process. If you're bothered by AI code, move on.
- Untested is a bit misleading: per the README, means "seems working; not thoroughly tested." They do seem to work at the time when their drivers are being built. Three weeks into this project I can't have everything stress-tested already.
- I built this more as a proof of concept intending for my own use; I did not expect it to gain popularity anytime soon, so the docs are very bad for now.