 My name is John. I'm from Valve. We've been working for a couple of years now on a devian derivative called SteamOS or SteamOS depending on how you want to pronounce it. I've been at Valve for a couple years and one thing I've found when I tell people I work there is there's two reactions. Some people have no idea what Valve is or what they do and some people are incredibly passionately excited about Valve. If you're in the first category, Valve has been around since 1996. Those originally started, developed PC games, mainly focused on Windows PCs. We have a wide list of PC games, some on mainly on Windows, also Mac and Linux now, but originally started on Windows and a few of them on consoles as well. Some you've heard of, some maybe you haven't, but anyway, that's how Valve got to start. But along the way, we developed this platform called Steam, started off just as a way to update our games, turned into an application store for PC games, social network, messaging, now it's a huge community, over 75 million active users, logging into Steam, playing games, communicating with their friends. Thousands of games, support on Windows, Mac OS and Linux. So one thing that a few years ago Valve saw was open platforms are really important. The way we work at Valve is we put stuff out there, listen to our customers, iterate on things quickly, listen to our feedback and try to give our customers what they want. The things they like will do more of that, things they don't like, we'll stop doing that. And open platforms the ability for people to run whatever they want on their computers, modify games, create their own content, really breathe that innovation, that kind of people do stuff you never expect when you give them the keys to their own car. And sometimes crash to the wall and sometimes they do amazing, great things. And one thing that's been a trend lately over the last years, we've noticed is a lot of platforms now are not becoming less open. You have consoles where you have to go through, you know, what the console manufacturer to get your software on that box. You have the iOS and Android app stores. And even on the traditional PC platforms like Windows and OS X, you're seeing these gated communities of app stores. So Val, we wanted to understand what's that, how do we think about that, how do we counter that effect and build our own platform? At the same time, we're thinking about how we can get into the living room, take the games people enjoy on their desktops, bring them to the couch, the 10 foot environment so they can enjoy those on their big screen TVs, just like a console today. And this required a lot of work across a lot of different parts of Steam and the games versus the big picture for a living room experience. The same interface you want on your desktop. We call it two foot experience with a mouse and a keyboard. Isn't appropriate when you're sitting on your couch, watching your 65 inch TV on the wall. So we have a whole new UI for Steam designed to be operated with a controller from a 10 foot, very big pictures, very big motions. Steam and home streaming is a way that we can take your Windows games that don't run Linux, run them remotely. You actually stream the UI, stream the input over the network where the wireless or wired network to a Linux PC. And you can play that Windows only game on your Linux box and actually get a great experience out of it. It's, you know, a lot of people don't think this is going to work, but they tried and it's almost magical in a way, how well it works. I personally was pretty surprised at how good the experience is. We've got the latency down really low. It's a very high quality gaming experience. Family sharing for letting people with multiple Steam accounts share the same Steam account, buy by a game on my account. Other people in my family can play it on the same box. And then the Steam controller is an effort that's been going on for a long time. It's really one of the pillars of our Steam machine. And that's a way to make it possible to play these keyboard-centric PC games with a controller. You know, a traditional controller isn't going to work very well with these games that are designed to be played with a mouse and keyboard. So we've done some innovative stuff around touch pads and adaptive binding of controller buttons to keyboard to make a really good experience there. And that's something that's ongoing. And then, of course, we wanted to bring all this stuff to Linux so we could have an open platform where people could do whatever they wanted with a box, we could sort of develop our own community of people experimenting and taking this platform in a way we didn't expect. So that started out with Steam for Linux, porting games to Linux, both Valve games and other companies' games. And then finally, SteamOS, which is the Debian distribution that we've developed with Valve, and then finally pulling it all together onto the Steam machines which will be shipping as a bundled piece of hardware. So Steam for Linux's goal was to take all the stuff we got on Steam, deliver the same great gaming experience onto Linux desktops, originally focused on Ubuntu 1204 LTS at the time. That was by far the predominant desktop Linux distribution. But we had, as you may have heard from Linux last night, a real problem with binary compatibility. How do we take, you know, one product Steam and all the games that run on Steam and make those run across a whole set of distributions? It's really hard. There's not a good way to do it. There's no way you're going to rebuild all these games for every different distribution. What we ended up doing was creating what we call the Steam Runtime. That's a very similar to Ubuntu 1204 binary system. We lay that down and we run all the games on top of that user space. And so far, that's been pretty successful. We've targeted all partners to run their games on top of the Steam Runtime, Steam itself runs on top of that. And we maintain that set of binaries across the set of distributions. And going forward, we'll guarantee binary compatibility for those games. And this was released about six months ago. And I'm happy to say there's over 600 Linux games now on Steam that you can download and run on your Linux box, which is pretty amazing when you consider where we started from. OK, now we have a Steam for Linux that's out there. We've got a third party porting our games to Steam. We've got a good installed base, got streaming, so we can bring your Windows games to Steam. The next step was really build out our own living room platform called SteamOS. Make it consumer-friendly, something that anybody could buy, you know, whether at your local hardware store or order on the internet. Give you great Steam performance. It's really tuned, latest, greatest graphics drivers, high-end science systems that can compete with a console in Xbox One or PS4. Provide a great steaming client. If you have existing Windows games, you want to play on your big screen. This is a great way to do that. Connect this box to your TV and you're done. Off you go. The main goal, the main distribution channel for this is going to be through our partners, through our OEMs, people selling Steam machines, pre-installed a fully, full bundle of SteamOS, the Steam controller and the Steam machine. But it is an open platform. It's not a locked down box. If you want to, you know, get to the desktop and install whatever you want on it, you want to develop your own software for it. It's wide open. It's really debuting underneath. Something everybody in this room is familiar with, I'm sure, and people can do and have done pretty interesting things with that platform. Things that it's not. I always think it's important to understand what it is you're not doing or else you end up doing everything. It's not a great desktop. It's a terrible Linux desktop. People want to use it as a Linux desktop. It's never designed to be that. We have a desktop system, but it's really a placeholder. It's a bare bones thing. I don't encourage people to install this and use it as their daily work station. There's plenty of Linux desktops out there already that do that. Val is not really going to play in that space. Some people want to do it with Windows again, and that's something that maybe is an interesting exercise, but it doesn't make a whole lot of sense from a product perspective. If you already have Windows and Steam on your desktop PC, that's great. Why would you also want SteamOS on there? To me, that doesn't make a whole lot of sense. We have invested a lot of time in that. Some people do do it, but mainly just to prove it can be done. Again, and because it's an OEM product designed to be sold through the hardware channel. It's not really designed to be installed by end users. They're not going to be faced with a Debian installer kind of experience to put this on their box. It'll come out of the box with a full 10 foot experience. And they'll never see the install process underneath. VM client, people like to run or try to run SteamOS in a VM because we really depend on the 3D accelerated graphics very heavily in OpenGL. It's never going to be good experience running this in a VM client today. The 3D graphics is just not there yet. Someday, perhaps, but not yet. An older hardware is also another thing that is not really a target for us. You know, people pull, I have this old laptop lying around. I want to put SteamOS on it. It's not going to be a great experience. We really haven't spent much time on that. And we really don't plan to. These are going to be pretty new hardware, new boxes, new drivers. Some of the changes we've made within Steam, mainly focused around consumerization. We have automatic updates using the standard app and unattended upgrades package set up to update it at shutdown time. So the user never has to say, oh, geez, there's updates. I got to do this. I got to do updates or whatever. Just within Steam, they see a notification. They need to reboot their computer to apply updates. It applies them automatically. And it's done. It's not an opt-in thing like it is in some operating systems. It's out of the box. It's going to stay up to date. It's going to be updated regularly. It's down top of security patches and such like that. Improved the graphical boot. The whole experience from the firmware up through the initial load of Steam has been tuned. We've worked with our firmware partners to make sure that they get a good consistent experience. They don't see text flying by our random modes, which is our things flying out of the screen. I just see Steam coming up and our boot right in the Steam log on screen. And it's all off-control or friendly. The initial boot, you know, you go through the whole thing selecting your time zone, your language, whatever that's all controller driven. You don't ever need a keyboard or mouse attached to this box to get the thing installed, get it up and running, get logged in. The other thing we've done that's a little interesting is some work in X to enable a separate Steam session, which is just Steam running in big picture and a desktop session with a traditional known desktop. And you can turn on that desktop experience and switch back and forth between them on the fly. So the graphics stack, obviously, is something we care a lot about for performance reasons, for hardware reasons where we do expect to be using the latest and greatest hardware from our partners. We need to have the latest and greatest drivers to take advantage of that. So we've worked very closely with them and as well as the seamless boot and shutdown sequences I've mentioned, that requires the firmware to do the right thing, requires the grub, bootloader to do the right thing, requires the graphics driver to do the right thing. So there's changes throughout the whole stack to make that all work seamlessly. We spent some time working on Mesa to get better Intel integrated graphics support. That's a really important price point for us because that's kind of the lowest price point. It's a very price sensitive area. So we want to do the best we can to get the best graphics performance out of that part we can. And we're working again with AMD and Nvidia to make sure that we have the latest of their drivers. We're closely with them on graphics performance in the various games, make sure if there's any issues we can address it and we can roll out newer drivers. That's the way you see when you boot up a SteamOS machine, assuming it's been correctly configured by the OEM. You get the native TV timings, the firmware is responsible for figuring out what the right settings are, setting that up and handing that off to EFI. And then that flows all the way through, that mode flows all the way through to Steam and the initial Steam experience. So if you're just kind of janky in and out mode switching black screens in between, we've done a lot of work to pay that out and make sure it looks just like one simple system booting up. The full screen graphics environment, this is another interesting work we've done with our own composition manager. There's really only one application running and SteamOS generally when you're running in the Steam environment and that's either Steam or the game. So you always get full screen. If the game tries to put up a small window, it'll be scaled so it looks full screen with your own custom compositing here. Redirect the mouse input to the right window and make sure that if you have an app that hangs, there's a Steam overlay. We can always bring that overlay up because it's running out of process and it's integrated with a composition manager and bring the overlay up, kill that app and return back into Steam. That's something we couldn't do in just a standard Linux or even Windows environment. We have to be in the application process to put up that overlay. The Mesa driver is something where we've done a lot of work working with a company called Lunar G. They have a lot of open jail graphics expertise to really update the Mesa that is in Debian Weezy to something that can run our games and run the other games and be really performant on the latest Intel hardware. So we've cherry picked patches and funded them to actually implement some new performance focused features in Mesa. This is all open source on our GitHub. You can go up there. You can see the branch that we're using in SteamOS today, submit patches, whatever you want. And this is something we think is going to be really important for the Intel based graphics to get that competitive. Our Linux kernel again, because we want to be able to run with the newest hardware, we've updated our Linux kernel. It's based on the 310 long term branch. We have various hardware drivers as our partners come and say, hey, we're shipping this platform with this wireless part that's not supported. We'll work with them and with a wireless card vendor to integrate that driver into our kernel and ship it. We've improved obviously the Xbox 360 controller support. So it's seamless out of the box support. Just plug in your Xbox 360 controller and we detect it and go with it. And hopefully this is something we can collaborate with our hardware partners over time to patches in our kernel to support their hardware. Are all those improvements, like especially the controller support, are those going upstream to kernel and Xorg? The controller support support specifically, I believe we've sent upstream. Purely would know because he did it. Yeah, the patches have been sent upstream. There's been some discussion, as always, when you send something upstream. So eventually it will make its way there and some shape of form, hopefully. And a lot of the hardware support packages we've actually pulled from upstream back poured into our kernel to get the newer hardware support in our older kernel. So I'll talk a little bit about the build and release process. You know, Steam OS, I think, just from going to some of the discussions here is a little bit different than some of the other Debian derivatives we've talked to. Now, we've actually rebuilt all the Debian packages from source. We use a system called OBS, open build system, open build system, does that rate? Claude, where I helped us set this up and worked out really well for us to pull in changes, pull in new packages, build them and deploy them. We also have another system called MergeMatic that looks at the upstreams. If there's a security patch upstream or some new release upstream from us, it will automatically merge in that patch, submit a request to OBS. We can just approve it, boom, it goes in, gets rebuilt in our system, pushes it out to our repository where we can then do our own testing if we need to of that. And the way that we do our release process, we modeled our SteamOS release process off the SteamClient release process. If you're not familiar with that, the way it works is there's a beta channel that updates pretty regularly. We try to be on like a one week update cadence for the last six months or so on SteamOS. We'll push out changes pretty regularly. There may be not very well tested. People who can opt into that beta channel test to give us feedback. After we feel like we've got what's in that beta channel is stable, getting good feedback from our customers, they'll get promoted to the release channel, which is where everybody will then get that update. So we have early adopter, people want to be on the bleeding edge, can opt into this and we might break you, we might break your video driver. I think we just broke some people's sound drivers last week. We'll try to address all those issues before we promote that to the alchemist. And recently we've moved to the same model with the Steam Runtime, which is a binary compatibility layer that the games will target and we'll be updating that in the same way where we'll have a beta. And once we feel like we have good coverage on the games and maybe do a formal test pass, that'll get promoted to release. That's something that updates much less frequently. We try not to touch that Steam Runtime unless we have to. But SteamOS we do, we have been rolling out pretty frequent regular updates right now. I think once we ship and have real hardware that cadence will slow a bit until it's just probably critical security patches, maybe new drivers every six months or so. I'm not really sure what the cadence of that is going to be. And we'll play that by ear a little. But that process has worked pretty well for us. So this is in general what our build workflow looks like. We have, you know, most of our packages come out of Weezy. A few we've taken from Jesse, the newer versions we need for one reason or another. And Mergematic basically monitors those every day on a daily basis. Detects any changes that are different from what we have. Automatically tries to merge them and pull them in and submit them into our OBS. We have a few packages on GitHub like the kernel, the Mesa library I discussed, which today is a pretty manual process to bring that GitHub source into OBS and build it. And similarly, we have a few internal packages that are maintained in an internal Perforce system that Valve uses. And those also flow into OBS in the same way. When OBS builds and they go into what we call the SteamOS master repository, which is always the latest and greatest things that have been built on the build system. And the next step is to take those and propagate those out to somewhere we can test them in a way that our customers will test them. So the first step is we use RepRipro heavily to move stuff around between the various repos. We have an internal repository of Alchemist Beta. The first step is to prop out the stuff to there. And then we can do some internal testing within Valve just using that repository to update our systems. Point them at that repo, make sure everything works. Once we feel like, OK, we've done the testing, we need to the targeted testing based on the changes we need to know. We know we've made or based on just general smoke tests, we can push that out. We can pull that out to our internal global repository, which is the main release repository. And from there, we can then we use our sync to basically replicate our internal repository out onto the Internet. And that's when everybody can get the same bits over testing internally. And the R sync from internal to external happens both when we prop an external data and when we prop an external release, it's always just a basically a mirror copy from our internal repository to the external one. So it's next. We're kind of in a state. You know, we've got a lot of hard run flight right now and trying to make sure all those parts line up before we can ship steam machines out the real world of respond to some feedback, enable the hardware that our partners need enabled. And then looking past our V1, which is going to ship on the first hardware that comes out. What do we do next? I'm really interested in and moving away from an app based update to more of an image based update system. We see this like with the Chrome books, we see this, I think some other a bunch of things be moving towards this read only image that's applied across everybody's machines is always the same and be able to roll that image forward in a more consistent way. That gives you a real control over what's on the bits that are on everybody's machine. You can roll things back, move to different image very easily in a way you can't do with that today. You can do it atomically as well, if you're clever. But it sort of takes away some of the control that people have over their machine, be able to install arbitrary things, be able to install their own packages. So figuring out what's the right trade off there between having a consistent consumer class appliance and being able to service that and being able to have a platform that people can do arbitrary things with and still going to get a great experience. That's something I don't think anybody has solved quite yet. We're looking at a couple of things for the next release in that area. Improving the desktop experience, you know, what we have there is basically a bare-bones known desktop. It's not by any means a great experience. That's a good way to open a terminal window and install some other stuff. It'd be interesting, I think, to figure out what is a 10-foot TV-centric desktop look like. I don't think there's anything really out there today that gives a kind of a power user experience ability to control your system at a fine level. But we don't have one today. I don't know if we'll build one or if the community will build one or whatever, but I think it's a pretty interesting area. A long-term binary compatibility with the steam runtime that's been working pretty well for us so far. It's a little limited, not sure exactly how we'll move that kind of binary level forward to take advantage of new libraries and things, whether we'll just add stuff into the existing one or whether we'll have multiple run times and apps can opt into that. Looking at some of the work that's going on in containerization and being able to isolate things from each other, I think that's a really interesting area there for us to provide a consistent binary compatibility environment that we can maintain across multiple distributions as a target for people who want to deliver a binary application through steam. Another thing is how do we make it easy for people to install stuff that's not through steam on a steam machine, right? There's people who don't want to deliver their application through steam, they want to do it through their own website, their own channel. There's things that we might not want on steam for some reason. How do we make it so people can install that easily? I know there's a bunch of efforts going on starting up now about sandboxed, compatible application, unprivileged things. I think we're trying to stay on top of that for us and figure out where can we leverage community and coming up with a standard for clicked install, sandboxed applications that could work just as well on a steam machine as they would on a desktop or a phone environment. And then moving to Jesse is something that's on our radar. How it commits is based on Weezy. It'll stay based on Weezy forever. At some point we'll have a new release that will be based on Jesse. There's going to be a bunch of work there. There's a lot of changes we need to think about. What's the right thing to do for us? And when that will happen, we're still up in the air bit. And thanks. I just want to say I take this opportunity to say thanks to the Debian developers and the Debian community. We could not have done this without all the work people all over the world and in this room have done. I don't know if people are aware of this, but we have a standing offer. Anybody who's a Debian developer can get a free Valve key on Steam that will unlock all the Valve games for you for free on Steam. Just email Debian-steam at cloudbro.com, mail signed by your key in your key ring, and it can't be a 1024 bit key rate. So far I think we've given out 415 keys. So if there's been a decline in productivity of Debian developers, might be some correlation there. I don't know. But that's it. So if you have other questions, there's some links, more information. We have sort of a general overview of all our Steam living room efforts at esteampower.com. There's a whole community with forums, questions, and answers that we monitor on a regular basis on Steam community. We also post any update announcements there on the Steam OS group whenever we put out a new beta or a new release that goes up there. You can look on the Valve software GitHub as well as the stuff I've mentioned. There's some other open source projects from Valve. And of course, if you're interested in working on any of this stuff, Valve firing, there's some job postings there. Or feel free to email me directly. I think one of the reasons that PC gaming was so successful from the very beginning is that you could use the same PC for work and for games. The work you're doing on making Steam OS computer easier to boot and easier to manage from with 10 foot UI. I think it would be useful if you could combine that with the proper working desktop. I think a lot of people would prefer to have their living room PC also be APC. Okay. Hi. I'm not going to disagree with you. I personally don't, but I believe some people do. I know people have tried to install LibreOffice on their Steam OS machine to do spreadsheets from their couch, I guess. And again, that's something that right now, we don't think it's really a thing. Maybe the community will do some stuff in that area and when we'll pick it up and adopt it, I'm not saying we'll never do it. I'm just, it's not super high on our party list to make this a productivity experience as well as a gaming experience. Okay. Yeah. So, I'm myself not interested in games, but I'm interested in the fact that others like games and by that fact would probably come to Debian because you provide games on Steam OS. So what would be, what I would love to see would be people using Debian because they want to play games on Steam OS. So my question would be what would it take for Valve to bring Steam directly into Debian in a way or another so that it would be one of the possibilities to play Steam games. Well, I'll just clarify all these games all work today on Debian. Yeah, but like, you have some other, you do some modification on Steam OS like you optimize X and kernel and whatever. Did you think about bringing that directly to Debian? A lot of the optimizations we've made are kind of specific to the environment we have and are not necessarily applicable to Debian at large. The things that we think make sense to go upstream, we'll definitely try to push upstream. I don't think, maybe Pierre Liu can talk to this one better, but I don't think the patch we've made to the X server, for instance, are broadly enough applicable that they would make a whole lot of sense in a general purpose operating system. Yeah. Right now, there's a lot of stuff that's kind of hackish put together to achieve that. So, for example, the X server we have does not, would not work properly in a traditional desktop environment. However, we're trying to standardize all that and getting it into a position where you can use all our components in Steam OS mode or in regular mode. It's worth it to know that some people have already done that in some capacity. For example, there's an Ubuntu PPA that lets you install our kernel modules, our improved Xbox controller and the full Steam OS session side-by-side with your desktop productivity session using our Steam Comp Manager which is fully open-source. They repackaged it so you can get that full experience traditionally next to a traditional Linux desktop today. It's just a little bit rough around the edges right now and we're hopefully going to make it better in the future. Any other questions, right? Yes. We'd love to be as close to upstream as we can but we're not afraid to make changes when we need to and if there's things that we change that make sense upstream we're happy to work with the right people make it happen. I have a question regarding libraries that developers can use. Do you have a list of compatible libraries with a Steam runtime? So as soon as we produce a game it can also be made readily available on Steam OS and other Linux platforms that use Steam. Well, what are the libraries in the Steam runtime? Is that the question? Yes. What libraries does it link to, for example? Yeah. You can go up the GitHub and the Steam runtime is one of the things that's up there. What's in there is text, OpenGL, audio, stuff that you would expect. I mean, it's basically the things that are in the runtime are the things that games are using today and that's why they're in the runtime. There are some scripts up there as well that let you monitor your application and see if there's anything that's using that's not in the runtime so you could either correct that or work with us to add stuff into the runtime. It's not out of the question that we add stuff in. It's pretty hard for us to take stuff out of things. Does that answer your question? Yes. Just a quick comment in response to the point about using Steam on Debian. It's already in the non-free repository of Jesse and Sid, so while not on Weezy in subsequent versions of Debian, you can already do Linux gaming, admittedly not with the various alterations to the lower layers but if they're not suitable for general use, they're not there, so you can already do them side by side. I've done it. It works. Yeah, and Pierre and I had lunch with Michael Gilbert today. There's a package for that, so we're trying to make it better for Steam in Debian. So two quick questions. One, how are you looking at Weyland yet? We've looked at Weyland. It's not there for us. When we look at Weyland and they promise compatibility with X and we now have hundreds and hundreds of games that depend on X. So when we look at Weyland, our perspective is okay, is this going to break us or not? And if it is going to break us, that's kind of a non-starter and if it's not going to break us, what does it give us? And right now that equation is unknown. Does that make sense? Yeah. We don't know about the black benefits because we're really open GL focused. It's not going to be much there for us. And it just has a potential to break X compatibility across all the games and things we have. And I don't know how good their compatibility story is because it seems to be in flux a bit. Okay. And my second quick question is have you considered better integration with wine? Like if I have wine installed in the system, would it be possible to have Steam recognize that and let me install Windows applications? The problem of that is it's really not Steam's job to be running a third-party app in a way that's not really ever designed or intended to be run. We can't guarantee anything. App is going to run under wine. We can't test it. We can't support it if you bought a Windows game and it didn't run under wine. Whose fault is that? Is it Steam's is it the game to visit? It's not really so you do I have to? So you mentioned some of the a lot of the benefits of having a hackable platform but I know that not all of it is so I'm wondering if you could be more clear about which parts of it are still proprietary and what the motivation is for keeping them that way given that what part of it's that you talked about. And the only thing that is not open source and Steam OS is the Steam client itself and of course all the why not the client and do you have any plans to encourage more free software games in Steam? I don't think we've talked a little about open sourcing but it's probably not going to happen I don't think I don't see it happening it's something we're actively developing it's pretty proprietary it's crucial to our business the cost-benefit ratio there doesn't seem to be right in my opinion to open source it at this point. There's a question on IRC one is in-home streaming coming from Linux to Linux again. Coming when home streaming is already there on Linux you can stream from it used to work and it stopped. There's been there's been some some refactoring of the code used to Steam from Mac and Linux but it's being actively worked on at the moment. I didn't know it. Sorry this question is maybe a little bit troll-ish but I apologize in advance. So I know you're focusing on the living room experience with Steam but it's the Linux Steam client is going to proliferate through any any Linux desktop do you think that it would be an extremely attractive platform for proprietary software that's not necessary games. You do sell some non-games on a Windows part but do you see that as an attractive platform where they would bypass the entire packaging except we have it. For people to sell things that are not games. Yes, because they have one thing that nobody else has metrics and it's very hard for a proprietary vendor to gauge the market the Linux market. So we do have some things that are not games that are sold through Steam. I'm probably not the right person to talk to if you have such a thing I could probably connect to the right people to talk to but we're not saying we only sell games we do sell right now I think it's mainly tools right for building games that get sold through Steam that's pretty popular there's probably a few other things I can't tell about Steam or something on Steam so but if it is the focus is mainly games. So you guys aren't going to open source the Steam client which makes sense in some respect but you guys are the gatekeepers to thousands of games do you ever foresee the future where open source games can sort of be like presented in a way that and actually sort of promote open source or free and like you can actually dig into the games open source right out of the Steam client like maybe like a right click menu option view source if the game supports it if the game supports it sure yeah I guess we could do that I haven't seen a huge demand for I mean there's the whole modding community it just happens sort of behind valves back essentially doesn't really like there's a lot of part of the the open platform you know we want to deliver is so people can mod all kinds of yeah mod there's all sorts of different ways you can mod stuff you look at a game like Skyrim and the mods are like almost way better than the original game I like Skyrim well you told us how you use you told us how you use Damian you told us how you destruct Damian engineers by giving away free licenses but I couldn't find any edges in your workflow diagrams leading back from SteamOS to Damian so how contribute you back to Damian yeah we've pushed a few bug fixes we found in Hapt and unattended upgrades so far that's been mainly and I don't know we did the app stuff yeah on to the conference that's great so if you take if you take all the for example the Mesa work with funding that goes directly back upstream into Mesa which makes its way back into Damian there's a lot of other projects where we've been contributing to I mean the kernel patches so we'll trickle back into Damian at some point whenever it makes it upstream and whenever Damian picks up that kernel release we're big proponents of keeping it that way not only because it benefits everyone but because it makes our lives easier when we want to switch to Jesse or whatever is the next table Damian release so it's definitely on our radar to do that kind of stuff and we are looking further ways we can help the community with questions please let me know so for example idsoftware is famous for releasing stuff initially as proprietary and then some years later re-releasing stuff as open source how easy would it be for someone who wrote a game for Steambox to later open source it I mean not sure what you're asking I mean it's open sourcing a game just like open sourcing anything else you gotta make sure you have all the rights and copyrights oh well I mean I mean is there if you're distributing through the Steam system is there like extra stuff that you have to do that's difficult to rip out in any way I don't think so the only thing but I mean as long as you don't distribute the actual library that we have everything else is fine right there's a library that integrates with Steam for doing friends and you know achievements and things like that that you would probably have to rip out but it wouldn't make sense outside of Steam anyway so there's not a lot of deep integration between SteamOS games and SteamOS because all these games work in Steam for Linux and most of the time stand alone too so that isn't a big issue you had a question sorry this is yeah so coming back to the question of how how Valve gives back in case people aren't aware I will let you know that in addition to the various things they've talked about and it's always of course good challenge companies about how they do contribute back to Debian Valve is sponsoring DevConf this year they are one of our Gold sponsors so thank you very much for that John we got a great place on the T-shirt too so one question I have for you is regarding your diagram of packages flowing from Debian to Steam where my understanding is that currently your Alchemist Beta and your Alchemist channels are both based on well currently on Weezy and you talked to me about how you would have a later release that would be based on Jesse have you considered pulling in from SID and tracking unstable for during the development phases why did you choose not to go that way we may have a package or two that we pulled from SID I don't remember off the top of my head looking at Pierre Liu but I should be looking at myself there are some there's nothing philosophically we have against pulling from newer and newer stuff it's just as easy for us and the stuff is not changing out from under us as much it's purely a matter of making our lives easier to build on something more stable than less so was your question whether we should like start experimenting with SID to a later foundation for our next release right so I guess the question is should the beta channel well so the way your beta channel works I guess is it's solely based on on pulling new versions in from the stable release that you're tracking and should there be a channel yes I guess I would say should there be some sort of experimental channel that users can start looking forward to that would be tracking SID or even it's purely it's purely would be just a bunch of work for us to track I mean we basically at that point have three different releases we had to manage rather than just one and one is is keeping us plenty busy so you know if we had an infinite number of resources maybe we could have alchemist something else something else that tracked and we easy Jesse and SID but we just the manpower for that and it's not clear what the benefit would be we'll bite that bullet and we have to so in terms of the libraries that are currently included in the runtime what kind of factors go into making that decision for instance if I had an application I wanted to distribute through Steam but it relied on another 30 libraries from different platform components would that be a case where you would just willingly add those to the runtime or that be a case where I would have to attempt to refactor we're not a verse to adding stuff to the runtime where it makes sense some things would be rather than you know adding you know refactoring application might be bundling that we see that for instance with mono or java based applications I'll just bundle that with their application so it's part of their depot their application and they ship that dependency along with themselves but if there's something that you know a lot of games have in common that makes sense for us to add to the runtime we recently added support for a clang version of GCC to take advantage of the C++11 stuff that was a pretty high demand from some of our developers wanted that newer compiler so we've up there on time with that alright I'm getting the one minute sign so one more question just a comment I'm looking at the SteamOS patches here against Debian a lot of them don't have any rationale in the changelog for example IP tables you're disabling the test suite I don't know why but just to comment more rationale in the changelogs would be awesome for Debian people looking at the patches I think we're disabling because it wasn't working in our system our environment I mean a lot of we build these things in the CH route and a lot of the tests kind of have some weird side effects on our build system I know PHP is notorious for that so whenever we build PHP we have to reboot machines and stuff it's crazy alright well thanks everybody thanks for your time if you have any other questions I'll be around for the rest of the day so thanks for the help