Equal effort is far more likely from Qualcomm than hardware docs. They don't even freely share docs with partners, and many important things are restricted even from their own engineers. I've seen military contractors less paranoid than QCOM.
I'd have to say that full hardware documentation, even under NDA, is prerequisite to claim equal effort. The expectation on a desktop platform (that is, explicitly not mobile, like phones or tablets) is that development is mostly open for those who want to, and Qualcomm's business is sort of fundamentally counter to that. So either they're going to have to change those expectations (which I would prefer not to happen), provide more to manufacturers, or expect that their market performance will be poor.
Qualcomm could've become "the Intel of the ARM PC" if they wanted to, but I suspect they see no problem with (and perhaps have a vested interest in) proprietary closed systems given how they've been doing with their smartphone SoCs.
Unfortunately, even Intel is moving in that direction whenever they're trying to be "legacy free", but I wonder if that's also because they're trying to emulate the success of smartphone SoC vendors.
I don't know if the prospect of being the "Intel of ARM" is very appealing when you can manufacture high-margin smartphone SOCs instead. The addressable market doesn't seem to be very large; any potential competition is stifled by licensing on both Microsoft and Softbank's side.
The legend of Windows on ARM is decades old, and people have been seriously trying to make it happen for at least the past two decades. They're all bled dry. Apple is the only one who can turn a profit, courtesy of their sweetheart deal with Masayoshi Son.
Well that would have an obvious solution. Go make RISC-V CPUs for phones etc. until you get good enough at it to be competitive in laptops, at which point Microsoft gets interested in supporting you and you get to be the Intel of RISC-V without dealing with Softbank.
The extent PCs are open is an historical accident, that most OEMs would rather not repeat, as you can see everywhere from embedded all the way to cloud systems.
If anything, Linux powered devices are a good example on how all of them end up with OEM-name Linux, with minimal contributions to upstream.
If everyone would leave Windows in droves, expect regular people to be getting Dell and HP Linux at local PC store, with the same limitations as going outside their distros with binary blobs, and pre-installed stuff.
OEMs don't care about that. It's Qualcomm in particular that sucks. If you buy a Linux PC from System76 it comes with their own flavor of Linux but it's basically Ubuntu and there is nothing stopping you from putting any other version you want on it. The ones from Dell just use common distributions.
Meanwhile Linux is getting a huge popularity boost right now from all the PCs that don't officially support Windows 11 and run Linux fine, and those are distribution-agnostic too because they didn't come with it to begin with.
Usually what is stopping us are the drivers that don't work in other distro kernels, or small utilities that might not have have been provided with source.
4% was last year, it was 5% by this summer (a significant YoY increase and about what macOS had in 2010) and the Windows 10 end of support was only last month so the numbers from that aren't even in yet.
> Usually what is stopping us are the drivers that don't work in other distro kernels, or small utilities that might not have have been provided with source.
A lot of these machines are pure Intel or AMD hardware, or 95% and then have a Realtek network controller etc., and all the drivers are in the kernel tree. Sometimes the laptops that didn't come with Linux to begin with need a blob WiFi driver but plenty of them don't and many of the ones that do will have an M.2 slot and you can install a different one. It's not at all difficult to find one with entirely open source drivers and there is no apparent reason for that to get worse if Linux becomes more popular.
Better do the math, which means 15 years to reach where macOS is nowadays, which is still largely irrelevant outside tier 1 economies, while assuming nothing else will change in the computing landscape.
I was around when everyone was supposed to switch in droves to Linux back in the Windows XP days, or was it Vista, maybe Windows 7, or Windows 8, eventually 8.1, I guess Windows 10 was the one, or Windows 10 S, nah really Windows RT, actually it was Windows 11,or maybe....
I understand, I used to have M$ on my email signature back in the 1990's, surely to be found in some USENET or mailing list archive, yet we need to face the reality without Windows, Valve would not have a business.
I mean, part of that is the difference between how easy it is to build a platform in Linux vs how hard it is to get into the tree. This is actually, in my mind, a major change in the Linux development process.
Nobody expected Intel to provide employees to write support for 80386 pagetables, or Philips to write and maintain support for the I2C bus. The PC keyboard driver was not sponsored and supported by IBM. Getting the code into Linux was really easy (and it shows in a lot of the older code; Linux kernel quality standards have been rising over time), because everyone was mostly cooperating on a cool open-source project.
But at some point, this became apparently unsustainable, and the expectation is now that AMD will maintain their GPU drivers, and Qualcomm (or some other company with substantial resources) will contribute code and employees to deal with Adreno GPUs. This led to a shift in reviewer attitudes: constant back-and-forth about code or design quality is typical on the mailing lists now.
This means contributing code to the kernel is a massive chore, which any person with interest in actually making things work should prefer to avoid. What's left is language lawyers, evangelists and people who get paid to sit straight and treat it as a 9-5 job.
The Asahi and pmOS folks have been quite successful in upstreaming drivers to the kernel (even for non-trivial devices like GPU's) as enthusiast contributors with no real company backing. The whole effort on including Rust in the Linux kernel is largely about making it even easier to write future drivers.
Agreed, and I'm fairly impressed by the GPU effort. That said, it did take a very long time, even with the demonstrably extreme amount of excitement from the Linux community (Linus himself was thrilled to use a Macbook). What do you do for parts that are useful but don't get people this excited?
What really burned me on this kind of stuff was the disappearance of Xeon Phi drivers from the kernel. Intel backed it out after they discontinued the product line, and the kernel people gladly went with it ("who'll maintain this?"). Intel pulled a beautiful piece of process lawyership on it: apparently they could back it out without difficulty, because the product was never released! (Never mind it has been sold, retired and circulated in public.)
This is just part of the bureaucratisation of everything. The bureaucracy always try to extend its power and find ways to self-justify its existence, accaparing ressources to extend the control and bring ever more people into the fold. It's an intrinsically parasitic process that ends up killing the host in the long term.
Which is why most communist like endeavor ends up in failure. Without the necessary pruning that comes with competition, you end up in a situation where it's more profitable to get the power to control the resources and take a fee for each interactions than actually do anything worthwhile to get "rights" to resource allocation.