SteamOS Has Its Own Graphics Compositor

[johnc]

The big question is, is it a media player too, so that people can replace their XBMC or Media PC's that are stationed at their TV's. If not Value/SteamOS has made a big mistake.

It would take an awful lot of effort to replace something like XBMC. That's a lot of code. It would be better to just have an option to switch between the two interfaces. Though I do understand that Valve wants to get into the media services stuff eventually.

[johnc]

This required UEFI support... what does that mean?

[e8hffff]

This required UEFI support... what does that mean?

UEFI=Unified Extensible Firmware Interface

Means that the motherboard needs to support a BIOS wrapper to upstage older PC compatibility and deliver new BIOS era.

[ninez]

SteamOS appears to be using linux 3.10 - PREEMPT_RT_FULL (unsurprisingly) with a heavy amount of patching (282 patches for -rt in the 'all' architectures/folder, alone). The kernel is also using aufs and they seem to be sitting on some bug fixes for upstream on top of that.

Some of the -rt related hacks they are using i have seen (in one case, i am using the same patch for ntrig)... It looks like they have gone to a lot of effort getting the kernel just right for their needs.

[e8hffff]

It would take an awful lot of effort to replace something like XBMC. That's a lot of code. It would be better to just have an option to switch between the two interfaces. Though I do understand that Valve wants to get into the media services stuff eventually.

Note sure if I agree. It maybe as simple as installing libav/ffmpeg and having the controls in the interface to link to the files.

[A Laggy Grunt]

So it's basically a modified xcompmgr. Nothing fancy.

Who cares if it's fancy if it's fast, functional, and reasonably secure?

[e8hffff]

SteamOS appears to be using linux 3.10 - PREEMPT_RT_FULL (unsurprisingly) with a heavy amount of patching (282 patches for -rt in the 'all' architectures/folder, alone). The kernel is also using aufs and they seem to be sitting on some bug fixes for upstream on top of that.

Some of the -rt related hacks they are using i have seen (in one case, i am using the same patch for ntrig)... It looks like they have gone to a lot of effort getting the kernel just right for their needs.

I haven't yet got into Linux Kernel hacking, but why would Value use an older kernel when the latest versions have had so much adage. It's not as if they are running a critical infrastructure outfit.

[iniudan]

I haven't yet got into Linux Kernel hacking, but why would Value use an older kernel when the latest versions have had so much adage. It's not as if they are running a critical infrastructure outfit.

Because they need stability, so they are using a LTS kernel.

[e8hffff]

Because they need stability, so they are using a LTS kernel.

I think it would have been easier to use say 3.12 Kernel and then if they find a bug then fix it for the whole community, rather than spend countless months backtracking/porting fixes for old code.

[ninez]

I think it would have been easier to use say 3.12 Kernel and then if they find a bug then fix it for the whole community, rather than spend countless months backtracking/porting fixes for old code.

Well, you may think that, but that is very uninformed... 3.12 has some weird issues with pstates (on PREEMPT_RT_FULL anyway), nohz is a bit flacky (again on -rt) and aside from that, as someone else pointed out to you - 3.10 is an LTS release... Lastly, as far as using the 'newest kernel' - 3.10 is still fairly new and linux-rt only tracks every 'even' number release; 3.0, 3.2, 3.4, 3.6, etc - So i think Valve has made the right selection, in this case...

and it doesn't appear that they have done a whole bunch of backporting from newer kernels, but it does look like they are sitting on some fixes though - while other patches are listed as being submitted to XYZ mailing list for review...