For massive scale SaaS and non-native-code PaaS hosts, cost and perceived Intel lock-in risk will be the factor that drives them to deploy and evaluate these servers side by side with their Intel hosts. And, yes, those devs will have access to this hardware in their offices.
Linus Torvalds on Why ARM Won't Win the Server Space
451–460 of 545 posts
Re: Linus Torvalds on Why ARM Won't Win the Server Space
#452Earlier quoted context omitted.
When that happens we’ll also see a big push to add ARM support to all the native nodejs modules that are out there. (And I assume Ruby, Python, Go, etc packages). Linus’s prediction is based on the premise that everyone will continue to use x86 for development. But that’s probably not going to be the case for long. Multiple sources have leaked the rumour that Apple will release an arm MacBook next year. And I wouldn’…
Developers don't develop on Surface books, and Macbooks are in low percentages. The majority of people in the world writing code are using x86 PCs and Microsoft and Apple aren't about to change that with any *Book. Linus' premise that everyone will continue to use x86 for development is because they will. There's no incentive for companies or individuals to go switch out all of that x86 hardware sitting on desks and…
> Macbooks are in low percentages
For some reason Macbooks seem disproportionately represented amongst web developers. All the agencies I know in Sydney and Melbourne are full of macbooks.
> There's no incentive for companies or individuals to go switch out all of that x86 hardware sitting on desks and in racks with ARM alternatives which will offer them lower performance than their already slightly aged hardware at initially higher costs.
Uh, why are you assuming ARM laptops will have lower performance and a higher cost compared to x86 equivalents? The ARM CPU in the iPad pro already outperforms the high end intel chips in macbook pros in some tests. And how long do you think Apple will continue to sell intel-based macbooks once they have ARM laptops on the market? Maybe they'll keep selling intel laptops for a year or two, but I doubt they'll keep refreshing them when new intel processors come out. When Apple moved from powerpc to intel they didn't keep releasing new powerpc based laptops.
Once web development shops start buying laptops with ARM chips, it will be a huge hassle if random nodejs modules don't build & work on ARM. At this point I expect most compatibility issues will be fixed, and that will in turn make deploying nodejs apps on arm a more reasonable choice.
Obviously we'll see, and this is all speculation for all of us. But I think its a reasonable path for ARM chips to invade the desktop.
Re: Linus Torvalds on Why ARM Won't Win the Server Space
#453I feel this is why Ubuntu is one of the most popular server distros. Ubuntu is pretty unsuited for servers IMO. It's just complex and error-prone, IMO. The packages aren't always server-quality. But it's great for the desktop IMO, because Canonical actually tests against real hardware for you. So the fact that people use Ubuntu for desktop/laptop development makes it popular in the cloud, which I've always felt was u…
Can you expand it on this? I agree that I use Ubuntu on server because I use it on the desktop, that makes sense. However, when I installed Ubuntu Server 18.04 recently it was delightful . There was this simple feature they added which automatically pulled down my ssh key from my GitHub account. During the install it asked me to enable the semi-recent kernel livepatching (and old fashioned unattended-upgrades) it eve…
I guess I'm making an argument around predictability and stability. To be honest I haven't used Ubuntu as a server in several years. Maybe they have improved things.
But I think they can mostly improve things "on top", but not the foundations. Patching over problems by adding layers on top generally isn't great for stability, and is bad for debuggability.
I'm comparing Ubuntu to BSDs, where there's actually a manual, and files are put in consistent places. (as far as I understand, I have less experience with them.)
It's also most of the same reasons that Docker switched its default image from Ubuntu to Alpine some years ago. Alpine is just smaller and makes more sense. Ubuntu does a lot but it's also sprawling and inconsistent.
Off the top of my head:
- Starting services is a weird mix of init scripts and Upstart. And now they're switching to systemd. When they switch they don't update all the packages. There are some weird compatibility shims.
- When you apt-get install apache2, it actually starts the daemon. (This is a problem with both Debian and Ubuntu.) This is bad from a security perspective. A lot of people don't know what's running on their systems in practice and what ports are open, and then they have to set up an extra firewall, which is more complexity.
- the file system is generally a mess, e.g. /etc. There seem to be multiple locations for everything, e.g. bash completion scripts. I think this is a function of the packages being old and patched over.
In general the documentation feels scattered and incomplete. The common practice seems to be googling stuff and pasting things in random files until it works. And then automating that with a Docker container.
That's now traditionally how servers were administered pre-Google :) System administration knowledge / quality seems to have taken a nosedive with the rise of the cloud and cheap hosting. I'm not saying that it's all bad, but it's a downside.
The great thing about Debian and Ubuntu is that there is so much software packaged for it. I think that's generally the reason that people use it. There is a network effect in the package ecosystem.
Re: Linus Torvalds on Why ARM Won't Win the Server Space
#454Earlier quoted context omitted.
On a related note, if Apple does switch to ARM chips for their laptops, that will make mainstream ARM server-side development more viable than any cross-platform story ever can. Or kill the Mac desktop. One or the other :)
It will most likely kill apple laptops as a developer platform. Unless you are deeply disconnected from the hardware, CPU architecture does matter. Most developers using macbooks I know have VMs for either Windows or Linux works. It might be conceivable to use the ARM port of , or the ARM version of Windows 10. But it would also require a good desktop virtualization solution for ARM. If Apple release its own solution…
Maybe WOA will be a thing then too....
Re: Linus Torvalds on Why ARM Won't Win the Server Space
#455It's extremely hard to agree with Linus on that. One problem in his argument is that he believes that everybody has a kernel hacker mindset: most today's developers don't care about environment reproducibility at architecture level. The second problem is that he believes that every kind of development is as platform sensitive as kernel hacking, and he even makes the example of Perl scripts. The reality is that one ye…
> most today's developers don't care about environment reproducibility at architecture level.
Source for this? Seems like pure speculation.
Re: Linus Torvalds on Why ARM Won't Win the Server Space
#456It's extremely hard to agree with Linus on that. One problem in his argument is that he believes that everybody has a kernel hacker mindset: most today's developers don't care about environment reproducibility at architecture level. The second problem is that he believes that every kind of development is as platform sensitive as kernel hacking, and he even makes the example of Perl scripts. The reality is that one ye…
Node and Ruby applications do fail on ARM though, when it comes to native libraries and extensions. And now your whole distro is different than your development machine, which adds complexity. Do I really want to be debugging why node-gyp fails to compile scrypt on the ARM distro on the new Amazon A1 ARM instance (which it did in my case)? And if I solve that, what about the other 2451 dependencies? Let's pessimistic…
> what about the other 2451 dependencies
Not sure if this is sarcasm or not, but if your project have that many dependencies not wonder it is hard to port anywhere.
Re: Linus Torvalds on Why ARM Won't Win the Server Space
#457War story time. File based encryption[1] (which used ext4 encryption) was supposed to have been released with Android M. It slipped by a full year because of this issue which Linus identified. At the time, we didn't have xfstests ported over so it could run in an Android/Bionic environment. So the only way I could test it was by taking the SOC kernel to which we had backported ext4 encryption, bashing it hard enough so it would compile on x86 again, all the while cursing the SOC vendor who had added "value added features" to their SOC kernel in a completely broken way such that the kernel would no longer build on x86, let alone boot on it, and then test the ext4 encryption feature backported to the Android kernel on x86 using kvm-xfstests (this was before gce-xfstests[2]). Unfortunately there was an ARM specific bug that we couldn't catch while testing on x86, and it showed up only when we were dogfooding the feature on two testers' phones. We couldn't reliable repro it on our development phones before the ZBB deadline. So we ultimately ended up having the pull the feature and wait a full calendar year for Android N because we could launch it.
As a result, a colleague developed android-xfstests[3] so we could actually do the necessary testing on an ARM platform. If we had this at the time when we were first trying to launch File Based Encryption for Android, it would have avoided a huge amount of hair pulling.
[1] https://source.android.com/security/encryption/file-based [2] https://thunk.org/gce-xfstests [3] https://thunk.org/android-xfstests
Re: Linus Torvalds on Why ARM Won't Win the Server Space
#458I build Go, Rust, C/C++ code for ARM/ARM64 (and MIPS) and it's completely transparent. 99.9% of the code just works, occasionally I need to worry about some details, but just once in a while. Go definitely is the easiest, it's built in: GOOS=linux GOARCH=arm go build Rust is almost as easy to cross build (as long as you have the right GCC toolchains installed!): cargo build --target aarch64-unknown-linux-musl Sooner…
That's all fine and dandy for the software you build, but then if it happens that the easiest way to get some job done is to extend an existing docker image or using an existing docker image in a multistage build, you might trip over the fact that the authors of those other images didn't care enough about your arch of choice to cross compile their stuff.
I've build & run docker on arm and used it to build my own arm based docker containers from scratch, but yeah, 99.9% of containers intel only.
Having said that, docker is perfectly usable on arm, just no one bothers to.
Re: Linus Torvalds on Why ARM Won't Win the Server Space
#459It'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 shuffling smartphones in under embedded I believe.
His thesis is that if you want a platform to take off, start shipping developer boxes of the platform. So mobile and pc will merge when and only when you can do all your development on a mobile platform.
Re: Linus Torvalds on Why ARM Won't Win the Server Space
#460Earlier quoted context omitted.
I couldn't name a major corporation that uses NetBSD on their servers or routers. (Yahoo used to use FreeBSD servers, but even they migrated to Linux.) Is there a major router vendor or something else that uses NetBSD in a big way?
Well at least Netflix does. https://fosdem.org/2019/schedule/event/netflix_freebsd/
That says FreeBSD