New blog post introducing the WIP Duranium project (immutable postmarketOS), some of its major features, and explaining why some design decisions were made.  

> Either the new image works, or the system falls back to the previous one automatically. No partially-applied state. No debugging audio when you need to make a phone call and no fussing with a broken web browser when you just want to doomscroll cat photos. It also means developers can reproduce the exact state of a user's device, making it much easier to track down and fix issues.

https://postmarketos.org/blog/2026/03/17/introducing-duranium/

#linuxmobile #postmarketos #duranium

Introducing Duranium: a more reliable postmarketOS

Aiming for a 10 year life-cycle for smartphones

postmarketOS
@postmarketOS how does "No debugging audio when you need to make a phone call and no fussing with a broken web browser" follow from "the system boots successfully"? The system may boot successfully with a broken audio and/or a broken web browser. I'm curious and didn't find it in the blog post
the idea is that faults like this can be discovered before an update is applied as it's much easier to replicate and test the images, and a partial-upgrade state (which might break something like audio) is entirely avoided as updates are effectively atomic
@alexia @postmarketOS broken audio makes me think primarily about audio being broken on particular hardware due to an unaccounted edge case. Doesn't that mean that you can test an image on some hardware or even a few different phones, but still miss it being broken on some particular other audio chip?

@YaLTeR @alexia that's why we're also building automated testing which will include automated testing of audio and phone calls.

eventually we hope to have a comprehensive test suite that every update must pass on every device before it gets shipped

@cas @YaLTeR @alexia You can also mark a boot as failed if pipewire is crashing, won't catch everything but its more than now
@alatiera @cas @alexia maybe you can run some audio smoke test at boot and rollback if it fails?

@YaLTeR @cas @alexia You don't even need that, systemd has a built-in way of handling this.

https://systemd.io/AUTOMATIC_BOOT_ASSESSMENT/

Automatic Boot Assessment

@alatiera @YaLTeR @cas @alexia that would also deal with pipewire failing, or selecting the wrong audio device all of a sudden, or stuff like that?
@esoteric_programmer @YaLTeR @cas @alexia It would deal with the service failing or crashing, but it wouldn't catch logic bugs like that