@developerbayman @kugiigi @libremax @lsitongia @moem
ok sorry, got a bit sidetracked there, lets come back to the actual diagram bayman posted
because i think we kinda blew past it and it deserves a proper look
so whats actually being proposed here
the framing is mesa-style — and thats not just vibes, mesa is a genuinely good analogy. mesa spent like 15 years being the "open graphics driver layer" while proprietary blobs were still everywhere, replacing subsystem by subsystem, vendor by vendor, until one day there just... wasnt a reason to use the blob anymore. no big bang. no single "we did it" moment. just a gradient
the diagram is proposing exactly that for halium. not "kill halium by tuesday", more like — make each new port depend on it a little less than the last one. track the gradient. call it halium-thin eventually, then upstream-first
thats actually a solvable problem framing. unlike "eliminate halium"
the AI cold water thing
i posted that ai takedown saying "its all or nothing, the kernel cliff is real, blobs break when you swap kernels"
and thats... correct? like, if you try to run android camera blobs on a mainline kernel they'll crash, the abi doesnt match, end of story
but i dont think that actually kills the idea. because the diagram isnt proposing you gradually blend kernels. its proposing you replace the userspace pieces that depend on halium, one at a time — audio via pipewire/droid modules, modem via modemmanager, graphics via drm/kms and mesa — so that by the time a device lands on a mainline kernel, halium is already mostly hollow. the kernel swap is still a hard cut, but youve already done the hard work before you get there
postmarketos have been doing exactly this for years. and in december 2024 they got actual working cameras on the pixel 3a and fairphone 5 under mainline linux, no android blobs, using libcamera with a software isp. not great quality yet, "retro appeal" as they put it lol, but it works. that was considered a major breakthrough
so the cliff is real, the gradient is also real. both things are true
what the roadmap gets right
phase 1 — make UT feel permanent is actually the most underrated part
standardise the boot bundle, own the OTA properly, hide the halium install jargon from users. this is boring infrastructure work but its the stuff that makes every port less fragile. the current situation where you tell users "install ubuntu touch, but first downgrade to android X" is just not a good look and its fixable
phase 2 — thin the compatibility layer is where the real meat is
audit each subsystem. keep on android, bridge temporarily, or replace with native. this is basically what the postmarketos device category system does — they move devices from testing to community to main based on exactly this kind of subsystem checklist. its proven to work
phases 3 and 4 are aspirational but not fantasy. fairphone 5 already has working calls, audio, and cameras on mainline linux via postmarketos. thats basically a phase 3 device today. it took years of work from linaro contributors and community folks, but it got there
the GKI angle nobody mentioned
one thing worth flagging: google's generic kernel image initiative (mandatory since android 12 for devices on kernel 5.10+) is actually a quiet tailwind here
pre-GKI, up to 50% of android device kernel code could be completely out-of-tree vendor junk. GKI pushes that stuff into loadable modules with a stable interface, so the core kernel is much closer to upstream linux. that makes halium porting on newer devices more reproducible and the eventual mainline jump smaller
this only helps for android 12+ devices obv, doesnt fix the old device pile. but for anything new its a meaningful structural improvement
the reference device thing
the diagram says "choose a few reference devices with good unlock paths and strong upstream interest"
this is just correct and postmarketos proves it. the fairphone 5 got so much mainline attention partly because fairphone actively cooperates with upstream developers and partly because it was a target worth spending time on. the result is that its now basically a showcase device for what mainline mobile linux can do
UT picking one or two devices to treat like this — not "we support everything forever" but "these specific devices are our reference, they will be properly upstream, everything else is best-effort" — would probably change the project's trajectory more than any technical work
what the diagram doesnt fully address
couple things i think are worth raising:
CI against real hardware — postmarketos specifically called out in their governance work that getting reference boards and real phones into their CI so regressions get caught before ports diverge is a priority. UT doesnt seem to have this at all. every port is essentially maintained by whoever ported it. a shared CI backbone for the reference devices would be a significant upgrade
the lomiri on debian path — as I mentioned this. if the goal is upstream-first, lomiri running on debian/bookworm on a mainline device is kind of already that? its worth tracking how close that is to being a daily driver, because it might be the actual phase 4 path rather than a separate project
the modem situation — modemmanager is already the upstream linux standard for this, its in active development (got gps-without-sim in 2024, working on cell broadcast alerts), and replacing ofono/rilmodem with it on halium devices is probably the single most achievable subsystem swap in the near term
tl;dr
the diagram is a solid plan, the AI critique attacked a version of the idea that wasnt actually being proposed, and there's a bunch of prior art (postmarketos, fairphone 5 mainlining, mesa analogy, GKI) that suggests the general approach is sound
the hard part isnt the architecture. its bandwidth, CI, and picking the reference devices and actually committing to them
anyway, thats my read on it. sorry again for the digression earlier
