Under the Hood of SteamOS

jones_supa writes "SteamOS has been further inspected to see what kind of technical solutions it uses. The Debian-based OS uses Linux 3.10, shipping with a heap of patches applied, with the most focus being on real-time-like features. The kernel is also using aufs and they seem to be sitting on some bug fixes for upstream on top of that. The kernel is not using the new Intel P-State driver, with the reported reason being, 'it causes issues with sound being choppy during BigPicture trailer video playback.' SteamOS is using SysVinit as its init system. The desktop is backed by X.Org server 1.12.4 and a custom desktop compositor which seems to be a 4,200-line patch on xcompmgr. Catalyst and Mesa components can be found on the system, but so far only NVIDIA is officially supported. The system boots into Big Picture Mode, but the user can drop into a GNOME desktop. Responsible for a great deal of the kernel changes, SteamOS compositor work, and other SteamOS code is Pierre-Loup A. Griffais, a.k.a. 'Plagman'. He was a NVIDIA employee dealing with their Linux support. Another Valve employee doing lots of the SteamOS system-level work is John Vert, who up until last year was a Microsoft employee since 1991. There's also other former Microsoft employees on Valve's Linux team, like Mike Sartain."

Comments

Re:Stop fragmenting

[Anonymous Coward]

Forking/Fragmenting is good when it solves a problem. Not when the differences are between using different conventions.

So... "A Linux-based gaming console" is a problem best solved by stock Ubuntu/Debian, rather than fine-tuning aspects of the OS to handle gaming demands that a desktop or server machine doesn't have? What are you getting at? Of course you fork something if you have a new use case.

Seriously, the iThingamajig audience has already taught me to hear "fragmentation" in the same tone of voice and significance as a Fox News pundit saying "destroying America" (voice: "whiny, desperate, and entitled"; significance: "zero"). You're not helping.

Re:Only nVidia?

[EmperorArthur]

so far only NVIDIA is officially supported

This seems odd to me, as I thought that the actual Steam/Valve hardware would be using AMD APU's?

Might be, but when you're doing early prototyping you go with what the developer knows, and in this case the dev used to work for NVIDIA.

I'm excited about the RT patches myself. I'm hoping one day that whole branch can get merged into the mainline kernel.

Sounds good

[gweihir]

Debian is a rock-solid foundation, that is just missing drivers. As to the custom-kernel, I have been doing that with Debian for over 10 years with no problems at all, except for some very recent issue with kernel include paths. (Which can be fixed by just using older kernel headers.)

Now they just need AMD GPU support and some games.

Re:Sounds good

[VortexCortex]

Not to mention, as an indiegame dev who cares more about the game than the money and creates cross platform code using GNU/Linux, I might just say screw purchasing iHardware and lose the additional time sink of build/test on Win. There's a few other developers I know of similar mindedness, so if the audience isn't non-existant you may see Linux exclusive games too. In my instance I'd just concentrate on the Linux build to get it out the door (as I always do), but put the testing on other platforms off until interest/demand warrants it.

Since I started with an OS abstraction layer and use the GNU toolchain everywhere, there's no such thing as porting between platforms -- setting up cross compiling is a one shot deal; However, there's nothing like testing on the metal. Porting changes even without the cross compiler suite is just "git pull && make" on any platform GCC runs on; I could use LLVM, but the point is that I'm not compiling with multiple different compilers with their own quirks to work around; FLOSS means vendor lock-in isn't a concern there. It's a shame that Apple makes it illegal for me to install their OS on my superior yet cheaper hardware. I can't justify buying separate lower spec systems just for OSX gamedev given their market share, and even setting up the cross compiling from Linux is a bit questionable, so while it's doable I avoid it. Linux and Windows allow installation on whatever they'll run on, even VMs in most cases.

Now that consoles are basically just neutered PCs where the functionality is sold back to you at a premium: Fees for multiplayer & P2P chat? Charging for publishing i.e. making their platform valuable? While ads are on the dash, wtf? And considering that heterogeneous computing is coming to desktops, mobiles, etc. I think this last console generation was it for me. Upgradeable game system? Yeah, it's just a full featured personal computer. FINALY! One thing I don't hear many folks talk about is the huge potential for tons of actual user generated content with SteamOS (PC) games in contrast with consoles; Not just gloating over social media screenshots and vids of in-game footage... You really need a desktop interface to get down and dirty with some wicked modding;

As a modder from way back, all of my game dev efforts are mod centric. I have mods I made for games decades ago that still play great today. If we want gaming to be realized as the full expressive medium it can be, we need to stop the practice popular in the last decade of birthing games and giving them DRM death sentences. I'm less concerned about this aspect on SteamOS than a console. EG: My Xbox 360 can see my friend's console. We'll be connected and chatting with each other. The consoles both know we have the original Halo 2 in the tray, and all the game needs is to be given the IP of the other client to play online -- And yet you can't do this on XBL, they turned off the Halo2 server; You have to purchase a newly released version of the game. That's asinine. Fire up a VPN w/ system link (or XLink Kai), BLAM, online multiplayer without XBL. What the fuck, MS. Might as well not be paying for your planned obsolescence non-service.

One day the Halo 3 server will be cut off, and all of the Halo Tracks we modders spent lots of time building and playing for that game will be unplayable online. Without emulators, our hardware will crap out too. This kills the game. Game devs and players benefit most if games can run everywhere forever, but most console makers are directly opposed to the game industry's benefit: They benefit if games can only be played in one place for a limited period of time. I really hope SteamOS takes off and breaks the cycle of needless game death. Art should not have needless death sentences applied.

Re:Stop fragmenting

[gweihir]

They are not fragmenting, they are deriving. As long as they offer their patches back to Debian or the upstream from there, everything is fine.

Re:UEFI excludes too much

[Anonymous Coward]

Reddit solved this yesterday.

http://www.reddit.com/r/SteamOS/comments/1su4t1/uefi_requirement_with_steamos/

P state driver audio issues?

[deviated_prevert]

Interesting that Intel's frequency scaling causes audio pops so they disabled the p state drivers at the kernel level. As such this release might work well as a DAW if one were use Ardour or ecasound with jack. I am thinking about setting it up for this purpose and seeing what kind of RT performance it will achieve. Ubuntu Studio is interesting but far to convoluted and difficult to modify to ones liking. Seeing that this system is using sysvinit, coding called functions will be much easier to script and run. It would be really great if it can be tweaked to do high bit rate audio recording and broadcast in realtime streams over networks. Nice to see they are paying close attention to audio problems caused by the system at the kernel level, this release could become much more than just a gaming platform.

tl;dr stfu foad lrn 2 troll n00b

[gman003]

You've basically revealed yourself as a moron who doesn't know what he's talking about but thinks he knows better than everyone else anyways.

SteamOS is an OS designed not just for gaming, but for a specific subset of gaming - using a controller and television instead of a mouse, keyboard, and monitor. The UI needs to be significantly different. You know how everyone bitches whenever an OS tries to reinvent the UI so that it works on both tablets and computers? This could have been the same situation, but Valve was smart enough to realize "hey, nobody wants to use a 10-foot UI on a 23" monitor, and nobody wants to type with a controller when they have a keyboard. Instead of pissing off our existing users *and* alienating the new target audience by making a compromise that fails at both, let's have two completely separate modes".

That's what SteamOS is designed for - a difference user interaction method. Or to be more precise, that's what Big Picture Mode (the Steam mode that SteamOS boots to) is. Big Picture Mode can be enabled as the default on any Steam install (Windows, OS X or Linux), and it's relatively simple to get Steam to launch by default as well.

However, SteamOS includes more than just a few default UI settings. There's the incredibly simple installation script - it offers very little customization, but it requires almost zero knowledge outside "getting your computer to boot off media instead of primary disk". That's essential for this particular niche, but would you want Debian dumbed down like that?

Or the stripping of unneeded crap. As I read TFA, I learned they built a rather customized compositor focused on game performance. Doesn't work too well in windowed mode, but it works well for fullscreen with UI overlays. Does that sound like something Debian ought to use?

Same for their kernel tweaks (some realtime scheduling stuff and disabling things that caused bugs with games), or their stripped-down install, or the dozens of other changes people are still trying to find.

But here's the thing - they are making almost all of this available as patches. It's open-source, except for Steam itself and the improved proprietary drivers. If Debian sees a use for these changes, they can merge it in. But to counter your inevitable repetition of "just make it a patch shit-gargler", you need to look at Valve's logic.

They saw Windows 8, and they were afraid. They realized that as long as PC gaming was reliant on one company (Microsoft) for an essential component, and that company has not just apathy towards PC gaming, but an outright reason to try to kill it in favor of their higher-profit-margin console, no matter how well Valve did at making games or keeping Steam running, their business could be destroyed. And with the Metro stuff and the locked-down app store, they saw a direct death threat. Shortly afterward, they started pushing their Mac port harder, and started work on the Linux port.

Given that history, would you really expect them to make themselves reliant on someone else for their console? Their thinking is basically "if we control our own OS, even if every other OS maker turns hostile to our market segment we can still keep it running". They have no problem with people running Steam on Windows or Ubuntu or Debian or fucking Slackware for all they care - but they want to make sure that there's at least one OS that will *always* be there to play games on. Hell, they even recommend Ubuntu+Steam for the old desktop experience, not SteamOS. Nobody is going to be rebooting into SteamOS - they'll be running it as the only OS on the machine because it's the only one that's usable on that machine's setup.

But everything I just said was kind of pointless, because you don't understand the very issue you're bitching about. Fragmentation on Android is a problem because programs that use new features do not work on old versions. Fragmentation of window systems or other APIs is bad because you have to write a new version for each system. And desktop Linux dislikes f