Do You Need Linux for ROS 2? Your Options on Windows and Mac

Yes, ROS 2 in practice needs Ubuntu Linux, but you can run that Linux inside Windows through WSL or inside a virtual machine on macOS. Almost every ROS 2 binary, driver and tutorial targets Ubuntu, so a non-Linux host means compiling from source on your own. That flips only when your robot never touches the ROS package set, which is where a single-machine layer such as HORUS lives. This post is for someone whose only computer runs Windows or macOS, who wants to start learning without wiping the machine they also work on.

You bought a kit, or you signed up for a course, and the first page of the instructions assumes something you do not have. It says to open a terminal and paste a line beginning with sudo. Your laptop is a MacBook, or a Windows machine your employer manages, and neither of those appears anywhere in the tutorial. You search, and the internet answers with four different routes, each written by someone certain the other three are wrong, and each one opening with a step that takes an hour. So you try whichever sounded easiest, get a wall of red text about a missing package, and lose the evening. The second evening goes to a virtual machine that boots to a black screen. By the third you are no longer learning robotics; you are learning package managers. What you wanted was a wheel that turns on command. The thing nobody says out loud in those tutorials is that this obstacle is real, it is not a sign you are bad at this, and there is a shortest path through it.

Do you need Linux to run ROS 2?

You need Linux, and you do not need to give it your whole computer. Every practical route ends with a Linux system somewhere, and the argument is only about where that Linux lives. On Windows, the Windows Subsystem for Linux gives you an Ubuntu that starts in a moment and can see your files, and it is the route most people should take. On a Mac, the honest answer is a virtual machine, a container, or a small Linux computer on your desk that you connect to over the network. There is a native Windows build of ROS 2, and there are recipes for macOS, and both carry you through the first hour before they stop matching what the tutorials say, because the packages you eventually want were built and tested by people running Ubuntu. What decides this is not loyalty to an operating system. It is that a beginner should be spending evenings on the robot, and any route where you are the first person to hit a given error is a route that spends them on the platform instead.

What does an operating system have to do with robot software?

The operating system decides which drivers already exist, which prebuilt packages install without a fight, and how precisely your program gets woken up when something needs doing on time. Robot software talks to hardware constantly — a camera, a motor controller, a joystick, a serial cable — and each of those conversations goes through a driver somebody wrote for a particular system. On Linux those drivers are usually already in the kernel, and the ones that are not are a package away. Timing is the other half. A control loop wants to run on a steady beat, and the operating system decides whether your loop gets the machine when the beat arrives or waits behind a browser update. Linux gives you controls over that; a desktop system tuned for word processing gives you fewer. Neither point is ideology, and neither means Linux is friendlier. Both mean the path of least resistance in robotics was worn into Ubuntu by a decade of people, and stepping off it costs you their work. A useful companion here is what actually runs on a robot besides your own code.

What goes wrong when people install ROS 2 straight onto Windows?

The install usually succeeds, and then the third tutorial fails. That pattern catches people out because the first hour goes well: a talker and a listener exchange messages, the demo works, and the platform looks fine. Then you reach for a package — a driver for the camera you own, a simulator, a tool for looking at what is flowing — and find it was never built for Windows, or was built once for a release two versions back. Now you are compiling from source on a platform the author never used, and the error you get returns nothing useful in a search, because the thousands of people who hit something like it were all on Ubuntu and their fix does not apply. The second failure is quieter. Paths, permissions and line endings differ, so scripts written by other people break in small ways that read like your own mistake. Beginners take this as evidence they are bad at robotics. They are not. They picked a road with almost nobody else on it, and that road is fine right up until the moment you need directions.

What are my actual options on a Windows laptop or a Mac?

There are six routes, and they differ in where the Linux lives rather than whether you need Linux at all. You can run Ubuntu inside Windows with WSL, run it in a virtual machine on either platform, run it in a container, install it beside your existing system as a dual boot, or keep it entirely on a small computer — a Raspberry Pi or something like it — that you log into from your laptop. The sixth is to build ROS 2 natively for Windows or macOS, which is supported and lonely. Sitting slightly outside that list is a different decision altogether: choosing a stack that does not lean on the Ubuntu package archive, such as HORUS, an open-source real-time middleware where Rust, Python and C++ share the same shared-memory ring buffers on one machine, which changes what you need from the ecosystem rather than where you run it. That route only makes sense if you were never going to use the ROS 2 catalogue, so treat it as a separate question rather than an easier answer to this one.

How do the ways of running ROS 2 without a Linux desktop compare?

Pick by which failure you would rather have, because every route trades away something different, and none of them is free.

Two rows at once is the normal answer, not a compromise: WSL or a virtual machine for learning, and a small Linux board for the robot itself.

What should I pick if I am a student starting my first robot?

Take WSL if your laptop runs Windows, take a virtual machine or a cheap Linux board if it is a Mac, and then stop researching. The way a first term goes wrong is not picking the second-best route; it is spending six weeks comparing routes while the robot sits on the bench. Once you have chosen, follow one tutorial series from beginning to end without mixing in advice from anywhere else, because most beginner failures come from stitching together instructions written for different releases. Pin the release you install and write down which one it was, since the pairing between a ROS 2 distribution and an Ubuntu version is strict and silently breaks things when ignored — the distro question is worth ten minutes up front. If your course or lab already standardises on something, use that instead of anything recommended here, including by this page. Matching the person who will help you when you are stuck is worth more than any property of the setup itself.

What should I pick if my robot is a Raspberry Pi or a Jetson?

Then the Linux question is already answered, because the board runs Linux and your laptop only has to reach it. This is the route most people arrive at eventually, and it removes the argument entirely: the software runs where it will actually live, on the operating system the packages were built for, and your Mac or Windows machine goes back to being an editor and a terminal. You edit either directly on the board over a network session or locally with your files synchronised across. Two cautions. Keep the release on the board and the release on any development machine matched, because a mismatch produces errors that look like your code and are not. And expect the network itself to become a topic: a graph spread across a laptop and a board over ordinary Wi-Fi behaves differently than one on a single machine, which is a well-known source of confusion. Heavy visualisation and simulation still belong on the desktop machine, talking to the board rather than running on it.

What should I pick if I need something working this month?

Choose the route with the shortest distance to a first success — WSL on Windows, a prebuilt virtual machine image or a Linux board on a Mac — and change nothing else until the deadline passes. A month is not enough time to learn a package manager, a build tool, a message model and a robot at once, so remove whichever of those you can afford to remove, and the platform is always the cheapest to remove. Do not dual boot under a deadline, because repartitioning a working machine is how a bad week becomes a bad month. Do not build anything from source. Do not update anything, including the parts that offer politely. Freeze the versions the day the first demo works and treat that combination as the deliverable alongside the robot. If a piece of hardware only has a driver for a release you are not on, decide immediately whether to change the hardware or change the release, and make that call in an afternoon rather than discovering it in week three.

What should I pick if I have barely used a terminal?

Pick the route with the fewest new ideas at once, which means WSL on Windows or a prebuilt virtual machine image on a Mac, and specifically not containers. Containers are a good tool and the wrong first tool, because they add a second mental model — images, layers, what survives a restart and what does not — on top of a shell you are still learning. Spend one deliberate afternoon on the terminal itself before touching robotics: moving between directories, what a path is, what permissions do, how the package manager installs and removes things, and how to read an error from the bottom up. That afternoon pays for itself within a week, and skipping it is why so many people conclude the framework is impossible when the shell was the actual obstacle. The broader version of this pattern is covered in the things that trip newcomers up, and almost none of them are robotics.

What do I give up by not running Linux directly on the machine?

You give up straightforward hardware access and honest timing, and while you are learning, neither one costs you much. Hardware access is the sharper edge: a USB camera, a serial adapter or a joystick plugged into your laptop has to be handed through to the guest system, and that handoff ranges from a checkbox to an evening depending on the route and the device. Graphics-heavy simulators are the other rough spot, since a guest system rarely gets the full use of the graphics card. Timing is the subtler loss. A control loop running inside a virtual machine on a laptop that is also running a browser and a chat client is not telling you anything trustworthy about the loop's behaviour on the robot. That matters less than it sounds, because the robot's own computer will run Linux directly and that is the machine whose timing counts. The rule to carry: use the laptop to learn and to write code, and use the robot's computer to decide anything about timing.

When is ROS 2 the better choice?

ROS 2 is the better choice whenever the ecosystem is the reason you are here, which describes almost every beginner asking this question. If you want a mobile base that maps a room and drives across it, the mapping and navigation already exist, they are tested, and rewriting them is a year of your life. If your course, lab, employer or teammate uses ROS 2, use ROS 2, because matching the people who will unstick you beats every technical argument on this page. If the sensor you bought ships one driver and that driver is a ROS 2 package, the decision was made for you at checkout. HORUS is not the answer in any of those cases, and the platform inconvenience of installing Linux is a small price next to rebuilding a catalogue by hand. The question of whether the framework is worth the learning curve at all is a separate one, answered honestly elsewhere, but if the answer for you is yes, then getting a Linux somewhere is simply part of the price.

Is ROS 2 on macOS good enough now?

No, and here is why. macOS appears on the supported list, but support is a spectrum rather than a switch, and macOS sits at the end where you build from source, resolve dependency conflicts yourself, and read release notes hoping for a mention. Prebuilt binaries are published for Ubuntu on a schedule; for macOS you assemble them. Then the packages you actually want — a driver, a simulator, a tool for inspecting messages — were written by people who never ran them on a Mac, and the assumptions they make about paths and libraries hold on Ubuntu and not on your machine. None of this is Apple being difficult. It is where maintenance effort goes, and it goes where the users are. The practical consequence is that a Mac is a fine machine for robotics and a poor host operating system for ROS 2, so the sensible arrangement keeps macOS as the place you write code and puts a Linux, virtual or physical, underneath the robot software.

Will running Linux in a virtual machine ruin my robot's timing?

Partly, but not the way you think. A virtual machine does add unpredictability between your program and the hardware, so a loop running inside one is a poor place to judge how steady that loop will be. The part people get wrong is assuming this matters for the robot. It does not, because you never ship the virtual machine — the robot has its own computer, running Linux directly, and that is the machine whose timing determines whether the arm stops before it hits the table. The real risk is quieter: drawing conclusions on the laptop and carrying them to the robot. A control loop that looks fine in a virtual machine can misbehave on the target, and one that stutters in a virtual machine may be perfectly steady on the board. Both surprises come from testing timing in the wrong place. Test timing on the target, always, and treat the laptop as a place to learn what the pieces do. The background on why loop timing matters is worth reading before you draw any conclusion from a laptop.

How do I decide which route to take this week?

Answer three questions and the route falls out of them. First: which operating system is on the laptop you already own? Windows means WSL unless something specific rules it out, and macOS means a virtual machine, a container, or a Linux board. Second: does the robot already have its own computer? If yes, put the software there and develop over the network, because that removes the entire platform argument in one move and puts your code where it will actually run. Third: does anything plug into your laptop by USB — a camera, a serial adapter, a controller? If yes, prefer the route with the least indirection between the device and the software, which pushes you towards a spare machine or the robot's own board rather than a virtual machine. That is the whole decision. Everything else is preference, and preference is not worth a week. If the three answers point in different directions, follow the second one, because where the code will run matters more than where you type it.

A short version, by situation:

• If you are on Windows and just starting out -> WSL, because it gives you a real Ubuntu without touching the machine you work on.
• If you are on a Mac -> a virtual machine or a small Linux board, because native macOS support means building what nobody else builds.
• If your robot already has a Linux computer -> develop on the board over the network, because the code then runs where it will live.
• If a course, lab or teammate has already standardised -> match them, because being unstuck quickly beats every property of the alternative.
• If you were never going to use the ROS package catalogue -> settle the middleware question first, because that answer changes what you need from the platform.

When you want to compare stacks rather than routes, the HORUS Fit Framework lines them up on five things that are not numbers: ecosystem size, setup effort, team size fit, deployment target, and licence. Here, setup effort and deployment target carry the weight: the laptop is where you learn, and the deployment target is what has to keep time.

HORUS is open source under Apache-2.0 and the repository is linked below. Star it so it is in your list when you start building.