Much as a multitude of snarky remarks can potentially be made about the “gaming press” being incredibly astute in regard to lacking awareness of anything external to themselves, the coverage of SteamOS this week has been deserving of all of that scorn and so much more. To take a high-profile example, Polygon’s musings into what Linux is and what it matters were headed up by an eight-year-old screenshot (or, if the benefit of the doubt is being given, a build designed for long-term stability that is still yet to go down) that managed to represent everything that has been levied (unfairly, for the most part) again Linux-based operating system user experience. Perhaps, more surprisingly, developers were decrying the terror of the Linux ecosystem in terms of the difficulty of porting software to the platform. This is somewhat tied in with the Polygon exercise in time travel: there was a time when huge issues existed in porting software, particularly when this porting was being undertaken from Windows to properly POSIX-compliant, Unix-like systems – this time is not now, particularly at a where use of middleware that is cross-platform, or allows simple porting between target platforms, is near-universal.
What SteamOS is – and what it could be
From what Valve have released, it seems likely that SteamOS will work in a similar way to most Linux distributions, featuring the Linux kernel, the GNU userland, with either X.org or possibly Wayland, if Valve are feeling adventurous with their technology choices, sitting on top to provide the graphical interface. Valve have stated categorically that the operating system is not designed around being a desktop-replacement, more of a living-room-oriented, media consumption-focussed effort along the same lines as Mythbuntu: it is then likely that the front-end of OS, and key method of interaction with it, will be a graphical shell that provides the current functionality of Steam, pushing a handful of new features to customers as value-add for being SteamOS rather than Steam application customers. This is not particularly surprising from Valve: given the moves they have made with regard to pushing Big Picture, it seems that such a “couch-oriented” OS would be in keeping with the overall strategy that appears to be focussed around challenging the dominance of consoles as front-room devices. Couple this with the commitment that Valve have made to partnering with video streaming services such as Netflix and it becomes quickly apparent that media consumption is to be the focus of the product, rather than creation.
This focus on consumption means that SteamOS does have a clearly defined niche that may itself help to overcome the stigma that anything Linux has in the desktop arena: given that people are happy enough to have devices solely for media curation (provided by the Steam Store itself) and consumption (provided for by the OS writ large), as demonstrated by the profileration of locked-down media-consumption-focussed tablet and phone operating systems that strictly limit what the user is able to do, an operating system with a fairly limited use case – consumption of games, music and video – could allow for optimisation of background processing and allowing for the eking out of performance that we see from consoles owing to their fairly inconsequential background overheads associated with their operating systems. Having an OS that will run on high-end PC hardware that seeks to stay out of the way of games could have some interesting implications for pushing hardware to its limits and perhaps a breakthrough in the complexity of game AI, if the industry can get past its focus on shiny and pretty.
Developers, developers, developers: Microsoft’s campaign of Fear, Uncertainty and Doubt
Much has been made by the gaming press, courtesy of testimonials from, mainly small, developers, that the effort of porting their games to Linux would present great technical overhead that simply could not be absorbed by indie developers in a reasonable manner. There are two strands to responses to this sort for of claim: first, it seems somewhat of an odd comment to make in the face of the people being best (as in, more consistent in their efforts) at porting their games across platforms tend to be the small-to-medium-indie community. As simultaneously naive and arrogant as the following statement is: if those in a similar niche to yourself can manage to undertake this work, why would you be unable to do so? Aside from that, there would be no compulsion for developers to create and publish ports, that would be a matter of discretion, most likely a decision made from a cost-benefit analysis of the loss of that segment of the market. Fashionable though it has become to knock big-bad Valve, there is nothing particularly coercive about saying that they will act as a sponsor for a new platform which will be, to all intents and purposes, interoperable with the old platform anyway through the streaming mechanisms that they have suggested.
The second strand of response is centred around situations where direct porting is made difficult by choices of technology: the use of the Microsoft-developed technologies of XNA and DirectX, for example. Naturally, given that these technologies are sponsored by Microsoft, their presence on other platforms is limited. Also, given the hegemony of the Xbox 360 at the beginning of this console generation, their proliferation bordered on inevitable. To make the decision, however, to make software architectural decisions on the basis of expedience is indicative of the genetic root of the problem here: there is, perhaps, a disjunct between those making games and those with the architectural insight to make good, long-term, commercially-wise decisions on the technology used. Using technologies because they just happen to be available at one given time is the logical culmination of the “just fucking ship it” attitudes that permeate the software industry, whether this be games or not.
Criticising these decisions as “bad”, however, may be a little unfair: the development tools around DirectX are incredibly competent, with Microsoft’s Visual Studio being a delight to use when compared to Apple’s Xcode or the Eclipse Foundation’s Eclipse, and for a while the platform was the only credible way to get smaller games onto home consoles. Developers are, for the most part, mainly concerned with getting their games out there: it is unfair to chastise them for doing so. Additionally, due to a series of campaigns around Fear, Uncertainty and Doubt from Microsoft with regard to more open technologies (the years-long restatement of their apocryphal assertion of “true total cost of ownership of Linux servers” being most demonstrative of their attitudinal approach here), the perception of the viability of the likes of OpenGL as a cross-platform alternative for 3D graphics rendering was undermined. Combine this with the consternation and infighting within the OpenGL project in the early to late 2000s, and there is a real reason for the wholesale adoption of DirectX over OpenGL and others. Valve, owing to their in-house technical expertise and their ability to control, through Steam, a large share of the PC games marketplace, are in a unique position for driving adoption of the more open technologies. With this technical expertise also providing contributions to efforts such as the SDL project, fixing of issues in these libraries could well be accelerated, allowing for an increase in the overall quality and value of the ecosystem to developers.
The missing pieces in the Linux ecosystem
Our “open” world, however, is by no means perfect: there do remain some issues, with some of them being particularly critical. From the point of view of the PC gamer, most vital among these issues is the elements of spottiness in hardware support for advanced features of graphics cards and the lack of a single API akin to Windows’s Xinput for gamepads. Though Nvidia have committed to a greater level of Linux support in the wake of Valve’s announcement of SteamOS, and AMD have traditionally been quite open with supplying the open source community with documentation for the creation of advanced drivers for their cards, support is still spotty. As a concrete example, DOTA 2 in Linux does not run on AMD cards if the open source driver in being used: the proprietary AMD Catalyst driver must be used. Though Ubuntu’s Device Driver manager has made installation of such drivers more simple, these drivers do not tend to be the latest beta drivers which often offer far greater performance than what AMD consider to be suitable for their stable branch. The situation is remarkably similar on the Nvidia side of the fence.
Another issue, owing to the multiplicity of graphics toolkits for X.org, the mainstream graphics server for Linux operating systems, is the impossibility of consistency across differing setups of Linux operating systems. While the severity of this issue will be limited in SteamOS, with it being a fairly locked-down-as-stock system that only allows for SteamOS-sanctioned applications to be run, there may be issues when the OS is inevitable rooted with people experiencing a great deal of difference in appearance between Qt and GTK toolkit user inferfaces, for example. While this is the price of the choice that the ecosystem offers, it does not make for good user experience, something that Valve will wish to ensure to push uptake of the OS. Of course, having a vendor as large as Valve pushing Linux may mean that designers actually come to the platform and things stop looking as if only an engineer has ever looked at them.
As a massive proponent of the FOSS ecosystem, there are doubts to be had around Valve’s drive towards a shift away from the closed systems of Microsoft and Apple to the open, crowdsourced model of free and open source software. It must be borne in mind that the SteamOS initiative was borne of concerns over the potential for Windows 8 to only allow applications obtained from the Windows Store to be run on the machine. This appears to be what SteamOS is seeking to do, but with Steam as the centre of things. While Valve appear to have a far greater friendliness to the idea of powerusers being able to do what they want at their own risk, it is apparent that the motivation behind SteamOS is the creation of Valve’s own little proprietary ghetto that just happens to use FOSS software to power it. The real value for the Linux community is in the downstream contribution back into the kernel that will be made by Valve and others on the back of the release of the OS.