You're the OS: a Pygame game where you schedule processes instead of shooting aliens
A game where you are a computer's OS and you have to manage processes, memory and I/O events.
At a glance
- What is it?
- A Python and Pygame game that turns the operating system scheduler into the thing you play, with a desktop build, a WebAssembly build, and a scripting API for automated runs.
- Who is it for?
- Adopt You're the OS if you want a small, readable Pygame project that models scheduling and memory pressure as gameplay, or if you want a scripting surface for automated runs. Skip it if you need a general purpose operating system simulator with configurable hardware, or if you cannot pin Python 3.14.
- Can I use it commercially?
- Yes, with conditions. GPL-3.0 is a copyleft licence: if you distribute software that includes it, you must release that software's source code under the same licence. Running it internally without distributing it does not trigger that obligation.
- Is it still maintained?
- Yes. The repository last received commits 8 days ago.
- What is it written in?
- Mainly Python, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 24, 2026, and from our analysis. They are not legal advice.
Editorial analysis
What You're the OS asks you to manage
The README states the premise directly: you are the operating system of a computer, and you have to manage processes, memory and I/O events. The failure condition is stated just as plainly. Leave processes idling for too long and the user gets impatient and reboots you. That is the whole loop, and it is narrower than the name suggests. This is not a tool for learning how real kernels are written, and it is not a system emulator. It is a game whose resource model happens to be the one an OS scheduler deals with.
The audience follows from that. If you teach an operating systems course and want a five minute demonstration of why a process cannot sit in the ready queue forever, the game gives you that without a lab setup. If you write Python and want to read a complete Pygame project with a clean entry point split, the repository is small enough to read in an evening. If you want to build your own kernel, this is the wrong tool, and the README does not claim otherwise.
How the process, memory and I/O model is wired
The repository layout tells you most of the architecture. The top level holds four launcher scripts: run-desktop.py, run-web.py, run-sandbox.py and run-auto.py. Each one is a thin entry point, and the game itself lives under src/. That separation matters because the desktop and web builds share the same game code and differ in how they are started. The web build is the Pygame project compiled to WebAssembly, which is why webassembly appears in the repository topics alongside pygame.
The automation layer sits in automation/, with a skeleton file the README points to for writing your own script. A second entry point, run-auto.py, takes a script path plus arguments and exposes its own help output. So the game exposes a programmatic surface rather than only a window and a keyboard. The README attributes the original implementation of that automation support to a contributor, which suggests it was added after the initial game rather than designed in from the start. That is a reasonable guess from the file layout, not something the README confirms.
Sandbox mode is the other non-interactive path, and it is explicitly labelled as a development feature. You supply a configuration file describing a custom stage, and the game skips the menu and runs it. The README recommends keeping that file in src/sandbox because files added there are ignored by Git. That is a small detail with a real consequence: your stage definitions will not show up as untracked files in git status.
Installing You're the OS and running a first stage
The README lists three prerequisites: Python 3.14, pipenv, and an empty .venv directory at the project root. It also warns that the project is not guaranteed to work with other Python versions, so treat the version pin as a constraint rather than a suggestion. If your system Python is older, the README points at pyenv as a way to install the required version without changing your global interpreter.
Start by cloning the repository and checking out a release tag. The README is explicit that the main branch can be unstable and that you should use a release tag for a stable version.
pipenv sync --devThat command installs the dependencies from the Pipfile, including the development group. Once it finishes, launch the desktop build:
pipenv run desktopYou should see the game window open on the menu screen. The README does not describe the menu contents, so what appears after that is not documented here.
For a custom stage without going through the menu, sandbox mode is the faster path. Copy the example configuration from src/sandbox/sample.py, edit it, and run it by module path relative to src:
pipenv run sandbox sandbox.sampleIf your file is src/sandbox/myConfig.py, the module path becomes sandbox.myConfig. The README states that sandbox mode is provided for development purposes, so expect it to be a developer surface rather than a polished feature.
The web build has its own commands. To build without launching, and to produce the itch.io archive:
pipenv run web build
pipenv run web archiveThe archive command creates web.zip. Before opening a pull request, the README asks that you run the linter and the unit tests:
pipenv run pylint
pipenv run pytestThe automation API and its screen warning
The desktop version exposes an API for implementing automated scripts, and the README ships an example. The invocation takes a script path and optional arguments, and the command has its own help flag:
pipenv run auto <script.py> [args]The README carries a warning attached to this feature: running automation scripts, including the provided example, may cause rapidly changing colors on the screen. That is worth taking literally. If you are photosensitive, or if you plan to run scripts on a shared display or in a recorded session, the example script itself is flagged as a trigger. The README does not offer a headless mode or a way to suppress rendering, so the automation path still draws to a window.
Writing your own script starts from automation/skeleton.py. The README says that file contains the information you need, and it does not reproduce the interface in the README itself. That is a documentation gap worth noting: the API surface is discoverable only by reading the source. If you are evaluating the project for an automated grading or demo pipeline, budget time to read skeleton.py before you commit.
Where You're the OS is the wrong choice
The Python 3.14 requirement is the first real constraint. The README states the project is not guaranteed to work with other versions, which means a machine stuck on an older interpreter, a managed CI image, or a distribution package will not simply work. pyenv is offered as the workaround, and that adds a toolchain step before you have run anything.
The second constraint is scope. Managing processes, memory and I/O in a game is not the same as configuring a kernel. There is no hardware model to vary, no filesystem to inspect, no syscall tracing. If your goal is to understand how a real scheduler behaves under a specific workload, the game gives you a stylised version of that pressure, not measurements. The README makes no claim about realistic scheduling behaviour, and none should be assumed.
The third is the contribution policy. The README states that pull requests addressing open issues labelled bug or help wanted are welcome, and that any other pull request is likely to be closed. Ideas for improvements are directed to the Discussions tab instead. If you were planning to fork-and-PR a feature, read that sentence first. The project still welcomes changes, but through a narrower gate than most repositories, and the README also asks that AI-assisted contributions follow the instructions in AGENTS.md.
You're the OS against a full OS simulator
The obvious alternative category is an operating system simulator: software that models a machine, a scheduler and the interactions between them, usually with configurable policies and observable metrics. You're the OS takes the opposite approach. It compresses the OS into a game with a win and lose condition, and it renders that condition as user impatience rather than as a queue statistic. The trade is legibility for fidelity. A simulator lets you compare two scheduling policies under the same workload and read the numbers. The game lets a newcomer feel the cost of a starved process in about a minute, and gives you no numbers at all.
That difference also shows up in how you extend each one. A simulator typically exposes configuration and instrumentation so you can script experiments. You're the OS exposes sandbox stage files and an automation script API, which is scripting for play, not for measurement. If your evaluation criteria include reproducible results across runs, the game does not offer them, and the README does not claim it does.
Licence, upgrade cost and what to verify
The project is GPL-3.0, copyright Pier-Luc Brault, 2023-present. The README includes the standard GPL grant and the warranty disclaimer. If you embed the game in something you distribute, the copyleft terms apply to the combined work, and that is a decision for you and, if the stakes are high, a lawyer. Nothing here is legal advice.
The assets are licensed separately and are worth checking before any redistribution. The game icon is a modified image under Creative Commons Attribution 3.0. The emojis come from OpenMoji under CC BY-SA 4.0. The Game Over screen image is CC0. Two fonts, VT323 and Victor Mono, are under the Open Font License. So the repository is not a single-licence bundle, and the attribution requirements differ per asset.
Upgrade cost is low but not zero. The last push was on 2026-09-23, and the most recent release listed is v1.11.1 from 2026-07-03. Releases are infrequent, roughly a few per year based on the three listed. Because the README warns that main can be unstable, pinning to a release tag is the low-risk path, and a pinned tag plus a locked Pipfile means upgrades are deliberate rather than automatic. The unit tests and the linter give you a way to check a candidate upgrade before adopting it. What the README does not document is a rollback procedure or a migration path between versions, so if an upgrade breaks your sandbox configuration, you are on your own to diff it.
Editorial conclusion
Adopt You're the OS if you want a small, readable Pygame project that models scheduling and memory pressure as gameplay, or if you want a scripting surface for automated runs. Skip it if you need a general purpose operating system simulator with configurable hardware, or if you cannot pin Python 3.14. Before cloning, check the release tag you intend to build, confirm your Python version matches the README, and read the warning about automation scripts causing rapidly changing colors on screen.
Frequently asked questions
What does "OS" stand for in You're the OS?
Operating system. The README states the premise as being the operating system of a computer, managing processes, memory and I/O events.
What does OS mean in the context of a game like You're the OS?
In this game it is not a menu overlay or a settings screen. The README frames the player as the operating system itself, responsible for processes, memory and I/O, with a reboot as the failure state if processes idle too long.
What is an OS in simple terms, as You're the OS presents it?
The game reduces it to a manager of running processes, memory and I/O events. That is the whole model the README describes, and it does not go into kernel internals beyond those three concerns.
Official sources
Add this badge to your README
If you maintain this project, the badge below links readers to this analysis and shows its maintenance status from the daily GitHub snapshot. Paste the markdown into your README; add ?metric=license or ?metric=stars to the image URL for a different field.
[](https://hysenlabs.com/projects/plbrault-youre-the-os)