They are not "just" running perfectly in the HIB. First, there are still many problems with many builds (sound, in general), second there was big drama for several of them on creation (Vessel, Limbo, Torchlight, Psychonaut) and lastly the builds don't address Linux, the many build packages given in the HIB library (support burden!) address only a subset of distros and are know to break regularly (e.g. distro upgrade).

At least for those I was playing with, it was running perfectly and tested on several distros without any issues.
At least…they tried. (Excepted for LIMBO because they just did a wine-packaged game which is have a nerve). I'm still sad that gog don't try too and it's a real problem for me…and lots of other peoples.
Btw, community can help : for example every HIB games are present in Archlinux's AUR with nosrc packages, it's helpful. Community helped to get Steam on other distros than Ubuntu and so on.

Have a nerve? Does it not work?

Maybe wrong usage of an expression (english isn't my native language).
I mean, something wine-packaged will have worse performance than a native port. That's logic. Every other devs before them made the effort to do a real port, so why didn't they followed the same rule? It's like cheating in my humble opinion.

Wine games can have even a higher performance. Wine can be only partly seen as emulation, it is more a re-implementation of the win32 API + directX than emulation. This postion was also the response to the "whiners" on the limbo port: Whining about Wine

Overall, I agree here with John Carmack that "WINE-platform"-gaming could be a way to go for linux gaming (John Carmack claims emulation is the key to Linux support, questions native ports/). Wine gaming would address existing industry accepted APIs and provide additionally a stable binary ABI, some qualities normaly missing on linux.

(As alternative, finally after the 2 decade lasting inability of the community itself for fixing this problem, Steam seems to address the missing ABI/API platform problem by a closed market model platform, sadly...)

You're doing here a common mistake. As its name explain it, Wine isn't an emulator (Wine Is Not an Emulator : http://en.wikipedia.org/wiki/Wine_%28software%29 )

Anyway, Stable and multi-platform APIs exists, but peoples still want to be enclosed in Microsoft's closed Direct X/Direct3D and so on (working only on Windows and Xbox) while OpenGL and lots of other things still to be available, for free and without any problems. Bu I wouldn't be surprised to lear that there are money flows to give priority to one technology.

Btw, if one game is working on OS X, the work to make it works on Linux is pretty small : they're cousin and have common bases. And I don't understand what are you refering to when you're talking about "2 decade lasting inability of the community itself for fixing this problem".

Usually that logic would apply. However, developing games on Linux is a new thing and native is not always better and faster. Two cases: DOTA 2 and The Cave. Both run better for me in CrossOver (wine) than their native ports

Ugh wish there was less zealotry in the open-source camp. While I do not want software to be stuck in the Windows world forever, I understand why, for technical/pecuniary reasons, some developers would use wine. I really don't get some people. They bitch and moan because there is not enough software on Linux but then they also bitch and moan when there are other ways to have that software run, and run well, (as is the case of LIMBO) without a developer having to spend huge sums of money to do a, what these guys call, *proper port*.

I have awesome performance when I play Borderlands 2 with my current rig, which is comparable to running the game on Windows. Comparable means I get at least 50-60 fps everywhere in it.

So before you start flinging poop at wine (or developers that use it), ask yourself whether or not native ports are always better? Don't Windows versions have bugs? Don't native Linux ports also have bugs? Then why is it such a huge issue when "wine" ports have bugs? Are you positively, 100% sure that what you say about a game's performance and stability being better if done natively is true when compared to using Wine for the job?

I don't however agree with Carmack. He's a brilliant programmer but a terrible business person (by his own admission, he thought Valve were crazy when they were doing Steam) Going all gung-ho on wine for porting stuff is a no-no. Why? Because you'd essentially still leave control of how things should be done on linux boxes and macs to Microsoft. Do they add new stuff to DirectX? You need to catch-up. Do they add new stuff to other parts of the OS? You'd have to add that too.

There probably does in some high-level development, especially for securing exclusives for Xbox which, in turn, use MS technologies. However, the important part is that money doesn't actually need to flow in any direction. There is no unified platform on Linux that would incorporate all functionality of DirectX (and no, even SDL doesn't do it nearly as well as it doesn't actually wrap OpenGL 3D functionality properly, even tho it's a great initiative), and all Microsoft really had to do was make a standardized, well-conceived environment for developers to work in and developers will flock towards MS technologies. So MS gave them fantastic documentation, great development tools and technology which is as simple to use as humanly possible. Linux world doesn't really have an answer to that.

I'm well aware what WINE means and what WINE is. Despite what WINE people like to claim, WINE is to a good part emulation.

As Fenixp also stated, there is no subsitute for DirectX+WIn32 (in all qualities! a bunch of libs is not a subsitute) in the linux ecosystem. Plainly, since 20 years this ecosystem failed to provide something comparable, so the best bet is at the moment to use an existing and accepted platform -> WINE platform approach.

They are right, it should be reasonable easy to make a game or port a game to a platform. At the moment it is unreasonable hard & overcomplicated. Also not straightforward and also no stable unified solutions to adress "all" the ecosystem ... solutions currently are hackish and fragile, requiring always and continous adaptions. This is not the way to go as game developers are passionated in developing games not learning the ways of linux, this is just a distraction for them. (Currently, some companies solving htis a by a specialist e.g. id with Timothee Besset...but if this specialist leaves ...no ports anymore, like in the case of id. Similar for HIB: 80% the ports are done by a handful of specialists only, Edward Rudd , Ryan Gordon and Ethan Lee)

And, no, demanding from developers that they just "have to learn" (the linux way) is lunatic, this approach failed since the 90s. It is way around, Linux has to learn the professional way of developing & deploying software, the SDK/platform way.

Now you are making assumptions. I demand nothing at all.
All I care about is getting games that are already working on linux.

You indicate that developer are lazy and ports are easy. I say, linux support & development is currently unreasonable hard. Also, your statement about the HIB games "they work just fine" is a exaggeration. While it is nice that some worked for you, there are too many reports of problems or breaks.

I would think these kinds of issues are now well on the way to being resolved though, considering that we have Valve putting a lot of resources into Linux and that big publishers/developers are now confident enough to start porting AAA titles over.

No I said that if they want to, they will.
The same can be said about Windows games too. Problems always existed and always will for that matter.