It's actually a great idea in some ways to use a phone instead of a Raspberry Pi, since it has a battery in case your electricity goes unstable, you can add LTE as a backup internet, and it has a screen to bootstrap it without an external monitor which not all of us have. I only wish Android phones would be more open to put a full Linux distro on them.
If Termux is enough for you the benefit is that it is quite a bit faster than userland.tech. There is also Nix for Termux which provides a lot more packages.
Wow. This is amazing. Just got a server-side Java application running in the Alpine Linux and was able to access it with the normal browser via localhost. Impressive stuff :D
Are you one of the developers? As I'm really curious how this works.
Ubuntu touch supports some old phones you can buy used. It's technically not a android phone anymore, but it's possible. I tried it on my oneplus 6 and I worked, I'm just not ready for the ecosystem yet
>Android phones would be more open to put a full Linux distro on them
Honest question. Why? How is Android not fulfilling your needs as a full Linux distro? Are there any features that you would like to see added, or do you feel that apps for what you want are not currently available?
> How is Android not fulfilling your needs as a full Linux distro?
I mean there's a lot of things that make life difficult with Android.
* If you want most hardware to keep on working, no kernel updates are possible after the manufacturer ends support.
* Root support and service managers need to be installed aftermarket using the unofficial solution Magisk.
* No vendor kernel out of the box supports kernel compile time flags to enable the infrastructure to run Linux containers using Docker, Podman or LXC.
* Self-invented file hierarchy with a lot of restrictions that make sense from an Android UI perspective but are prohibitive when used as a regular distro.
* Since Android and drivers use bionic libc, it's not possible to run regular Linux binaries that tap into certain hardware features like Vulkan without reworking and recompiling them.
Just from the top of my head, there's a bunch of other things people could name I'm sure. Android misses a lot of the expectations people have for regular GNU/Linux distributions have - expectations that non GNU/Linux distros like Alpine do meet for the most part.
>If you want most hardware to keep on working, no kernel updates are possible after the manufacturer ends support.
Yes, this is a problem and it is trying to be addressed by generic kernel images which should make it so that you no longer need to build a device specific kernel as all of the device specific stuff has been modularized.
>Root support and service managers need to be installed aftermarket using the unofficial solution Magisk.
Root should not be necessary and these break Android's security model. Perhaps there is an operating system API that could be added that could provide the features you are looking for while keeping the system secure.
>No vendor kernel out of the box supports kernel compile time flags to enable the infrastructure to run Linux containers using Docker, Podman or LXC.
Android apps already have their own sandbox. It would be better to develop apps than docker images as darker images don't really follow the Android security model as well. What you want should be possible with Android 13 allowing for kvm.
>Self-invented file hierarchy with a lot of restrictions that make sense from an Android UI perspective but are prohibitive when used as a regular distro.
Why care about a file hierarchy? NixOS does away with it and seems to get along fine. Apps shouldn't rely on it.
>Since Android and drivers use bionic libc, it's not possible to run regular Linux binaries that tap into certain hardware features like Vulkan without reworking and recompiling them.
Most people run apps and not binaries. It is going to need to be reworked anyways.
I know there are reasons why Android works like this, but you may not be aware you've been replying to a post where I listed what I missed about Android compared to a regular Linux distro.
Android is highly opinionated to work as a platform for apps on touchscreen devices, but those opinions do add a lot of restrictions compared to other things built on Linux.
I don't think a comparison to NixOS is fair here. I'm an avid NixOS user. I would love to be able to use it or something like it on mobile. Instead, I can't do much of anything other than consume from my android device.
Likewise, I don't want to have to package all my stuff as apps. If I already have a docker container and I wish for it to be ran on my device I think that there shouldn't be another barrier. Android security model? Why do I care about that? I have a device and I want to run my software on it. It's as simple as that.
Android provides you with a heavily locked down linux kernel and network setup, which is great for app sandboxing, but not great for certain tasks you might want on a server.
For example, android makes it difficult to run userspace containers, like lxc or docker, which also limits what orchestration and deployment systems you can use (since some make very strong assumptions about being able to use containers).
Similarly, various different pieces of server software just won't work because they make use of some linux feature android intentionally builds its kernels without for security reasons.
I didn't try it out, maybe you're right. I know how to deploy my stuff via systemd, install Rust/cargo/Elm/Python/Node/GHC/libopencv/Nix/whatever, link static libs and so on. And when I'm using Raspberry Pi I need near-zero new knowledge to do all that.
I suspect that trying something like that on Android will be a long road with lots of caveats, even if possible, learning to do all the things the new "Android" way. Am I wrong?
For building native code it will mostly be the same, but you will need to learn some Android stuff for making the nonnative part of your app so you can learn how to create a background service and how to tell Android to restart your service if it gets killed due to low memory.
