构建新的通用计算架构生态是个世界级难题，技术本身不是最难的部分，最难的点有两个：一个是得有丰富的应用生态，用户才能获得较好的用户体验；另一个是要有很大的出货量，这样才有成本优势。这两个条件互锁，类似于先有鸡还是先有蛋的问题，那要如何破局呢？
ARM是一个擅长做生态，且有成功记录的公司。它最擅长耐心，日拱一卒，以5年，10年为节奏，去完成听起来朴实低调，但其实特别宏大，以至于像吹牛一样的目标，例如，Linuxonarm，Worksonarm，Windowsonarm。
Linuxonarm
Linux是什么时候开始支持arm的？
第一次把Linux移植到ARM上是在，ARM成立之前。ARM的前身Acorn计划把1.0.x的linuxkernel移植到AcornA上。当时的目标是在A上得到一个类Unix的操作系统，而且没有想过把结果返回到Linus的kerneltree上，因此只是一次移植，并不算Linux支持arm。
移植过程跟现在的应用移植区别也不大，把源码包解压缩，配置kernel，编译。不过整个过程是非常曲折的。当时没有配置脚本，需要手工编辑makefiles，编辑头文件，比较费时费力。kernel是分段编译的，文件系统，kernel，ipc等都是单独编译。内存管理（mm）系统需要重写，因为物理页和逻辑地址空间的映射关系反了。幸好那时的A相对简单，因此驱动就没有太大问题。但是汇编相关的所有内容都需要重写。所有模块都编译通过之后，就需要把它们链接为完整的kernel。第一次链接不出意料的失败了，返回了一长串的未定义字符。经过一个月的修补，终于Linux启动了。随后根盘（rootdisk），文件系统，shell程序，C库等等，没有一项是一次性通过，都是需要一番修补调试或者重写才能正常工作。
最早支持ARM的正式发行版是Debian。年8月15日，Debian2.2（Potato）支持了Inteli，Motorolaseries,alpha,SUNSparc,PowerPC和ARM架构（多么百花齐放的年），其中PowerPC和ARM都是新移植的。这个版本由个Debian开发者，维护了多个二进制文件和多个源码包。在那个时候，就有近上千个应用，需要测试。而且在年，还没有平板，chromebooks或者现在的智能手机。一些工程师用康柏的iPaqs（还有多少人，记得康柏？）进行测试。
但是从此之后，Linux与arm就一帆风顺了么？并没有，年3月LinusTorvalds那封著名“thewholeARMthingisaf*ckpainintheass”邮件，震惊了这个Linux社区，对ARM软件团队也是一个很大的触动。本来ARM是属于佛系努力派的，就是虽然努力，但是也很佛系，能做则做，能支持则支持，力所不能及的就随缘了，最后总有需要的这项工作的一个或者几个ARM系公司把它做了。但是这封要求arm加强控制的社区邮件，其实指出了由于ARM的IP授权模式，会出现多个不同的SOC提供商需要修改相同的Linux文件来支持自己的硬件的问题。重复工作效率低虽然是问题，但彼此之间有冲突，才是致命。没有人管理的冲突，最终的结局是分裂。
其实arm已经意识到存在生态分裂到问题，在这份“F”开头的邮件之前的一年，就成了了Linaro，这个独立的非盈利的工程师组织。Arm希望Linaro以中立的身份，组织arm阵营的所有合作伙伴，解决LinuxKernel和GNU工具链方面问题，形成合力夯实软件生态。Linaro也确实做到了，仅仅一年的时间，就让怼天怼地地LinusTorvalds换了赞许的态度。
歪一句，那封“Fx”邮件是回复OMAP团队的一个pull请求，现在读起来唏嘘OMAP今何在？有人说ARM幸运地搭上Androids的车，可是如果当年Symbian赢（诺基亚的），Symbian的车上也是ARM。大家以为ARM是移动计算市场的幸运者，其实是尸横遍野之后的幸存者。
如果说移动计算市场，arm还是有先发优势的，那么年才发布64位的ARMv8，才开始的数据中心生态建设，才真正是教科书一般的生态建设路线（一场硬仗）。
企业版LinuxonARM
其实数据中心市场和移动计算市场非常不一样。数据中心市场是标准驱动的，从系统该如何启动到软件如何大规模部署。更要命的是，数据中心发行版需要硬件提前upstream所需的代码和改动，然后才能在部署中实现对新硬件的支持。而且数据中心的架构也在不停的演进着，从OpenStack到K8s……。因此ARM联合自己阵营的生态伙伴们组队制定标准，移植测试，保证互操作性，配合多种编排软件，甚至推动开源软件社区的多指令架构的软件架构策略…做了很多事情以确保在数据中心中所需要的海量开源软件，在ARM架构上既可用也性能良好。
红帽在年的峰会上，展示了从年开始，到年6月，红帽团队为ARM生态而做的重要事件里程碑。这4年多的时间里，红帽开始移植OpenJDK的工作，和Linaro一起成立了Linaro企业组（后来更名为Linaro数据中心组LDCG，把网络分离出来成为另外一个工作组），制定SBSA/SBBR标准，发布Fedora社区版加速upstream活动，最终完成OpenJDK的移植任务，发布RHEL预览版。红帽的参与，集成，稳定三步走策略也是非常经典，每个参与ARM生态的开源软件社区基本都经历了这三步曲。
不仅仅是红帽，Canonical（Ubuntu），SUSE，OpenEuler，FreeBSD对于AArch64的支持，都是按年来进行工作计划的。而这仅仅是操作系统层而已。
有了基础的标准SBSA/SBBR，基础的编译工具GCC，LLVM（其实在编译工具上，ARM还曾经走过一段弯路，前瞻性的全力以赴LLVM，阶段性放弃了GCC，然后发现软件世界的长尾效应非常长），还有了操作系统，但是这离繁荣的生态还有一大段距离呢。
生态，某种程度是开发者的生态。开发者的最低要求，是要有开发的环境，但是人手一台服务器，这个属实有点“钞”难度。但是云上的生态，可以云上解决部分。
WorksonARM
从年开始，Packet（Equinix公司）和ARM一起启动WorksonARM这个项目，提供免费的ARM云主机的访问，以此为起点撬动更多的开源软件社区在arm64架构上进行开发测试工作。
到年年末的现在，可以申请免费云主机资源的可不仅仅是Packet，还有AWS，Googlecloud，微软的Azure，拿树莓派做服务器的MiniNode，俄勒冈州立大学的OSL，甲骨文云和国内的腾讯云。
但是WorksonARM的主要成果，并不仅仅是它的免费硬件资源，也不是这个项目支持了50多个著名的开源软件项目。而是在这个项目的撬动下，CI/CD工具完全打通。
本来CI/CD的最流行工具是Jenkins，Drone.IO作为后入者，也有一个要扩大生态的问题，同时受到Docker提倡的多指令集架构的鼓舞，Drone.IO团队把支持arm架构作为一个重要突破方向，年8月正式宣布支持arm架构。Drone.IO对arm的支持是双赢的，在宣布支持arm的支持之后，其服务业务有10倍速的增长。
在Drone.IO的带动下，其它几个主要CI/CD的玩家也纷纷行动。年10月TravisCI在其支持的多CPU架构列表中正式加入了arm。几乎在相同时间，Gitlab宣布其64-bitRunner可以在Packet和AWS的arm实例上运行。年3月CircleCI宣布支持arm架构。年5月Jenkins和甲骨文的OCI团队一起合作，实现对arm实例的支持。
复盘一下整个CI/CD生态都很好的支持了arm服务器的过程，这是一个长达5年的一个项目一个项目的迁移努力，也是天时加人和的结果：ARM一方面推动开源社区支持的多CPU架构策略，另一方面顺利搭上builtinthecloud快车，把arm云实例带到云原生的产品迭代流程中。对于软件来说，特别是云原生软件，可移植的架构无关的软件会有更好的生命力。一个原生的支持多架构的CI/CD流程，也能保证其上的软件产品的稳定性和可移植性，CI/CDonARM是一个双赢的结果。
到目前为止，WorksonARM的成果，除了CI/CD平台之外，语言和编译器也非常丰富，包括EclipseAdoptium(之前的AdoptOpenJDK)，GNU的工具链，GoLang，LLVM，Node.JS，OpenJ9，Python，Rust和Swift；操作系统和虚拟化软件有AlpineLinux，CentOS，CloudHypervisor，Debian，Gentoo，KVM，OpenEmbedded(之前的Yocto)。数据库ScyllaDB也利用项目的硬件系统来样子性能和程序的正确性。
如果再看看AWS，谷歌云，微软Azure，甲骨文OCI，上跑在ARM实例上的软件应用，可以很中肯的说，ARM在数据中心上的生态已经可以打A算是优等生了。
不过一直非常能整活的大神Linus说“在一个ISA推广的初期，可供软件工程师测试的硬件平台是一个关键门槛。一个几个人的小团队，小公司也可以负担得起的小PC盒子，工程师可以把自己的代码运行在上面，自由测试，然后这样的应用如果得到高速发展，在数据中心中心中落地，这就是真正的服务器应用。”，他的结论是，如果没有ARMPC，也就没有ARM服务器的未来。从历史上看，Intel也确实是先拿下PC市场，然后再把一众经典RISC处理器挤出了数据中心。
那么问题来了，是ARM不喜欢PC市场，才没有大举进攻PC市场么？
（在这个问题上，让我们跳过苹果这一章，苹果的生态做得好，但是一般人学不来）
WindowsonARM（WOA）
把Windows生态移植到arm上的努力，开始的很早，第一个成果就是年的微软SurfaceWindowRT。但在年，抛开硬件性能拉垮之外，生态方面差距太大，ARM的系统只能运行部分已经预先编译过的应用，哪怕是Chrome、Photoshop都不能安装……
年微软再次尝试WindowsonARM时，已经完全吸取前次教训。正式发布的Window10forARM，可以支持arm设备跑任何存在的Windows应用。Windows10操作系统是完全重新编译的，DLL（也就是多数的Windows库）也都是重新编译过的，部分应用已经是编译过的原生arm应用，其它应用则采用动态二进制翻译技术，将应用代码转换为ARM64代码执行。
二进制翻译是WindowsonARM的答案么？不，这仅仅是博一个开端而已。微软和ARM的策略都是支持WindowsonARM的原生应用开发，从赢得开发者的心开始，从端到端的工具链开始构建一个强壮的生态系统。
微软团队自己动手移植VisualStudio,VSCode,VC++toolchain,classic.NETFramework,modern.NET和Java的工具链，同时和arm，开源社区一起移植通用工具，运行时，框架和库。微软Azure提供arm的虚拟机和CI/CD工具，同时还提供WindowsDevKit（ProjectVolterra）硬件小盒子给开发者。
年11月发布的Electron6.0.8算是一个开端，年10月发布的原生的VisualStudioversion17.4才是大菜一盘。
而且微软年2月加入Linaro，对就是Linaro，不知道Linaro会不会把自己的口号从LinuxOnarm改成allonarm……。Linaro的WOA项目页，非常朴素，有介绍有项目列表，还有一张已经徐徐展开的路标图，每一页，每个标注都是软件生态的一次迁徙。
我不知道别人看好WindowsonARM笔记本的哪里，是电池待机时间长，5G一直在线，方便与手机同步，还是超薄超轻无风扇设计？我希望windowsonARM在PC市场上迅速成功，以带动ARM服务器进入一个新高度。