zlacker

AOSP is still the better OS. It is fully open source. It has a much better protection model. It is production ready and optimized. It has a working build system. It supports reliable updates.

I find the idea of Linux phones pointless. Instead of trying to create an app ecosystem that will never compete against proprietary-ecosystem optimized and well-isolated one, we can leverage it. I wouldn't want an OS where the banking app can peek into my browser. Desktop OSes are still like that and that's crap OS design in 2025. It has been crap since 90s. Linux being popular has significantly hindered OS innovation in open source world.

If you would like to help, I think helping projects like LineageOS or GrapheneOS is better. You can also try joining reverse engineered driver efforts for open source drivers like Freedreno. You can help porting device-specific kernel drivers to mainline. So we can boot whatever kernels we want on normal Android phones with Mesa OpenGL.

"A lot of C experience" doesn't really tell anything. Have you worked with cross-language systems? How much you know about ABIs? How about interface definition languages (IDLs)? Have you actually written a production driver for Linux systems? Have you implemented any system-level service that got deployed a number of nodes? You need to join somewhere and improve things marginally.

>>okanat+(OP)
The Linux kernel runs AOSP. Linux has nothing to do with the design decisions that you mentioned.

>>okanat+(OP)
I think what people would like is, if they were able to just run the same programs seamlessly on the phone. That's why porting standard (GNU/) Linux distros to mobile seams worthwhile.

>>171862+QF1
Those programs and GNU userland are severely under-secured for a general purpose phone that has multiple privacy sensitive sensors. AOSP has better equivalents in all of performace, security and usability. It is Apache licensed.

As I mentioned if the core driver libraries for the userland are reverse engineered (like Freedreno driver in Mesa instead of closed-source Qualcomm stuff) and the kernel drivers are ported to mainline you'll have a better mobile OS than any GNU system can achieve in the same time frame.

If you still want your GNU environment, there are already ones that implement it like Termux.

>>katche+C8
Do you behave internationally obtuse or do not really understand that "Linux" is often used for GNU/Linux systems and this is what meant by "Linux phone".

What makes AOSP a better and more meaningful target for a truly open source system is being also open source and having a much better userland implementation that is supported by specific kernel patches that isolate client programs from direct hardware access and from each other. Moreover it has better libraries for creating mobile apps. It has a better and established ecosystem full of experts, some of which already implement FOSS apps.

No GNU system has anything close and getting close is a huge engineering effort that you don't need to do.

What AOSP does is actually workaround or extend Linux kernel with a system layer that makes the runtime for apps look more like a microkernel. It is a much secure design for carrying a general purpose computer with GPS, Camera and Bluetooth on.

So why not just improve Apache-licensed AOSP? Port the closed drivers to open source ones and everyone can utilize all of AOSP's benefits, without being controlled by Google or phone manufacturers too (as long as you can modify the software). FOSS friendly phone vendors can always help with porting efforts and remove blockers.

>>okanat+tR1
These phones seem to have hardware isolation for the privacy sensitive sensors, so this matters less. I the user already use all the GUN programs daily. It would be nice to be able to use them on the phone. Having these in some isolation like Termux, isn't that useful, as I want to use the programs to control my phone. Not sure if ssh -X works on Termux.

>>171862+cN6
Having granular access != no control. On the contrary, I want more control over the apps. There is no benefit to me if my banking app or any other app can also have access to GPS, while I am navigating with a map app. AOSP is much much better in this aspect. Normal desktops are nowhere near. GNU userspace also simply has very litte preparation for this. Creating granular SELinux rules, and then separating each hardware into its own system agent and then isolating them further with various containerization is no small task. GNU userland is still struggling with styling Flatpaks and keeping them performing well and small. Android's frameworks libraries provide a consistent UI with little overhead.

I don't know why you need ssh with Xorg on your phone though? There are ways like scrcpy to control your phone remotely. Apps like KDE Connect on Android already give quite a bit remote control opportunities too. There are open source remoting apps that fit the Android user interface better like RustDesk. If you still want an Xorg running, there is nothing stopping you from encapsulating it in an Android app too.

>>okanat+S18
Yes for most domains encapsulation is fine. It is not fine, if the domain is the device itself. I want to apt update the phone, I want to switch to another kernel on boot, I want to update the firewall from the shell, I want to sync config by rsyncing parts of my home directory. All of these won't work by running an App on top of Google Android, because I want to change the layer below.

> ssh with Xorg

For example to run gufw on the Phone, but access it on my computer? Sure I could also learn to do it in the shell, but it is so damn convenient. Sometimes it's also nice to run an editor directly on the device itself and not run the editor locally on an ssh-mount.