I think the main reason many people (including me), very often, lack the motivation to read content that is likely generated by AI is the suspicion that it comes from a place of intellectual laziness. Another reason, based on personal experience, is that AI content may suffer from too much verbosity, too much jargon and over-confidence, which makes the reading experience feel fake and border-line irritating. In many cases the content may have very little to no nuance, which is ultimately a waste of time.
As an anecdote, someone posted a blogpost on Linkedin on using agents to implement a driver to access PCIe devices over TCP/IP. I was intrigued because that's not an easy task for several reasons, like handling PCIe interrupts and DMA. For exmaple, how does the remote machine map the device's PCIe BARs? And when it issues I/O to the devices registers, how are these reads and writes transferred to the remote device. In the end, this is just some virtual memory. In a local machine, this is either directly mapped to the PCIe physical addresses or some IOMMU virtual address space which is then translated by the hardware upon CPU/device/VM access.
After reading the long verbose promising article, in the end, the guy (with the help of the agent) only managed to implement access to the PCIe config space so that lspci on the remote machine works and shows the remote PCIe device, but that's all. It never addressed the issues above nor even mentioned them. The code was AI generated. The article was AI-written. The article never made a reference to DMA, interrupts, MSIX-X, IOMMU, IOTLB, virtual memory, etc, but it made big claims on next-gen datacenter disaggregated architecture, boosting GPU utilization, reducing large scale inference costs, etc.
Anyway, you get my point: big long beautiful words, but zero nuance.
My question is always, "Am I willing to maintain this code?"
Sometimes that's a yes, even if AI generated it and I can tell despite someone making half an effort to be a human for a minute during the PR process. But sometimes it's not.
It gets really dicey when you've kept an architecture a certain shape because there's a difficult feature you intend to slot into the negative space. There are two or three ways to implement that feature, and the one they chose just stomps all through your potential. But that's why we have code reviews. You don't have to read my mind if I just tell you. But it can be frustrating if someone asks you to do it a different way, and then has comments on how you accomplished that, and then comments on the fixes for your other comments.
It is extremely annoying when you have a certain problem that surely should have someone making a solution for it and then you find a blog post. And in the end blog post doesn't actually solve the issue as it does has final step. But actually never implemented the most important middle bits. Thankfully I found someone who had actually solved that middle bit in workable hack. But still those blogs are really annoying pollution.
I struggle to read long code docs even if they're 100% human-written and maintained, mainly because the longer the text, the greater opportunities for miscommunication, staleness, repetition etc.
My point being, docs were already an unsolved problem in code. Of course LLMs dumping reams of docs is not good, but are we really sure it's worse than before? Undocumented code is bad, and mis-documented code is the worst.
I think the main reason many people (including me), very often, lack the motivation to read content that is likely generated by AI is the suspicion that it comes from a place of intellectual laziness. Another reason, based on personal experience, is that AI content may suffer from too much verbosity, too much jargon and over-confidence, which makes the reading experience feel fake and border-line irritating. In many cases the content may have very little to no nuance, which is ultimately a waste of time.
As an anecdote, someone posted a blogpost on Linkedin on using agents to implement a driver to access PCIe devices over TCP/IP. I was intrigued because that's not an easy task for several reasons, like handling PCIe interrupts and DMA. For exmaple, how does the remote machine map the device's PCIe BARs? And when it issues I/O to the devices registers, how are these reads and writes transferred to the remote device. In the end, this is just some virtual memory. In a local machine, this is either directly mapped to the PCIe physical addresses or some IOMMU virtual address space which is then translated by the hardware upon CPU/device/VM access.
After reading the long verbose promising article, in the end, the guy (with the help of the agent) only managed to implement access to the PCIe config space so that lspci on the remote machine works and shows the remote PCIe device, but that's all. It never addressed the issues above nor even mentioned them. The code was AI generated. The article was AI-written. The article never made a reference to DMA, interrupts, MSIX-X, IOMMU, IOTLB, virtual memory, etc, but it made big claims on next-gen datacenter disaggregated architecture, boosting GPU utilization, reducing large scale inference costs, etc.
Anyway, you get my point: big long beautiful words, but zero nuance.
Yes, ARM sued Qualcomm, Qualcomm won, and separately Nuvia has shipped, 2, 3? times now? I don't know how it's a failure or if the delay were "huge" and "dragged out". It's not like it launched an old product or took years and years and years. 39 months between acquisition and Snapdragon X Elite being available for purchase.
> You’re equivalent of saying the Intel delays were a success too.
If Trump nuked TSMC's production lines the day before M1 went to production, and the production lines came back 3 years later, would Apple ship the M1 on it? Or, the M3?
As you point out, it makes 0 sense to ship the M1.
If it makes 0 sense, why project that idea onto me?
When faced with a contradiction, first, check your premises. (and read your interlocutor's, "It's not like it launched an old product" obviates your claim that I'd also applaud Intel's delays)
You switched your claim from "they released the same chip they would have released 3 years earlier and you're stupid for thinking that was a good idea" to "I thought it was slow [because I'm hyperfocused on Apple competition and forgot the perf vs. Intel/AMD]".
Nothing got switched. Go check the facts. The chip was made. It was delayed due to the lawsuits and drama. The first release was an old chip. Hence slow. All the same. You can slice it how you like.
AMD barely has laptop designs (the point here) and Intel is long dead in this space.
I created my first Linux from scratch when I was a freshman in college in a third world country (not India). Fast forward few years later, I now write Linux kernel code for a living. Not sure what you did wrong, bud, to end up miserable like this.
I worked at Linaro, who was contracting for Qualcomm. Qualcomm were pushing for some protected hypervisor called Gunyah (which had its own Linux interface and needed a new qemu port) that apparently no one liked. I tried to port it to KVM [1], but upstream folks (mostly Google) outright rejected the port. Otherwise KVM would have been available on QCOM boards. You can still try it. I have a Linux kernel and a Qemu port on my github [2,3]
Upstream would accept a patchset that exposed an independent Gunyah-specific UAPI (why not the same one as downstream — crosvm already supports that) instead of pretending to be KVM (it's not a "port", you can't port a hypervisor to a hypervisor).
KVM is available on current compute platforms (laptops) if you escape to EL2 via slbounce; and on Glymur (X2E) it will be available by default (yay!).
That's not how operating systems work. KVM is both an interface and a hypervisor. Just as we have different hypervisor implementations for amd, intel, arm and others all abstracted behind the same KVM interface, there is no reason the same can't be done for Gunyah. Userspace does not have to know anything about that. KVM already supports svm and vmx for amd and intel on x86. Why is something similar can't be done for Arm? Plus now there is pKVM.
I just don't understand this argument of a separate interface. The only reason you want to do that is to decouple from the KVM community, but that introduces a shit tone of duplicated effort and needless fragmentation to the virtualisation software ecosystem hindering your users from enjoying the existing upstream tools they already know about. In other terms, vendor locking and shitty downstream experience.
