eylenburg.github.io

Eylenburg's Tech Website maintains several comparison tables that let you evaluate operating systems side by side: an 18-system OS comparison (Windows, macOS, iOS, Android, ChromeOS, GNU/Linux, FreeBSD, NetBSD, OpenBSD, DragonFly BSD, Illumos, Haiku, ArcaOS, RISC OS, MorphOS, AmigaOS, AROS, OpenVMS), a 6-distribution Android comparison, and a 19-distribution Linux comparison. Use these tables when you need to pick an OS for a specific device or purpose, understand how a distribution differs from its upstream, or trace where a system came from. The site also includes a timeline and family tree covering roughly 1,400 operating systems since 1950, plus an appendix on running them in a virtual machine.

Comparing the 18 Major Operating Systems

The main comparison table covers 18 systems spanning desktop, mobile, server, and hobbyist platforms. The set breaks into recognizable families:

• Proprietary desktop/mobile: Windows, macOS, iOS, Android, ChromeOS
• Open-source Unix-like: GNU/Linux, FreeBSD, NetBSD, OpenBSD, DragonFly BSD, Illumos
• Non-Unix or niche systems: Haiku, ArcaOS, RISC OS, MorphOS, AmigaOS, AROS, OpenVMS

The table's value is that it puts these on the same attributes rather than describing each in isolation, so you can see where, for example, a BSD differs from a Linux distribution on the same axis, or where a hobbyist system like Haiku or AROS stands relative to mainstream options.

The appendix explains how to run these systems in a virtual machine — useful if you want to test an unfamiliar OS before committing hardware to it.

Android-Based Distributions vs. Stock Android

The Android comparison covers six distributions plus stock Android:

These differ from stock Android mainly in what they remove (Google services, telemetry) and what they harden (security features, sandboxing). The choice between them depends on your device support, how much Google infrastructure you're willing to give up, and whether you prioritize maximum hardening (GrapheneOS) or broader device compatibility (LineageOS, DivestOS).

Two appendices add practical context:

• Work profiles vs. private spaces vs. secondary user profiles in Android — these are different isolation mechanisms, and the distinction matters if you're separating work and personal data or compartmentalizing apps.
• Alternative smartphone operating systems beyond iOS and Android — for readers considering non-mainstream mobile platforms entirely.

Linux Distributions: What Actually Differs

The Linux comparison covers 19 distributions: Debian, Ubuntu, openSUSE Tumbleweed, openSUSE MicroOS, SUSE Linux Enterprise, Fedora Workstation, Fedora Atomic Desktop, Red Hat Enterprise Linux, OpenMandriva ROME, Mageia, PCLinuxOS, Arch, Slackware, Gentoo, Alpine, Void, NixOS, Guix System, and Solus.

The meaningful differences between distributions come down to a handful of technical choices, and the site's appendix tracks exactly these across the most important distributions from 2000 to today:

• Desktop environment — KDE Plasma, GNOME, Xfce, and others
• Widget toolkit — Qt vs. GTK and related
• Display server — X11 vs. Wayland
• Package format — deb, rpm, and others
• File system — default choices per distribution
• Init software — systemd vs. alternatives
• Security module — SELinux, AppArmor, and similar

The appendix also asks how heterogeneous distributions are today versus historically — useful if you want to know whether the ecosystem is converging or diverging on these choices.

A separate desktop environment comparison covers 10 desktops (Microsoft Windows, Aqua, KDE Plasma, GNOME, Xfce, MATE, Cinnamon, LXQt, COSMIC, Budgie), plus discontinued and mobile environments, with screenshots and short personal reviews.

Tracing Lineage: The Timeline and Family Tree

The timeline and family tree spans roughly 1,400 operating systems from 1950 to today. This is the resource to use when you want to understand:

• Which modern systems descend from which ancestors
• When a given OS appeared and what it influenced
• How families like Unix, BSD, and DOS/Windows relate

Lineage matters practically: knowing that macOS and iOS share a Darwin/Unix heritage, or that the BSDs share a common ancestor, explains why certain tools, conventions, and security models recur across systems that otherwise look unrelated.

How to Use These Comparisons to Decide

1. Identify your constraint first — device (desktop, phone, server), hardware compatibility, or a specific requirement like de-Googling or maximum security hardening.
2. Narrow to the relevant table — the 18-system table for cross-platform questions, the Android table for phones, the Linux table for distribution choice.
3. Compare on the attributes that matter to you — for Linux, that's typically package format, init system, release model, and desktop environment; for Android distributions, it's Google dependency and device support.
4. Check lineage if compatibility or tooling is a concern — the family tree shows what a system inherits.
5. Test in a virtual machine before committing — the OS comparison appendix covers how to do this.

The site's tables are updated periodically (the OS table and Android table as of late 2026, the timeline as of early 2026), so check the "last update" note on each page if currency matters to your decision.

Netflix uses technology and engineering to run a global streaming service end to end: encoding and delivering video, personalizing what each viewer sees, operating large-scale cloud infrastructure, and supporting the internal culture that lets teams build and ship software. The Netflix TechBlog is the company's own public record of that work, so it is the most direct place to see how these systems are described by the engineers who build them.

The main technology areas Netflix invests in

Netflix's engineering work clusters around a few broad problems that come with streaming to a large, worldwide audience.

• Streaming and content delivery. Getting video from source to a viewer's device reliably, at high quality, across many device types and network conditions.
• Personalization and recommendations. Deciding what to surface for each viewer, which shapes both the product experience and how content is discovered.
• Cloud infrastructure and platform engineering. Running the underlying systems that other teams build on, including the tooling and operational practices that keep services available.
• Data and experimentation. Measuring behavior and testing changes so product and technology decisions are based on observed results rather than assumptions.
• Studio and content technology. Supporting the production side of the business, not just playback.

These areas are connected. A change in encoding or delivery affects what a viewer actually experiences; a change in personalization affects what they choose to watch. That connection between backend systems and the viewer experience is a recurring theme in how Netflix describes its engineering.

How the engineering culture shapes what gets built

Netflix's culture is part of the technology story because it determines how teams are organized and how decisions get made. The TechBlog frames engineering effort alongside company culture and product development, which signals that the two are treated as linked rather than separate.

In practice, this tends to show up as:

• Teams owning the systems they build, rather than handing work across rigid boundaries.
• A preference for solving problems with tooling and platforms that other teams can reuse.
• Public, detailed write-ups of internal systems, which is itself a cultural choice — it means engineering work is documented and shared rather than kept private.

If you want to understand why Netflix builds something a particular way, the culture context usually explains more than the technical spec alone.

Real systems and tools described on the TechBlog

The Netflix TechBlog is where the company publishes concrete descriptions of systems and tools. Rather than a single product, it functions as a running archive of engineering problems and the approaches taken to solve them.

When reading it, the useful pattern is to look for three things in each post:

1. The problem — what constraint or failure mode the team was facing.
2. The approach — the system or tool they built, and the tradeoffs involved.
3. The outcome — what changed in reliability, scale, or viewer experience.

This structure is what makes the blog useful beyond Netflix: the specific systems are Netflix's, but the problem framing and tradeoffs often apply to other teams running similar workloads.

How technology decisions reach the viewer

The link between engineering and the viewer experience is the thread that ties the blog together. Infrastructure and platform work is not abstract — it exists to keep playback smooth, make recommendations relevant, and let the product change without breaking.

A practical way to read any Netflix engineering post is to ask: what would a viewer notice if this system failed or improved? Sometimes the answer is direct (playback quality, load times). Sometimes it is indirect (the ability to ship product changes faster). Both are part of how technology decisions connect to what people actually use.

Where to follow Netflix's engineering work

The primary source is the Netflix TechBlog at netflixtechblog.com, which covers engineering, company culture, and product developments. It is the place to go for deeper technical detail than a summary can provide, and it is written by the engineers doing the work.

If you are researching Netflix's approach for your own team, the most efficient path is to pick the area closest to your problem — streaming, personalization, infrastructure, or data — and read the posts in that area first, then follow the references and related posts from there.

If you want to replace the stock Android on your phone, the main alternatives are GrapheneOS, CalyxOS, LineageOS, /e/OS, iodeOS, and DivestOS (the last of which has been discontinued). Eylenburg's Tech Website compares six Android distributions plus stock Android in a single table, and the practical differences come down to three things: how hard they try to remove Google, how much they harden security, and which phones they actually run on. The right pick depends on your device model, your tolerance for setup work, and whether you need Google apps to keep working.

The distributions at a glance

The comparison table on Eylenburg's site covers these six distributions plus stock Android, and it is the most direct source for side-by-side detail.

What actually differs between them

De-Googling

This is the headline feature for most people. GrapheneOS, CalyxOS, /e/OS, iodeOS, and DivestOS all let you run without a Google account. The difference is how they handle the apps that expect Google services:

• GrapheneOS keeps Google Play in a sandbox so it has no special system privileges — you can install it, but it can't reach into the rest of the OS.
• CalyxOS and iodeOS offer microG, a reimplementation of Google's APIs, so apps that depend on Play Services work without the real thing.
• /e/OS ships its own app store and cloud services, aiming to replace Google's ecosystem outright rather than patch around it.
• LineageOS leaves the choice to you — no Google by default, but you can flash a Google apps package if you want.

Security hardening

GrapheneOS is the outlier here. It is built specifically around hardened memory allocation, stricter app sandboxing, and faster security patch delivery, which is why it is restricted to Pixel hardware — Pixels are the only phones that support the required verified boot and firmware update guarantees. The other distributions improve on stock Android's privacy defaults but do not match GrapheneOS's security model.

Device compatibility and install difficulty

This is usually the deciding constraint:

• GrapheneOS — Pixel only. Installation is a web-based flasher, relatively painless, but you must own a supported Pixel.
• CalyxOS — mostly Pixel, with a small number of other supported devices.
• LineageOS — the widest support by far, including phones that no longer receive vendor updates. This is the main reason to choose it: keeping an old device alive.
• /e/OS — broad support and, importantly, sold pre-installed on some phones, so you can skip flashing entirely.
• iodeOS — broader than Pixel-only, aimed at users who want privacy without buying new hardware.

Installation generally means unlocking the bootloader and flashing a recovery image, then the OS. Expect to wipe the device. Some manufacturers block bootloader unlocking, which rules those phones out regardless of which distribution you prefer.

Updates

Update cadence matters more than any feature list, because an unpatched phone is a privacy problem in itself. GrapheneOS and CalyxOS track Android security patches closely. LineageOS depends on maintainers for each device, so quality varies. /e/OS and iodeOS release on their own schedules. DivestOS, notably, has been discontinued, which is a reminder to check whether a project is still maintained before committing.

Android's multi-user features, explained

The comparison table's appendix addresses a question that comes up constantly: what is the difference between work profiles, private spaces, and secondary user profiles?

• Secondary user profiles are fully separate users on the same device. Each has its own apps, accounts, and data. Switching means logging out of one and into the other. Good for sharing a phone, but heavy.
• Work profiles are a managed container inside your main profile. Apps in the work profile are separated from personal apps, and you can turn the whole profile off with one toggle. Originally for employers, but anyone can use one to isolate, say, social media from banking apps.
• Private spaces are a newer Android feature that creates a hidden, separately encrypted profile you can lock away entirely. It is designed for the apps you don't want visible on your home screen at all.

For most privacy-minded users, a work profile is the easiest win: it isolates a set of apps without the friction of switching users. Private spaces go further if you want plausible deniability about what's installed.

How to choose

Work from your constraints inward:

1. Do you own a Pixel? If yes, GrapheneOS is the strongest option for security and privacy, with CalyxOS as the more convenient alternative if you want microG and a gentler setup.
2. Do you need to keep an older or non-Pixel phone alive? LineageOS is the realistic answer, with iodeOS as a privacy-oriented alternative where supported.
3. Do you want to avoid flashing entirely? /e/OS is sold pre-installed on some devices, which removes the biggest technical hurdle.
4. Do you depend on Google apps? GrapheneOS's sandboxed Play and CalyxOS/iodeOS's microG both let you keep them working; a fully de-Googled setup will break some apps, particularly banking and DRM-dependent services.
5. Check maintenance status first. A discontinued distribution (like DivestOS) means no security patches, which defeats the purpose.

If you are unsure, start by confirming your exact device model appears on the support list of the distribution you're considering — that single check eliminates most of the options for you.

Desktop environments differ mainly in resource use, customizability, default workflow, and how actively they are maintained. If you want the broadest comparison available, Eylenburg's Tech Website maintains a "Desktop Environments - Comparison Table & List" covering 10 desktops — Microsoft Windows, Aqua (macOS), KDE Plasma, GNOME, Xfce, MATE, Cinnamon, LXQt, COSMIC, and Budgie — plus a much longer list of discontinued and mobile environments, with screenshots and short personal reviews. Use that table when you need current specifics; use the summary below to decide which environments are worth investigating for your hardware and habits.

The main axis: resource use vs. features

The environments most people compare fall into rough tiers:

These tiers are tendencies, not guarantees — actual memory and CPU use depends on the distribution, compositor settings, and which background services you enable.

Customizability and default workflow

• KDE Plasma is the most customizable of the mainstream Linux desktops: panels, widgets, and shortcuts can be rearranged extensively. Choose it if you want to shape the desktop rather than adapt to it.
• GNOME offers the opposite philosophy: a opinionated, minimal workflow with extensions as the escape hatch. Choose it if you prefer defaults and don't want to configure much.
• Xfce, MATE, and Cinnamon keep conventional desktop metaphors (taskbar, menu, desktop icons). Cinnamon and MATE are common on Linux Mint; Xfce is a frequent choice for older hardware.
• LXQt targets low resource use with a traditional layout, at the cost of fewer integrated features.
• Budgie sits between GNOME's simplicity and a traditional layout.
• COSMIC, listed as new on the comparison table, is a newer entrant — treat its maturity as still developing rather than settled.

Using Windows and macOS as reference points

Microsoft Windows and Aqua (macOS) appear in the same comparison table, which is useful if you're migrating and want to map familiar behavior onto a Linux desktop. They are not alternatives you can install on arbitrary hardware, so treat them as baselines for judging workflow, not as options in the same decision.

Discontinued and niche environments

The site's exhaustive list also covers environments that are no longer maintained or are rarely used — CDE, Enlightenment, Trinity, Unity, Pantheon, Lumina, Deepin, and UKUI, among others. This matters for two reasons: you may encounter them on older systems or in screenshots, and you should avoid building a new setup around an unmaintained environment unless you accept the lack of updates.

How to choose

1. Check your hardware first. On limited RAM or older CPUs, start with Xfce or LXQt; on modern hardware, resource use is rarely the deciding factor.
2. Decide how much you want to configure. Heavy customization points to KDE Plasma; minimal fuss points to GNOME or Cinnamon.
3. Match your workflow. If you want a traditional taskbar-and-menu layout, MATE, Cinnamon, or Xfce will feel familiar immediately.
4. Verify current status before committing. Maintenance activity and feature sets change; the comparison table's last update (October 2026) and its screenshots and reviews are the better source for specifics than any static summary.
5. Try before switching. Most Linux distributions let you test a desktop environment from a live session or install multiple environments, so you can compare them on your own machine.

The single most useful next step is the comparison table itself, since it consolidates the desktops, their screenshots, and the author's hands-on reviews in one place.

Eylenburg's Tech Website compares 17 (actually 19) Linux distributions in a single comparison table and timeline, covering Debian, Ubuntu, openSUSE Tumbleweed and MicroOS, SUSE Linux Enterprise, Fedora Workstation and Fedora Atomic Desktop, Red Hat Enterprise Linux, OpenMandriva ROME, Mageia, PCLinuxOS, Arch, Slackware, Gentoo, Alpine, Void, NixOS, Guix System, and Solus. The comparison focuses on the technical choices that actually distinguish these distributions: desktop environment, widget toolkit, display server, package format, file system, init software, and security module — tracked from the year 2000 to today. If you want to pick a distribution based on how it is built rather than on marketing claims, that table is the fastest route; the summary below explains what those dimensions mean and how the major families differ.

The dimensions that actually separate distributions

Most "which distro" debates reduce to a handful of structural choices. Eylenburg's comparison uses exactly these:

• Package format — how software is delivered and installed (e.g. deb, rpm, or source-based approaches).
• Release model — fixed releases with version numbers versus rolling releases that update continuously.
• Default desktop environment — the graphical shell shipped out of the box, if any.
• Widget toolkit — the underlying UI library (e.g. GTK or Qt), which affects look, feel, and theming consistency.
• Display server — X11 versus Wayland, which matters for hardware support, security, and multi-monitor behavior.
• Init software — the first process started at boot; systemd versus alternatives.
• File system — the default filesystem layout and features (snapshots, copy-on-write, etc.).
• Security module — mandatory access control frameworks such as SELinux or AppArmor.

The site's appendix goes further and asks how heterogeneous the distributions are today compared with the past, using those same dimensions. That historical angle is useful: two distributions that look similar now may have converged from very different starting points, which tells you something about how quickly each one adopts change.

The major families

Debian family

Debian sits at the base of a large tree. Ubuntu derives from it, and Ubuntu in turn feeds downstream projects. Debian is associated with the deb package format and a conservative, stability-first release cycle. If you want a large software repository and long-term predictability, this is the family to start with.

Red Hat family

Fedora Workstation and Fedora Atomic Desktop sit upstream of Red Hat Enterprise Linux. Fedora is where Red Hat's desktop and server technologies appear first; RHEL is the long-support, enterprise-facing product built from it. The comparison table lists both Fedora variants separately, which matters because Fedora Atomic Desktop uses an image-based model rather than a traditional package-by-package update.

SUSE family

openSUSE Tumbleweed (rolling) and openSUSE MicroOS (image-based/transactional) sit alongside SUSE Linux Enterprise. The split mirrors the Fedora/RHEL pattern: a fast-moving community edition and a slow-moving enterprise edition, plus a third variant optimized for immutable-style updates.

Arch family

Arch is the reference point for rolling releases and user-driven configuration. It is not a family in the same sense as Debian or Red Hat — it is a single distribution whose model others imitate — but it anchors the "always current, you assemble it" end of the spectrum.

Independent and specialized distributions

Slackware, Gentoo, Alpine, Void, NixOS, Guix System, Solus, OpenMandriva ROME, Mageia, and PCLinuxOS each make a distinct structural bet:

• Gentoo — source-based, you compile what you install.
• Alpine — minimal, widely used as a container base.
• NixOS and Guix System — declarative configuration and reproducible builds, a fundamentally different model from imperative package management.
• Void — independent, with its own package manager and init choices.
• Solus — independent desktop-focused distribution.
• OpenMandriva ROME, Mageia, PCLinuxOS — the Mandriva lineage, each with its own release philosophy.

Choosing by scenario

What to weigh before deciding

Three trade-offs dominate, and they pull against each other:

1. Stability versus software freshness. Fixed-release distributions (Debian, RHEL, SUSE Linux Enterprise) change slowly on purpose. Rolling distributions (Arch, Tumbleweed) stay current but require you to keep up.
2. Convention versus control. Mainstream distributions make choices for you — desktop environment, init, security module. Source-based and declarative distributions (Gentoo, NixOS, Guix) hand those decisions back, at the cost of a steeper learning curve.
3. Ecosystem size versus coherence. A large family (Debian/Ubuntu) means more third-party packages and troubleshooting threads. A smaller independent distribution may offer a more consistent design but fewer places to find answers.

The comparison table's value is that it shows these as concrete, checkable attributes — package format, init software, security module, and so on — rather than as vague reputations. Before committing, check the specific row for the distribution you are considering and confirm that its choices on display server, init, and security module match what your hardware and workflow require.