28 comments

[ 3.1 ms ] story [ 63.6 ms ] thread
Does this imply the existence of a Podman that can run on stock Android?
assuming the kernel is compiled with support for subuid and gid framework and proper namespace support...sure? I'd be suspicious if the pod networking would function properly though
I was just thinking that it could be fun to turn all my old phones into kubernetes nodes
Android 13 ( ~ 2022H2 ) has a Virtualisation support

"Thanks to Android 13, phones such as the Pixel 6 are able to run virtual machines for Windows and Linux with better performance and fewer headaches."

https://9to5google.com/2022/02/14/android-13-windows-linux-v...

It's likely most smartphones won't use it. Qualcomm notably shown itself quite stubborn against their customers using their own VMs.

Also, you won't be allowed to run your own VM without rooting. Only OEM/Google VMs will be allowed to run.

"Run Windows 11 on your Android 13 right now"

* "Users could soon be able to run Windows 11 on their Android devices."

* "Google is currently working on a plan to integrate the OS and Android 13 which will require a little bit of tweaking."

* "Virtual Machines will be the first to test out this new feature to see how it performs."

https://windowsreport.com/run-windows-11-on-your-android-13-...

A big "YMMV" note should be added.
On my Librem 5, it was just `sudo apt install docker.io`. Even amd64 containers work thanks to qemu-user :D
(comment deleted)
You probably know this, but you'll gain a lot of performance by building native containers. In most cases it's trivial as long as the software builds on arm64 or can be crosscompiled.
Of course, hence "even" - it's still a fun option to have for cases where rebuilding the container is not feasible or even outright impossible and you can deal with slowness imposed by emulation.
Samsung DEX had a DEX on Linux app that started an Ubuntu 16.04 container with a X11 desktop. They developed it with Canonical and worked well.

It went away with the upgrade to Android 10 [1] probably because Samsung didn't want to spend money when only a few people was running it.

[1] https://www.slashgear.com/samsung-linux-on-dex-is-dead-here-...

It makes me kind of sad. I was so excited about this. And really tried to use it whenever it made sense.

Sadly the experience wasn't fluid enough to make more people interested. And I think hardware were just one generation or two from being in a sweet spot of making it reliable and fast enough for most.

Still have my hopes of it coming back

I loved it and I was quite pissed, after I found out that this function was killed with the update.
> It went away with the upgrade to Android 10 [1] probably because Samsung didn't want to spend money when only a few people was running it.

Just to clarify this: From my experience, the cost to maintain this would probably be 4 full-time very competent system software engineers, because pretty much every pieces of Android will be fighting against such a use, and Google certification for Android devices will forbid most changes you'd want to do to have Android allow it. Also, you'll be much more likely to delay the project (either release or even simple upgrades, because Google's tests are often upgraded with new tests), making it liable for all other features as well.

So yeah, it's sad it went away, but I can't blame Samsung for it.

Quibbling over terminology, but rooting and flashing system images, although commonly conflated, are different things. My understanding is that true rooting (exploiting a vuln to get root privs) is rare now because it is relatively common to be able to unlock the bootloader and flash images. They probably want to go with "unlocked" in place of "rooted".

https://gist.github.com/FreddieOliveira/efe850df7ff3951cb62d...

Rooting is used correctly in the article, as evidenced by sudo dockerd --iptables=false . You need to be able to run commands as sudo.
It is worth noting that getting root on Android does not require exploiting vulnerabilities like on iOS. At least, not for most reasonable phones with an unlocked (or unlockable) bootloader.

When flashing an operating system, some do allow root access, some don't, or some make it configurable in settings. Another option is to install a tool like Magisk after installing the operating system.

Rooting doesn't imply using a vulnerability, it just means obtaining root privileges. This is most commonly done through modifying the initrd by "flashing" Magisk (I think that's what it does, not entirely sure).
Great! I've just destroyed a screen of my Android mobile and thought it could be great to use it as Raspberry Pi, as fixing that costs more than a new mobile.
Imagine Microblades: standard Android phone form factor slide in servers.

Building a home lab k8s cluster by buying something similar to a phone.you could go to a website say if you want a display or not, how much storage and than you have a flat server you just slide into your case.

Then a few years later you buy a stronger one and replace it while the old one is used by someone else.

Like how a Nas manages your disks, k8s could manage your Microblades.

Cheap ha with Autoupgrade capabilities.

I could also start using the outdated Microblades for offshoring when I keep them running at my parents place.

The enclosed could also provide networking and perhaps a 13" slide out display with a display selector.

I'm curious about how performant is a cheap phone ($50-150) against a Raspberry Pi thanks to the economics of scale. And it even has a screen! ;)
Maybe if you modify it to replace the battery with a heat sink
Autoscale provisions by ordering phones or creating returns on the Amazon website and creating jobs on fiverr to plug/unplug stuff.
Given that decent ARM cores are unpurchasable on SBC, and given the abundance of cellphones, this makes hella sense.

totally doable today. not holding my breath but usb4 also includes direct system-to-system connectivity, so these would be Just a Bunch Of Nodes with 40gbit connectivity each. plus the high efficiency & battery backups they already have today.

I don't understand the point of avoiding running docker in a GNU/Linux chroot, given that it has no downside that you don't already have due to running containers and would vastly simply the setup.

Also, the kernel xtaguid patch looks probably wrong, since it's removing code that is probably there for a reason, and it looks like the correct fix might be to add some other condition.