“Any sufficiently advanced technology is indistinguishable from magic.” That line from Arthur C. Clarke fits because systems that once felt fast can age into frustration.
I see this daily: my long-lived Windows installs creep slower, updates add clutter, and drivers drift out of sync. So I stopped arguing about the best operating system in the abstract and started practical testing.
Virtualization lets me spin up clean environments on demand. That avoids the slowdowns I encounter and gives repeatable results when I run a linux distributions comparison for actual tasks.
In this guide I’ll treat each distro as a tool for a job: desktop, developer workstation, or server. I anchor this approach in facts: many developers and critical systems favor open tools for repeatability and uptime.
Success here means fast setup, predictable updates, solid hardware support, and a helpful community in the United States. I’ll focus on release cadence, package managers, desktop choices, and security defaults — practical checks, not vibes.
Key Takeaways
- I test using virtualization and Live USBs to avoid long-term Windows slowdowns.
- The article compares distros as practical tools for real jobs, not ideals.
- Expect clear criteria: setup speed, updates, hardware support, and community help.
- Many professionals choose open systems for repeatability and uptime.
- Virtualization reduces risk by letting you validate essentials before switching.
Why I’m Comparing Linux Distributions in the US Right Now
Right now in the US the choice of a distro often decides whether a machine stays reliable or becomes a maintenance chore. I want tools that balance stability for work with access to modern development tools.
Where it already matters: over 55% of professional developers prefer Linux for development workloads, and all top 500 supercomputers run on it. Desktop market share remains low (~3.05% as of December 2025), so community help and solid docs matter for newcomers.
Where it wins today: developers and supercomputers
Development teams pick systems for predictable toolchains and containers. High-performance computing favors the kernel for scale and tunability. Those wins show this isn’t a niche hobby.
What “distro choice” actually changes
Choice changes three daily things: the default desktop, the package manager, and the update rhythm. For example, APT on Ubuntu differs from DNF on Fedora. Ubuntu LTS gives five years of security updates; Arch updates continuously.
- Packages: which software is easiest to install.
- Desktop: the default UI and its performance profile.
- Updates: how often and how risky upgrades feel.
I’m setting a practical frame: I won’t push one favorite. I’ll show how to match a distro to what you actually do, then explain my testing method next.
How I Define a Fair linux distributions comparison
Clarity matters more than opinion. To keep this review fair, I split choices into three practical lanes: desktop for daily use, server for long-running services, and security-focused builds for auditing and forensics.
What I compare
I stick to objective criteria so results are repeatable. My core checks are release model (fixed vs rolling vs immutable), support window length, and the day-to-day package management experience.
Why support and package counts matter
Support affects planning: longer lifecycles mean fewer forced migrations for teams and less urgent upgrades for servers. I treat repository breadth and number of packages as a productivity factor, not a popularity contest.
What I exclude
I do not test unstable beta branches or non-Linux operating systems. Those paths add noise and break apples-to-apples measurement.
| Family | Latest stable | Release model | Support (typical) |
|---|---|---|---|
| Debian/Ubuntu family | Stable LTS | Fixed | 3–5 years |
| Fedora / cutting edge | Current release | Short-cycle fixed | ~1 year |
| Arch / rolling | Rolling | Rolling | Variable (continuous) |
| RHEL-style | Enterprise stable | Fixed / enterprise | 8–12 years |
When I say one distribution is “more stable,” I mean it produces fewer disruptive changes given its release model. Also, security in my testing is about defaults, update speed, and how quickly maintainers ship fixes—not a single toggle.
Quick Snapshot of Major Distro Families and Forks
I’ll sketch the major family trees so you can spot common tools and support patterns at a glance.
Debian-based ecosystem: Debian stable is at 13.3 (2026-01-10). Ubuntu and most Linux Mint editions inherit that base or Ubuntu’s packaging. That makes them a familiar start for US desktop users because tooling and packages are broadly available.
Red Hat family: Fedora feeds features upstream while RHEL 10.1 holds ~12 years of support. Rocky Linux and AlmaLinux track RHEL closely (Rocky 10.1; AlmaLinux 10.1) and offer near-enterprise stability without the same vendor licensing.
Arch family: Arch itself is rolling. Manjaro and EndeavourOS give easier installs and extra guardrails for users who want immediacy over predictability.
SUSE lineage: openSUSE offers Leap (stable) and Tumbleweed (rolling). SUSE Linux Enterprise provides long support spans (~13 years) for enterprise linux workloads.
| Family | Example | Release model | Support (typical) |
|---|---|---|---|
| Debian-based | Debian 13.3, Ubuntu, Mint | Fixed / LTS | 3–5 years (Ubuntu LTS), Debian stable cadence |
| Red Hat family | Fedora, RHEL 10.1, Rocky 10.1, Alma 10.1 | Short-cycle upstream + enterprise stable | Fedora ~1 year; RHEL ~12 years; Rocky/Alma ~10 years |
| Arch family | Arch, Manjaro, EndeavourOS | Rolling | Continuous (variable) |
| SUSE lineage | openSUSE Leap/Tumbleweed, SLE | Fixed or rolling | openSUSE ~1.5 years (Leap); SLE ~13 years |
- I map family ties so shared bases mean shared package formats, tools, and fixes.
- Pick a base to match your priorities: stability, fresh packages, or enterprise lifecycles.
Release Models and Update Philosophy That Shape Daily Stability
How a system updates determines whether I get surprises or smooth continuity. The release model you choose changes how the operating environment behaves week to week.
Fixed releases are calendar-based. I upgrade on milestones, so updates arrive after longer testing cycles. Ubuntu and Debian-style releases give fewer moving parts and fewer sudden breakages.
Rolling releases push packages continuously. I get the newest tools fast, but I accept more frequent changes and occasional manual fixes. Arch-style flows reward immediacy at the cost of extra vigilance.
Immutable and image-based systems treat the base OS as a sealed image. Updates apply in transactions and can be rolled back. Examples include snapper with Btrfs snapshots on openSUSE, rpm-ostree rollback on Fedora Atomic variants, and transactional-update on MicroOS-style systems.
In practice, rollback features are where modern stability comes from. If I hate surprises, I lean fixed or immutable. If I need the latest compiler or features, rolling or a fast fixed cadence wins.
- I choose release style to match my use: conservative for workstations, fast for developer machines.
- Update philosophy directly ties to how often I reboot and troubleshoot after changes.
Security Update Lifecycles and Long-Term Support Expectations
Support lifecycles drive maintenance decisions more than marketing copy. I choose a release based on how long it will receive fixes and whether that matches my risk tolerance.
Enterprise-length support: Red Hat Enterprise Linux (RHEL) delivers about 12 years of security updates. That long horizon exists because large organizations pay to avoid churn and keep stable systems.
RHEL alternatives: Rocky Linux and AlmaLinux offer close compatibility with RHEL and about 10 years of support. I rely on them for long-lived servers where a decade of maintenance matters.
| Release Type | Example | Typical support (years) |
|---|---|---|
| Enterprise | RHEL | ~12 years |
| RHEL-compatible | Rocky / Alma | ~10 years |
| Desktop LTS | Ubuntu LTS / Mint | ~5 years |
| Fast-cycle | Fedora / openSUSE stable | ~1–1.5 years |
I translate these numbers into plans: longer support means fewer forced upgrades for servers and simpler patch windows for workstations.
For developer machines I accept short cycles like Fedora to get newer toolchains. For production systems I prefer decade-class support from RHEL or its compatibles.
Bottom line: security updates are not optional—lifecycle length affects exposure. Match your choice to whether you want “set-and-forget” systems or always-current software.
Desktop Environments Comparison for Real-World Hardware
When I test a desktop I care less about branding and more about how it behaves on real hardware. That practical check shapes what I recommend for everyday users and for older machines.
GNOME is the default on many popular releases. In my experience it needs at least 4GB of RAM to avoid stutter under typical multitasking. GNOME gives a modern, streamlined environment but expects a bit more memory and a reasonable GPU to stay smooth.
Xfce is my go-to for older or budget systems. It runs well around 2GB of RAM and stays responsive on hand-me-down laptops. If battery life and simple graphics are priorities, Xfce keeps the system usable without extra tuning.
KDE Plasma sits between power and polish. It offers deep customization and a full feature set while remaining surprisingly light if tuned. I pick Plasma when I want a traditional desktop workflow and many UI options.
I avoid choosing solely by a distro’s default desktop. Many installers let you pick another environment, and spins/editions provide alternatives (for example, Fedora spins and openSUSE choices). Start with your hardware limits, then pick the family and the environment.
- Quick decision shortcut: match hardware first (RAM, GPU), then distro family, then desktop environment.
- Practical note: desktop choice affects battery life, graphics driver needs, and how updates feel day to day.
Installers and First Boot Experience: What I’d Recommend by Skill Level
A smooth first boot shapes whether a new installation feels like a success or a frustration.
Beginner-friendly: I prefer a graphical installer that offers clear defaults and a minimal set of decisions. A good gui asks about time zone, disk layout, and a user account, then leaves me at a working desktop after first boot.
What beginners should expect
Graphical installers like Subiquity, Anaconda, YaST, or Calamares reduce early mistakes. Sensible defaults for partitions, drivers, and networking keep new users from breaking the setup and losing confidence.
What experienced users get
Text-based or hands-on installs (for example archinstall-style flows) give control over partitioning, bootloader, and network. I use a command-driven path when I want a minimal, tuned system.
“Choose an installer based on how much troubleshooting you want to do after first boot.”
| Skill level | Installer style | What you get at first boot |
|---|---|---|
| Beginner | Graphical (GUI) | Working desktop, sane defaults, minimal commands |
| Intermediate | Guided text / hybrid | More control, some manual steps, predictable setup |
| Advanced | Hands-on / command | Custom partitions, manual drivers, full control |
- Tip: match the installer to how comfortable you are with the command line and troubleshooting.
- Note: installer popularity often links to better community help when you search for fixes.
Package Management and Software Availability Across Distros
Package tooling shapes how often I open a terminal and how confident I feel before a full-system upgrade.
I notice four native managers most: apt (Debian/Ubuntu), dnf (Fedora/RHEL), zypper (openSUSE), and pacman (Arch). Each has a feel: command syntax, metadata speed, and how often I must resolve conflicts.
How package managers differ day to day
Apt feels familiar and safe for many users. Dnf shows clear rollback and dependency messages. Zypper is fast at metadata refreshes. Pacman is minimal and very quick for upgrades.
Repos, universal formats, and AUR trade-offs
Repository depth beats marketing. If the packages I need aren’t present, I waste time building or trusting random sources.
Flatpak, Snap, and AppImage add compatibility across a range of systems. Snap is convenient on Ubuntu but can have slower app startup. AppImage often needs libfuse2. Flatpak balances sandboxing and distro-agnostic installs.
The AUR expands availability for Arch users. It speeds access but raises security and maintenance risk for production machines.
| Manager | Example base | Strength | Typical trade-off |
|---|---|---|---|
| apt | Debian/Ubuntu | Wide repo, stable | Conservative package versions |
| dnf | Fedora/RHEL | Clear updates, SELinux-aware | Faster churn |
| zypper | openSUSE | Fast metadata, snapshots | Smaller ecosystem |
| pacman | Arch | Lightweight, quick upgrades | Requires more user maintenance |
Hardware Compatibility, Drivers, and Secure Boot Reality
Real-world compatibility wins or loses before you ever open an app. If Wi‑Fi or graphics are flaky, nothing else matters. I start here because good hardware support makes the rest of the setup painless.
Where proprietary drivers matter most: Wi‑Fi chipsets and GPUs cause the most friction. On many modern machines these parts will either work out of the box or force extra driver installs and firmware blobs.
Secure Boot behavior and what to expect
Secure Boot works out of the box on Ubuntu, Fedora/RHEL-style systems, and openSUSE/SUSE Enterprise. Debian can require MOK enrollment and kernel signing, so many users disable Secure Boot during installation.
Old machines and 32-bit reality
True i686 support is rare now. If you maintain a legacy laptop, your distro choices narrow and you should test a Live USB first to confirm drivers and basic compatibility.
| Issue | Typical symptom | Distros that boot cleanly | What to test |
|---|---|---|---|
| Wi‑Fi chipset | No network after install | Ubuntu, Fedora, openSUSE (broad vendor firmware) | Live USB: scan and connect to Wi‑Fi |
| GPU drivers | Black screen or poor refresh | Ubuntu (proprietary packages), Fedora with RPM Fusion | Login, run video playback, check compositor |
| Secure Boot | Refuse to boot unsigned kernel | Ubuntu, Fedora, SLE (signed kernels) | Try boot with Secure Boot enabled; test installer path |
| Legacy 32‑bit | No ISO or unsupported installer | Specialist builds only | Verify i686 ISO or use very old releases |
Practical tip: Don’t assume a dual-boot from windows behaves the same across systems. I always validate with a Live USB before committing to a full installation. Filesystem snapshots (next) help undo bad kernel or driver updates later.
Default Filesystems, Snapshots, and Rollback Strategies
A good rollback strategy turns a risky update into a routine maintenance task. The default file layout and snapshot features change how painful a broken update feels.
I compare three common options I encounter: ext4, Btrfs, and XFS. ext4 is simple and stable for most desktops. Btrfs adds snapshot tooling that makes rollbacks easy. XFS scales well on servers and handles large data sets reliably.
Snapshot-based rollback for safer updates
Snapper with Btrfs gives point-in-time snapshots. I can revert a bad update in minutes without rebuilding the whole system.
rpm-ostree and transactional-update work similarly on immutable trees. They treat an update as a transaction you can boot back from if something breaks.
When rollback matters more than latest packages
- Choose rollback-first for production machines and work laptops.
- Pick ext4 when you want minimal admin overhead.
- Pick Btrfs if you want snapshots and safer updates without much downtime.
| Filesystem | Strength | When I pick it |
|---|---|---|
| ext4 | Simple, stable | Everyday desktop, quick installs |
| Btrfs | Snapshots, rollbacks | Workstations needing recoverability |
| XFS | High throughput | Large servers, heavy IO |
Bottom line: file defaults signal a distro’s priorities. If I need uptime and audit trails, I favor snapshot-enabled defaults. Rollback complements security features; it does not replace them.
Security Defaults: SELinux, AppArmor, Encryption, and Auditability
Good defaults decide how much security work lands on your desk after installation. I treat defaults as the baseline I get even if I never tweak a policy.
SELinux on Fedora/RHEL-style systems
SELinux ships enabled by default on Fedora and RHEL-style releases. That enforces strict access controls out of the box.
For servers and serious workstations this is ideal. Expect a learning curve: denials appear and must be diagnosed, but the system gains stronger containment.
AppArmor patterns on Debian/Ubuntu-style systems
AppArmor is the common pattern on Debian and Ubuntu families. It feels friendlier for desktop users who want protection with less policy plumbing.
AppArmor often uses profile templates that protect common services while keeping everyday troubleshooting simple.
Full-disk encryption: what I check during installation
I run a short checklist before committing to encryption at installation:
- Generate and securely store recovery keys or passphrases.
- Confirm disk layout implications for dual-boot and swap (hibernate needs a swap keyfile).
- Test boot with TPM/UEFI settings if using hardware-backed keys.
Auditability matters: logs, readable policy output, and prompt security updates make a system verifiable. “Secure by default” is a stack—defaults, patching, and monitoring together.
“Defaults protect you until habits and update discipline either strengthen or weaken that protection.”
| Default | Strength | Best for |
|---|---|---|
| SELinux enabled | High containment | Servers, hardened workstations |
| AppArmor profiles | Practical protection | Desktops, casual users |
| Installer FDE option | Data at rest protection | Mobile laptops, privacy-focused setups |
Bottom line: defaults are a tie-breaker when two releases otherwise match. I weigh those defaults alongside update habits and available tools before I recommend anything.
Head-to-Head Comparisons I Actually Use When Recommending Distros
My go-to comparisons are driven by who will use the machine and how they work. I run short, focused tests that show practical trade-offs for desktop and server use.
Ubuntu vs Linux Mint for first-time desktop users
Ubuntu wins on community size and LTS support: five years of updates and massive Q&A. Linux Mint follows the same LTS cadence but offers a gentler UI for migrating users.
Fedora vs Ubuntu for developers
Fedora gives fresher toolchains and SELinux by default. Ubuntu gives longer support windows and broader documentation. Pick by whether you need the latest compilers or steadier upkeep.
Arch vs Manjaro; openSUSE Tumbleweed vs Arch
Arch is pure rolling and manual; Manjaro stages updates for convenience. Tumbleweed adds automated testing and Btrfs snapshots for rollback—guardrails that matter if you prefer rolling with safety.
RHEL vs Rocky Linux vs AlmaLinux for enterprise-like servers
Red Hat offers ~12 years of support. Rocky and Alma aim for near-RHEL compatibility with ~10-year windows. For US servers I weigh lifecycle, vendor docs, and auditability.
- Documentation depth (Arch Wiki, Ubuntu forums) heavily affects my picks.
- I recommend based on fit, not a single “winner.”
Testing Without Commitment: Why Virtualization Fixes Most “Try Linux” Friction
Before I repartition a drive, I spin up a virtual machine and run a quick smoke test. That lets me explore a desktop and package manager without touching my primary windows install or risking data.
Virtual machine testing with VirtualBox: what it can and can’t validate
What it validates: installer flow, desktop feel, basic package installs, and how a system behaves under a default setup.
What it misses: real Wi‑Fi, some GPU quirks, and subtle power management problems tied to firmware. VirtualBox is great for ergonomics and early debugging but not for final hardware vetting.
Live USB testing: the fastest way to confirm real hardware compatibility
Live sessions run on actual hardware, so they reveal whether drivers and firmware play nice. If Wi‑Fi and display scaling work in a live session, the odds are high you’ll be fine after installation.
My quick validation checklist: networking, video playback, display scaling
- Connect to Wi‑Fi and test web pages (validates networking and drivers).
- Play a short video locally or stream to check GPU and audio.
- Try an external monitor and adjust resolution and scaling.
“Virtualization lowers the psychological barrier; a Live USB confirms the real risk.”
Workflow tip: test two or three releases back-to-back while your impressions are fresh. This process reduces regret and helps match a candidate to your intended use, lifecycle, and tools.
How I Match a Distro to Your Use Case in Minutes
The fastest way to pick a distro is to ask four focused questions. I run a short decision tree: what is the user’s comfort level, what hardware you have, which software or tool versions are required, and how long you need support.
Beginners who want a familiar desktop and strong community support
I prioritize a friendly desktop, a clean installer, and a large community so new users get help fast. Ubuntu or Linux Mint usually fit that brief because they minimize early friction.
Developers who need modern containers and current compilers
I weigh Fedora-like freshness against Ubuntu LTS stability. If you need current toolchains and container work, I pick a distro with newer packages or a rolling channel.
Security specialists who need purpose-built toolsets
For lab work I recommend a purpose-built image like Kali in a VM. For a daily driver I use a stable desktop and isolate testing in virtual machines for safer workflows.
Server admins optimizing for stability, lifecycle, and documentation
Server choices hinge on long lifecycle and clear docs. I favor enterprise-style releases for production systems to reduce upgrade windows and operational risk.
“Answer four quick questions and I can shortlist two or three distros to test.”
- Comfort level → hardware → required software → support window
- Result: a concise shortlist you can trial in a VM or Live USB
Conclusion
What matters most is how a release cadence fits your daily work and tolerance for change. Pick a release rhythm that matches the time you want to spend on maintenance.
Core takeaway: distros differ mainly by release philosophy, support lifecycles, package ecosystems, and security defaults. I judge each distribution on those objective criteria rather than hype.
I avoid long-term pain by testing first. I spin a VM for a quick feel, then use a Live USB to confirm drivers on the real system.
Remember that updates, release timing, and defaults shape stability more than any single feature. Match update frequency to your work, verify security and support windows, and you’ll reduce surprises.
Practical next step: shortlist two linux distributions from the head-to-heads, test both in a VM and on a Live USB, then pick the one that fits your workflow. Switching later is normal and low-risk when you use these testing steps.
FAQ
What actually slows down Windows over time, and how does virtualization help?
Over months I see clutter from installed apps, driver mismatches, registry bloat, and fragmented updates slow Windows. Virtualization isolates the guest OS so I can run a clean image every time, avoiding long-term degradation and making backups, snapshots, and rollbacks simple. That fixes performance drift without needing full reinstalls.
Why am I comparing Linux distributions in the US right now?
I compare options because developers, enterprises, and supercomputers show where each option excels. In the US market there’s strong demand for desktops, servers, and enterprise support. I focus on release cadence, security updates, package tools, and community so my recommendations match real-world use, hardware, and developer needs.
Where does this ecosystem dominate today?
I see dominance among cloud providers, research clusters, and developer workstations. Universities, data centers, and continuous-integration systems favor open environments for reproducibility and automation. For desktops, adoption varies by community, but the server and HPC spaces remain the strongest footholds.
What does distro choice actually change for day-to-day users?
It changes package management, default desktop environment, release and update policy, and the available tooling. I find that these differences affect daily workflows—how I install apps, get security updates, and tune the UI—more than the underlying kernel itself.
How do I define a fair comparison between options?
I use objective criteria: release model, support window, package management, security update lifecycle, hardware compatibility, and documentation. I also separate desktop, server, and security-focused editions so I compare like with like and avoid mixing unstable branches or different OS kernels.
Which families and forks should I pay attention to?
I track Debian-based lines like Debian, Ubuntu, Linux Mint, and elementary; the Red Hat family including Fedora, RHEL, Rocky Linux, and AlmaLinux; Arch and its derivatives such as Arch Linux and Manjaro; and SUSE variants like openSUSE Leap/Tumbleweed and SUSE Linux Enterprise.
How do release models affect stability?
Fixed releases give predictable upgrades and longer testing windows, which I prefer for production. Rolling releases deliver the newest software but require frequent updates and a tolerance for occasional breakage. Immutable or image-based systems change how I handle updates and rollback strategies.
What are realistic support expectations for security updates and LTS?
For enterprise, RHEL offers around 10–12 years of support; Rocky and AlmaLinux aim for long maintenance windows too. Desktop LTS versions like Ubuntu LTS provide about five years, and many desktop spins align with that cadence. Fedora and similar projects have shorter windows focused on fresh features.
How should I choose a desktop environment for my hardware?
I match GNOME to modern hardware where RAM use is acceptable, Xfce to older or low-RAM systems, and KDE Plasma when I want deep customization with a full-featured feel. I also consider whether the distro ships a default desktop or offers choices at install time.
Which installers and first-boot experiences do I recommend by skill level?
For beginners I pick graphical installers with sane defaults and clear partitioning options. For experienced users I prefer text-based or hands-on installers that let me control LVM, encryption, filesystems, and bootloader setup precisely.
How do package managers differ day to day?
apt, dnf, zypper, and pacman feel different in command syntax, dependency resolution, and repository tooling. The availability of packages and the quality of repos directly affect how quickly I can get work done. Universal formats like Flatpak, Snap, and AppImage help with cross-distro delivery but have trade-offs in sandboxing and disk use.
When do proprietary drivers and Secure Boot matter?
Proprietary GPU and Wi‑Fi drivers often matter most for gaming, multimedia, and certain laptops. Secure Boot is mostly a non-issue if the distro ships signed kernels; otherwise I sign kernels or disable Secure Boot. For older 32-bit machines I pick distros that still offer legacy support.
Which filesystems and rollback features should I prioritize?
ext4 is reliable for general use; Btrfs offers snapshots and rollback that I value for safer updates; XFS suits large storage and servers. When I need quick recovery from bad updates, I prefer snapshot-based rollback over chasing the latest packages.
What security defaults should I check at install time?
I look for SELinux in Fedora/RHEL-style systems or AppArmor in Debian/Ubuntu-style systems. I also enable full-disk encryption during installation when I need data protection and check available audit and logging tools for compliance and incident response.
Which head-to-head matchups do I use for recommendations?
For newcomers I compare Ubuntu vs Linux Mint. For developers needing newer toolchains I look at Fedora vs Ubuntu. For rolling-release control I weigh Arch vs Manjaro. For enterprise servers I compare RHEL vs Rocky Linux vs AlmaLinux. For rolling updates with guardrails I contrast openSUSE Tumbleweed and Arch.
How should I test options without committing to install?
I use virtual machines (VirtualBox, QEMU) for initial testing and Live USB sessions to validate real hardware. My quick checklist covers networking, video playback, display scaling, and peripheral support before I install on a disk.
How do I match a distro to a use case quickly?
I ask whether the user is a beginner wanting a familiar desktop and strong community support, a developer needing modern containers and compilers, a security specialist needing purpose-built toolsets, or a server admin focused on stability and lifecycle. That narrows the choices fast.
What additional tools and resources should I consult?
I rely on vendor docs from Red Hat and SUSE, community wikis like the Arch Wiki, and package trackers. I also check hardware compatibility lists, security advisories, and community forums to validate support, drivers, and updates before recommending a setup.