Hacker News Reader

Comment by rkalla | Hacker News Reader

This is effectively the software-only equivalent of a console launch.

Is anyone else skeptical that they can motivate publishers to spend time/money porting their games to the Linux platform?

Valve certainly has a better chance than most at pulling this off (and likely enough user/market data to make this seem like a valid investment) I am still super skeptical that these publishers are going to spend the time porting their AAA releases to this platform.

A good chunk of the console games barely make it to PC/Windows as it is, let alone a PC/Linux platform... seems like a tough sell.

If the goal is an entertainment OS with streaming and DVR capabilities in addition to the few Linux compatible games on Steam, that's a bit different of a story but not a huge commercial win I don't think (unless they having some amazing partnerships planned with Netflix/Amazon/Vudu/Hulu for streaming that I am not thinking of).

If the goal is to make Steam into an entertainment platform (not just games) it is interesting to watch all these platforms converge on this "entertainment delivery pipeline" solution.

View on HN

Well, there is some teasing along those lines there:

> Watch for announcements in the coming weeks about all the AAA titles coming natively to SteamOS in 2014.

But more importantly, control of Steam gives Valve a lot of leverage in this. It's easy to see the reasons for Linux support in indie games. But harder to see why mid-tier developers like Paradox or Eugen started to port their latest games to Linux. It's a good bet that some kind of a Steam-related carrot was involved there.

Juho, great call-out with the "Steam-related carrot", I hadn't really thought down that path but you are absolutely right. Valve could easily offer big discounts in their split with the publishers for the first few years for Linux sales.

My (possibly very incorrect) assumption was that the profit from the Linux sales were so low as to not matter, but maybe they can provide a catalog-wide carrot... something more significant (as you suggested) to motivate the publisher en-masse.

This was my thought also. Offer $100 in games with the console, or release hl3 only on the console.

I'm really glad you guys pointed out this was a console launch because I tried to point it out on reddit and got shut down...

http://www.reddit.com/r/gaming/comments/1mywq0/steamos_annou...

Argh, that can be frustrating. I for one certainly agree with you :D

This is likely to be coupled with some manner of hardware launch, as well. I am skeptical that the name "Linux" will be a particularly useful term in that context.

Couple that with my skepticism that they're actually shipping much if any traditional Linux userspace software, and it's even less useful to compare potential SteamOS users to traditional Linux users.

Other than that I agree that with Valve as a patron there's a lot more credibility. Steam was a long-term move, and it paid off. So Valve has a good track record and solid momentum. If they can help make it easy for game companies to port their work, taking out a significant or non-trivial amount of work and offer the carrot of sales & paying customers, I could see this taking off.

I was skeptical of Steam back in 2004 but I wasn't thinking long term enough. Launching your own operating system isn't a short term move. It suggests to me that this will only get better and more impressive over time, if Valve is as committed to this as it seems.

What are your definitions for "traditional Linux userspace software" and "traditional Linux users"? Do you consider Android to be "Linux"?

"Traditional Linux userspace software" is an informal definition, but let's say something like X. Or your average window manager. Or, say, almost anything from GNOME.

"Traditional Linux users" is another informal definition, but if you use a distro, you're probably a traditional Linux user. Contrast this with an Android user. They run the Linux kernel but the software they interface with is an entirely different breed. The statement "Android is Linux" is true, definitely, but it's inside baseball to anyone but us nerds. The Linux-y aspects are more or less invisible (by design).

I'm not trying to slight either desktop Linux or Android or SteamOS or whatever, just to be clear. I think it's a huge win for Linux, at least in some sense.

I think it's misleading to read "Linux" and imagine "desktop GNU/Linux with all the trimmings." I can't imagine there won't be some way to get that on a SteamOS machine. My skepticism is directed at the idea that Valve will ship anything which, out of the box, resembles a traditional desktop Linux experience. I expect it will be more like an Android experience than Ubuntu, with rather limited access to OS internals, filesystem, package management, etc.

Does that make more sense?

The closeness of the SteamOS experience to that of a typical desktop Linux distro is irrelevant. If it runs on the Steam Box, it will run on a Linux desktop of compatible architecture.

Considering there is already Steam for Linux, its probable that Valve will ensure Linux games run on both platforms equally well.

In any case, if there is no need for "all the trimmings", if Valve just wants to make an entertainment pipeline, then that's fine by me. It's the same kernel; this is a huge win for Linux by any measure.

> on both platforms equally well

But if they are optimizing a number of things in their own distribution, it's not far-fetched to think that games would run marginally better on the SteamOS.

I expect optimizations will come in the form of:

- GPU driver improvements (they've already been working with nvidia, amd, and intel) which everyone benefits from

- kernel patches (maybe they fiddle with the scheduler or something) which anyone could pick up

- new/improved subsystems (perhaps they do some low latency input or audio layer), which (assuming they open source it) distros could choose to adopt or not

- improving porting techniques for bringing games or game middleware to Linux based platforms (everyone benefits)

It's possible that some stuff could be foreign enough to the way it has always been done on linux that it may take some time to make it upstream (see wakelocks from Android finally turning up in the kernel under a different name and a different implementation but providing the same functionality), but if it actually improves things, eventually I suspect the mainline kernel or distros or whomever will come around.

e: fix formatting

I think you misunderstood the point of my comment.

The context was whether or not "Linux users" will pay money for software. In this respect, the closeness is only relevant insofar as it is useful to discuss "Debian users" in the same breath as "SteamOS users."

> but let's say something like X. Or your average window manager. Or, say, almost anything from GNOME.

This doesn't apply to embedded Linux, or Linux for servers, which could be argued to be just as "traditional" a use case as Linux for desktops.

Additionally, for the desktop use case, nearly every distribution uses a different window manager anyway. There are such a wide variety of window managers, I wouldn't know how to compute an "average" between them in a meaningful way. Although I use Linux for a desktop everyday, I don't have GNOME installed, and I would barely notice if X was missing and replaced by Wayland or a different component.

> I think it's misleading to read "Linux" and imagine "desktop GNU/Linux with all the trimmings."

Right. It's not Linux for the desktop, or Linux for the phone, or Linux for embedded devices, or Linux for servers, it's Linux for the living room. My point is that due to the diversity of the Linux ecosystem, there really wasn't such a thing as a "traditional" or "average" Linux Desktop in the first place, and that we can't even say Linux for desktop is the "traditional" or "average" use of Linux. Anything running the Linux kernel should be able to call itself Linux, without qualification.

That's fine, but the context was whether "Linux users" will pay for software or not. I basically agree with you in terms of the facts, but speaking primarily in terms of user behavior, each of those platforms is manifestly different.

I think it's pretty unlikely that Xorg won't be a part of it somehow. X+extensions is basically the only meaningful, portable, direct interface to video hardware that exists on linux. At least if you want the hardware vendor's own drivers (which steambox obviously would, Nouveau is not up to the challenge).

It would also mean that all the 300+ games that currently work on Steam For Linux would have to be retooled for whatever proprietary windowing layer Valve would have to invent. And Valve would have to convince nVidia to come along for the ride.

My guess would be anything that runs X.org + Gnome/KDE/XFCE ... (and the list goes on)

My guess is that SteamOS is a rather specialized flavor of linux ... akin to Android.

... Just my 2 cents.

Yes, this is a more succinct phrasing of what I meant. :)

Android is Linux, but very clearly not "traditional Linux".

"Traditional Linux" suggests to me the traditional distributions like Fedora, Ubuntu, SUSE, Debian, etc.

It'll be interesting to see how much SteamOS will look like a traditional Linux. Considering the many Linux offerings on Steam, I suspect they'd like to have executable compatibility on that level, which Android probably doesn't have. But will it be as wide open as a traditional Linux? I suspect not.

It'll probably be along the lines of Chrome OS, where you do have access to the full Linux system, you just have to work for it...

Even if the market is small, it's critical to be "first" than later. That way you get a bigger share of the market instead of being drowned in an ocean of software like on many app stores these days.

A steam-related carrot with lower fees might be a huge incentive. But when we are speculating a gaming company in the business of selling $60-$100 games might be more worried about their ability to differentiate their products from sub-$10 games. If they believe steambox could provide that then it might be an easy sell.

Remember:

The PS4 and Xbox1 both are literally built on top of DirectX11, meaning that games for next-gen consoles (read: AAA) will be DirectX by DEFAULT but will certainly not be OpenGL by default.

And OpenGL is a requirement for Linux support of these games.

How Valve is strong arming manufacturers into writing the graphics code for their games in BOTH frameworks is beyond me. I'm not sure the major engines out there support both either.

But Microsoft won a massive coup this generation with all consoles being Win7 developer kits + Visual Studio 2012 + DirectX 11.

With Microsoft providing the major tools for AAA-games, it's going to be harder going forward, not easier, for the Linux proponents to make their case and win.

> The PS4 and Xbox1 both are literally built on top of DirectX11

I'd love to know where Sony said that the PS4 uses DirectX.

They discussed it at length at GDC: http://arstechnica.com/gaming/2013/03/sony-dives-deep-into-t...

That doesn't seem to say the same thing: the article says it has the feature set, but it doesn't say it uses DX11.1+.

Edit: oh, just read MLR's comment.

Both PS4 and Xbox One are now on the X86 architecture. They also share the same GPU (with minor differences).

PS4 runs a BSD derived OS with a Sony-specific graphics library called RSX (very similar to OpenGL, but much lower level).

Xbox 360 and PS3 games threw away the fixed function graphics pipeline. Everything was done with shaders. With Linux graphics drivers nearing OpenGL3 compliance, it is much more feasible to target Linux in addition to Windows and Consoles without needing to re-architect the graphics architecture of your engine.

It will be trivial for next-gen developers to target PC/PS4/Xbox One/SteamBox.

Some clever folks might even be able to compile once and dynamically link against platform-specific graphics/platform libraries. :)

edit: this was directed at criley2 - not McGlockenshire

Isn't RSX (Reality Simulator) was just a name for nvidia graphic chipset in PS3? Oh wait, it is.

PS3 used libGCM and PSGL, which is pretty much OpenGL ES 1.1 + Nvidia Cg. Don't forget the fact that OpenGL ES isn't OpenGL.

XBox never used DirectX neither, because why would you need such abstraction if all of your target market has the exact same hardware inside? (I'm omitting fact that guy above compared Direct X and OpenGL which is retarded). It used something similar, but not the same.

So RTFM or STFU.

I certainly did confuse the RSX (ps3 GPU) with libGCM (the ps3 GPU library). I haven't forgotten that OpenGL ES isn't OpenGL - it's OpenGL minus all of the garbage.

It's also true that Xbox 360 did not use DirectX. But they DID have an abstraction in the form of the XDK (Xbox 360 SDK).

Comparing OpenGL and DirectX is not retarded - they are both competing graphics libraries that are slowly converging on the same feature set.

Just FYI the PS4 low-level library is called GNM, and their higher-level wrapper is GNMX.

(source: http://www.eurogamer.net/articles/digitalfoundry-how-the-cre...)

I was wrong re: ps4's library name. Thanks for the article. I left the games industry just before the transition to the new consoles.

With Nvidia drivers you can use OpenGL 4.3 (the most recent version). It's only the Intel drivers which are limited to OpenGL 3...

"Sony is building its CPU on what it's calling an extended DirectX 11.1+ feature set, including extra debugging support that is not available on PC platforms. This system will also give developers more direct access to the shader pipeline than they had on the PS3 or through DirectX itself. "This is access you're not used to getting on the PC, and as a result you can do a lot more cool things and have a lot more access to the power of the system," Norden said. A low-level API will also let coders talk directly with the hardware in a way that's "much lower-level than DirectX and OpenGL," but still not quite at the driver level." http://arstechnica.com/gaming/2013/03/sony-dives-deep-into-t...

Is what I was going on, but I can see that "DirectX feature set" is not the same as "DirectX", so I apologize for misleading.

The PS4 does not use DirextX, they use their own system, people are getting confused because they said it had features equivalent to 'DirectX 11.1+'.

Most major engines, such as Unreal/UDK, already allow export to Linux and consoles, so what the console supports isn't the limiting factor it was when everyone had to code directly to the metal.

As other have pointed out, you are obviously wrong about Microsoft Direct X being available on Sony's Playstation 4.

But you are also wrong in the larger picture. Direct3D and OpenGL are first and foremost abstraction layers to access the GPU. Since in a console the hardware is immutable, you can gain a lot of performance by skipping (or trimming the fat of) these abstractions.

The XBox 360 version of DirectX is very different from the PC version: it's much much closer to the metal and exposes pretty much all the GPU functionalities.

Here is a thread talking about XBox 360 dev: http://beyond3d.com/showthread.php?t=62049

There's no reason to think that it will be any different for the XBox One. Hardware-wise it's a very average PC: its sole advantage versus an actual PC is this ability to get that much closer to the metal.

So, dev tools for PS4 are still bad?

The interesting thing is that convincing AAA publishers to port merely requires them to think it'd be profitable.

20 years ago, if someone asked to raise a quarter of a billion into a video game, they'd be laughed out of the building. Now it happens often. Over the years, increasingly big-budget games got funded and created.

So, all they need to do is to replicate a similar process. First you move all the indie games and source engine games to linux to "bootstrap" your market. Maybe make them free or a few bucks. Once you have a paying userbase from that, you show financials to bigger fish in an attempt to draw them in. Lather, rinse, repeat.

Even better is the fact that publishers love "free money" that doesn't require them to gamble. A port of an already successful game is much less risky than a new game. And (conditions permitting, like engine support) it costs a very small amount compared to the actual budget. So they can work on smaller margins to still turn a healthy profit.

I believe Humble Bundle has a partnership with a consultancy that will take care of porting a game to other platforms to enable their Mac/Linux/Windows value proposition. Valve could probably do something similar (though I imagine it's a lot more work to port a AAA game than an indie platformer).

If you're using an off-the-shelf engine (Unreal engine, say), it's probably somewhat easier, as some of the work would be one-off, at least in theory. But I don't honestly know how that breaks down.

Most off-the-shelf engine support Linux.

This include all Quake engine variations (including Source, and GoldSource) and Unreal variations.

and probably the branched version from activision used in their `call of duty` franchies.... -_-''

Don't forget Unity, and C#/XNA support via Mono/Monogame.

I can't speak for recent Humble Bundles, but the linux experience of earlier ones was inconsistent to say the least. Some games were as if they were intended to be native. Others just didn't work or actually didn't exist. Others worked, but were buggy... and never got the update fixes. Maybe they have become better?

Yeah in the recent bundles it has been much better.

Interesting, where did you hear that?

Total production costs of the famous Atari's E.T. (1982) were $125M according to Wikipedia. It's more than $300M in 2013 dollars.

Which works out to $25 million to get the E.T. license, $100 million to make millions of cartridges to bury in the desert, and $200,000 on actual development.

That ratio explains a lot.

I think I have read somewhere that the cartridges being buried in the desert is just a hoax.

http://www.snopes.com/business/market/atari.asp

Next Generation Magazine reported that Atari earned US$25 million in sales, but netted a loss of US$100 million.

Doesn't seem like it was a good idea, though.

Not so simple nowadays.

Games are not fire and forget anymore. Now it's all about downloadable content and In-Game-Currency (which is basically a way to allow gambling legally)

Just being profitable initially doesn't mean jack. I think everyone learned that from the emails from Jobs and the Printing industry (and what i'd give to read the ones with the music industry...)

Pfft. Most big ticket games continue to be the familiar standalone titles without any in-game purchasing models. Sure, DLCs and 'season passes' and the like are more common. But the vast majority of money that a big AAA title is going to make continues to be made in the first few weeks of its release. Being profitable initially still means a great deal indeed. It's still what franchises are made, or broken upon. You have to really be drinking the kool-aid to believe that the fundamental economics of gaming have been upended by a few obnoxious trends du jour.

Not true. Most big AAA games and the higher quality Indie Games you just buy once, and you get the whole version. Examples are Minecraft, Braid, Fez, for indies, and pretty much all AAA titles are buy-once... Even many of the higher quality Android titles are a one-time purchase.

I'm pretty sure those titles do not have much leverage on the deal discussed there.

It's far more trivial to port now that PC and Next-Gen consoles are all X86.

Valve has three announcements this week: http://kotaku.com/looks-like-well-hear-about-valves-new-hard...

One of the announcements is widely believe to be the long-rumored Steam Box hardware...

Why would they announce the software separately from its #1 use case?

Casual vs Hardcore gaming. If they announce the console first, and it's not able to run the latest and greatest games on their highest resolution they stymie the idea of being able to run SteamOS on a high end gaming rig.

This way people are thinking about how they can run SteamOS on their existing hardware before thinking they need to run it on a Steambox.

well, the next icon on this page http://store.steampowered.com/livingroom/

sure looks like a box enclosing the circle that turned out to be the OS. It's not really a separate announcement as this is all part of one unified event.

Third one is more interesting since they already announced streaming from Steam to SteamOS.

Maybe this? But who really knows, with Valve:

"SteamOS will be available soon as a free download for users and as a freely licensable operating system for manufacturers."

Same reason Android was announced before the first phone: because surfing the wave of rapidly improving hardware is part of the plan.

Valve likes to escalate announcements. It would be very "Valve" to announce the OS, which can run anywhere, and then next announce the box they want you to run it on.

...and then announce the game that you'll be playing on the box?!?

No, it's not half life 3. The logo for the 3rd announcement wouldn't make any sense then.

My thought is to temper disappointment. If they announced the steam box today and it ran a flavor of Linux it would be a disappointment. If we know about steam OS for 48 hours before the steam box announcement, we would all expect the steam box to run steam OS.

Yeah, but you know that we'll only get two announcements and the third will be delayed indefinitely.

From the iconography on the main page I'd guess the second announcement will be Steam hardware and the third one will be Half Life 3 (second circle indicates software product again?). Pure speculation on my side here.

http://store.steampowered.com/livingroom/

We know that the circle represents the SteamOS. The brackets int the second announcement must represent SteamBox. The third announcement has two circles with a plus sign in between which has to do something with connectivity to other players. Probably an equivalent of Xbox Live. ( My bet for the name is SteamPipe :) )

If Half-Life 3 was represented it would have to be a sign inside the circle as it is mainly a singleplayer experience. Also a single game as a third announcement is way too narrow-minded as Valve already has the one of the most popular games (Dota 2).

The SteamPipe name is already used for their content distribution system: https://developer.valvesoftware.com/wiki/SteamPipe

Steam already has most of the xbox live functionality. Friends list, messaging, voice chat, online store. I think the only major missing piece is probably 'parties' though maybe that's in there (I've never had much of a need for it personally).

Why is the circle off to one side of the box. Maybe I'm reading too much into it... but perhaps it could be a game controller and not a set-top box?

That could be interesting... but I must say, the Xbox360 controller is fantastic, inexpensive, and easily integrates with a PC. Sort of a solved problem, if you will, so unless they have significant value to add, I'd hope they'd focus elsewhere.

but microsoft can simply make the xbox360 controller difficult to implement in other games (tho i don't know how they'd do that…), and would effectively stop indies from supporting it. Having a proprietary controller, but coded using an open library (akin to what the steam workshop does), might mean that it's easier to have games implement controller support that's not fragmented.

It's a standard USB HI device, you don't need any kind of MS code to use it. Changing it would make it incompatible with their existing xbox360 install base and games for windows. I guess they could stop selling the xbox360 controller, but why would they when it's making them money?

Valve took out a patent a while back on a gamepad where the fixed D-pads were replaced with sockets that could accept a D-pad, a trackball, extra buttons, etc: http://gamerant.com/valve-console-controller-hold-137072/

I will be so Goddamn happy if they're actually making that thing. I love modularity, and a trackball gamepad would flawlessly combine the convenience of a gamepad with the precision of a mouse. Several groups have tried to bring one to market, and studies have shown their superiority, but apparently they were too weird to get enough preorders. Hope hope hope...

The third icon could be O: Steam OS + O: Orange Box 2. Orange Box 2 may include Half Life 3 and more.

Damn now you got me exited..., No! Half-Life 3 is still far far away.

We now know that the circle is SteamOS. Then, the second announcement would be "SteamOS in a box", and the iconography of the third announcement is "two SteamOS". This probably has something to do either with playing or sharing with friends, or more details on streaming games from another machine on the network.

Come to think of it, Dota2 just mentioned recently an update that either just came out or is coming out in a few days that would allow you to play a Dota2 LAN game. Perhaps the third announcement will be more along the lines of sharing a game only you own with friends on your LAN, for that sort of purpose?

Back to the halcyon days of yore, when a single copy of Starcraft was all you needed for a great night of LAN gaming for a number of people. Allowing 'spawned' copies for friends to share for gaming would make co-op games so much more fiscally bearable.

Steam doesn't properly support sharing games still. You can share your entire library and if you aren't playing anything at all, your friend can play a game from your library. Which you could do already, you just had to give your friend your password. Currently me and my brother share a library just fine by having one of us set steam to offline mode and then we can all play at the same time. It's less useful than the old behaviour, but without sharing your password. Oh and you can save in the cloud and earn achievements personally for yourself. Excuse me while I vomit.

Useless.

> iconography of the third announcement is "two SteamOS".

Two Steam OS added together. I think it means if you get two devices running steam you can combine them to increase the available resources for playing a game. Possibly some kind of build in clustering API that steam games can use.

As this is as good a place as any to record my guess, I'd go for some sort of virtualization.

O = SteamOS

[O] = Hardware partners Steam box (in tiers inc. an inexpensive stream target box for $99)

[O O] = Being able to run a SteamOS game on your Windows system. Think DOSBox or HyperV.

If they could do this then really it's a case of convenience vs performance, and a few exclusives or two would push people to dual boot rather than VM it.

It could also be the way they plan to stream, i.e. a self-contained mini-OS that runs under Windows but streams out/in visual and inputs. The 'local' version fits ok with that, in that you can run a SteamOS title in Windows by localhost'ing it really.

Just speculating, but it's interesting to think about.

A 99 dollars havfdware? That would stink bad in terms of performance.

I was just thinking a dedicated OnLive / ChromeCast like wee box for the LAN, perhaps with a Valve designed controller (i.e. an analog something). All real processing would be on the host SteamOS PC really, with dedicated hardware to help reduce lag on the stream.

I think you didn't read the announcement correctly. Sure the box can do streaming but it is also expected to run "native games". So, for streaming maybe a cheap box is OK, but for actual gaming on the box, you'll need something way more powerful than what you can get for 99 dollars.

That's why I used the word 'tiers' if you read more carefully. The bottom tier may be an inexpensive streaming box, the highest tier may be a high performance dedicated gaming PC running SteamOS.

Got it. Then I agree, such tiering is possible.

The controller is the most interesting hardware component, the rest can improve over time much more easily.

Steam OS needs to be on the Public Domain like an Opensource Project..Which it will most likely be..

In addition to that the Hardware should also be opensourced, like how to build the most optimal gaming console to work on Steam OS...

But It will all come down to the gaming pad, how the gaming pad will be designed and how it will integrate with build your own systems

Steam OS needs to be on the Public Domain like an Opensource Project..Which it will most likely be..

Steam is a DRM platform with a few user features on top. Releasing an open source platform would be as uncharacteristic as suicidal.

Have to think about it like android, FOSS linux base that in most cases ships with a non-FOSS storefront application from its primary contributor.

I don't think game publishers would trust their cash cows to an Android platform either.

If I were them I'd make Half Life 3, Portal 3 and whatever next versions they have of their own games, exclusive to their own Steambox, at least first months or so.

They might not get as much money on the games themselves initially, but they'd make so much more on the hardware (they don't need to all Blu-ray and all the extra crap, so they could be profitable on it), and it would also be a great way to seed their console into the market, so developers target it.

Alienating their main user-base for the sake of promoting their own console seems like a high-risk play when most people already are aiming at spending their "console-allowance" on the PS4 or One. The Steam Box is supposed to be modular (upgrade-able), while being strictly plug&play, this alone gives it a huge edge over existing consoles. Now we know SteamOS will be Open Source, and we know both Nvidia and AMD are commited to improving Linux drivers. What that means is AAA-titles don't even need to be ported, the Wine layer is able to provide 1:1 performance as proven with for instance World of Warcraft. The Wine devs don't even have the luxury of source access like game developers to.

All in all, if Valve does this right they're sitting on a potential goldmine.

Too bad PS4 wasn't based on Linux, too. Both could've helped Linux games a lot more.

1. Steam

2. Steambox

3a. some VR peripheral (looks like a VR goggle/headset to me)

3b. some special cross-play between Steambox and Windows/Mac/Linux

3c. cross play between steambox and PS4

I hadn't thought about the possibility that day 3 could be about their VR stuff. Abrash has been beavering away on all that stuff for some time now. It has also been a fair while since he posted anything up on his blog (July 26, 2013): http://blogs.valvesoftware.com/abrash/

I am sure it will be just 3b or 3c. a VR peripheral would be a long shot but I would be glad to be wrong. :)

1. SteamOS

2. Steambox

3. It looks like two sets of wheels from side on. Gaben is giving us all A NEW CAR!!!

Honestly, I think that what Valve's going for here is they're trying to generate hype around a "new platform" that's actually an existing platform that's underutilized. Valve sees that there's a lot of what's effectively free RND work going into Linux as a platform for gaming, but that no one's taking advantage of that.

I think SteamOS is just going to be a highly tuned distro, since Valve really doesn't have the man power (or the internal motivation) to build an entirely new platform. However, they are trying to make it seem like a new and different platform so that the distributors and studios will take notice and say "Maybe we should develop for this." In doing so they'll be developing for Linux at large, they just might not know it.

Valve has the resources; it's more a issue of internal commitment, which I agree they don't seem willing to make. To make SteamOS a serious contender to NXE Dashboard or CellOS they'd need to:

* Develop a XrossMediaBar like UI

* Devote resources to Wayland or Mir to reach production quality

* Create a new audio subsystem, or bring OSS v4 up to date for Linux

If I heard something like Valve dedicating 5 programmers on Wayland and 2 on OSS, SteamBox could be a serious contender for my next console purchase.

> Develop a XrossMediaBar like UI

What's wrong with Big Picture? It's very usable and has replaced XBMC as the primary interface on my HTPC. It's already almost as functional as any console or media center's interface, all it really needs is a system settings area.

They don't really need Wayland right now, and OSS isn't required for gaming on Linux. I've been pretty happy with xorg + pulseaudio + alsa and their Steam for Linux client. I've been surprised at the quality this early in the game.

I'm still a bit amazed that they've released a Steam for Linux client that works as well as it does, and that they are iterating and improving it so quickly. They've done everything right so far, let's see where it goes.

According to an X11 dev, Daniel Stone, Wayland reduces the latency and eliminates tearing issues associated with X11.[1] This is exactly the kind of upgrade to Linux that will make SteamBox a viable alternative to PS4.

As far as audio goes, PulseAudio is fine for playing music, but a real PITA for many hardcore gamers[2][3] including myself. I found latency was terrible with Wine + PA and later saw the developers had an issue with PA too.[4]

I've been playing native and Wine game on Linux with for about 6 years now and by far the best experience I had was with OSS4 and my old SB Live. When I eventually "upgraded" to ALSA, I immediately noticed some latency in games like OpenArena.

I'd think that maybe this issue was just me, accept Steam said in their announcement, they were "targeting audio performance". If they do put some resources to clean up the linux audio subsystem, it will be a win for us all.

[1] https://www.youtube.com/watch?v=RIctzAQOe44

[2] http://www.techrepublic.com/blog/linux-and-open-source/pulse...

[3] http://ubuntuforums.org/showthread.php?t=960195

[4] http://www.phoronix.com/scan.php?page=news_item&px=MTEyODM

There are a good chunk of games that barely make it to the consoles... (or just simply never do). I think it is much more rare to not make it to PC/Windows.

A hunch I have is that developers are unwilling to target linux because of its diversity. By providing SteamOS they are providing a stable target for developers to release games against instead of trying to support all Linux distros.

Sure, but I would argue that one AAA title is worth the entirety of those games that aren't ever making it off of the PC as far as sales go (thinking from a publishers POV).

Absolutely agree with you on the unifying effect of SteamOS being a single target for devs; that by itself, as you are pointing out, will drive more development for the platform. Gives everyone a target to aim at.

As far as sales - yes. As far as profits, or at least ROI is involved - no.

Unity has made good strides in making developers think about linux as a viable target for development (and streamlining the process).

I'd say there is hope. Especially as most (and I'm guessing here) PC revenue comes from Steam anyway.

There were some rumors about Crytek and Unreal guys wanting to support Linux, too. With these latest announcements, I'm sure they will now, if they weren't going to do it before.

Exactly. And why not put the players and developers on the same platform? It's a match made in heaven!

Moving toward an upstreaming, open-source, GNU/Linux platform means that not only do they have more fine-tuned control of everything, but also that there are _many_ more sets of eyes and hands to find/fix problems and to help contribute to the gaming and Linux ecosystem as a whole.

After seeing nVidia's CEO making his keynote for a new line of video cards on a Ubuntu powered laptop[1], I have no doubt that there are many companies other than Valve that see the great potential in this.

[1]http://www.youtube.com/watch?v=8kIQWWJs_po

The announcement page claims all 3000 titles are available via streaming, similar to the OnLive service but only for your internal network, I'm guessing. Effectively working around the porting issue.

The streaming works if you have a beefy Windows machine in your house already, it's not a solution for people wanting a dedicated "Steam" console.

Granted it's a stop gap measure until they have more developers developing directly on OpenGL rather than Dx. But most people that are excited about this do have a fairly good gaming machine in their house already.

It is a brilliant tactic to migrate the considerable Steam base to the Steambox. It is transitional, of course, but brilliant for it.

Okay I have 1 beefy PC. I want a second machine upstairs.

Old Way) I have to spend all the money for equally good hardware. I also need a copy of Windows.

New Way) Just get something that can render YouTube videos well. I now have a second Gaming PC. No copy of Windows!

This opens up all the platforms depending on how they play the streaming thing. If they make this work well and release client apps on the mobile side, suddenly Steam has a domination of the whole home on a level that Microsoft has been playing at for years.

If you don't have a beefy machine, then you're probably not using Steam much anyway, which means you're not in their target demographic. (And if you were playing old games or small indies, you won't need a beefy machine to stream them).

It doesn't seem crazy that their target demographic might be people who'd otherwise buy a PS4 or Xbox; and they don't necessarily have a beefy gaming machine.

It seems to work like the nVidia Shield's streaming. Another computer on your home network handles the heavy lifting and streams the video output to your SteamOS box.

I've never had good luck with streaming a game, even on a local, wired connection. There's just way too much input lag.

That doesn't make any sense. If you can handle ~20ms of latency from your TV itself, how is <1ms of latency from a local ethernet connection a problem?

I really doubt an ethernet connection can push a full HD video frame in 1ms. The <1ms is for ping, which uses a really small network packet. Pushing 1080p HD video is a totally different matter.

ping uses whatever size packet you tell it to:

    $ ping -s 1450 192.168.11.10
    PING 192.168.11.10 (192.168.11.10): 1450 data bytes
    1458 bytes from 192.168.11.10: icmp_seq=0 ttl=255 time=0.646 ms
    1458 bytes from 192.168.11.10: icmp_seq=1 ttl=255 time=0.478 ms
    1458 bytes from 192.168.11.10: icmp_seq=2 ttl=255 time=0.469 ms

1080p video is nowhere near 1458 bytes.

For raw 720p RGBA you'd send: 1280 * 720 * 32 = 29,491,200 bits but obviously you're not going to do that. Suddenly you're not only sending data but also encoding / decoding it.

Indeed.. assuming 60fps, that works out to around 1.8 Gbps. Well within the range of HDMI, but well out of the range of your off-the-shelf router on ethernet.

..though 802.11ad is supposed to be out early 2014, and that maxes out around 7 gig, and has cooperation from the HDMI consortium to use it for streaming. I wonder if some kind of some kind of ultra-high-speed wireless dongle is in Steambox's future..

>1080p video is nowhere near 1458 bytes.

It doesn't matter, that's the point. Your MTU is almost certainly 1500 bytes. You are sending 1500 byte packets at the most. That does not cause latency. If you want to argue that we're incapable of encoding or decoding video with acceptable latency go right ahead, but doing it in response to me correcting a misconception about network latency doesn't make much sense.

Having worked on the particular issue of streaming real-time video over wireless, I can say that the main issue is not link latency.

The main lag comes from encoding/decoding. If you do it naively you encode frame-per-frame (encoding slices is more difficult), and the encoder does not only outputs iframes: you get partial frames that depend on both previous and future frames. Also the decoder does not always output frames in order. So you have to expect something around ~10 frames of latency, maybe less if you optimize everything well enough. That still means easily more than 100ms of lag.

The network is really not the main issue here.

What about scrapping the conversion to streaming video entirely and replacing it with a networked graphics protocol that allows one PC to draw on another's graphics natively?

It seems to me, intuitively, that the only ways to do that are:

1. Essentially equivalent to streaming, or

2. Essentially equivalent to normal CPU->GPU communication but over the network (and, thus, needing the bandwidth that local CPU->GPU communication has if you want to avoid slowing things down -- GigE wouldn't seem to be enough, much less WiFi, even if you consider only bandwidth and not latency.)

Well that would simplify things greatly of course, but then it means bit hit on the bandwidth.

I mean, a 720p60Hz stream in 4:2:0 (12 bits per pixel) still amounts to 663Mbits/s. You won't get that out of a gigabit link realistically (at least not over IP). Of course you could use a lightweight compression algorithm, but you'll have to divide this bandwidth by at least 5 to make it manageable for the average home network I'd say (I have absolutely nothing to back that last number, but 100Mbits/s doesn't look too scary...). And that's only for 720p remember.

I think if you plan to stream HD video over the network you have to encode and be clever about it.

>You won't get that out of a gigabit link realistically (at least not over IP)

I just got more than that using scp with no compression. Yes, you absolutely can get that realistically from gigE.

I would think that the people at Valve would be able to find a solution if anyone could... or are you claiming that this is a hard nut to crack and SteamOS's streaming solution won't end up being that great for high-resolution TVs?

Oh I'm sure if they put their minds to it they can make some improvements and clever optimizations. The thing it becomes exponentially more difficult the lowest the latency you want to achieve, obviously. <300ms? easy. <100ms? manageable. <50ms? hey, very good! <10ms? uh, I want to see it with my own eyes.

Also, you have to remember that steam won't control the encoding end of the pipeline (and if the "steambox" is third party hardware with steamOS installed, no control at all on the hardware). Which means that in the end the observed latency will depend a lot on the hardware and drivers of the desktop PC and there isn't much Valve can do about that.

So in the end I'm sure it'll be more than fine to play Civilization or Torchlight, MMOs and most RPGs but maybe not Counter Strike or Quake III.

Why are people acting like this is impossible even after it has been done? Remember onlive? Notice how the latency was entirely the same as your network latency to their servers, and there was no problem with encoding adding any (noticable) additional latency?

It would be insane to do this, but you could shove ATSC between boxes over ethernet by shoving each 188-byte MPEG transport stream packet in an ethernet frame and skipping all the layer 3 stuff. Or UDP it, if you want to route it. They probably like the idea of a difficult to route protocol keeping data on one ethernet segment.

My HDhomerun ATSC receiver certainly has no problem shoving a couple megabits of high def video over ethernet. Nor does my mythtv setup, or even just plain old NFS shares to watch videos.

You're kidding. This is perfect.

This is genius. All you need now is a micro box running windows with appropriate video card that you can stick in the corner next to your router and never have to look at again. Assuming the streaming and UX works half as well as they're playing at, they've just managed to commoditize hardware compatibility.

I don't think the importance of this can be understated.

You could do this already for years with Apple TV and Airplay mirror. The real problem is that of controls, mouse and keyboard don't match well with couch

The difference being that i can see Steam releasing the applications to make this work everywhere, while Apple has traditionally been hostile to this kind of interoperability.

It's true that Apple is hostile (= doesn't release spec, but doesn't actively make the protocol hard to reverse-engineer either, eg: the DRM stuff is limited to DRM content and not part of the protocol proper), but the protocol has been reverse engineered and there are many implementations of AirPlay nowadays.

What is the precedence on which you base your belief that, whatever protocol Valve has come up with to replicate the video stream, it will be open? I'm not that much into gaming, but Steam is a closed-source software that includes mandatory DRM for the games, it doesn't really set a precedent of openness and interoperability.

Couple of reasons. First off, Steam is the only DRM I can think of that actually adds value and makes my life easier instead of the reverse.

Second, keep in mind that they've already announced streaming inside the LAN. Having mobile apps would be a natural extension of that. (Note I didn't say that it would be open, I said they will probably release mobile apps).

That streaming is also completely not a threat to their system.

I'm not fully following you: what should these mobile apps allow you to do? Stream the video of a games running on your phone to the steambox to get to the TV?

Function as another endpoint for the stream. Instead of a TV, you have a tablet or a phone. Onlive already does this.

Many, many PC games support a controller these days.

My living room is perfect use case for this. Has an older PC just for simple games. Now it could stream my entire Windows/Steam library of games, powered by the more beefy hardware in my home office rig.

As you say, if the streaming feature works well, this is a huge win. At the very least, it should save me from running 60+ feet of HDMI/USB cables which was my original plan.

I don't know if they are going to attempt something like onlive, but this streaming is on your local lan from your Windows or Mac box.

Sure that's what I meant, I edited my comment to be more clear.

They are almost definitely going to use some sort of streaming similar to OnLive. If OnLive can beam playable game streams across the internet and all its attendant issues, then they definitely can manage to stream it across your in-home wireless/wired network.

Consider all the PC-only titles. It's safe to assume that many of them make the vast majority of their sales via Steam. If steam promises massive takeup of SteamOS, then it's in their best interests to make them available for it.

From the demand angle, lots of games are console only because they fear piracy on PC versions. But if all these console users are offered a cheap new platform they can use just as easily as their consoles, it's safe to say that many of the users who buy a steambox would start buying games on it too. Console gamers aren't going to suddenly turn into torrent junkies because they wouldn't need to. This would make the PC platform profitable again. And if they start pricing games cheaper, like Steam games are liable to be, piracy would go down even further. Lots of indie PC titles are making money after-all.

Overall, I think once it hits a critical mass it would be a fantastic idea for all parties involved.

Ultimately, what other choice does Valve have? Every single other company is coming out with its own "App Store" - few are exclusive at this point, but the tide might turn that way (already I believe Microsoft and Apple have taken steps that have made it more difficult for Steam).

That said, OpenGL is an increasingly relevant player due to WebGL, mobile devices, Apple's growing market share, etc. It is also possible to simultaneously target OpenGL and DirectX with things like ANGLE. If your game is written in OpenGL, it is relatively easy to port to different operating systems, assuming you don't rely heavily on platform-specific libraries (and if you already support Mac, it is typically even easier to port to other *nix-based platforms). If the XBox One is OGL capable (via its Windows layer), porting could get even easier.

To top it off, I'm pretty sure it will get support from at least of the few big engines: ID Tech, Unreal, Unity, and CryEngine all seem to be potential candidates. 90+ percent of games use one of these engines.

Targeting DirectX is a waste of time because Windows can run OpenGL, and players can use the latest OpenGL features on every version of Windows (ie. not have to update to Windows 8.1 just to use a newer version of DirectX)...

I'm skeptical that they can convince regular people to put PC hardware in their living rooms. Microsoft and manufacturers made a ton of effort in this direction last decade, and it wasn't half bad: Windows Media Center was a pretty decent user interface for TV-watching, and lots of "living room PC" form factors popped up (remember the ubiquitous Shuttle case?). But nobody cares. It was just too weird and clunky for the average consumer to put OEM PC hardware in his AV stack. Hard core geeks will do it, but that's not a big enough audience. Maybe that's changed enough to make this work, but I kind of doubt it.

AppleTV sells reasonably well, and GoogleTV would probably be thriving right now if the major networks didn't discriminate against its UA. I don't follow gaming that closely, but I believe most of the consoles released since the Dreamcast use a variant of the PowerPC chip that used to power Apple's computers.

Silicon is silicon; it's the UI that makes a difference. People have been paying money to have gaming systems in their homes since the 80s, and entertainment-center computers have been popular since TiVo in the 00s.

Moreover, these manufacturers are all working on "smart TVs," which is what has been keeping GoogleTV alive in spite of the entertainment industry's hostility towards it. With the right UI and licensing, I could see an LG or a Samung (or a Vizio for that matter) releasing a SteamOS-powered TV.

Microsoft had trouble getting people to run Windows in their living room. They had no trouble getting millions to put PC hardware in their living room as evidenced by the XBOX.

Calling the XBox "PC hardware" is really picking nits and missing the point, in my opinion. The problem with PC hardware in the living room is that no matter how you dress up an HTPC to resemble a piece of consumer electronics, it's all cosmetic, and it's still a PC in that it's not a fixed hardware configuration like a console. This makes the software more complicated, adds driver issues, support costs, hardware reliability is unknown, etc. The result is a tradeoff in how polished the product can ever really be. Geeks will put up with it. Regular folks probably won't. Again, my opinion.

This is alot closer to an xbox than a pc. Value just doing it via slightly different (and smarter) process. This is still aimed squarely at the gaming market it's just a bigger pass at it.

"In-home Streaming"

This one is going to be the killer I think - it means two things to me.

1. Not everything has to be ported to Linux straight out of the gate.

2. Its going straight on my living room machine! I've been waiting for the ability to use my beafy gaming PC (which is at a desk, with a keyboard and mouse) to drive games on the TV for a long time.

I don't know if that means intra-home streaming or inter-home streaming. Basically i'm not sure if that means Valve/Steam is doing what nVidia, AMD, MS, and onLive are doing or if they are doing something else.

I see Steam's long tail being more on the Indie side of things, giving the little guys a way to monetize their hard work without needing huge budgets. As long as they come along for the ride I think the platform can be grown organically. That said, Valve's own AAA titles alone will be good for the platform, so if they can get a handful of other major players on board I think it can be very compelling.

Any console has its own platform to target. When that platform happens to be Linux-based, this magically becomes an onerous and unlikely requirement.

This has nothing to do with Linux and everything to do with who wants to target Steam's pet platform (vs Xbox pet platform, etc.) Comparing this to Windows is nonsensical.

Any developer has an addressable market to target. I don't think we really care what the OS is (Win,Xbox,PS4,iOS,whatever). If there is a market opportunity, we pounce. There simply has not been a Linux market opportunity that has inspired any real business. Will SteamOS change that? Time will tell....

A large part of it may be covered by this functionality; "You can play all your Windows and Mac games on your SteamOS machine, too. Just turn on your existing computer and run Steam as you always have - then your SteamOS machine can stream those games over your home network straight to your TV!"

Exactly. Gigabit ethernet in the home (or really fast wireless) should make this pretty feasible even with twitch-based action games (we can hope!)

With twitch-based games you'll have to convince twitch-based game players of that. These are people that look up latency specs on wireless keyboards because they think that makes a difference.

And I would bet that they are enough of a minority that it financially doesn't matter. They will keep playing on their finely tuned rigs with old CRT monitors anyways.

But the average person who wants to play the latest Assassin's Creed or Grand Theft Auto over that kind of streaming system? There are lots of those (including me).

It's a dual-edged sword, as being able to stream windows titles doesn't give much incentive for game devs to fully support linux, does it?

But it gives the users a reason to switch which is important. The idea of forfeiting 300-400 games is not pleasant.

It's a stepping stone.

Valve has a lot of power. They can offer discounts and say that instead of taking 30% of every game purchased through steam we will only take 20% if it supports steam os. I'm sure developers would consider it when they can be making 10% more from every sale.

In-home Streaming seems to be backwards compility answer.

This means they don't start with empty plate like Android for example.

To keep cheap rig in living room for stream playing and media center, does not seem to be so bad idea. Most gaming will happen still whereever main rig is, but when you have friends over, you can just move to living room. And knowing steam(compared to others), I think it will be decently out of the box working thing.

Anyway, I support linux gaming, I would love to ditch windows at last.

I'd love to see Linux get 1st class graphics driver support from vendors. I pay as much for my Radeon card as anyone else, but the fglrx drivers STILL don't support X composite.

But other then gaming I never boot into Windows these days anyway.

I'd love to see them just publish docs so we can get good drivers instead. Bluescreens from video drivers are still a problem on windows, it is an even bigger problem on linux with fewer resources going into making the driver, and fewer people using them to serve as paying testers. Nvidia and ati/amd have both made it very clear that they either do not have the desire or they do not have the resources to make good drivers. So let the open source community do it for you.

I'd love to see them just publish docs

They have in the past, and got nothing but flak.

No, they haven't. They have released bits and pieces under NDA, but never actual complete docs. That's the problem. Maybe you should have listened a little closer to the "flak" to see if it was actually legitimate problems.

I wasn't nearly as involved in Linux news at the time, and it's too late to go back and change that now. Apologies for not knowing the complete details, and I'd appreciate it if you'd link me. Been having trouble finding the historical details.

ATI has released (almost) complete specifications at this point, NVIDIA has released nothing.

http://renderingpipeline.com/graphics-literature/low-level-g...

All you get is register dumps. Compare the ati and intel info on that site. Intel has released full docs. Ati has done as little as possible to be able to say "we released stuff" for publicity purposes.

Depending on who makes the hardware in the upcoming Steambox, we might finally get some decent drivers for 3D hardware acceleration. I would imagine Valve has the pull to entice AMD, nvidia, or maybe Intel to devote additional resources to it.

AMD had been releasing documentation for their Radeon GPUs, as well as supporting development of the open source radeon driver for linux (http://www.x.org/wiki/radeon/ and http://www.x.org/docs/AMD/). The open source driver just has nowhere near the resources devoted to it that the proprietary drivers have.

I wish I could do that. At the moment I still use wacom tablet and photoshop+gaming, so I spend most of the time in Win7 :/

Nvidia's Linux drivers are at feature parity with their Windows drivers. And perform at least as well...

Meaning they randomly lock up the system about once every three days?

In my case, yes. But the performance is good.

My Linux system with Nvidia graphics easily gets a month uptime; I only reboot every now and then for updates and changes to the system. Never had an issue with the drivers, even when using them for 3d gaming with Steam.

Now, don't get me started on AMD's awful attempt at graphics drivers.

I don't have any instability problems, with neither AMD or NVidia (I have a computer with each).

What kills those drivers is ongoing support. Since they aren't at the mainline kernel, they lose sync, and upgrading the kernels turns into a lottery where sometimes I have to uninstall the newest one, not a big deal, but anoying.

Are you running beta releases of drivers?

Anyway the reason NVidia has had strong Linux driver support for such a long time has nothing to do with desktop Linux and certainly not Linux gaming.

It's because Linux is huge in 3d and special effects (mainly movie, tv) and of course dominant in hpc.

However, Steambox is likely resulting in NVidia improving their Linux video drivers with focus on game performance.

No, I'm running Windows x64, so it's possible that Linux drivers don't have the same problem. I was being somewhat facetious, but the fact is that I can't run any nVidia driver after 314.22 on my system for more than a few days without occasional temporary freezes and some that require a cold restart. This isn't an isolated complaint. They have a bug, somewhere, that's been there for a few months now.

I see, I would point out that for production work you are very unlikely to be running the latest release of any video driver due to it being largely untested in the wild, no matter if you run Linux or Windows.

So the official SteamBox will come with very stable drivers for it's hardware configuration, and the same goes for third-party 'Steamboxes' aswell I'm sure.

For Steam users running on their own machine configurations it's another thing of course, but that's no different from the way PC gaming has always been.

One possible difference is that the official Steambox will likely function as a 'confirmed' hardware configuration so even if you 'build you own machine' or look to buy another offering you can use the hardware setup of of existing Steambox(es) as a hint of what to buy for the best 'Steam-experience'.

Tonnes of AAA titles are 'available' on FreeBSD - the PS3. Publishers won't be bringing their games to Linux, they'll be bringing them to SteamOS.

Except that the PS3 has a dedicated SDK... Up until now Steam has instead allowed games made with any technology AFAIK

that means, among others, Python (Analogue: a Hate Story) and Mono (Bastion)

As long as they let developers have freedom over their tools of choice, I don't think we risk any embrace/extend/extinguish outcome

Has there ever been any confirmation for the "PS3 runs FreeBSD" rumor? I've just seen FreeBSD mentioned on Sony's page listing open source components, along with stuff like expat and freetype. They've probably just lifted some bits from FreeBSD.

Hell, it could be the old Win NT thing of using the network code. That hardly constitutes "using BSD".

PS3 runs FreeBSD likes Android runs Linux.

That is, they may share a kernel and some tools, but the user spaces are mostly alien.

PS3 ran on Cell CPU Architecture. Now PS4 run FreeBSD 9.0 modified BUT x86 architecture!

Android = Linux Ubuntu = Linux they both run the same exact kernel! BSD != Linux because they are 2 different kernels.

Why do people always try to say Android is not Linux?????

if you want to go down this road Android !== GNU Linux || Android !== Linux as the first compare two OS, and the second compare an OS and a kernel. Sure they share a lot of libraries that are in use in those sort of application (more so than GNU Linux and Windows variant) but still, those are not the same.

Mind this is begging a question: with all the TV box running Android, are manufacturer going to target Android or SteamOS (More and more so called smart TV are running some version of Android)? And what about indie developer? Right now you can pick up an Android TV Box for anything in between 50 and 100 GBP.

Android uses the Linux kernel. But when one talks about Linux, one usually means GNU/Linux: that is, the kernel and the unix (or rather, not unix) userspace.

Android has little, if any, of that user space. That is, assume I have a dynamically linked Linux program: I'd probably won't be able to run it on Android, even if cross-compiled to the proper hardware, because much of the libraries and tools one expect a Linux distribution to have are missing there.

Because you don't run just a kernel. It's fairly obvious a lot more things go into an operating system. Calling Android and Ubuntu under the same "Linux" umbrella is like calling bread and pasta as "Wheat" since they use the same raw material.

Absolutely. This is my point. The fact that SteamOS is Linux is basically irrelevant to publishers, just like Android being Linux is irrelevant to app developers.

One thing people haven't mentioned in this thread is the Windows Store. Windows is already following OS X in creating a walled garden with signed software. Microsoft implementing more controls on the Windows software ecosystem could be catastrophic for companies like Valve.

Steam OS will ensure Valve has something to rely on, it will also force Windows to keep tabs on their software ecosystem.

Microsoft isn't killing the Windows Desktop (i.e. traditional windows apps) anytime soon. 99.9% of Windows users rely on it.

I suppose they could plug the hole a little including a dalvik vm and get android games running too. In theory they would be able to get a large amount of games working and kill the OUYA. I'm not sure that's in the best interest of the Steam store unless they plan to start selling android games.

I hope not. Dalvik is terrible (a legacy of Android's roots in circa 2004 Java-mobile land), I'd rather see native games, and then maybe that can help Ubuntu Phone and Sailfish OS take off on mobile...

Some of the Valve documents explicitly sell the porting to Linux/OpenGL process as a stepping stone to mobile. And given their talk of breaking pointless silos I can imagine a steam store on Android that can play any Steam game you've got the horsepower for.

link to said documents?

https://developer.nvidia.com/sites/default/files/akamai/game...

Thank you.

It's not a tough sell. Valve can offer a massively higher cut then Sony and Microsoft will do.

Porting old games no, porting new games yes.

Using the word easy liberally, Unity makes it easy to develop multi-platform games. Unreal is going the same direction.

In the past each platform had its unique limitations. Now all devices down to a tiny smart phone are very powerful. The mobile market is gigantic. Users go from device to device.

Take a look at Occulus Rift + the wireless devices used to control it. The days of sitting down with a keyboard and mouse are passing, even for the desktop users.

Google, Apple, Amazon, and others are gearing up for what are in effect micro-consoles. Other than Apple they are all Android. Its as good of time as ever for Steam to move forward.

Aren't games pretty damn portable these days? It seems like most non-firsty party titles are all multi-platform now. I don't know anything about game development but they must be developing with portability in mind.

Almost every major engine out there (ie: IdTech, Unreal Engine, Unity, Frostbite) is cross platform off the shelf.

As suby mentioned, off-the-shelf I think these engines support multiple platforms, but it is surprising (to me) how many big, non-1st-party games don't make it across all the platforms in a timely fashion. That signals to me that it isn't as easy as we might think.

> A good chunk of the console games barely make it to PC/Windows as it is, let alone a PC/Linux platform... seems like a tough sell.

True today but both the PS4 and XBone are now 8 core x86 platforms with desktop style GPUs. I would imagine most developers already abstract away the OS/graphics APIs as much as possible to facilitate porting to both consoles, adding a third platform for a 'PC port' should be much easier this console generation, particularly given that the relative pain of coding for the PS3 cell processor is now gone.

> Is anyone else skeptical that they can motivate publishers to spend time/money porting their games to the Linux platform?

All they have to do is heavily subsidize (or give away) the console they are undoubtedly working on. Right from the get-go you can stream your existing PC Steam games to your TV which everyone will jump on. When the installed base is large enough, publishers will follow.

This sounds an awfully lot like: "To be rich all you have to do is make a ton of money and then you can buy whatever you want" -- yes... I absolutely agree, but there is an ocean sized gap of potentially company-crippling decisions between "heavily subsidize/give away" and "large enough install base, publishers will follow" :)

I think the point is that AAA titles are at a low time low of market share. Indie titles could carry this platform by itself.

I hate commenting in extremes, but I am willing to bet a large volume of the blood in my body that this is false and the platform would be a total failure if this was their only play (indie games).

One GTA 5, for example, is equivalent to the sales produced by every indie game, combined, multiple times over. Even Minecraft with some $30-40mil is a miniscule fraction of what GTA 5 did opening _day_ and will eventually do in its lifetime.

Definitely chose extremes here, but I imagine the equation looks the same with any other AAA title compared to the entirety of indie titles combined.

I wrote a response to your comment but it became rather long so I decided to make it into a blog post instead.

http://mortdeus.blogspot.com/2013/09/linux-core-component-po...

Also, even for games that do have a Windows release, it's hard enough getting a Mac release most days... Linux is an even tougher sell in the current market, but perhaps that'll change if Valve can start showing some serious SteamOS install numbers?

Isn't part of the reason there are not a lot of developers working with Linux because there isn't near as big of a demand from the Linux community? This, if it becomes a popular option, it would/could increase that demand.

"porting their AAA releases to this platform"

Play Station 4 is running a modified a Free BSD 9.0 on x86 architecture. So the work to go from a BSD base to Linux I imagine is MUCH easier than what it has been in the past in my opinion.

Actually an excellent point; just dug up some info, didn't realize Orbis was based on FreeBSD. Would absolutely agree that for both the engine companies (Unreal, Crytek, Unity, Frostbite, etc.) since they are already going to FreeBSD, being able to target SteamOS as a secondary platform with minimal effort would be huge. Then hopefully abstract that effort away from the publishers as much as possible so if Capcom/Microsoft/EA/Activision decide to go SOS, it is minimal work.

If they announce Half Life 3 as an exclusive launch title for Steam OS, I think there are a lot of people who would give it a shot. Steam is a very influential and well-connected company, don't underestimate them.

It's an operating system, there are not going to be exclusive launch titles. Unless of course, you think Valve is going to release HL3 only for Linux users, but that idea is absurd.

Games run on operating systems. They revealed there are going to be some AAA titles coming to the OS. Of course if HL3 eventually is confirmed it won't be a solely Linux only release but that doesn't mean Valve won't release it for the OS though. It was an example.

With the streaming support, I'm assuming you'll get immediate access to everything that's playable on your PC. It's not a perfect solution, but certainly helps with the adoption issue.

There is no "Linux Platform", unfortunately.

I think that's what Steam is doing here. Creating a platform that doesn't exist yet, to bridge PC and console gaming.

Game developers can just use cross-platform games engines (like Unity) that support Windows, Mac and Linux.

The market is already there. Steam already has more users that both Xbox and Playstation combined.

Assuming you meant Xbox 360 and PS3, I think your stats are off:

    * Steam - ~60 million [1]
    * Xbox 360 - ~80 million [2]
    * PS3 - ~80 million [3]

If you literally meant the Xbox and PS2 from 11 years ago, then yes, you are probably correct :)

  [1] http://en.wikipedia.org/wiki/Steam_(software)
  [2] http://en.wikipedia.org/wiki/List_of_best-selling_game_consoles#Microsoft
  [3] http://en.wikipedia.org/wiki/List_of_best-selling_game_consoles#Sony

That's an unfair comparison. It should be with XBox Live [1] and PlayStation Network [2]

    * Steam - ~60 million users
    * XBox Live - 46 million users as of February 2013
    * PlayStation Network - +100 million

although PSN includes PlayStation Portable and PlayStation Vita handhelds so the number of PS3 users is probably similar to XBox given the number of consoles sold.

Also, the Steam page you referenced says: "Steam has an estimated 50–70% share of the digital distribution market for downloadable PC video games"

[1] http://en.wikipedia.org/wiki/Xbox_Live [2] http://en.wikipedia.org/wiki/PlayStation_Network

You can stream games from your desktop to Steam OS. That alone is awesome.

it all depends on how many people will use SteamOS. Costs of porting games to other platforms will also go down with the next generation as xbox one and ps4 are basically standard PCs.

http://store.steampowered.com/search/?os=linux

Valve has been planning this for a while, and has had pretty good success motivating a lot of smaller publishers to target Linux, even though the base isn't there yet, and of course have moved their own incredibly valuable games to Linux. Major game engines (Unreal 3D, Unity, among others) already support Linux as an equal target.

Dennis, maybe you are right... this is a long-game and they are just getting ahead of the inevitable (engines supporting Linux natively, eventually more and more releases for the platform).

I suppose this is the curse of the first-mover, it always seems to be risky/nonsensical until it isn't... then we all see it as an obvious move in hindsight ;)

Yeah, this reminds of the initial launch of Steam back in 2003. At first it seemed like an annoying hoop to jump through. As the years went by and it got more dependable, more games, and more features, it became easier and easier to forget how annoying it was in the beginning.

I wonder if the same thing will happen with SteamOS. At best it will initially seem like a novelty, then 10 years from now a huge group of customers will have forgotten what it was like to never have had it.

in fact, microsoft should be scared of this move - because the gaming scene is basically what keeps a whole bunch of machines installed with windows.

For home users, yes. But in the business world, it's the Microsoft Office Suite, especially Outlook + Exchange. Sure, MS Office has been ported to OSX, but it's more expensive to go with Apple Hardware than commodity PC + MS Windows.

If Microsoft flipped their lid and ported Office to run on common Linux distributions (Debian/Fedora), you'd see a lot more corporations switching.

Microsoft does have their Office365.com, which is a web-based version of Office. I haven't tried it myself, but from what I've heard, a lot of its advanced features rely on Silverlight and using browsers other than IE on Linux or Mac OSX puts you in a sort of basic mode. The advanced mode is very comparable to running the desktop version while the basic mode is akin to the Google Docs editor.

> Is anyone else skeptical that they can motivate publishers to spend time/money porting their games to the Linux platform?

no.

porting and refactoring tools are so good now you can even port a direct3d app to opengl in 2 days or less, you could use a d3d>opengl wrapper in a day of work.

libraries are also so good at dual platform it requires minimal changes (usually just a new build system).. afaik the biggest change is handling input (theres no directInput on linux - most games use directInput for mouse/kb).

theres also numerous benefits to a closed system economy like an app store - for example even if nobody uses it you are practically exclusive and will get more buys than other places you can sell your app.

I would merely make the point that if porting was as painfully simple as you suggest here, non-first-party publishers would be making their games available for every platform (in most cases) without a second thought.

Even though multi-plat development is infinitely easier today than it was even 5 years ago, I still think getting titles onto multiple platforms is much harder and time consuming than you are giving it credit.

Reply on news.ycombinator.com