281–290 of 545 posts
Didn't Linus recently go to sensitivity training or something? I think he missed out on the bigger picture.
It seems like his argument is more about shaming anyone who disagrees with him, instead of expressing an opinion.
It's of course impossible not to respect Linus' opinion and first hand experience in this space, but doesn't this whole post completely ignore the 100 ton blue whale in the room? Namely smartphones . That's an entire enormous segment of the industry and it's nearly 100% (or entirely 100%?) literally develop-on-x86-deploy-on-ARM. Smartphones also fit > "This isn't rocket science. This isn't some made up story. This is…
He's also apparently assuming that ARM-based Chromebooks will never be a useful developer environment. I wouldn't take that bet -- a lot of the newer ones will support Linux VMs out of the box well enough to support at least a half-decent development environment (via Crostini). (You can get a Pixelbook with 8GB RAM and a 512GB SSD, if you're wondering about storage space. And while Crostini still has issues with in-V…
I don't think it's as black and white as wanting the same CPU and OS on your deployment platform and development platform. When it comes to mobile development, having those two be completely different is the norm. It's not much of a problem in practice. The differences between different platforms with the same cpu architecture and OS from different vendors is a much bigger headache than the difference between each of those and the windows or mac + intel laptops the software is being developed on. The difference between windows and macs still causes some headaches of course but is mostly managable. If it works on Linux it generally also works on mac. And if it doesn't that's a good sign of immaturity. All I'm saying here is that most mainstream technologies work across all three of those without much headaches.
Earlier quoted context omitted.
The NetBSD people vehemently disagree. By ensuring your software works on various architectures, you expose subtle bugs in the ones you actually care about. Lots of 32-bit x86 code was improved during the migration to 64-bit, not because the move created new bugs, as because existing ones (i.e. code that relied on undefined behavior) couldn't get away with it anymore.
I wouldn't call their bugs. If the binaries worked correctly on x86 due to compiler specific guarantees then the code wasn't buggy. It just wasn't written for a generic C or C++ compiler.
Modern DevOps and CICD should be able to abstract this away. Devs can develop on whatever they want and then push to ARM or x86 servers.
That's assuming you're not using any libraries that contain hand-optimized SIMD where one platform is better supported than the other.
All devs had SPARC machines and no intention to move to x86 on the desktop, until after Intel steamrollered the performance contest.
It's of course impossible not to respect Linus' opinion and first hand experience in this space, but doesn't this whole post completely ignore the 100 ton blue whale in the room? Namely smartphones . That's an entire enormous segment of the industry and it's nearly 100% (or entirely 100%?) literally develop-on-x86-deploy-on-ARM. Smartphones also fit > "This isn't rocket science. This isn't some made up story. This is…
And speaking of x64...
> It's why x86 won. Do you really think the world has changed radically?
No, x86 is loosing to x64. And at some point another instruction set will supplant x64.
Honest question: why is it not viable to run an ARM virtual machine for your development purposes - is it not accurate enough?
Someone please tell him what LLVM bytecode is, probably he doesn't know because he uses GCC, Apple showed recently how that can leveredged in scale, with Apple Watch's architecture change overnight.
ARM and RISCV are here.