OS Selection — Linux / Windows / UNIX and ARM

About this article

This article is the fifth deep dive in the “System Architecture” category of the Architecture Crash Course for the Generative-AI Era series, covering OS selection.

Server OS selection is the area least amenable to redos — apps, middleware, runbooks, monitoring tools, and personnel are all bound to the OS. This is a decision where you have to be ready to carry the choice for 10 years. The article covers the three families (Linux / Windows Server / commercial UNIX), distribution selection, license / EOL management, and CPU architecture (x86 / ARM).

What is OS selection in the first place

OS selection is, roughly speaking, “deciding which base software will serve as the server’s foundation.”

Imagine a house’s foundation work. A wooden frame (Linux), a steel frame (Windows Server), and reinforced concrete (commercial UNIX) require completely different construction methods and tools. If you decide “actually, I want steel” after the foundation is poured, the only option is to tear down the house and rebuild. Server OS is the same — apps, middleware, runbooks, monitoring tools, and personnel are all bound to the OS, and once you choose, you live with it for a decade.

Why OS selection matters

What happens if you take OS selection lightly? Once code, runbooks, and monitoring tools are written for a specific OS, switching to another is essentially a rebuild. Defaulting to “just go with what we know” locks the team out of switching for the next 10 years, losing technology-selection flexibility.

For new projects today, the real decisions narrow to two: which Linux distribution and whether to use ARM. OS is a foundation you can’t change later — decide at project planning time.

A 10-year commitment

The main options are Linux, Windows Server, and commercial UNIX. For new projects in 2026, the actual decisions narrow to two: which Linux distribution and whether to use ARM. Windows Server gets picked when there’s an integration requirement with an existing Microsoft platform; commercial UNIX gets picked only to maintain existing core systems.

OS is the “decide it at project planning” domain. Once code, runbooks, and monitoring tools are written for one OS, switching is essentially a rebuild. “Just go with what we know” locks the team out of switching for the next 10 years.

OS is “a foundation you can’t change later.” Decide at planning time.

The major options

For new projects, the temperature is “if you pick anything but Linux, you owe a reason.” With cloud and containers as the assumption, building a rationale to pick anything else is harder than just picking Linux.

Linux

Linux is the open-source UNIX-compatible OS Linus Torvalds began in 1991. It now runs the world’s servers, smartphones (Android), and embedded devices, and dominates cloud VMs, containers, and supercomputers as the foundation.

Most AWS EC2 / GCP / Azure instances run Linux. The de facto for server use, and “Linux when in doubt” is the modern default.

Linux distributions

A Linux distribution is “the complete Linux package” — Linux kernel + various software bundled. They split into Red Hat family and Debian family, with different package-management commands and config layouts.

Pick the family the team is comfortable with. Enterprises lean Red Hat family; developers and startups lean Debian family (especially Ubuntu). After CentOS’s EOL policy change in 2021, Rocky Linux and AlmaLinux were elevated as RHEL successors and have become mainstream.

Distribution selection by case

Ubuntu LTS gives 5 years of support and is the favorite for startups and in-house development. Finance, public sector, and large-enterprise core systems pick RHEL’s commercial support — willing to pay tens of thousands of dollars annually for the comfort of getting Red Hat on the line during incidents.

For new Linux: Ubuntu LTS / Amazon Linux / RHEL family. All three have high AI-generation accuracy.

Windows Server

Windows Server is Microsoft’s commercial server OS. Even in the Linux era, companies built around the Microsoft platform (Active Directory, .NET, SQL Server, Office) still pick it as the first candidate.

Mostly used to extract value from existing Microsoft assets. Picking it for a new cloud-native web app is a bad fit.

Skip Windows Server for new builds outside Microsoft-platform integration.

Commercial UNIX

Commercial UNIX (AIX from IBM, HP-UX, Solaris) was tied to a specific vendor’s hardware and used in large-scale, high-reliability workloads. From the 1990s into the early 2000s it ran financial core, airline reservation, and telco systems, but Linux’s rise drove share down significantly.

Commercial UNIX is essentially never picked for new builds. Most efforts are now in “maintain the existing core system, gradually migrate to Linux.”

Don’t pick for new builds. Only relevant for legacy maintenance.

License forms

OS license form maps directly to cost structure. Cloud generally bills “OS-included by the hour,” but you can also bring existing OS licenses (BYOL — Bring Your Own License).

RHEL / Ubuntu Pro is the hybrid model: “OSS but with commercial support.” At scale, the annual support fee buys the comfort of getting official help during production incidents.

Support period (EOL)

EOL (End of Life) is the day OS vendors stop providing security patches. Continuing past EOL means accumulating critical security risk as vulnerabilities go unfixed. Pick a version with EOL well past your operational period.

For systems that will run 10+ years, picking near-EOL is a landmine. Within a few years you trigger an OS-update project at significant cost.

EOL = patches stopped. Pick a version with support longer than the project.

CPU architecture

Equally important is CPU architecture. x86_64 (amd64) was overwhelmingly dominant traditionally, but ARM64 has risen since the early 2020s in cloud, mobile, and Apple Silicon as a low-power, low-cost option.

AWS Graviton (ARM) runs 20-40% cheaper than equivalent-performance x86 instances. Web servers, Java apps, and many managed services (RDS, ElastiCache, etc.) support Graviton, and not considering ARM for new builds is a missed opportunity.

In cloud, ARM adoption can cut cost 20-40%. Always evaluate for new builds.

Container-specialized lightweight OSes

Container-only OSes optimized for the container era have appeared, surpassing general Linux on security, startup speed, and ops automation, with growing adoption on Kubernetes platforms.

No SSH login, API-only management — minimizing attack surface while automating ops. Worth considering when running Kubernetes seriously.

Selection criteria

OS selection is decided by “existing assets, people, use case.”

For new SaaS / web services, Ubuntu LTS + ARM64 is overwhelmingly the best 2026 choice. Plenty of learning material, easy hiring, low cloud cost.

EOL management / patching ladder

Note: industry rates as of April 2026. Periodic refresh required.

OS isn’t “pick and forget” — the real work is the 10-year run to EOL. What matters changes by phase.

Continuing on an EOL’d OS produces the same structure as the Equifax 2017 incident (Apache Struts unpatched, 147M records leaked). Manual patching doesn’t scale; modern practice automates with tools like AWS Systems Manager Patch Manager.

EOL: act backward from the announcement date. Last-minute discovery doubles migration cost.

Patching / migration traps

After Equifax, companies that ignored known vulnerabilities took on lawsuits, fines, and stock drops. Security patches are “updates that don’t add features” — automate and apply continuously.

“It’s running, don’t touch it” is a hotbed of security incidents. Patches are not optional.

AI decision axes

With AI-driven development as the assumption, “engineer familiarity” drops as a criterion, replaced by “AI training data volume” and “command standardization.”

1. EOL must exceed operating period + 2 years.
2. Existing-platform integration (Microsoft / UNIX legacy).
3. Commercial support contract sized to industry risk.
4. CPU architecture: always evaluate ARM64 (cost axis).

Ubuntu / Amazon Linux have high AI generation accuracy

When AI writes shell scripts or systemd unit files, targeting Ubuntu LTS or Amazon Linux 2023 yields higher accuracy. apt/dnf package names, config file paths, and service startup methods are abundantly present in training data.

Conversely, RHEL-specific minor-version differences (SELinux policy configuration, firewalld zone design) and commercial UNIX command systems have thin training data, and AI may generate non-working code by extrapolating from generic Linux knowledge.

Why Windows Server GUI ops become disadvantageous in the AI era

Windows Server managed via GUI doesn’t record config changes as operations, making it outside the scope of AI-driven config review or automation. Even the same Windows Server, if managed via PowerShell DSC or Ansible, becomes code that AI can read and write — so the GUI-vs-code operational policy determines whether AI utilization is possible.

The CentOS 8 incident (industry case)

After picking CentOS 8 and developing on it, December 2020’s sudden announcement of “support ends end of 2021” forced a migration in about 1 year on projects that should have run until 2029.

One Japanese SI took millions of dollars and several months of unplanned work to swap CentOS 8 across dozens of deployed sites to Rocky Linux. Stories of “we just kicked off a new project on CentOS 8 — meeting the next week was hellish” abound.

The lesson is simple: “OSS doesn’t mean roadmap reliability is the same.” For free distros too, check “who’s behind it” and “have they moved EOL before?” as a defense line.

“Should be usable for a long time” can flip on one announcement. Verify the backer’s reliability.

What you must decide — what’s your project’s answer?

Articulate your project’s answer in 1-2 sentences for each:

• OS family (Linux / Windows / UNIX)
• Distribution (RHEL family / Debian family / other)
• Version and EOL date
• CPU architecture (x86_64 / ARM64)
• License contract (free / paid sub / commercial)
• Patching policy (manual / auto / Blue-Green)
• Support contract scope

Related Articles

https://en.senkohome.com/arch-intro-system-bcp/ https://en.senkohome.com/arch-intro-system-cloud-vendor/ https://en.senkohome.com/arch-intro-system-deployment-model/

Summary

This article covered OS selection — Linux / Windows / UNIX comparison, distributions, EOL management, ARM architecture.

New Linux: pick from Ubuntu LTS / Amazon Linux / RHEL family. Windows Server: only when integrating with Microsoft platforms. Commercial UNIX: only legacy maintenance. CPU: ARM64 evaluation is mandatory. The 2026 realistic answer.

The next article covers datastore (overall data placement at the system-architecture level).

Back to series TOC -> ‘Architecture Crash Course for the Generative-AI Era’: How to Read This Book

I hope you’ll read the next article as well.