lets talk about the phasing out of haluim
-
you will get to try it if you want
Thank you this is very cool and advanced setup for me. Lately I just chill in the backyard of progress. But I wish you the best of luck on your endeavours and my spirit is with you!
-
... my own custom AI ...
? LLM style, or something else ?
-
@grenudi said:
... Dipping my hands into those projects ... and finally get working on perfecting the actual day to day use cases ...Hmmm - no such thing as perfecting, just iterating and releasing ... (hahaha)
Embedded - Fun stuff, like my Fridge temp graph: Arduino, now ESP32, + 3.5" LCD, because I tried to find & buy one & nobody made what I wanted.
I wanted Linux native on my phone, but my brains coding limit is ESP32 (maybe better in future with AI help...).
Searched for years !
Fortunately, the UT devs finally got it to a point I can use it ! -
Embedded - Fun stuff, like my Fridge temp graph:
Thats cool I was seriously thinking about making opensource brains for washing machines
at some point, on arduino or even pi. That is actually a major problem with washing machines, I dont know if anyone has made such a project since I last thought about it. But they all have ugly mess of different mods for different clouthes, that each manufacturer creates themselfs, not to mention remote controll over wifi from a smartphone on old machines, and times when it works but strangly and you have no feedback on why, and to through away super robust hardware just becase its brains got messed up feels like such a waste. -
@oldbutndy uses ollama on the backend but its the framework in which it sets so it is agentic ...i made this before chagpt codex or openclaw
-
also i very much desire for my pylinux distro to become the home of UT ...its not ubuntu ....but im going to make a living space for UT in my OS vast set of custom tools ...everything from porting to flashing ....all things in between ....really to achieve this is easy make tools the UT community cannot resist because they are so useful and time saving ...this is how my OS will show UT love
-
also perhaps my initial thought was just off ...maybe instead of thinking replacement perhaps i should be thinking streamline? ....like what could make bringing devices easy ....wouldnt it be sweet if we could run a program that reads the entire device like in fastboot or something and then utilize AI to backwards engineer hardware drivers because it "sees" the hardware and then just make some software for it based on what it saw? ...companies would be mad but its not doing anything with their ip but simply right to repair your own device you paid for and own ....they wont come off the software so you make some ...well AI anyway and on the fly ideally the user shouldnt even know its happening
-
wouldnt it be sweet if we could run a program that reads the entire device like in fastboot or something and then utilize AI to backwards engineer hardware drivers because it "sees" the hardware and then just make some software for it based on what it saw?
@developerbayman would be a hell of a job and ground breaking achivement if you can pull this off! Providing a setup where it has closed loop development with ability to touch the hardware and not just work with words. Maybe it would be easier to first streamline the porting process with ubtouch on halium, if anything, the resulting "all in one place" doc for the whole process will be beneficial in itself, esspecially adjusted as a guide for people with 0 tech knowledge (just thinking outloud. No expert on the subject)
-
...well AI anyway and on the fly ideally the user shouldnt even know its happening
This would make me dump whatever it was, hard and fast. People should always, always be aware that a process uses AI, so they can make a choice.
-
@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
-
@moem @developerbayman wouldnt it be more fitting in the os category ? as the next pinned "The road(map) explained" topic as the one @mariogrip did in 2020, and its still pinned even when this road has already been crossed
-
grenudi said:
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
But at minimum, do some constructive research about what the effort would take, where expert volunteers could start with upstreaming, and so forth.
@projectmoon how is that for a constructive research ? Its already been made by @developerbayman and as I understand, he is more than eager to see it through and coordinate, contribute as far as he can.
@marcellotogg Maybe this will interest you as a disscution of "whats next"
Hello! It looks like you're interested in this conversation, but you don't have an account yet.
Getting fed up of having to scroll through the same posts each visit? When you register for an account, you'll always come back to exactly where you were before, and choose to be notified of new replies (either via email, or push notification). You'll also be able to save bookmarks and upvote posts to show your appreciation to other community members.
With your input, this post could be even better 💗
Register Login