481
submitted 5 months ago by hanrahan@slrpnk.net to c/linux@lemmy.ml

Most of the functionality is present but many important bits are still being developed.

all 42 comments
sorted by: hot top controversial new old
[-] qjkxbmwvz@startrek.website 118 points 5 months ago

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)!

[-] henfredemars@infosec.pub 58 points 5 months ago

Arm:

Somehow, the kernel has been loaded and we have transferred control into it.

[-] possiblylinux127@lemmy.zip 23 points 5 months ago

But we still need a hundred blobs and if the kernel needs to do something it has to make a call to the firmware.

This is what we get when you use Broadcom

[-] fredhampton@sh.itjust.works 7 points 5 months ago

Somehow, the kernel returned. -Poe dameron

[-] zarenki@lemmy.ml 50 points 5 months ago

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.

[-] onlinepersona@programming.dev 30 points 5 months ago

I'm hoping RISC-V will start showing up in consumer products soon. Hopefully the first ones will be Linux laptops. Windows doesn't have RISC-V support yet, does it? This might be the opportunity for Linux to become the default for RISC-V.

Anti Commercial-AI license

[-] morrowind@lemmy.ml 7 points 5 months ago

wouldn't risk-v be worse in terms of standardisation? At least for advanced functionality

[-] possiblylinux127@lemmy.zip 2 points 5 months ago* (last edited 5 months ago)

Pine64 has a few Risc-V boards

[-] possiblylinux127@lemmy.zip 13 points 5 months ago* (last edited 5 months ago)

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.

[-] bamboo@lemm.ee 1 points 5 months ago

I don’t think this is as much of a problem, proprietary hardware is a thing on x86 too. The two big problems are a lack of boot standardization, and vendors not upstreaming their device drivers. A lack of standardization means it is difficult or impossible to use a single image to boot across different devices, and the lack of upstream drivers means even if you solved the boot process, you won’t be able to interface with peripherals without using a very custom kernel.

[-] possiblylinux127@lemmy.zip 1 points 5 months ago

True, one of the issues of Android is also cost and development time. Manufacturers want to develop a product as cheap and fast as possible to keep up with demand.

[-] bamboo@lemm.ee 1 points 5 months ago

That’s true for all commercial development. No company wants to invest more than they have to. Upstreaming does save time in the long run, but not in the short term.

[-] possiblylinux127@lemmy.zip 1 points 5 months ago

Technically Google could of made upstreaming easier or even the default but they instead modified the kernel a bunch and then encouraged bad practices in development.

There are of course trade offs to everything though. For instance, Qualcomm could do better.

[-] bdonvr@thelemmy.club 6 points 5 months ago* (last edited 5 months ago)

I mean, you can get the Pi to use EFI and just boot generic images.

[-] possiblylinux127@lemmy.zip 3 points 5 months ago

It needs proprietary software to boot

[-] Username@feddit.de 4 points 5 months ago

Most x86 EFIs are, so the comparison is not really fair.

[-] possiblylinux127@lemmy.zip 3 points 5 months ago

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

[-] LeFantome@programming.dev 3 points 5 months ago

“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.”

[-] MonkderDritte@feddit.de 1 points 5 months ago* (last edited 5 months ago)

The actual downside is, that you can't have generalized drivers.

[-] smileyhead@discuss.tchncs.de 1 points 5 months ago

It's not x86 vs ARM problem. But rather vendor problem, how AMD/Intel upstream their Linux support while other do not.

[-] possiblylinux127@lemmy.zip 91 points 5 months ago* (last edited 5 months ago)

That is actually really good news

[-] sfera@beehaw.org 45 points 5 months ago

Any hardware vendor taking Linux support seriously is good news!

[-] possiblylinux127@lemmy.zip 8 points 5 months ago* (last edited 5 months ago)

Which is most of them (Linux is great)

[-] SpaceNoodle@lemmy.world 20 points 5 months ago

Why is this surprising? Qualcomm releases Linux BSPs for all their mobile SoCs.

[-] possiblylinux127@lemmy.zip 13 points 5 months ago

That's Android not mainline. You can't easily upstream the changes and you are stuck with a single kernel version.

[-] SpaceNoodle@lemmy.world 4 points 5 months ago

They regularly uplevel the kernel, and not all Android Linux code is inherently incompatible with mainline.

[-] possiblylinux127@lemmy.zip 7 points 5 months ago* (last edited 5 months ago)

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.

[-] KillingTimeItself@lemmy.dbzer0.com 11 points 5 months ago

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.

[-] Grappling7155@lemmy.ca 7 points 5 months ago

? the age of the Linux phone has been here for years with Android

[-] KillingTimeItself@lemmy.dbzer0.com 7 points 5 months ago* (last edited 5 months ago)

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.

[-] MeDuViNoX@sh.itjust.works 3 points 5 months ago
[-] KillingTimeItself@lemmy.dbzer0.com 5 points 5 months ago

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
[-] smileyhead@discuss.tchncs.de 3 points 5 months ago

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.

[-] MeDuViNoX@sh.itjust.works 1 points 5 months ago* (last edited 5 months ago)

He asked and said he'd wait, I just took the straight up easy route and grabbed the first video off search. I honestly don't know much about Linux, but I'm learning more every day.

Chrome books seem like they're closer to Linux than Windows is though, right?

[-] secret300@lemmy.sdf.org 1 points 5 months ago* (last edited 5 months ago)

Bad example because you can. With the linux container you can install any linux app and it works on a Chromebook. Appears in the app search too. But I definitely get what you mean, Chrome OS and Android may use the Linux kernel but they'll never be Linux

[-] KillingTimeItself@lemmy.dbzer0.com 2 points 5 months ago

you say bad example, yet you literally have to jump through hoops to do it. I think it's a bad fucking distro of linux, if it requires you to setup and configure and entire fucking container system in order to run non google approved applications, specifically those that debian hosts, because i'm not sure it lets you run other containers.

Chrome OS and Android may use the Linux kernel but they’ll never be Linux

yes, my point here is that android is linux in the same way that you can install blender on chromeos using an entire secondary system, and bullshit containerization, while i can just tell my package manager to install it, and it fucking installs it. And then i can just fucking open it.

By this logic windows is also a fucking linux system because you can use WSL on it.

[-] secret300@lemmy.sdf.org 2 points 5 months ago

By this logic windows is also a fucking linux system because you can use WSL on it.

Okay I never thought of it this way and I actually completely understand your point now.

[-] KillingTimeItself@lemmy.dbzer0.com 2 points 5 months ago

exactly! It's such a loose definition, even though it fits none of the standard modes of operation for linux. If something that broadly not linux counts as linux, we might as well count BSD as a subset of linux, even though it's completely different.

[-] LeFantome@programming.dev 2 points 5 months ago

WSL runs Linux in a VM. They have made it easier but it is by no means native.

By contrast, while the other poster thinks Blender is too hard to install on ChromeOS, it is nevertheless running right on the Linux kernel. The only reason you have to jump through hoops is because Google wants to make it hard.

The same is true when you run Android apps on Linux. They run natively on the kernel. There is really not much difference between running. Android on Linux and running actual Linux apps via Docker or Podman. Running Blender on ChromeOS is the same.

[-] KillingTimeItself@lemmy.dbzer0.com 1 points 5 months ago

yeah and technically containers aren't native either? They do run natively on the kernel of the existing machine, but the environment around them is entirely manufactured.

ChromeOS itself isn't even clear about whether it's a VM or a container, it says it's both.

My problem here isn't that you can run android apps on linux, or vice versa, my problem here is that android and linux are two fundamentally different systems, this is like putting a 13inch tire on a car that normally uses 21s. It'll "technically" work, but good luck getting around at any effective pace.

[-] smileyhead@discuss.tchncs.de 2 points 5 months ago

No? Linux – all the benefits why we want Linux = Android.

Try and run Android on your PC for a week and tell me how it went.

this post was submitted on 15 May 2024
481 points (100.0% liked)

Linux

47943 readers
1265 users here now

From Wikipedia, the free encyclopedia

Linux is a family of open source Unix-like operating systems based on the Linux kernel, an operating system kernel first released on September 17, 1991 by Linus Torvalds. Linux is typically packaged in a Linux distribution (or distro for short).

Distributions include the Linux kernel and supporting system software and libraries, many of which are provided by the GNU Project. Many Linux distributions use the word "Linux" in their name, but the Free Software Foundation uses the name GNU/Linux to emphasize the importance of GNU software, causing some controversy.

Rules

Related Communities

Community icon by Alpár-Etele Méder, licensed under CC BY 3.0

founded 5 years ago
MODERATORS