I read that while these Snapdragon laptops do technically have UEFI + ACPI, the information they provide is not useful for Linux and is more coupled with Qualcomm's proprietary drivers on Windows. Therefore, device trees are needed on Linux (I could be wrong about the first part).
Instead Qualcomm should improve their ACPI implementation and improve the kernels handling of it
It's an Armish not an Androidism. It's an embedded legacy that really doesn't make sense anymore. But inertia is powerful enough that even Apple is still using device trees, even on their M series SoCs ( https://asahilinux.org/docs/fw/adt/ )
Phoronix should have revised that article, it's completely misleading.
Why? Downstream vendor kernels generally use device trees and they can typically be easily extracted and decompiled for cases where the vendor is not GPL compliant and hasn't provided sources.
I've ported arm board device trees to mainline based Linux myself, porting the device tree has not really been the hard part in general...if mainline already has the necessary drivers.
The bigger issue tends to be that vendor kernels have a bunch of drivers that don't have upstream equivalents. I've been porting a lot of Allwinner ARM SoC drivers recently for the purpose of mainlining board support and it has been quite involved as Allwinner downstream kernels very heavily diverge from their mainline equivalent versions and are often based on 10 year old kernels. Even with Allwinner vendor sources(which are typically available in some form from BSP releases floating around on the internet) the drivers typically need to be fully rewritten due to Allwinner doing things in ways that mainline wouldn't accept. Luckily LLM's are quite good at this sort of porting work since they can ingest lots of garbage vendor driver code and create mainline variants(although there's usually substantial review/refactoring needed to get these merged upstream).
Often one also needs to port the drivers to uboot as well, in many cases one can mix a vendor uboot with mainline kernel but that doesn't always work properly(i.e. for Allwinner you generally can't boot a mainline kernel from vendor uboot and need to port uboot as well).
One other issue I've run into is that mainline Linux doesn't have great support for dynamic hardware probing which is often needed when vendors have different minor hardware variants that are all expected to use the same software builds. For example Allwinner on some SoC's will use a different co-packaged EPHY depending on the SoC revision which requires dynamic hardware detection via efuse probing. In other cases one may need to say detect a touchscreen device and driver by probing i2c addresses, mainline Linux has some support for this sort of thing but it's not particularly mature so sometimes one needs to do the hardware detection in uboot and patch or conditionally load device trees and/or device tree overlays which can be a bit involved.
I'm typing this on a Thinkpad x13s Gen1, "21BX000XGE". I really really like the device, best laptop I've owned so far, speaking strictly from a hardware perspective. No vents mean I can use it on a pillow, and it's dead silent. It never runs hot, great battery life. Thin and light, yet has all the performance I need. But would I recommend the laptop to any fellow Linux user? Absolutely not.
Even though it was released in 2022, the webcam still won't work. I can't limit the battery charge to 80% like on my x86 Thinkpad. There was a time when the graphics driver and Chromium didn't like each other and I had to wrangle Chromium into software rendering mode to avoid heavy artifacts on the screen (export force_gl_vendor="notfreedreno"). In fact, I still have the workaround in place. Not sure if it's still needed though. A fix was merged upstream last year, need to check whether it made it into Fedora yet.
I got the machine in 2025, and here are the workarounds and config changes I had to make just to get Fedora running last year, 3 years after release:
- extra kernel arguments ("arm64.nopauth" seems to be needed still in 2026, "clk_ignore_unused pd_ignore_unused" I have been able to remove at some point)
- GRUB config (GRUB_DEFAULT_DTB=/boot/dtb/qcom/sc8280xp-lenovo-thinkpad-x13s.dtb)
- initramfs modification, /etc/dracut.conf.d/x13s_firmware.conf: install_items+=" /lib/firmware/qcom/sc8280xp/LENOVO/21BX/qcdxkmsuc8280.mbn.xz /lib/firmware/qcom/sc8280xp/LENOVO/21BX/qcadsp8280.mbn.xz /lib/firmware/qcom/sc8280xp/LENOVO/21BX/qccdsp8280.mbn.xz ". Not sure if these are still needed, they were at some point.
In late 2025, installing Fedora was still a pain in the butt. There were custom-built ISOs for my device, but they didn't work because my firmware was too new. Stupid me ran a firmware update on the preinstalled windows. I tried building my own ISO, but the firmware never recognized those as a boot device for some reason (I have successfully built custom ISOs for x86 many times). In the end, I was able to use QEMU + chroot on my x86 machine to install Fedora ARM onto an external HDD, make the needed modifications in there, boot that on the laptop and run the anaconda installer, then make modifications to the install on the internal storage.
I just ran a quick `wc -w` on my installation and debug notes for the machine, and it's a cool 11180 words. At some point, it turned out that the display my unit uses was not in the list of known displays for the x13s. Seems that was mostly inconsequential aside from a kernel warning and maybe slower wakeup. Helped upstream with that, which eventually resulted in this commit: https://github.com/torvalds/linux/commit/3330b71caff6cdc387f...
I'm no stranger to exotic architectures and machines, having used Gentoo on a ppc64le machine as a daily driver for 3+ years. And I do like the laptop. But w/o fundamental improvements to the way ARM bringup works, not just improvements for individual machines, I wouldn't recommend this stuff to any unsuspecting user.
The device trees either exist in the proprietary blobs, or can be written.
"This gets USB, keyboard and touchpad working in ACPI mode on the HP Elitebook X G2q."
https://marc.info/?l=openbsd-cvs&m=178891082169317&w=2
Tobias (who also works for Canonical) recently demoed Ubuntu on mastodon and confirmed ARM EL2 works, meaning KVM support unlike previous generations.
bsd.network/@tobhe/117122761215052773
(I'd love to get my hands on one of these X2 Elite machines, hmu qcom.)
I don't really care about raw performance, just want long battery life, decent screen, and a *nix environment to work in. 99% of workload is going to be on a remote machine anyways.
I also purchased the T14s Snapdragon two years ago, and it gets longer battery life (if you just use a terminal only, the battery life remaining will sometimes say 20 hours, but it's more like 14-15 realistically). However, it can get uncomfortably hot on the left edge at the speaker. The T14s 2-in-1 (Intel) does not have any hot spots, though.
> We're upstreaming core drivers for Snapdragon X2 Series — including the Hexagon NPU and Adreno GPU — to open the door to developers and partners.
Glad this isn't going to be some semi-proprietary thing like support for chromebooks. Hopefully it continues.
Many Chromebooks have better linux support today than any of Qualcomms laptops from the last few years.
So same ARM BS as usual - AMD and Intel x64 are still the kings when it comes to out the door Linux support.
I'll buy a ARM PC when I can swap its motherboard CPU and GPU to a newer gen and my existing Linux install boots up without having to flash a new bootloader and custom vendor kernel with proprietary GPU blob.
The "original" X Elite was also supposed to get good linux support but it unfortunately never happened.
So hopefully the X2 will actually happen!
It's not huge because Qualcomm has proven that they'll continue to half-ass support until the next product is announced and then they'll disappear into the ether.
[1] https://browser.geekbench.com/processors/snapdragon-x2-elite...
[2] https://browser.geekbench.com/macs/macbook-pro-14-inch-2026-...
Hopefully this means Framework releases an X2 mainboard as it would be a match made in heaven.
My friend showed me his brand new Framework the other day, but I couldn't hear his spiel about its features over the noise of its fan!
Consider me cautiously optimistic.
Not some flaky "one release sometime after launch", a fully integrated release-chain for all components needed to boot Linux on any X2 series device
Well, in case anyone else is wondering, I have the answer. That's because Google is maintaining a cartel, the "GMS" cartel in short. Due to intense lobbying and incredibly weak antitrust enforcement, this cartel still continues to operate globally, keeping soc makers like Qualcomm, Mediatek and Unisoc in chokehold. We won't see any real competition in the smartphone space unless it's destroyed, but market forces alone can't do that.
I want the stuff to work, I want Qualcomm to provide an easy process to grab a X2 Elite Windows Laptop and install Linux.
No magical binary blob extraction. I want everything tested.
With SteamFrame out we might even get decent gaming !
If we could have a similar experience to Intel-based ThinkPad Carbon X1 or T series with performance, graphics, Wi-Fi, battery life, suspend/resume, external displays, etc, that would be awesome!
Apple hardware is awesome but I want to run Linux.
In other words: it might be a trap and you could get screwed in n years if they stop maintaining it and some kernel changes make the driver not compilable on newer versions.
It has been so many attempts to run Linux on this chips without any collaboration from Qualcomm. Companies even drop support after years of development.
Qualcomm provided efficiency (battery life). But intel is catching up fast to make Qualcomm irrelevant.
Welcome, but too late.
"We're stuck with just a protocol that can have arbitrary implementations including full backwards compatible X11 servers"
An open Linux is hobbled without the rest of the stack.
Expect binary drivers for specific releases of Ubuntu and Debian.
Also here is an answer to other day's why people still use Ubuntu.
Part of this is probably motivated by the fact that Microsoft and Nvidia have teamed up.
A x2 based workstation will also be very cool.
You hold them up to the Apple M series rollout and its just hilarious how far "the competition" is behind when it comes to laptop low power CPUs
Unless they're enforcing signed boot from the factory, it's up to software to run on hardware.
Please sell >1 model of computer with X2 EE (elite extreme) please please please. Not that #1 was bad at all but more please! https://www.notebookcheck.net/Asus-Zenbook-A16-Laptop-Review...
I really hope it's like 2031 and we're swimming in way too many of these. Running great Linux. How sick would that be. (And X4 is running mainline great too).
Is Googlebook a new name for chrome os? Or is it a typo?
[1] https://www.qualcomm.com/content/dam/qcomm-martech/dm-assets...
[dead]
Remember the Snapdragon Insider phone that was almost instantly abandoned? I think it never even got a single major release update.
They took everything that was open about Atheros WiFi and closed-sourced it by putting everything into binary blobs.
Most of the laptops from the last year or two are still not usable. Audio and webcams will almost certainly never be fully supported, or even supported well enough to be usable.
Still keeping my fingers crossed that in the near future we can throw Linux onto an HTC Vive Focus or a Meta Quest and re-take ownership of our data and devices, but it’s strictly hopium at this point.
[dead]
[dead]
I'm not a kernel developer, but it seems to be one of those things that's great when you're adding support for a particular device on a particular platform, but becomes a giant PITA in the aggregate for the downstream ecosystem. It's a mismatch of incentives and preferences.
Kernels always have to be changed for different hardware, that's nothing new. x86 kernels don't run on ARM machines, full stop. Gameboy Advance kernels don't run on Switch 2. IBM mainframe kernels don't run on AWS EC2.
As part of good engineering practice we like to separate the parts that are volatile with regard to hardware changes from the parts that are nonvolatile. But that's a kernel implementation detail and we shouldn't pretend it means the combined kernel doesn't need to be changed.
We can also embed several volatile components for several different hardware configurations. That's called inefficiency, or bloat.
There were several attempts for hardware to incorporate the volatile component itself and be self-describing. ACPI (in ROM) is one; device-tree-in-ROM is another. Neither turned out to work well, because it turns out you actually want to evolve that code and so kernels contain lists of ROM patches anyway, which isn't much better than just including whatever was in the ROM to begin with.
Isn't there a way to have loadable device drivers that live outside the kernel?
This is definitely a thing in some embedded systems I’ve used. There are some Marvell boards which do this. They all use U-boot though.
It’s crazy to need a million device trees on server or laptop class devices.
On Windows, Qualcomm ships custom drivers that override normal ACPI platform logic in various places, IIRC
One of the reasons is that Qualcomm uses supplemental ACPI tables (think device tree overlays) shipped inside of the driver packages. Look at the .bin in plenty of the drivers carefully and you'll see that they're supplemental ACPI tables.
Windows doesn't have such a notion and it's implemented via having an ACPI table loader statically linked in to individual drivers.
_On top_ of that, Qualcomm uses PEP to intercept plenty of ACPI functions and implement them in native code instead.
Meanwhile in x86 land you can just download a distro and boot it. Secure boot works out of the box. It's night and day.
Sometimes the SDK is a zip of the developer workspace in a pseudo working state with no clear records of all that's been patched.
Vendors providing binary only kernel and system images containing god knows what is not uncommon either.
I'm convinced now that arm hardware vendors are simply incapable of even understanding what proper software support is. I'm sure some of their devs do their best but management does not care. By the time the chip ships, efforts move to making the next thing so they never properly finish the software side.
Linaro is (or was, back when I was involved ~10 years ago) non-profit sponsored by SoC vendors to develop, maintain and upstream SoC support for Linux, along with running a comprehensive validation lab for all the boards they support.
A list of manufacturers did change a few times, and it was half-sponsored by ARM directly.
What I hear a _lot_ is that the thing could have been an esp32 (or Arduino rarely).
That’s a way wider price gap. I can order Costco-sized lots of esp32’s for the price of a single RPi.
RPis pricing has really, really narrowed the space where their products make sense. Low power devices can be esp32, high power can be x86 NUC things (or interconnected esp32s if you need tons of pins).
I don’t encounter a ton of things in “too big for an esp32 but I’m positive I don’t even want the option of a beefier x86 CPU”.
No hate if it works for you. I don’t even dislike RPi, they’re just in a narrower band for me these days.
The standby battery life is so bad, it will burn through half the battery overnight with the lid closed. The battery life actually seems better when using the laptop opposed to standby.
Other standby modes were removed on a firmware level by lenovo despite the processor supporting it.
I still have my 4th gen X1 carbon, it was an amazing machine for 8 years and I really thought I'd get another 8-year laptop buying the latest X1, but now it sits off and only comes out for specific uses. Bought an m4 air for day-to-day laptop use.
I ran Windows on it up until a few months ago and it was as you said, delightful. Long battery life, fanless, great size, great screen. I put Ubuntu on it (where they've mainlined a good bit of things), and it's still just not very good. Sleep doesn't work (and never will without Qualcomm), certain things still just crash on occasion -- but I do think the webcam works.
I'll likely put Windows back on at some point, which is a shame, because the laptop is great, but Windows is terrible. I simply do not believe any claims Qualcomm has about future support, as much as I'd love to see a newer Thinkpad device with full ARM support.
Why? In theory the UEFI firmware can pass Linux a devicetree. Not much different to different laptops having different ACPI tables.
*: I’m sure there’s some features that still aren’t working right.
Better for everyone. Apple gets lazy on top. And for those who don’t want a Mac, they should be able to have something great too. And since PC makers are far more willing to experiment with form factors, I’d like to see what they try.
It will be interesting. because Qualcomm doesn’t give away anything for free, so any of those Linux Distro’s who thinks it’s going to be a free lunch? Are gonna be in for a surprise.
Care to postulate on what those nefarious reasons/surprises could be?
A20 Pro P-Core is the largest jump in performance per watt in the past 5 years. I am not sure why Apple is lazy in their hardware front. Not the same could be said about their software though.
Finally the end of IBM PC clones is taking shape.
For many years Apple dominates the Laptop hardware scene, and while there is no comparably performing competitors threatening them, they keep releasing newer, faster, more efficient chips. After using many operating systems, I know that for sure I don't want MacOS, but the hardware itself is hard to beat.
What are you thinking of here? ATX is from 1995 and ITX from 2001, since then we've had stuff like the lamp imac, trashcan mac pro and nowadays the finger-thin imac and tiny mac mini from Apple.
Price-wise, you're still often better off with amd64. People like to compare the top-end chips, but the competition for a huge slab of amd64 is a small laptop running an iPhone CPU, not the M6 Ultra or whatever the latest and greatest is today. After Apple followed the rest of the industry, the launch price advantage of the Neo quickly grew smaller, especially outside of the USA. If you want a 15 inch laptop, you're pretty deep into high end prices the moment you consider a Macbook.
In practice, getting the M series to run Linux takes longer than it takes Qualcomm to release a Linux build that works, and amd64 takes a few months of actual vendor support rather than enthusiasts hacking away for free, so in that sense the M series is still behind.
Note however, since I've been using my Thinkpad 2-in-1 on battery almost everyday for a year, it is somewhat degraded. upower shows
energy-full: 50.61 Wh
energy-full-design: 58 Wh
Not very close at all, not even to the two-year-old model, it appears
https://wccftech.com/snapdragon-x2-plus-loses-to-m4-in-4-out...
Where a desktop's TDP is actually useful is for multi-thread performance, and naturally the multi-thread chart is topped by Threadrippers.
Moreover, Geekbench is rubbish in general. For example, it has Threadripper 9980X with a <50% higher multi-thread score than Ryzen 9 9950X even though it has twice the memory bandwidth and four times as many of the same cores and you have to look pretty hard to find a real multi-threaded workload where it's not significantly more than twice as fast:
https://www.phoronix.com/review/amd-threadripper-9970x-9980x...
nothing wrong with it! looks fine! just: there should be other products with the nice core. i could really use a 10-14" tablet. i mean, after all, ROG Flow 13 with a Strix Halo was not even that late after launch! dense is doable!
[deleted]
No wifi, no bluetooth, no fingerprint reader, no hardware accelerated 3D..
There is a special version of Ubuntu that largely works (it's a bit old) and if you dist-upgrade to a new version it will break.
I spent about a week trying to get it working and just gave up, awful experience.
https://archlinuxarm.org/platforms
Alas, new Chromebooks are no more. "Successor" Googlebooks are all Android.
ALARM isn't official Arch, so this also isn't an "official Arch supported hardware list". Arch is currently still only x86_64 and everything else is at best unofficial if not just straight up unaffiliated.
(do note that this might change soon-ish™ considering [0], but I think they want to first get their automated build infrastructure ready)
[0]: https://gitlab.archlinux.org/archlinux/rfcs/-/merge_requests...
Regular OEMs will never give their differentiation factor freely.
Even Linux OEMs like Tuxedo apparently cannot get access to hardware specifications, and have to reverse engineer their own devices.
add in swappable batteries like older laptops and phones, and I would as well. not now though.
I've had a Snapdragon X Elite laptop for 2 years, constantly trying to get Linux off the ground on it. Didn't happen (well, technically, toward the end of that period, there was an unsupported port of Ubuntu but it lacked half the drivers). And yes, when I bought it there was a very similar announcement from Qualcomm promising first-class Linux support. So I wouldn't gamble on it (especially considering that prices are crazy) until there indeed is a supported distro.
A competent FTC would be fining them for these false and misleading statements. Until that happens, nobody should buy these thinking Linux will ever be supported.
But it can be annoying to use day-to-day since a lot of stuff is not upstreamed or not integrated into the major distros.
Is QCM slow to upstream or are they doing things in an incomplete manner or is there some other reason?
I'm trying to imagine a world where intel or amd releases a new platform/chip and it takes _two years_ to get linux booting on it
That's been my experience dealing with QCM based devices running linux in the past. Some OEM buys a batch of chips, gets a reference design and an old version of the linux kernel with a zillion out-of-tree hacks and patches that make updates impossible.
I generally advise clients to use rockchip as they have _very_ good mainline support and put any QCM modem at the end of a USB connection so it doesn't hold the product back.
Consider me dangerously pessimistic
It was already proven by the whole netbooks, Android, WebOS, and ChromeOS.
Linux yes, as cost cut factor, and as means to power specific commercial products, running on top of WSL/Virtualisation Framework, or expensive racks on hyperscalers.
The whole community stuff, from OEMs point of view, only when it really has to be.
If the drivers are upstreamed and good, it should work well.
This is the danger when you don’t upstream your shit. Now you’re stuck on kernel 3 or 4 because your chip vendor is lazy. And Qualcomm has got to be one of the laziest.
If there were alternatives (like on the desktop and for some parts of IoT) it would be more cost-efficient to upstream everything, but with the current situation it's fully up to Google.
When Google wanted them to move all their chip-specific code to modules (GKI), they had to do that. And if someone at Google randomly decided "hey, now you'll upstream this stuff", then guess what? They'd have to follow, it's how this monopoly works.
I don't love how much control Google is exerting over Android, and I don't love having to use their signed kernel. But I do prefer that vs. being stuck on an abandoned vendor kernel. If I have to accept low-quality proprietary kernel code, I'd rather keep it in small module-shaped boxes.
Companies like Qualcomm complain about this, but their historical practices are what drove Google to mandate it in the first place.
So that if you want to use the next distro release you will be forced to buy their next-gen chip because that's the only supported one on that distro. D'uh.
Because getting your stuff upstreamed in Linux is more work than releasing a custom kernel.
On the contrary, Apple has to do a lot of greenfield work by refusing standards like UEFI, Vulkan and normal filesystems. They end up reinventing the wheel just to support the same featureset that Qualcomm, Nvidia, AMD and Intel all generally planned for.
The tech world is a better place without full-stack UNIX grifters demanding a pound of flesh. Eventually macOS will be buried alongside them, as Apple has clearly has no intention to develop a fully-featured OS for Apple Silicon.
I suspect in the next 5 years something like this will come up.
I am thoroughly enjoying the trouncing that Apple is giving everyone in terms of exploiting ARM - it is bothersome however in many ways true — I just am not so sure the open-ness of things has been fulfilled as much as, say, the good ol’ OpenPandora days, if you catch my drift ..
Everything has to be open. No blobs, compilers everywhere as a first-class application, well managed open source repo’s for everything, updates free of charge around a namespace that is large and wide for many, many communities of developer/user interactions occur, unimpeded by needing to ask permission to sign things, but rather just letting everyone sign things together easily from user to developer-level, and let ship new apps from well-oiled repositories ...
No, I think the tooling in the MS/NVidia domain is going to be pretty much the lynchpin. I really, really prefer 100% open source, to the extent it is feasible..
[deleted]
However, there is a fatal flaw in the process that makes this a pipe dream in reality. In Linux, these rules only apply to reviewed and merged drivers. And during review any new DT interface will almost certainly be bikeshedded in some way.
So unless your chip vendor has upstreamed ALL their drivers before a device is manufactured, the device's firmware-provided DT will very likely work only against a vendor kernel and requires updating.
Fanless just means slower.
It's not necessarily any better on Windows. I've worked with Qualcomm based laptops that wouldn't work without a bespoke Windows image from the manufacturer. I also had one where the "generic" ARM Windows image wouldn't work with it even though it should've and the manufacturer never provided a bespoke image.
They (along with Intel) also ended up making most of the non-Apple ARM chips, which are not competitive with the Apple ones.
And looking at the direction Microsoft is going, and thinking: "Shackling our laptop and desktop chip sales to this is a bad idea."
The entire landscape outside of the Raspberry Pi is a shitshow in terms of "Just download a distro for your device class and arch and it'll work."
Arm SystemReady appears to be a slow push in the right direction from the opposite end.
The Intel models were worse, but they weren’t bad as far as I know.
Which is fine. Have a great day.
There are projects trying to tackle it, but compared to x86 it's a fragmented mess. That's what we're losing with ARM laptops - universal computing.
If ARM processors are regularly incompatible and segmented, we all lose out and end up in isolated silos.
I'll also grant that Apple has gotten more boring with age - the G4 imac is still the coolest computer I've seen to this day. Just so outrageously out there. Current offerings are efficient but a bit boring. Apple Silicon could make something like the trashcan design work, when it basically failed with x86 PC components.
Having said all that I wouldn't mind seeing an ecosystem of ARM-based components even if they followed the ATX standard. Being able to buy an ARM-compatible motherboard and upgrade my ARM-based CPU and pair it with separate RAM and SSD's would be nice!
I have an m1 16gb MBpro in our fleet for editing and it runs probably as fast as the day I got it (first wave of m1’s).
The low power draw is also very impressive. Fraction of my AMD rig at home.
And even on my desktop, where battery life doesn't matter, I wouldn't mind my CPU needing less cooling.
I say this as someone who will probably never own a mac.
This is a natural major conflict with the qualities of a laptop that’s good at being a laptop, but yeah, I’d prefer that my custom built tower be efficient, cool, inaudible, and a small as reasonably possible without severely impinging expandability.
I’ve heard of people building desktops around mobile x86 CPUs soldered onto ITX/mATX boards, which sounds like it might be the solution that mainstream manufacturers don’t want to give us. Even a modest desktop cooling solution is vastly more capable than what can be fit into a laptop and so should keep such a CPU chilly with ease.
Also, that's on Ryzen AI 7 PRO 450, you might be getting even more out of the Panther Lake alternative.
¹ https://www.notebookcheck.net/Excellent-business-laptop-with...
https://browser.geekbench.com/v6/cpu/19122559
https://browser.geekbench.com/v6/cpu/14591329
yup... still laughably behind by nearly 20%. And that is behind the M5, not even the current M6
20% slower than the M5 is still a great result. I'm still using an M1 macbook pro, and it's more than fast enough for editing film, browsing the internet and writing code.
I think we have a different definition of what laughably means. Especially since A16 is 25% ahead of M5 in multithreaded.
You're still trying to deliver your original point after you were told you use the wrong reference and you're not doing a good job.
Intel said no to designing iPhone chips, IBM and Motorola couldn’t see a future of faster/better chips to meet the demands of future tech devices, Apple with that crazy CEO, Steve Jobs? Had to go it alone and the rest is history.
The Apple Silicon design group appears to be on a roll. What next? Bringing memory in house? I think they will. Because that will be the only way they can build the devices they want to build at a reasonable price going forward.
Before you yell no what is it about the last 28 years have you missed? They seem to be able to execute long-range projects when it comes to hardware and software in comparison to their tech peers, looking forward to the M7 ultra, in-house memory and the C3 modem.
> What next? Bringing memory in house? I think they will.
It's okay to say that you don't know anything about chip fabrication, instead of making silly assumptions like this.
In the ARM world, that other part you are completely ignoring isn't standardised, even with device trees, they only help to alleviate the pain that each computer is its own OEM snowflake.
In ARMland, there's no such thing as standard OS images you can install on any machine, or generic components that users can buy and install themselves.
[deleted]