# Giving SteamOS its own place in Bourbon

> A separate guest lifecycle and tighter launch observation.

Canonical page: https://pyrosoft.pro/blog/giving-steamos-its-own-place-in-bourbon

Live development journal; no publication date.
Work period: 2026-10-09 to 2026-10-12
Updated: 2026-10-20

Bourbon's normal Windows translation route and its SteamOS experiment solve different problems. Wine translates Windows software on the Mac. SteamOS Beta runs a separate Linux guest, with its own disk, sign-in and installations. The October 9 work gave that guest experience a clearer place in the app.

The new SteamOS integration replaced the older Linux presentation and kept guest lifecycle handling isolated. Diagnostics became bounded, and a suspended session received a clearer state. That helps when the question is simply whether the guest is paused, still preparing or actually stopped.

Pointer work followed over the next couple of days. Fullscreen geometry changes needed tracking to reset correctly, and held mouse drags needed to survive click anchoring. Those sound like small input details until you're trying to use a desktop or game and the pointer no longer matches what your hand is doing.

The main Windows route was getting stricter at the same time. Orphan Wine clients stayed classified as busy, renderer changes required recovery snapshots, and native Steam launchers were preserved. Later October 12 fixes stopped stale renderer logs from certifying a new launch and improved cold-start observation.

What this means is that Bourbon was doing more work to connect a result to the session that produced it. A log from an earlier run shouldn't make today's attempt look successful. A guest state shouldn't be inferred from a window that happens to exist.

SteamOS remained a beta route, and the optional desktop guests retained their own gates. I like having these options available, but they need clear boundaries so choosing one doesn't unexpectedly change the Windows stack or a native Mac Steam installation.