 Hello everyone. Welcome to my presentation on Gamer OS, an arch-linux-based distro that is focused on gaming in the living room. My name is Alish, and I am the main contributor and founder of Gamer OS. My goal with this presentation is to show you the journey that I went on that ultimately resulted in the creation of Gamer OS. I also wanted to explain some of the concepts and ideas behind Gamer OS, why I think it is unique, and why it works the way that it does. I want to take this opportunity to thank everyone that works on Arch Linux, because without you, Gamer OS would not be possible. Finally, I wanted to thank the ArchConf organizers for giving me this opportunity to talk about Gamer OS. Before we get into it though, I just wanted to give a quick overview of what Gamer OS is. It is basically a free operating system that you can download and install on your x86 computer, and it essentially turns your computer into a gaming console. We accomplish this by leveraging Steam Big Picture mode, which we launch automatically at startup. In that sense, Gamer OS is very similar to Steam OS, but we dial it up to 11 in terms of out-of-the-box support for software and hardware. Gamer OS itself is open source to the extent possible, but obviously the biggest piece, the Steam client, is proprietary software, and we can't change that. Just for some additional context, I want to play a demo of Gamer OS for you now. So here is Gamer OS. It's essentially just Big Picture mode that we start up immediately. You have the store where you can make purchases. You have your games library where you can select and play the games you've purchased from Steam. So what exactly is the problem that Gamer OS is trying to solve? For myself, I really enjoy video games, especially on the couch in front of the TV. There's nothing quite like playing a fun local multiplayer game with friends or family. I really like retro games, and I am a bit of a collector, but I don't want to wear out the physical games, and I want to preserve them as much as possible. But I also want to play them. A lot of people say, well, just use a console, but I find them too limiting and frustrating. Each console is essentially vendor lock-in, and you can't use games from one console on the other, or carry your games forward to the next generation of consoles. Another problem is underpowered hardware. The PS3 and PS4 generation in particular were incredibly disappointing. I still can't believe that a PS4 can't even run in 1080p. And the other thing is I have a large collection of Steam games, and I want to play those in the living room too. Unfortunately, while the PC can overcome the limitations of consoles in terms of game compatibility and it offers freedom of choice in hardware, the experience in the living room is quite poor. This goes for both Windows and desktop Linux. They were just not made for gaming in the living room. So why not both? You know, why can't we have a gaming system that is as flexible and compatible as a PC, but is simple to use as a console? Why can't I easily play all the games I own across multiple generations of consoles and across the various online gaming platforms? You know, why can't I play my Nintendo games on a PlayStation? This is the question I asked myself, and GamerOS is my answer. So with all that being said, the ultimate goal is to provide a streamlined, out-of-the-box gaming console experience. But on PC hardware. As it turns out, our friends over at Valve were already working on this problem. They provide us with a very good starting point, a lot of pieces to work with. So one of those being Steam for Linux, which really is a prerequisite. We can't really modify Windows. I mean, even if we could modify Windows to work well in a living room environment, we can't really redistribute that, obviously. Another key piece is Steam Big Picture. So that was obviously needed so that you get a good experience on the couch to be able to use your gamepad. Without it, you know, back in the day, I used to have my PC connected to my TV in the living room, and I'd have to get up off the couch all the time to start games and deal with other things like dialogues popping up and things like that, which is incredibly annoying. And Valve did also give us Steam OS with a lot of components that really help the story around gaming in the living room on Linux. Some more about Steam OS, so the way it kind of worked is it would just boot directly into Steam Big Picture, and Steam Big Picture actually had some extras just for Steam OS so that you could do things like Wi-Fi setup with a gamepad. It also actually had a custom window manager, and so what that really did was there was a problem with some games that wouldn't run full screen, and so they would kind of pop up on your TV in a tiny window, which is not great, especially if you only have a gamepad, you can't really, and you're sitting on the couch and you can't really see to turn on the full screen mode in the game. So what the custom window manager did is it would automatically make sure that games were always full screened. And then Steam OS also had automatic updates that required no human interaction, which is obviously important if all you have is a gamepad, you can't run, have to get update or whatever. In a way Steam OS did this is since it's based on Debian Valve provided their own Debian repository and they could strictly control what goes into the repo and so they could manage updates in that way. So Steam OS was really great. I used it for, I'm not even sure, probably years. I did things like install emulators and add shortcuts to be able to play a lot of different games, but eventually Steam OS kind of stopped being updated. It sounds like Valve got busy doing other things like working on Proton and trying to sort of work on the compatibility problems. Supposedly they're going to come back to Steam OS and I'm really hopeful for that. But for now, because it hasn't been updated in so long, I really started having problems, even just building emulators to work on Steam OS became a problem. The game compatibility story kind of dropped off, so new games on Steam would have sort of trouble working on Steam OS because the GPU drivers weren't updated. So I kind of eventually became frustrated and started looking for alternatives. Unfortunately, I looked around and there weren't really that many alternatives to Steam OS. There are some forks of Steam OS, but they directly rely on Steam OS. So if Steam OS doesn't get updates, then those forks also don't get updates. So that wasn't really helpful. At the time, I was using Arch Linux on the desktop. I love Arch. The biggest thing is it just has really easy access to all the different software, so the emulators and all the drivers for GPUs, which is really important. And also because it's a rolling release distro, you always get the latest drivers, you always get the latest software, which is really important for that compatibility. A lot of emulators use a lot of bleeding edge features in the GPU drivers. Having the latest drivers is important. Also important for game compatibility in general. So I ended up actually wiping Steam OS off my living room gaming PC and installing Arch Linux. And using Arch Linux, I was kind of trying to recreate the experience I was having on Steam OS. So the three key sort of features that are needed for a good experience that Steam OS provided. First being able to boot directly into Steam Big Picture. That's pretty easy to handle. So I just set up the login manager to automatically boot up into Steam Big Picture. Not a big deal. And so at first I didn't have the custom window manager that Steam OS had and I just kind of used GNOME and that wasn't a great experience. You know, there's problems like after you exit a game, you'd be dropped to the desktop, which then you're stuck on the couch with your gamepad and you can't do anything, which is not great. But eventually I found that someone had packaged the Steam OS window manager and they packaged it in the AER. So that's amazing. Thank you to whoever did that. So that allowed me to get really close to the experience I had with Steam OS. But now I had the latest drivers. I had, you know, the latest software and emulators and it was, you know, I didn't have to custom build my emulators. It was just a, you know, Pac-Man command away. So it's very, very easy to maintain. But the one thing that I still didn't have was the automatic updates. Obviously using Pac-Man, we all know you really need a human interaction to make sure that your updates are working well. So at this point I felt like, you know, the system was pretty interesting and could be useful to others. So the very first version of Gamer OS was actually a custom script that you could run from the Arch Linux installer. And that would set up an Arch Linux system, do everything like partition, install all the packages that you need, drivers and everything to set up a nice gaming environment. So that was the initial version of Gamer OS. It was really just a script. And even that was pretty useful and, you know, it got quite a few people using it. But, and so I did use that for a while. But doing updates did become pretty annoying eventually, you know, having to drag my keyboard into the living room, run the Pac-Man commands to update. And because I'm lazy I wouldn't do it as often as I should. And then I'd encounter issues and sometimes downtime. So after a while I just decided that, OK, let's see what we can do about getting automatic updates working with this system. So I looked around and saw that kind of saw two possible solutions. One was using multiple repartitions. So this is something that I think Chrome OS uses where instead of having one repartition you have multiple repartitions and you sort of swap between the two. So while you're running the one partition, you update the other and then at boot time you swap and that kind of gives you an easy way to update the system all at once. And it's in an atomic fashion to avoid any kind of issues. So this was kind of the backup plan. The reason why I wasn't too keen on the solution is because to do this you really need to determine the size of your partitions ahead of time. And I didn't really want to, I didn't want to take up too much space but I also wasn't sure exactly how much the gamer system would sort of grow over time. So if at all possible I wanted to avoid having to make that upfront decision. So that led me to find something called OS Tree which is pretty new, very interesting. I know Fedora, Silver Blue and Endless OS make use of it. OS Tree, you can kind of think of it like Git for operating systems. You can sort of check out multiple file system routes and boot them, boot into them and run those operating systems. It's very interesting. I did actually give it a go. I tried to get Arch Linux and booting through OS Tree but I kept encountering issues and I just eventually gave up. In any case, at the time at least OS Tree did have other issues so because it does act kind of like Git, it has a lot of little tiny files, it's hard to host, it's hard to have it on mirrors. But I think that is being worked on if not already solved but at the time it was a problem. So I had kind of resolved myself to just using the multiple root partition solution. But then I actually discovered that another solution might be to make use of butterfs. So butterfs has the concept of sub volumes which are kind of like directories and kind of like partitions. Sub volumes are easy to create like directories but they do act like partitions and you can basically create them and delete them at will. So that kind of solves the problem I had of not wanting to make that up front decision about partition sizes. The other thing that I discovered that was quite amazing I had no idea that you could do is that you can actually boot into sub volumes. So you don't boot into the root of your file system, you can actually boot into a subdirectory of your file system. Which completely solves all these problems and why I went with butterfs. Eventually I created a project that I named freezer and freezer is a way of installing and updating operating systems based on butterfs sub volumes. It essentially replaces pacman as a method of distributing updates and system images replace the need for individual packages. Each version of an operating system is built into a compressed butterfs sub volume image file and distributed to users. Freezer downloads the new system image and extracts it to the disk and to complete the update you simply restart your system. And this is all without any human interaction required. This is quite similar to how Chrome OS works except that instead of multiple partitions we use multiple butterfs sub volumes to switch between the operating system versions. This does have some limitations the main one being that the root file system is read only and you can't install additional software because even if you did any changes that you made would just get wiped out with the next update. So in gamer OS the official way to add custom software is either through flat pack. Or by creating your own system image which we make sure is as easy to do as possible. This limitation is acceptable though for the use case of gaming of a gaming appliance which gamer OS is. And really I actually see this as more of a strength of gamer OS rather than a limitation. And this is because it kind of makes it a lot easier to report on and track game game compatibility issues. You know the only two pieces of information we need to know is the gamer OS version and the GPU being used. Right so there's nobody can you can't mix and match different packages and cause problems. And another interesting thing is that freezer could actually be reused for other sort of appliance like systems. There's nothing in the project itself that is really gamer OS specific. This is kind of what it looks like. At the top you got your physical file system and on the bottom you have what the user sees. So under the root we have a directory called deployments and under that we have our file systems for all our operating systems. Here we only see the one gamer OS 19 that contains the entire file system for a gamer OS system. And then on the right we have the state. So between updates we want to keep our state and that's done by keeping it on the root disk with home and var being sub volumes and etc being an overlay. And inside the user facing file system that we mount home and var and the overlay etc. And in order to do updates we need to manipulate the files under the deployments directory. So we mount the actual root onto a freezer root mount point that allows us to actually download updates. So the reason we need the etc overlay is without it you wouldn't be able to maintain things like time zone settings and network settings. Because the underlying gamer OS system already contains files under etc. So we need to add in the extra bits for user configuration. So when you do an update what happens is we download the new version to under the deployments directory. So now we have gamer OS 20 and then we update the bootloader to point to that new sub volume. And when the user reboots at the time of their choosing now we booted into the new version of gamer OS. And it just mounts the state on top of the directories and we've maintained all the user files. So now that we have a freezer and this update system now we've got all the things that steam OS had. We have booting into steam it picture we got the custom window manager and we have fully automatic updates. So we've got pretty much what steam OS has but we wanted to do some more. So the other sort of things that we have on top of what steam OS has is we have a very much more simple installation. It's also faster. We have zero downtime updates. So not only are the updates automatic but you don't have to wait for them. They download in the background and whenever you want you can reboot your system to get into your latest to get into the latest version. We have the latest update drivers and software. We have support for a lot more game pads so things like the Xbox One controller with the dongle works out of the box. We have some support for VR so it's still a hassle to set up but it's a lot easier. A lot of the command line trickery you have to do you don't need to do we do that for you. We have simplified FTPSH access some remote management tools and performance monitoring tools and we have steam shortcut management. Flat pack support and 4k support and we have one more thing most important of all game compatibility. So there are kind of four things that work towards game compatibility. The main thing being Proton. Thank you Valve. Proton being the fork of wine developed by Valve that can run Windows games on Linux. So then we have the specialized Steam OS compositor. I forked that because there were a bunch of games that kind of had trouble with it. So I forked that and kind of hacked around those problems. It's not pretty but it works. It doesn't look like Valve is accepting any more upstream changes as they've almost completely rewritten that. So at some point that will be something that we'll have to address. So then we have Steam Tweaks and what that is is a database of tweaks that we can apply to games to get them to work out of the box. So that's for Steam games and then we have Steam Buddy which is a way to manage non-steam games. So uploading your ROMs, installing flat packs from FlatBuddy and now also installing games from the Epic Games Store and more stores in the future hopefully. So a little more on Steam Tweaks. So what you can, the kind of things that you can set up for each game. You can set up the Proton version. You can set up the Proton configuration. So there are some games that only work with specific versions and specific configurations of Proton. So we set that up sort of automatically so the user doesn't have to. Then there's something called Steam Input. So this usually affects Linux native games where a lot of Linux native games don't have the best gamepad support. Valve created a system called Steam Input which creates a virtual controller that's usually detected by almost every game. So if the game doesn't support detecting your particular controller, you can, Steam has a mapping for it to this virtual controller. So that way you can get a lot more, you can get a lot more games to work with controllers. And there are specific games that kind of really need this otherwise they don't even work with controllers at all. So we enable this. You can't enable it globally because it creates another virtual input. So the games that properly handle gamepad support will actually view your single controller as multiple controllers and that causes problems. So we only enable it for the specific games that need it, at least the ones that we know about so far. Then you can specify launch options so some games just don't work. They need specific environment variables and specific flags, that kind of thing. And then we also have a system for applying patches. So there's a game recently that I created a patch for Freedom Planet. And it's very peculiar in that it has gamepad support but the gamepads don't work the first time you start the game. You have to actually use a keyboard to start the game the first time. And then the next time you start, you can use a gamepad. So that's pretty annoying, especially if I don't have a keyboard on hand. So what I've done is I figured out what, that the game was doing some kind of configuration. So I figured out what it was doing and I just kind of patched that in. So the first time you start the game, you can use a gamepad. So that's kind of things that we're doing to sort of fill the gaps created by some games that don't quite have either the Linux support or the support for a good experience in the living room with a gamepad. So a little on SteamBuddy, which is probably right now the biggest project in Gamer OS. What it is is it's a remote management web interface where you can sort of install and manage non-steam games. So like ROMs, FlatHub, FlatHub games and Epic Games Store games. So because it's a web interface you can also kind of use it from your phone. It's pretty easy to do, pretty easy to use. It also functions as kind of remote control. You can do things like exit the game, restart Steam and toggle the performance overlay and a whole lot more. So let's take a tour of SteamBuddy. I have a browser window that I've opened up on my desktop computer. And put in the IP address of my Gamer OS machine. Then we get a login screen. So we'll just log into that. And now we're presented with the list of supported platforms. So you can see most platforms are emulation based with RetroArch. Most platforms is always increasing. And we do have a few stores here, FlatHub and the Epic Games Store. So if we take a look at FlatHub, we foresee the list of games that we've already installed and apps. So if you want to install some additional software, we just click on the big plus sign. Now we get a list of all the additional software that we can install. So let's go ahead and install something. Click the install button. The UI is a little bare bones and hopefully that will improve in the future. And that was pretty quick. We go back to the FlatHub list and now we see a new game is installed. And now that we've installed the game, it will be available in big picture mode alongside all your other games. And these are the projects that I created that kind of make up Gamer OS. It's Freezer that tries to address the automatic update problem. Then we have the SteamOS Compositor Plus which tries to fix some of the issues with specific games and adds in 4K support. And it also is what helps giving us that couch gaming experience by making all the games full screen. And then we have Steam Tweaks that kind of fills in the gaps and tries to smooth over some of the issues that some games have and SteamBuddy to add in support for games outside of Steam. So with Gamer OS, I really think that we have created an operating system that accomplishes the goal of an out-of-the-box streamlined game console experience on PC hardware. All the various pieces and projects I talked about come together to make it happen and we are always making improvements. I want to thank all the contributors who have helped make it a reality. And that's all from me. I hope this talk was informative and thank you for watching. Yeah, my name is Luna and I have some questions for Alice Slovak, but we're some Gamer OS. Hi. The first question is, are you actually allowed to cheap stream, pre-installed from Sven's taro? So my understanding of that Valve specifically re-licensed Steam just to allow this, but it's possible I'm wrong, but my understanding is that it is allowed. Also Valve hasn't stopped me and I've talked to them about this, so I take that as tacit approval. Alright, and then we have some more questions about different games on Steam. The first one is from AuraQ. Q, how is compatibility between Gamer OS and a Steam link? Steam link with Steam on my existing Arch Linux OS has been hit and miss. So I have a Steam link and I don't know if I would actually use it with Gamer OS, but I have done streaming from Gamer OS. I always found it worked well, but yeah, it would probably depend on your setup. Then we have a question from Ram said, how well does Steam remote play work? What kind of specs are needed for that? Remote play being the, if you're playing, if it's just like streaming from within your home, then I don't know about the specs, but whatever Valve says, I guess. Yeah, sorry, that's the best answer I can give you. Alright, then we have a question from Keto. What has been the biggest challenge from adapting Steam OS to Arch systems? So yeah, definitely, and I spoke of this at length. The automatic update system is definitely the biggest challenge. I had that, you know, I spent a lot of time on OS tree and that failed. So yeah, it was definitely the biggest challenge. And then Raspberry 101 wonders, does it have any benefit in game compatibility department compared to the standard installation of Arch Linux? Yes and no, it has better game compatibility, sort of out of the box, but you can. So the tools that I mentioned in the talk, Steam Tweak, Steam Buddy, it's all in the AUR. So if you actually install Steam Tweaks, you will get a lot of the benefits that are included in game or OS. So, yeah. And then there's some more questions, more targeted to the operating system, one here from Lirst. Are there any plans to support wireless during installation? So yeah, a lot of people ask that. The problem is, you can't, yeah. The problem is it requires network before you can actually get into the wireless settings inside the Steam Big Picture mode. So it's possible in the future, somebody would have to work on it. And it requires a bit of extra work. And then David wonders, what do you do about games that are required to be installed on an EXE4 partition? I don't know of any that exist. I've never seen anybody report such a problem. And then some questions. What is the processor? Why not use Pacman? Why not yet Pacman and beat the RFS snapshots? What's the advantage of your method? So we're going for is like no human interaction. So if you're using Pacman, you need a human there to monitor the update. Or, you know, sometimes there are, there's intervention you need to do with an update. So we're taking that completely away. So what we do is essentially we're reinstalling Arch from scratch every single time and then pushing that resulting system image to users. Fresh Arch install for every update, essentially. And then XIO wonders, what if a config file on the overlay file system needs an update? That is, that's a really good question and keeps me up at night. But if that was required, we could do some kind of factory reset or something to zap the user configuration. In gas wonders, are you or will use delta updates for image updates? I'd like to. And it's definitely possible, but our but our best supports that using Delta sub volumes. We just haven't implemented it yet. It might come at some point, but the image files are actually not too, too huge. If you compare them to the games you have to download, you know, it's under the updates are the system image is compressed under one gigabyte compared to, you know, 50 gigabyte games. It's not a huge, huge deal. And we don't update too often. It's at most once a month. So it hasn't been a huge issue, but it's definitely something that would be nice to have but it hasn't happened yet. And I have a kind of related question. So always trees overlay file system that can apply to current file system to have stable updates. I'm guessing it uses this for something to reduce this usage. So always tree isn't really is not overlay positive. I don't know if I could do a justice explaining what it is. But like I said, it kind of allows you to check out. It's like a Git repository and you check out different versions of your operating system. And then you can boot into them. And you kind of mount the it also handles state. So it has a way of a different way of handling etc. It does similar things like mounting bar and home on top of the root file system. So it's, it's actually pretty similar to what we've done. It's just a different way of doing it. The next question is just wonders, was the distra ever noticed by any big windows only game development company. Yeah, I don't think so. Not that I know of. And then another question by the same guy. Did any company approach you to make a gaming console based on your operating system or making a huge donation and shipping and commercial thing based on it. People of course, and if so, would you consider selling it the distro to them if you get a lot of money or some money or not at all. No, there was nothing like that. And I don't think that would ever happen to actually make a gaming console would actually you need a light to actually sell it sell it as part of a console you'd need to get a license from valve and apparently they don't do that anymore. So that was part of the steam machines thing. So it's probably not possible without valve. And then get the wonders, will the image files contain all possible emulators inside of it. Or is the plan to reinstall them after every update. So they contain a lot of emulators I mean we don't have every possible emulator. There's a lot of them. There's actually more emulators than steam buddy supports so that people can use it manually if they want to. And I mean technically you do reinstall them every update but you're reinstalling everything essentially with every system image contains all the entire all the packages part of the system basically get reinstalled every update. All right, and there's then there's a lot of people if it can wondering if it can use this other stores or game services other than steam like battle not epic games. Right. For example. Yeah, so that's where steam buddy comes in because we can't the steam client is proprietary we can't quantify the UI. There's no real easy way to add in extra sort of support for other stores. So that's why I created steam buddy to allow you to manage the games outside that aren't the steam games. So, I did in the last release we did add epic game store support, because that was really the easiest it had to really pretty mature command line client that we sort of use. I do want to add gog and hdio and other things. Battlenet I'm not sure if that is possible. It may not be. I don't think they have an API that's publicly accessible or anything like that. I mean, there's a hard question. What percentage of steam games can run on Linux with proton now. Oh, I don't know you have to look at proton DB it's, I think there's a large amount. So what I think for compatibility to note is that for in the case of gamer OS, it's not just about the windows compatibility is also about the sort of experience in the living room on in a 10 foot experience with the game pad. There are a lot of games that do work on Linux but they suck to play with a game pad right so games that I would say is compatible with with the gamer OS philosophy, then is in general for Linux. That's when star has a question about your releases. How much of the gamer OS release process is automated. So, we have for building the images were actually we're hosted on GitHub, and for building the images that is fully automated. Every time I make a commit it just builds a new image. We do that through GitHub actions. So that's nice for the ISO which we don't because the way it works is the ISO will just just starts. It's based on arch ISO by the way, and it, the installer all it does is pulls the latest image system image. So we don't update that one as often because it's not really necessary. But that is still kind of a manual build process. That was all the questions we have. Okay, for now. I still have some time I guess, but thanks for the questions. Hopefully I answered them well.