Raspberry Pi, BeagleBone and various arm based embedded systems played a much higher role in getting most linux, BSD tools working under arm.
Same thing that’s happening now with RISC-V and SiFive’s boards.
It’s not apple M1 that’s making this migration possible, its just the cherry on top of a cake.
The cake was all those consumer arm boards and dev kits which got in the hands of various OS developers, software maintainers. Who put in their time to port their codebases to arm and ensure compatibility.
It was pioneering in how low-cost and mass market it was at launch, but before the Pi there was plug computing, largely based around Marvell Kirkwood processors. There were also a variety of hackable NAS devices, I used some with Orion5x CPUS in. Then before plug computing there was the linksys NSLU2 with its Intel Xscale IXP chip, and all the hackable linksys routers going back to 2002, and that's just some of the stuff I've played with over the years. Before that I imagine there were previous generations of linux ARM support.
The Pi and other hobby boards are really great, don't get me wrong, but there's a tendency to credit them with a bit too much.
For their time (20 years ago), they certainly were cheap. $100 or so for a small power efficient box that could run almost a whole Linux distribution was an amazing bargain. Before that, you needed a good-sized desktop or server to do anything involving a Unix-like OS, or paid dearly for the convenience of a laptop.
And it wasn't much before that, that running Unix on any microcomputer was just a dream.
It's hard to comprend just how amazingly affordable computing has become in such a short amount of time.
I remember that time in my life very well. I literally had around $50 in my local currency in the coin box, and that was it. Hand me down computers were unavailable where I was.
Yes, it reached a wide audience, they did a lot of great stuff getting capable dev boards out to a lot of people. But fully functional Linux on ARM pre-dates the Pi significantly.
(I’d argue the NSLU2 and sheevaplug were both pretty affordable, at sub-$100 too, but the Pi definitely upped the game there)
It is my contention that this support was largely already present. That's all.
Pi did great work getting cheap boards out to people, and put a lot of effort into education and community building. They exposed a huge number of people to the possibilities of non-x86 computing that otherwise might not have been. So indeed let's credit them with that, it's all great stuff!
But it's quite revisionist to say they helped get linux or BSD or their tools onto the platform, IMHO.
If Pi3 was so popular, why didn't it exist as a binary?
Beyond that, I can only hypothesize that Docker on non-x86_64 (or multiarch Docker, in general), was very difficult to kick-start for whatever reason. This may have been compounded by the fact that Docker wasn't as broadly adopted by hobbyists back then, so demand for ARM builds want that great.
Getting more attention to the platform was definitely a good thing, exposing more people to a different architecture, to having a machine cheap enough to just play with, to all sorts of great stuff.
But Linux and BSD themselves were already mature on arm by that point.
Whoa, haven't heard that one in a looong time. Still have mine sitting in a storage closet, I think...
I used to run my own mail server on one and use another as a media server. I even did a small hardware mod and soldered a wifi card to one of the internal USB headers on one of them. Much fun!
I don't imagine the processing power stands up to modern devices though :)
Pi entered a mature ecosystem, it just made it a bit more consumer/newbie facing but the system level foundations were all there.
Ironically the Pi isn’t even particularly well supported in terms of drivers compared to commercial offerings.
While strongarm and others have been around longer, none had any real mass market hold. With Pi & co, you can build a (slow) server with $35. You can build a k8 cluster with $150. That's why we have cross platform packages for almost anything server related.
Fast forward to today, you can apt-get cross-compilers and build tools.
M1 probably enables the same transition for customer-oriented, proprietary apps. But it has little to do with cloud computing, except proving that performance and ARM are not mutually exclusive, thus providing more acceptance.
Well, to be honest it was probably macos+M1 platform support. Docker runs a virtual machine with Linux in it on macos and windows, not sure improvements there directly translate to server workloads. I am not sure about node, but it was surely working very well on ARM before that, although it might gain some optimizations thanks to M1.
If there are CLI ways to do this stuff I'd love to hear them.
I know sshd is controlled through systemsetup[1].
sudo systemsetup -setremotelogin on
None of the paid software with a tiny userbase you're thinking of is relevant to the server market, the point is that it's free and open.
I don't disagree, but going mainstream is different.
>It’s not apple M1 that’s making this migration possible, its just the cherry on top of a cake.
M1 would not exist without the Apple's App store all based on ARM.
Apples are upset their $2000+ laptop isn't the revolutionary catalyst for the Arm revolution but instead a crappy $25 computer that's been around for a decade.
Of course Pi has started a big movement and prepared the groundwork, but M1, which I also use, is something else in terms of performance, and it caused this build-up to become an avalanche. Cloud systems will inevitably ride this wave, and will seriously eat into Intel's market share.
Just provisioned a small docker-lab in an ORACLE Cloud Ampere system. This thing is seriously snappy at the first glance.
So the only thing that is new is that ARM architecture is finally starting to "spill over" into the notebook/desktop and server market and preparing to eat Intel's (and AMD's) cake. But the wide-scale adoption of the architecture already has a long history, so presenting Raspi and Apple M1 as "pioneers of ARM introduction" is a bit misleading (Apple was a pioneer, but already back in 2007).
Before that there were already ARM servers too, but they're few and far between.
So I was trying to say that, Raspberry Pi and Apple M1 made ARM "touchable" with standard development tools and utilities for the normal people out there. So, this interaction accelerated the acceptance and software porting and grown the ecosystem faster.
Everyone already had an iPhone or Android, how was it not touch distance for the layman?
OTOH, you can get a pi, add peripherals (or just network), and you have a system to be hacked and tinkered on.
This is what I meant by touch distance.
Jailbreaking was so easy someone like Justin Beiber did it. https://www.idownloadblog.com/2011/07/29/justin-bieber-jailb...
Saurik and the original jailbreakers did all the heavy lifting, APT, SSH, and the usual CLI tools were ported so they could enjoy their handheld Unix computers.
Pi was an image on a microSD, some computer interfaces, it was very slow, burned out the microSD card, and was discouraging for me to use when I had a much better computer, the phones were easy to invest effort in, if I had a way crappy computer I wouldn't do too much with it, most people throw PiHole and never touch it again.
Been there, done that. Doesn't matter. Tinkering with a critical life infrastructure device vs, tinkering with a device made for tinkering is different. Way different.
> Jailbreaking was so easy someone like Justin Beiber did it
Again, doesn't matter because of the reasons I've said earlier. I'm using both platforms for a decade, and won't do them to my primary devices either. Because these devices are handling a lot of stuff for me, tinkering with them is not an option.
> Pi was an image on a microSD, some computer interfaces, it was very slow, burned out the microSD card, and was discouraging for me to use when I had a much better computer, the phones were easy to invest effort in, if I had a way crappy computer I wouldn't do too much with it, most people throw PiHole and never touch it again.
Actually, with a semi-decent SD card, burning one out with a Raspberry Pi is almost impossible. If you're worried about that, you can add a ZRAM, move swap and some folders to it (as Raspbian does), and sync during reboots, or periodically. If you're downloading world on it, a USB drive can alleviate the worry too.
On the slowness side, a first generation Raspberry Pi has a comparable performance to a Pentium II - 266MHz system, with similar performance to GPUs of that era. Considering the things I've done (live webcasting for example) with a P2 at that time, A Raspberry Pi is a powerhouse for its size.
You may have a much better computer with way higher specs, but you're missing the point. A Pi is a literally unbrickable and forgettable Linux PC with decent performance and no noise for many tasks many people do. I'm running an home infrastructure on an OrangePi Zero and the bottleneck is the 512MB RAM, not the CPU. With a decent SD card, it's not slow either.
I can replace all of it with a Raspberry Pi 1 or 2, but the OrangePi is much smaller.
Just because it can't race with a specially built workstation, doesn't mean it's useless.
If you use them for a lot of things, wouldn't you want to tinker them to make them run better? I certainly do on linux.
>You may have a much better computer with way higher specs, but you're missing the point. A Pi is a literally unbrickable and forgettable Linux PC with decent performance and no noise for many tasks many people do. I'm running an home infrastructure on an OrangePi Zero and the bottleneck is the 512MB RAM, not the CPU. With a decent SD card, it's not slow either.
I don't fear my PC being brickable, and its not noisy either, you can use water cooling for desktop or use a modern laptop, many are fanless (can't say the same about the Pi4). I have for example a router I used custom firmware on that can do everything a pihole can do, and more, just works quietly, it can do also act as a smart hub but I don't see the point.
>I can replace all of it with a Raspberry Pi 1 or 2, but the OrangePi is much smaller.
I find the problem with SBCs is they are too slow to be worthwhile, Android phones are much faster, have all inputs, and just works. Its not hard to buy an extra or use an old one if you fear tinkering.
>Been there, done that. Doesn't matter. Tinkering with a critical life infrastructure device vs, tinkering with a device made for tinkering is different. Way different.
What is "made for tinkering"? A Unix phone that can run all the software I want, a linux phone with root access, or my PSP which was made to play PSP and PS1 games with excellent homebrew counts as not made for tinkering seems alien. What can't they do? Throw a breakout board if you need the pins, I don't get the issue with using them. A one click root or unlock is way less complex than buying required parts to make an SBC work.
>On the slowness side, a first generation Raspberry Pi has a comparable performance to a Pentium II - 266MHz system, with similar performance to GPUs of that era. Considering the things I've done (live webcasting for example) with a P2 at that time, A Raspberry Pi is a powerhouse for its size.
>Just because it can't race with a specially built workstation, doesn't mean it's useless.
No its just not very useful for me, its hard to want to eat ground pork when there is steak to be had, I don't see the point of it really when my computer does everything better, why would someone want to use it to webcast for instance or use the PII era GPU? Sure you can emulate games one it, but I can on my computer already.
>I'm running an home infrastructure on an OrangePi Zero and the bottleneck is the 512MB RAM, not the CPU. With a decent SD card, it's not slow either.
You aren't disagreeing with me, you use it for a purpose (like a PiHole), not as a computer. I can use slower boards for purposes like yours too, what do you use it for? I don't really understand the benefit of a smart home hub, what are you running on it for what automation/smart?
For example, consider that golang has been able to cross-compile to ARM since almost the very start. That alone has probably contributed more to actual ARM server deployment than M1 (which is by the way not available for cloud or any server systems).
Apple most definitely does _not_ support that thing. In fact, they have in past tried to shut down similar initiatives.
Even before Pi my router had DDWRT, I don't think Pi did very much.
The biggest thing not being talked about that hurts Intel is AWS’ pool of Intel CPUs that currently run S3, SQS, Dynamo, etc (m3s, c4s, etc) all being released to the public and offered at such a discount (especially on the spot market) that new onprem purchases (i.e. new Intel chips) are not cost effective.
Disclaimer: I used to work at Amazon but never in AWS. This is all based on public speculation.
1) if their managed services (RDS, DynamoDB, etc) can run on ARM and it provides a better price/performance ratio, they'll use that internally, thus needing less x86 hardware
2) if most customers can run on ARM (interpreted languages run out of the box, compiled ones need more effort but is still doable) and it's better priced than x86 there is less demand on x86 again.
I think Go needs a flag specified at compile time to work on ARM. Instead of `go build`, run `env GOOS=linux GOARCH=arm64 go build`.
Rust is similar, except it requires the appropriate toolchain to be installed first (1-liner).
It’s probably less effort what I’ve described because there are GitHub Actions that will generate appropriate binaries out of the box.
(This holds true for JS/python/… too.)
Just tell Go to use the appropriate cross compilation chain for the C bits, e.g. `apt install gcc-aarch64-linux-gnu` and set the `CC=aarch64-linux-gnu-gcc` environment variable to compile for arm64. Compilation becomes a bit slower, but it's still manageable.
It's that easy thanks to the foundations laid by the distribution that ships a solid cross-compiler setup (in this example, thank you Debian!) and of course the brilliance of the Go design and toolchain.
I do think x86 will be phased out as you suggest. I feel either Intels foundry division and/or chip designs for ARM and/or RISC-V will very likely get incorporated into Graviton-X (and similar) if only as a bargaining tactic between Intel vs TSMC and Intel vs Qualcomm vs ARM.
> Plus, I'd guess that AWS is probably making sweet margins off those Graviton instances.
> It also gives AWS negotiating power with Intel.
It's not just about pricing. Another convincing argument for the move towards ARM [1] is that the big cloud providers like AWS have much more insight into cloud workloads than Intel could ever have, with vast amounts of metrics, so custom-designing chips would be a somewhat natural path by itself.
[1] I heard this first in a presentation by Brendan Gregg, but I can't find the slides at the moment.
Our entire deployment stack is Java/Python on Linux.
I'm looking at our deployments and thinking, we sure would save a lot of money, and likely deliver a superior product if we switched to ARM on both AWS and OCI. Better product due to beefing up the Postgres clusters with part of the savings.
My hope is that by the end of Q2, our default deployment is on ARM on OCI. We're looking at nearly a 50% cost reduction versus the current m5 RDS and other EC2 instances.
If switching to ARM means general parity on per core performance, I can easily sell rolling a portion of that savings into a bigger baseline config for all customers. Especially on Oracle, where their charges for RAM on A1 are peanuts.
I thought the industry's consensus was a key component of Intel's dominance is they leveraged the best fab tech in the world, made possible by huge volume. That's a virtuous cycle on the way up and terrible as volume decreases...
I’d guess like everything they do, they’re taking a bath on margin in the short term to solidify a monopoly in the long term. Amazon made basically $0 for over a decade. Investors were fine with that because everyone knew they were building a monopoly to later be exploited.
The applications themselves are in TypeScript, and Node as a runtime is cross arch without any extras. The hardest part is building docker images from my Github action.
I wouldn't be surprised to find out that AWS is secretly switching the hardware running of their serverless overrings to use their in-house chips. Things like lambda (assuming source is distributed), aurora serverless, Dynamo, Cognito, CloudFront, etc
Let's rather say that Apple helps developers realize that the vast majority of open source dev tools they need have been working seamlessly on arm platforms for decades thanks to the work of linux and bsd distros.
The danger is that the transition to another architecture is used as an excuse to not do this, even for devices that have historically been open.
> coup-de-gras
Is funny. Gras (pronounced gra) means fat(as in animal fat, not a fat panda), and the real saying is coup de grâce (pronounced gras and means grace). For some weird reason English speakers pronounce coup de grâce improperly, skipping the s sound at the end ( funnily it's usually the French language which cuts sounds), including in movies (like Kill Bill).
That's why I consider alternative ecosystems (that don't have exorbitant prices) like RISC-V and Raspberry Pi to be critical to the survival of general-purpose computing. Once your ability to run on bare metal disappears (via Secure Boot or otherwise), you're in grave danger of simply not having physical hardware to convert new users.
[1] https://www.congress.gov/bill/117th-congress/senate-bill/299...
Wasn't the Apple I the modern general purpose computer?
Virtually all of which are user-unlockable. But keep telling me how unopen they are?
(BTW, those of us who actually want secure systems very much appreciate the fact that malware can't overwrite my boot sector without a hardware-level vulnerability.)
> How easy is to replace the operating system on an ARM mobile device
Very easy if you have an Android phone :)
But the restriction is that many OEMs and/or carriers forbids bootloader unlock.
1. Have bootloader unlock available via official channels. If you are in the 1% with a supported phone variant, congratulations. Service box unlocks, while often possible unofficially, rarely result in a critical mass of developers that's needed for the next step.
2. Have a ROM ready to go. If lucky, it'll be Lineage OS. If less lucky, some unofficial build of Lineage OS with potentially some hardware not supported (but there's hope!). If you are really unlucky, the phone is so unpopular that a ROM developer hasn't taken enough interest in it to produce a usable ROM.
3. Flash the ROM, keeping all idiosyncrasies of the particular hardware in mind. Hope you got the right partition table/kernel/bootloader/ fragile fragment, because if you flash the one meant for GEX5546ab on a hardware that corresponds to GEX5546cb, you just killed your phone. Run through contingency procedures for unbricking the phone in case you need them.
4. Congratulations. You now have a firmware that works better than the factory OS, but they also happens to potentially not support small things like Bluetooth or the camera blobs. You may get support in 2-3 months, hopefully. Your secure enclave keys are also gone, so bank apps will be suspicious and Netflix will refuse to serve higher-quality content.
Untrue for most of the phones on XDA, S3 was the most popular android phone and came locked.
>2. Have a ROM ready to go. If lucky, it'll be Lineage OS. If less lucky, some unofficial build of Lineage OS with potentially some hardware not supported (but there's hope!). If you are really unlucky, the phone is so unpopular that a ROM developer hasn't taken enough interest in it to produce a usable ROM.
Luck to me is more than LOS, its the bare minimum, but I have gotten unlucky with non popular phones. Not hard to look at roms when you see if you should root or install custom bootloader.
>3. Flash the ROM, keeping all idiosyncrasies of the particular hardware in mind. Hope you got the right partition table/kernel/bootloader/ fragile fragment, because if you flash the one meant for GEX5546ab on a hardware that corresponds to GEX5546cb, you just killed your phone. Run through contingency procedures for unbricking the phone in case you need them.
You could just run Halium to run Linux with all drivers, or use chroot to have linux in it too. Safety that existed since 2012 prevented me from ever having a single issue like that, and I never bricked a phone with over 20 flashes.
>4. Congratulations. You now have a firmware that works better than the factory OS, but they also happens to potentially not support small things like Bluetooth or the camera blobs. You may get support in 2-3 months, hopefully. Your secure enclave keys are also gone, so bank apps will be suspicious and Netflix will refuse to serve higher-quality content.
This was occasionally true before 2017. All new phones have mainline linux support. https://www.computerworld.com/article/3306443/what-is-projec... https://www.xda-developers.com/android-project-mainline-modu...
Basically, if you spend 10 minutes looking up relevant information, buy a popular phone with good support and you will face 0 problems. You are making a mountain out of a molehill.
>Can you install Windows or Linux on ARM Macs?
ARM Windows sucks. I wouldn't even try, asahi can be installed (but I don't get why you would, all unix stuff works) https://asahilinux.org/about/
Apple has moved to arm but does this really make it easier to write cloud apps for arm linux? What is Apple doing to make this easier?
So the conversation went from “what’s the cost of getting our systems running on ARM and how does that compare to cloud pricing” to “our systems work everywhere, so who’s giving us the best deal”
They’re making ARM machines with really great perfs and used by a pretty large amounts of developers leading to:
* way more developers getting comfortable and natural access to ARM devices, meaning way easier for them to test & debug ARM issues
* way larger market for ARM developer tools
To be honest, i hardly know anyone ( little bit biased because of .net development)
I was using a Mac when I worked for a Fortune 500 enterprise. The choice was between a top of the line Macbook Pro with sudo rights and some underpowered Thinkpad where I'd have to request software to be installed by someone.
Not exactly what i suspected, but in retrospect my comment wasn't clear. I should have mentioned that eg. IOs engineers / Mac developers have no option. Which would be some share of the market.
But your comment was more valuable, thanks!
The killer is there was no friction at all and target is cheaper. It all just worked. Absolutely no issues at all.
The thing that scares intel is that they’re not special any more.
Actually google was the first. Its called TPU - Tensor Processing Units and has been available for their ML platform for a long time. Interestingly, TPU replaces nvidia in this case.
There are already largescale Kaggle benchmarks on CPU vs GPU vs TPU - https://towardsdatascience.com/when-to-use-cpus-vs-gpus-vs-t...
I'm mentioning that Google Cloud primarily hosts and bills your ML code on TPUs. Today TPU v4 run at exascale.
so the equivalence "scared" behavior exists for both Intel and nvidia on Google already.
Instead $/ML training job or time to complete training given X budget is likely a better measure.
If I'm writing new software using Java, C#, Python, JavaScript, etc. it's easy to deploy to ARM. With Apple moving to ARM and 25% of developers using Macs (41-45% using Windows)*, there's going to be good ARM support for what developers need. Sure, some things might might run better on Intel and some things might not easily port, but that feels like it isn't the case for the majority of stuff that developers are going to be doing.
It seems likely that Microsoft and Google will introduce ARM-based instances. We know Google has dipped its toe in with its Tensor processor for the Pixel. We've seen reports that Microsoft has been working on ARM processors for servers. Qualcomm is gearing up for a major push into better ARM processors to compete with Apple on the desktop/laptop, but presumably they'd be happy to get cloud workloads as well. Oracle, while not a major cloud provider, has ARM-based instances already.
Intel has had a virtual monopoly for 20 years. Now they're facing a resurgent AMD stealing x86 marketshare and ARM processors that are quickly becoming a better price/performance option - and Apple is ensuring that everything developers need will be ARM compatible. I don't think it's an existential threat, but there's a huge difference between the margins you get as a virtual monopoly and the margins you get when you have to compete against strong competitors.
Plus, I'd guess that AWS is probably making sweet margins off those Graviton instances. Let's say that their margin on Intel instances is X and that margin on Graviton is 2X. That leaves AWS a lot of room to start pushing Intel out of their datacenters as old hardware is replaced. Let's say you're a company spending $100M/year with AWS and you're renewing your contract. Maybe Amazon suggests that they could give you a 20% discount off Intel boxes and a 40% discount off Graviton boxes - which they say are already 20% better price/performance so it's basically 52% off!
It also gives AWS negotiating power with Intel. If 20% of AWS customers move to Graviton, you can go to Intel and say, "we're finding Graviton processors really cheap to make and operate and customers are loving them...more and more they're realizing they don't need your Intel processors...if we don't get cheaper Intel processors, we might have to accelerate our incentives to get people onto Graviton boxes...the more we accelerate that, the more Google Cloud and Azure will likely want to prioritize ARM boxes..."
They're scared because it's the type of thing that snowballs until their lock-in is near meaningless. If ARM becomes 50% of the server market, there goes Intel's ability to demand high margins. 5-10 years from now, most deployments could use Intel or ARM based on price/performance rather than instruction set - and that makes life a lot harder for Intel.
The problem with this ad/page is that the ship has already sailed. Once Apple introduced its M1 MacBooks, we were getting first-class ARM support for everything developers would need going forward. It didn't happen overnight, but with Apple going all-in on ARM chips and with Macs being such a big player in developer usage, the war was lost that day. Now it's just a matter of time. Once all your devs are running and testing their stuff on an M1 MacBook, why not deploy it to an ARM instance?
* From StackOverflow's 2021 developer survey