81–90 of 124 posts
I have a virtual instance of Win11 ARM running in UTM on my MBP. It's honestly been surprisingly rare that I have to figure out how to run something that requires x86. More and more Linux distros have an ARM version that I can run if I need to.
Earlier quoted context omitted.
Most people outside US, and similar G8 countries, aren't going to pay Apple.
No, but Microsoft are also going arm. Where the us goes, the world goes eventually.
Additionally beware what to wish for, as CoPilot+ PC are locked down with Pluton security processor, from XBox and Azure Sphere.
I'm quite concerned about x86 future, but the article has a point if you read it past the title. It says that x86 is highly standardised - even with different combinations of chips, peripherals and motherboards you know it will work just fine. It's not the case for ARM systems - can you even have something similar to IBM PC with ARM? I personally know that adding support for ARM devices on Linux is a huge and manual…
RISC-V can be essential for this open future
It’s a crapshoot. That’s why whenever anyone recommends a certain cool Arm motherboard or mini PC, the first thing you have to figure out is what its software support situation is like. Does the OEM provide blessed Linux images? If so, do they offer more than an outdated Ubuntu build? Have they made any update promises?
I really hate to like x86 but I know that when I set up an embedded x86 device it's flash, apt-get update/upgrade, and I've got the latest stuff running and supported.
Earlier quoted context omitted.
> can you even have something similar to IBM PC with ARM Yes, it's called SBBR which requires UEFI and ACPI. It is more common on server hardware than on consumer-grade embedded devices. The fact that it is not ubiquitous is really holding back ARM.
Will you PLEASE stop promoting UEFI and ACPI?! These are closed-source blobs that the manufacturers will never update and have complete control over the system at ring -2. Why would you even consider it? Device tree does the same thing and it's open source. Even if you only extract it in binary form a proprietary kernel or uboot, you can decompile it very easily.
Well, no, UEFI can have proprietary implementations, but nothing prevents just shipping edk2.
Conversely, there are so many phones with devicetree... and proprietary blobs controlling boot and running beneath ring 0. You're kinda pointing out a real problem, but confusing it with a different part of the stack.
Earlier quoted context omitted.
> can you even have something similar to IBM PC with ARM Yes, it's called SBBR which requires UEFI and ACPI. It is more common on server hardware than on consumer-grade embedded devices. The fact that it is not ubiquitous is really holding back ARM.
Will you PLEASE stop promoting UEFI and ACPI?! These are closed-source blobs that the manufacturers will never update and have complete control over the system at ring -2. Why would you even consider it? Device tree does the same thing and it's open source. Even if you only extract it in binary form a proprietary kernel or uboot, you can decompile it very easily.
ARM device trees suck. ACPI for sure it's hell, but a DTB per device it's a damn disaster. U-Boot it's open, but it sucks at having to plug a damn USB-serial cable in 2026 in order to get a prompt . That should come builtin, and with an easy builting help or some text based menu.
It's either a DTB per device or a firmware blob per device . I'll take the open source device tree anytime!
Earlier quoted context omitted.
^ that! You can't run a COM program today. Not without emulation. Recent PCs can't even run DOS EXE because they're missing the BIOS interrupts most DOS programs use.
You can just boot freedos to run them, it will execute in real mode which has the same cpu instructions as 40 years ago.
Earlier quoted context omitted.
You can still boot Linux on PCs though. ARM devices, you're SOL in most cases. Device tree is a total shit show. For random ARM device, better hope randomInternetHero42 on a random forum has it for your device. Just asking the device itself what exists would be stupid question in ARM world.
I don't know what you're talking about. If the device boots, you find the device tree in /sys/firmware/fdt, or in unpacked human-readable form in /sys/firmware/devicetree/* .
Earlier quoted context omitted.
Will you PLEASE stop promoting UEFI and ACPI?! These are closed-source blobs that the manufacturers will never update and have complete control over the system at ring -2. Why would you even consider it? Device tree does the same thing and it's open source. Even if you only extract it in binary form a proprietary kernel or uboot, you can decompile it very easily.
What? You can build an entirely free UEFI. ACPI has a free compiler and a free interpreter. Neither implies or requires the existence of non-free blobs, and neither implies or requires any code running in a more privileged environment than the OS.
Earlier quoted context omitted.
What? You can build an entirely free UEFI. ACPI has a free compiler and a free interpreter. Neither implies or requires the existence of non-free blobs, and neither implies or requires any code running in a more privileged environment than the OS.
Which x86 devices ship with a free UEFI/ACPI? Or even allow users to replace the preinstalled UEFI/ACPI with a free one?