Most of the functionality is present but many important bits are still being developed.
the age of the linux phone is approaching. People keeping saying it isn’t they’re wrong, i don’t know why they think otherwise.
? the age of the Linux phone has been here for years with Android
android is not the linux phone.
The chromebook would the desktop linux workstation if that were true.
Go install blender on a chromebook, i’ll wait.
cons:
- has to enable linux containers
- can’t use native filesystem for emulated applications because it’s a completely different environment
- potential for performance issues given that it’s literally a non standard environment
- wastes a bunch of disk space
- requires an entire secondary system to be maintained and updated
pros:
- can technically run linux applications
Bad examples. Just running some program is not an argument. Even Windows can run most Linux programs in WSL, but does not mean it’s Linux.
One of the real downsides of ARM is, it seems, the relative lack of standardization. An x64 kernel? It’ll run on most anything from the last ten years at least. And as for boot process, it’s probably one of two options (and in many cases one computer can boot either legacy or EFI).
ARM, on the other hand…my raspberry pi collection does one thing, my Orange Pi does something else, and God help you if you want to try swapping the Orange kernel for the Raspberry (or vice versa)!
A standard called SystemReady exists. For the systems that actually follow its standards, you can have a single ARM OS installation image that you copy to a USB drive and can then boot through UEFI and run with no problems on an Ampere server, an NXP device, an Nvidia Jetson system, and more.
Unfortunately it’s a pretty new standard, only since 2020, and Qualcomm in particular is a major holdout who hasn’t been using it.
Just like x86, you still need the OS to have drivers for the particular device you’re installing on, but this standard at least lets you have a unified image, and many ARM vendors have been getting better about upstreaming open-source drivers in the Linux kernel.
Arm:
Somehow, the kernel has been loaded and we have transferred control into it.
If the system is SystemReady then the EFI boot chain is fairly straightforward now. My current workstation just booted off the Debian usb installer like any other pc.
Faith in standards temporarily restored
I think a lot of the problem is how proprietary some of the hardware is. For instance, the Raspberry pi only runs the raspberry pi kernel which has a lot of proprietary blobs.
Meanwhile boards from Pine64 don’t need proprietary software to boot. The achieve this by being selective with the hardware and hardware vendors.
“So far, Qualcomm has most of the critical functions working inside Linux, specifically version Linux 6.9 that was released not too long ago. These critical functions include UEFI-based boot support along with all the standard bootloaders like Grub and system-d.”
I mean, you can get the Pi to use EFI and just boot generic images.
It needs proprietary software to boot
Most x86 EFIs are, so the comparison is not really fair.
That is only sort of true. You don’t need proprietary software on a live USB to boot x86. That’s not the case with the Raspberry Pi as it boots from its GPU
That is actually really good news
Why is this surprising? Qualcomm releases Linux BSPs for all their mobile SoCs.
That’s Android not mainline. You can’t easily upstream the changes and you are stuck with a single kernel version.
They regularly uplevel the kernel, and not all Android Linux code is inherently incompatible with mainline.
Tell that to my phone. Its possible some are worse than others but for Android devices the track level isn’t good. Just check out the mainline status of PostmarketOS devices.
