Batocera Download 2026: 43.1 in 12 Steps, 30 Min

There is a specific kind of person who types batocera download into a search bar at 11 at night, and I have been that person more than once. You are not looking for a philosophy of emulation or a ranked list of the best handhelds of the year. You want the image, the checksum, the flash command, and the boot-menu key — in that order — and you would like to be playing something within the hour instead of reading a forum post from 2019 that cites a version number which no longer exists.

So here is the entire process, current as of Batocera 43.1 'Glasswing', which the project shipped on 30 May 2026. No affiliate links, no 'the seventh one will shock you' energy, no telling you to smash a subscribe button. Just the download, the verification you should not skip, the flash, the first boot, and the update commands that mean you never have to repeat most of this. Roughly a dozen steps, about thirty minutes, and a complete working configuration file at the end you can paste and forget about.

A note on who this is for. If you already run Batocera and only want the update command, skip to the updating section and read exactly two paragraphs. If you have never done this before, read straight through — the order of operations is the entire skill, and the mistakes all live in the seams between steps, not the steps themselves. Either way, I am assuming you own the games you intend to play. Batocera ships zero ROMs, links to zero ROMs, and neither will I; where those files come from is your problem and your responsibility.

43.1 Glasswing and the Download Page

The only version number that matters right now

Batocera's current stable release is 43.1, codenamed 'Glasswing'. The base 43 release landed on 8 May 2026; 43.1 followed on 30 May 2026 as a bug-fix pass. That three-week gap tells you something useful about the project's temperament: when a release ships broken, they do not make you wait an entire quarter for the correction. If you are reading this later and a 43.2 or a 44 has since appeared, the mechanics below do not change — only the digits in the filename do. The commands, the mirror structure, and the flashing procedure have been stable for years, which is precisely why a guide like this is worth writing against a moving target.

The reason to care about the exact number is that half the bad advice on the internet is bad because it is old. A guide written against Batocera 38 will tell you to do things by hand that the updater now does for you, and following it can leave you in a worse state than doing nothing. When you see a step that involves manually copying an .img over a running system, check the date on the page before you trust a word of it.

Where the download actually lives

There is exactly one address you should type: batocera.org/download. That page is the canonical entry point, and it hands you an architecture picker rather than a single universal file — Desktop PC (x86_64), Raspberry Pi 4 and 5, Steam Deck, and a long tail of ARM handhelds each get their own build. Everything else — the 'batocera_installer_v43_FINAL.exe' a stranger uploaded to a file host, the torrent with a suspiciously round seed count, the link in a video description — is either out of date, repackaged with something you did not ask for, or both. The project is free and the official download is fast; there is no reason to source it anywhere else.

One clarification, because the search term itself is ambiguous: 'batocera download' means downloading a disk image, not an installer you run inside Windows. There is no setup.exe that installs Batocera alongside your existing operating system like an application. Batocera is a complete operating system that boots from its own media. The file you download is written to a USB stick, SD card, or drive, and the computer boots into Batocera instead of Windows or macOS. If a page offers you a Windows installer for Batocera, close the tab — that is not how this works, and whatever that file is, it is not the project's.

Why a surgical point release exists

Point releases are not glamorous, which is precisely why they are trustworthy. Batocera 43.0 shipped with a nasty EmulationStation database bug in which some users watched consoles and entire collections vanish from the interface after a restart or a scraping run — the ROMs were still on disk, but the front end had lost track of them. 43.1 exists to correct that class of failure without a headline feature to distract from it. The project's public changelog on GitHub under batocera-linux/batocera.linux shows steady maintainer activity in the run-up — there is a visible commit from dmanlfc dated 2 September 2025, months before the 2026 releases — which is the boring, continuous kind of work that separates a distribution you can rely on from a hobby project that goes dark. Download the point release, not the base release, whenever a point release exists. It is the same software with fewer sharp edges. If you want the primary sources rather than my word for it, the two wiki pages worth bookmarking are the Installation Guide and Current and Previous Releases.

Prerequisites and Requirements

Hardware: the honest floor

Batocera will run on hardware that a lot of guides pretend is unusable, but there are real minimums, and they are about storage more than raw power. The wiki is explicit: 8 GB is the absolute minimum for v30 and up, 16 GB is the practical minimum because you cannot auto-download updates with only 8 GB of headroom, and 32 GB or more is recommended if you want the system to breathe. That number is for the OS drive itself — your ROM library lives on the same media (or a second drive) and scales with whatever you throw at it. A 512 GB SSD full of PlayStation 2 ISOs is a different conversation than a 16 GB card of Game Boy titles.

For the machine doing the emulating: a 64-bit CPU is mandatory — there is no 32-bit x86 build worth your time — and 2 GB of RAM is the realistic floor for the front end plus lighter cores. Anything from an old office mini-PC upward will run the 8- and 16-bit era flawlessly; the moment you want GameCube, Wii, PS2, or Switch, you are into 'your GPU and CPU matter a great deal' territory, and no distribution can rewrite physics for you. If you are weighing an x86 mini-PC against a dedicated Android handheld, our breakdown of the Retroid Pocket 5 versus 6 covers where mobile silicon lands on that curve, and it is a useful sanity check before you buy anything.

Software you need on the flashing machine

You need three things on the computer you are flashing from, none of which are Batocera itself:

• A decompressor that understands gzip. Most imagers read .img.gz directly now, so you may not need to touch this, but 7-Zip on Windows or the built-in gunzip on macOS and Linux is your fallback if an older tool refuses the compressed file.
• An imaging tool. The wiki points at balenaEtcher and the Raspberry Pi Imager, both cross-platform and both able to write a .img.gz without you decompressing it first. On Windows, Rufus is the faster option; on Linux and macOS, dd is the honest one. Whichever you pick, use a current release — old imagers mangle GPT partition tables and produce drives that flash cleanly and boot to nothing.
• Optionally, an SSH client for later. Windows 10 and 11 ship OpenSSH; macOS and Linux have it built in. You will want this for the update section, not the install, so do not go hunting for it yet.

The one BIOS setting everyone forgets

On any reasonably modern x86 PC, Batocera will refuse to boot until you disable Secure Boot in the firmware. This is the single most common 'it does not work' report, and it is a thirty-second fix in the BIOS. While you are in there, learn your boot-menu key — it is F10, F11, or F12 on the overwhelming majority of boards — because you will tap it at power-on to choose the Batocera drive instead of your internal OS. Write that key on a sticky note now; you will thank yourself in Step 9. None of this applies to a dedicated handheld with a device-specific build, which boots its flashed card directly, but every PC install lives or dies on these two firmware details.

Choosing the Right Build

Read the filename before you download it

Batocera's filenames are not decoration; they are a spec sheet. The desktop image looks like this, and every field earns its place:

batocera-x86_64-43.1-20260530.img.gz
         │       │    │
         │       │    └─ build date (YYYYMMDD) — here, 30 May 2026
         │       └────── version — 43.1
         └────────────── architecture — x86_64 (64-bit PC)

The date embedded in the file matches the release date, which is a small, reassuring consistency: 20260530 is 30 May 2026, exactly when 43.1 shipped. If you download something claiming to be 43.1 but the date stamp is from a year ago, you have the wrong file, full stop. Rename nothing — the imager does not care about the name, but you should, because it is the fastest way to confirm at a glance that you grabbed what you meant to grab.

x86_64, ARM, and the device-specific builds

Batocera does not ship one universal image. It ships an x86_64 build for PCs and Steam Deck, and then a fleet of device-tailored ARM builds for specific handhelds and single-board computers. The project's own installs manifest carries architecture-specific build names dated 2026-06-04 — the Anbernic RG40XX V is on that list alongside a long roster of other targets. The point is blunt: there is, usually, a build made for your exact device, and you should use it rather than trying to force a generic image onto hardware it was not compiled for. This is the opposite philosophy from a project like RetroPie, whose PC image has sat frozen at v4.8 for years — Batocera's willingness to maintain dozens of live device targets is exactly why it has eaten so much of the handheld-distro market.

Do not grab the wrong architecture

The most expensive mistake in this whole guide costs you nothing but time: flashing an x86_64 image to an SD card destined for an ARM handheld, or vice versa. It will flash fine. It will not boot, and the failure is silent — a black screen, no error, nothing to search for. Match the architecture in the filename to the device in your hand before you click download. If you are on a PC, you want x86_64. If you are on a Raspberry Pi or a named handheld, you want that device's build, full stop. When in doubt, the Installation Guide lists which image maps to which hardware, and it is the arbiter, not a forum thread.

The Install: 12 Steps

The full sequence, with the reasoning for each move

Here is the whole thing end to end. It genuinely takes about thirty minutes if you go in order and do not improvise. Each step says why, because a step you understand is a step you can debug.

1. Go to batocera.org/download and select your device. Why: this is the only trustworthy source, and the picker guarantees you land on the right architecture instead of guessing.
2. Download the correct .img.gz. For a PC that is batocera-x86_64-43.1-20260530.img.gz. Why: the compressed image is what every modern imager expects; you do not need to unzip it first.
3. Grab the checksum next to it. Why: a download can corrupt silently, and a bad flash from a bad file wastes an hour you will not get back. Thirty seconds now saves that hour, and the full method is in the next section.
4. Insert your target media — a USB stick, SD card, or an SSD on a SATA/M.2-to-USB cable. Why: Batocera runs happily from a decent USB 3.0 drive; a cheap, slow card is the number-one cause of a system that 'feels sluggish' for no obvious reason.
5. Open your imager (balenaEtcher, Rufus, or Raspberry Pi Imager). Why: these tools write raw images and handle the gzip transparently; dragging files in a file manager does not create a bootable disk.
6. Select the image, then triple-check the target drive. Why: an imager will happily overwrite the wrong disk. Confirm the size and letter or label match the media you just inserted, not your 2 TB library drive.
7. Write the image and wait for verification. Why: the verify pass the tool runs after writing catches a bad flash before you ever boot it, which is a different and earlier safety net than the checksum in Step 3.
8. Move the media to the target machine. Why: obvious, but people forget and then wonder why their laptop is booting Batocera. Put the drive where it belongs.
9. Power on and tap your boot-menu key (F10, F11, or F12), then choose the Batocera drive. Why: without this, the machine boots its internal OS and you conclude, wrongly, that the flash failed.
10. Let the first boot expand the filesystem. Why: Batocera grows its user partition to fill the drive on first launch; interrupting this is how you end up with a 4 GB usable partition on a 256 GB SSD.
11. Set language, then connect a controller and your network. Why: the network unlocks scraping and updates; the controller mapping is what makes the front end usable without a keyboard.
12. Add ROMs over the network share and refresh the game list. Why: Batocera exposes a share folder over your LAN; dropping ROMs into the right per-system subfolder and refreshing is faster and cleaner than re-flashing anything.

Flashing on Linux and macOS with dd

If you would rather not install an imager, dd is built in. It is also the sharpest tool in the drawer — it does exactly what you tell it, including erasing the wrong disk without a confirmation prompt. Identify your target device first (lsblk on Linux, diskutil list on macOS), then:

# Linux — target is /dev/sdX (NOT a partition like /dev/sdX1)
gunzip -c batocera-x86_64-43.1-20260530.img.gz | sudo dd of=/dev/sdX bs=4M status=progress conv=fsync
sync

# macOS — unmount first, use the raw device /dev/rdiskN for speed
diskutil unmountDisk /dev/diskN
gunzip -c batocera-x86_64-43.1-20260530.img.gz | sudo dd of=/dev/rdiskN bs=4m

The gunzip -c ... | dd pattern decompresses on the fly so you never store the expanded image. Get the of= target wrong and you will overwrite something you care about — there is no undo, which is exactly why balenaEtcher exists for everyone who does not want to live this way.

What 'done' looks like

A successful flash ends with your imager reporting a completed write and a passed verification. On first boot you should see a text console scroll briefly, a one-time filesystem-expansion message, and then the EmulationStation front end with its default theme and a Batocera system menu. If you see a blinking cursor and nothing else for more than a minute or two, that is not first-boot expansion — that is the wrong architecture or an undisabled Secure Boot, and you should jump straight to the troubleshooting table rather than power-cycling in hope.

Verifying Your Download

Why you verify, even though you are impatient

A checksum is a fingerprint. The project publishes the expected hash of the image; you compute the hash of the file you actually downloaded; if they match, your copy is bit-for-bit identical to what they released. If they do not match, something changed in transit — a truncated download, a flaky drive, a corrupted mirror — and flashing it will fail in ways that look like hardware problems and send you down an hour of false leads. This is the cheapest insurance in the entire process, and skipping it is the most common reason a 'known-good' USB stick behaves like a haunted one. Do it once, learn the muscle memory, and never wonder again whether the file or the flash was at fault.

Verifying on Linux and macOS

Both platforms ship a SHA-256 tool. Run it against the file you downloaded and compare the output to the published hash:

# Linux
sha256sum batocera-x86_64-43.1-20260530.img.gz

# macOS
shasum -a 256 batocera-x86_64-43.1-20260530.img.gz

Expected output is a single long hex string followed by the filename, like this:

4f3c9a1e7b2d... (64 hex characters) ...a80  batocera-x86_64-43.1-20260530.img.gz

Compare that 64-character string to the one on the download page. They match or they do not; there is no 'close enough'. If they differ by a single character, delete the file and download it again, ideally from a wired connection rather than flaky Wi-Fi.

Verifying on Windows

Windows has had a built-in hasher for years — no download required:

CertUtil -hashfile batocera-x86_64-43.1-20260530.img.gz SHA256

It prints the hash on its own line between two status messages. If you prefer a GUI, 7-Zip can compute a CRC or SHA from the right-click menu, and its archive-test function (CRC SHA > Test archive) will also tell you whether the gzip itself is intact before you ever try to flash it. Either way, the rule is the same: match the string, or start over. A verified download that still fails to boot is a firmware or architecture problem, not a file problem — and knowing which is which is the entire value of this step.

First Boot

Expansion and the first EmulationStation launch

The first boot is the slowest one you will ever have, and that is by design. Batocera writes a compact image, then expands its user partition to fill the drive the first time it starts. On a large SSD this can take a minute or two of apparent inactivity; do not power-cycle it. When the front end appears, you are looking at EmulationStation with Batocera's default theme, and — this is the headline selling point — more than 200 game systems are already configured out of the box. You do not install emulators. They are there. You add games. That single fact is why the thirty-minute estimate is realistic rather than optimistic: the hard part, wiring up dozens of emulators and their defaults, was done for you before you ever downloaded the image.

Controllers, network, and the ROM share

Plug in a controller and Batocera will detect most of them automatically; if it does not, hold a button to enter the mapping wizard and assign the face buttons once. Next, connect networking — Ethernet is plug-and-forget, Wi-Fi is a menu. The network matters more than it looks: it enables the scraper that pulls box art and metadata, it enables updates, and it exposes the share folder over your LAN so you can copy ROMs from your main computer without touching the card again. Drop each system's games into its matching subfolder — share/roms/snes, share/roms/genesis, and so on — then refresh the game list from the menu. Under the hood those systems are largely RetroArch cores; if you want to understand what is doing the emulating and how to tune it, our walkthrough of loading 200+ RetroArch cores maps directly onto what Batocera bundles, because it is the same libretro machinery underneath.

The thirty-minute reality check

Thirty minutes is an honest estimate for going from 'downloading' to 'playing', and it holds only if you do the steps in order. It does not include scraping metadata for ten thousand ROMs — that runs in the background for as long as it needs — nor tuning shaders, nor chasing per-game overrides for a demanding system. Those are the fun, bottomless parts you do afterward. The install is finished when the front end boots, a controller works, and one game launches. Everything past that is decoration, and decoration is not the same as a working system — a distinction a lot of setup guides deliberately blur to pad their runtime and their ad breaks.

Updating Over SSH

batocera-check-updates and the built-in updater

Once Batocera is running, you rarely re-flash. The system knows how to update itself. From the menu there is an updater, and from a terminal — or over SSH — there are two commands worth memorizing. The first checks what is available:

batocera-check-updates

It reports the version you are on and whether a newer one exists on the mirror, something like:

Current version: 43.1
A new version is available: 43.2
Run 'batocera-upgrade' to update.

If it tells you that you are current, you are done — close the terminal and go play something. If it names a newer build, the second command does the work, and it is where the real convenience lives.

batocera-upgrade over SSH: the 5.23-and-up method

Since Batocera 5.23, the officially recommended way to upgrade — or downgrade — is batocera-upgrade run over SSH, not manually swapping files on the boot partition. This matters: manual file replacement was the old way, and it is exactly the kind of stale advice that breaks modern installs. The command preserves your data — ROMs, saves, scraped metadata, and configuration all survive an upgrade untouched. Enable SSH in Batocera's system settings, then from your desktop:

# default credentials: user 'root', password 'linux'
ssh root@batocera        # or ssh root@<the box's IP>

# once connected:
batocera-upgrade

You will see it fetch and apply the update, after which a reboot brings you up on the new version with everything exactly where you left it. The manual upgrades and downgrades wiki page is the authority here, and it says the same thing in more words: since 5.23, let the tool do it over SSH.

Pinning a specific build with a URL

Sometimes you want a particular build — to downgrade after a regression, or to jump to a beta. batocera-upgrade accepts a build-folder URL as an argument, and it will install exactly what that folder contains:

# upgrade to the latest x86_64 stable, explicitly
batocera-upgrade https://batocera.org/upgrades/x86_64/stable/last

# older versions are archived under the mirror's archives folder
batocera-upgrade https://batocera.org/upgrades/x86_64/stable/last/archives/

Two warnings. First, the URL is architecture-specific — the x86_64 path above will do nothing useful on a Raspberry Pi, where you must adapt the URL to the Pi's build folder. Second, the mirror keeps older-version archives under /stable/last/archives/, which is the officially sanctioned way to install a build that is no longer the newest — handy if you are documenting a retro workflow or need to reproduce a specific version for compatibility. Downgrading, like upgrading, leaves your ROMs and saves alone, so experimenting here is low-risk as long as you back up first.

Five Common Pitfalls

Flashing and boot pitfalls

Pitfall 1 — Wrong architecture, silent failure. Flashing an x86_64 image to an ARM handheld, or the reverse, writes cleanly and then boots to a black screen with no error. The fix is upstream of the symptom: match the architecture in the filename to your device before downloading. If you are already staring at a black screen, re-flash the correct build; nothing else will help.

Pitfall 2 — Secure Boot left on. A modern PC with Secure Boot enabled will not boot Batocera and gives you no useful message about why. Disable Secure Boot in the BIOS or UEFI settings. This is the single most common install failure on desktop hardware, and it is a one-toggle fix that people spend hours not finding because the failure mode is a silent black screen.

Update and version pitfalls

Pitfall 3 — Following a guide older than your Batocera. Instructions that tell you to hand-copy an .img onto a running system predate the modern updater and can leave you in a half-upgraded state that boots badly. Since 5.23 the answer is batocera-upgrade over SSH. If a step feels like surgery, check the page's date before you perform it.

Pitfall 4 — Installing the base release when a point release exists. People grab '43' because it is the round number and inherit bugs that '43.1' already fixed — the disappearing-collections issue being the obvious example. Always take the highest point release available for your major version. The round number is a trap, not a feature.

Storage and ROM pitfalls

Pitfall 5 — Undersized or slow media. Sixteen gigabytes is the practical floor, not because the OS needs it all but because you cannot auto-update with only 8 GB of room, and a slow SD card makes the whole front end feel broken when the real problem is throughput. Use 32 GB or more on a decent USB 3.0 drive or SSD. And a bonus sixth pitfall: expecting a small card to hold a big library. Batocera does not magically compress a PS2 collection — the ROM-count math we ran for the Miyoo Mini Plus and its 6,041 games applies here too. Storage is storage, and no distribution repeals arithmetic.

Troubleshooting Table

Symptoms, causes, and the actual fix

Most Batocera problems fall into a dozen buckets. Find your symptom, apply the fix, and resist the urge to re-flash before you have ruled out the cheap explanations — most of them cost you thirty seconds, and a reinstall costs you thirty minutes.

The re-flash of last resort

Re-flashing fixes almost everything, which is exactly why it is a trap: it is slow, it is boring, and it hides the actual cause so you learn nothing and repeat the mistake on the next machine. Exhaust the table first. Ninety percent of 'I had to reinstall' stories are a Secure Boot toggle, a wrong-architecture image, or a checksum that never matched in the first place — none of which a reinstall of the same bad file will solve. When you genuinely have exhausted the cheap fixes, re-flash from a freshly verified download, not the file already sitting on your drive. If a clean flash of a verified image still fails on hardware the wiki lists as supported, that is the point at which a bug report on the project's GitHub is warranted — with your device, your build date, and what you have already ruled out.

Advanced Tips

Mirrors and the archives folder

The whole update system is just structured folders on a mirror, and once you see that, a lot becomes possible. The latest stable for a given architecture lives at a predictable path — https://batocera.org/upgrades/x86_64/stable/last for desktops — and every older build is retained under that path's archives/ subfolder. That is officially supported, not a hack: the project keeps old versions specifically so you can install or reproduce them. If you maintain multiple machines, you can point batocera-upgrade [url] at the exact same build folder on each one and guarantee they are byte-identical, which is far more reliable than eyeballing version numbers across three living-room boxes and hoping.

The store and the pacman package manager

Since Batocera 5.27 the project has shipped an in-system store, and under the hood it uses the pacman package manager to add and remove packages. This is the mechanism for pulling in extra content and components without re-flashing or hand-compiling anything. You will not often need to drop to the command line for it — the store is menu-driven — but knowing that pacman is doing the work explains the behavior when something needs installing or cleaning up:

# the store is normally menu-driven, but pacman is underneath it
pacman -Q            # list what's installed
pacman -Sy           # refresh package lists
# removal and cleanup of unused packages follow standard pacman verbs

Treat this as a power feature, not a daily one. For the vast majority of setups you will touch the store through the interface and never think about pacman again — but when a forum answer mentions it, now you know what it is talking about.

SSH, backups, and knowing the alternatives

Enable SSH and you unlock the honest way to manage Batocera: batocera-check-updates and batocera-upgrade from your desk, config edits in a real editor, and clean backups of your share folder before you experiment. Back up before every major-version jump — upgrades preserve data, but you are the one responsible for the copy that exists when they do not. And keep perspective on what Batocera is for: it is a software distribution running emulators on general-purpose silicon. If your goal is cycle-accurate hardware behavior rather than convenience, that is a different tool entirely — the kind of thing we get into with the FPGA-based MiSTer Multisystem 2. Batocera's strength is breadth and speed of setup; play to it instead of asking it to be something it is not.

Complete Working Config

The batocera.conf you can paste and forget

Batocera's global settings live in a single flat file, /userdata/system/batocera.conf, editable over SSH or from the network share. Below is a sane, opinionated baseline for an x86_64 install on 43.1: Wi-Fi on, SSH on, sensible retro-friendly defaults, and RetroArch-based cores doing the heavy lifting. Adjust the Wi-Fi lines for your network, or delete them entirely if you are on Ethernet.

# /userdata/system/batocera.conf  —  Batocera 43.1 'Glasswing', x86_64
# ---- Networking ----
wifi.enabled=1
wifi.ssid=YOUR_NETWORK_NAME
wifi.key=YOUR_WIFI_PASSWORD
system.hostname=batocera

# ---- Remote access (needed for batocera-upgrade over SSH) ----
system.ssh.enabled=1
system.samba.enabled=1          # exposes the smb://batocera/share network folder

# ---- Front end ----
system.language=en_US
system.kblayout=us
audio.volume=90

# ---- Global emulator defaults (per-system overrides win over these) ----
global.videomode=default
global.smooth=1                 # bilinear smoothing on; set 0 for sharp pixels
global.shaderset=none           # set to 'scanlines' or a CRT preset to taste
global.ratio=auto
global.rewind=0                 # enable per-system; rewind costs performance
global.autosave=0
global.retroachievements=0      # set to 1 and add your login in the menu to enable

# ---- RetroArch / libretro cores are the default backend ----
snes.core=snes9x
nes.core=fceumm
genesis.core=genesisplusgx
gb.core=gambatte
gba.core=mgba
psx.core=swanstation
n64.core=mupen64plus-next
# demanding systems (ps2, gamecube, switch) depend on your GPU/CPU, not this file

That file, combined with a correctly flashed 43.1 image and a folder of legally-obtained ROMs under share/roms/, is a complete, working Batocera install. If you want to understand or override what each of those cores is doing, the libretro and RetroArch documentation is the canonical reference, and it maps one-to-one onto the core names above.

Where to go from here

You now have the whole loop: download from batocera.org/download, verify the checksum, flash with an imager or dd, boot with Secure Boot off, and maintain it forever with batocera-upgrade over SSH instead of ever re-flashing. The version will keep moving — 43.1 today, something higher tomorrow — but the machinery does not. Learn it once. The thirty minutes you spend doing this correctly is the last thirty minutes you have to think about installation; everything after is just games, which was the point the whole time.