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.
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.
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.
If they don't provide hardware documentation for Windows either (a desktop platform), how can it be a prerequisite for equal effort?
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.
4 replies →
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.
6 replies →