From what I understand, there are three major challenges to developing a game for Linux.

The first is using cross-platform libraries. Instead of focusing on DirectX, the developer would need to use libraries like OpenGL, SDL, and OpenAL. While this does take a little more work, most developers nowadays end up using multiple libraries, especially when cross-developing for consoles and PCs. The standard practice is to implement one's own container API, which would be able to use multiple types of libraries and still present the same interface for the game itself. This makes swapping between something like Direct3D and OpenGL relatively trivial, and is pretty much required if a game is being developed for consoles and PCs.

The next challenge is that the game needs to recognize a POSIX-based filesystem. This can be somewhat tedious to implement, especially if some paths are hardcoded into the game (bad practice!), but in the end it would be less work to do than accommodating cross-platform libraries.

The last major challenge is linking the libraries. There are two main methods of linking libraries when compiling a program. One can either dynamically link the libraries, so that the game would use DLLs/SOs to access functions for OpenGL, OpenAL, DirectX, etc, or one can statically link the libraries, so that the game has the code directly built in and has no need for DLLs/SOs. Whereas in Windows, one can simply put the DLLs required in the install directory of the game, on Linux programs aren't installed in their own directory, but rather the components of the game are installed in specific directories. For example, the executable is stored in a bin directory of some sort, libraries are stored elsewhere, and data is stored elsewhere. This means that on a regular installation, the SOs would NOT be installed with the game, but rather installed as their own package and the game would utilize it. The problem comes when the SOs are updated and their interface is changed from whatever interface the game uses. On Windows, the game would continue to use the old, out of date DLL that is provided in the game directory, but on Linux the game would try to use the new SO and would fail due to the changes. Most open-source projects are maintained by the community, so even if the original developer stopped supporting the software long ago and had no intention of updating it to fix the incompatibility, the community can step in and make the changes. This is usually not the case for commercial games.
The solution is to compile the library right into the executable itself. However, that brings its own problems, such as potential security issues, a larger executable, old libraries using resources not available in new versions of the Linux kernel, etc. I'm not familiar with all the solutions to this, but I'm sure there are plenty of ways to do it. (A wrapper class translating old SOs to new interfaces seems ideal to me.)

There are other minor issues that may come into play when developing a game for linux, but these are the major ones that cost the developer the most time and effort. Someone mentioned that different distributions would be an issue, but this is not the case. Granted different distributions use different package managers and installation methods, but the overall method of installing something on Linux is exactly the same for all distributions. The company can either release an installer that automatically builds a package for whatever distribution the game is being installed on (the ATI installer for videocard drivers does this pretty well), or they can make their own shell-script to install the game (which should be fine as long as they provide an uninstaller, as the package manager of the system would not recognize the installation through this method), or they could go the Unreal Tournament 2004 method, where the game is simply copied into the user directory and run locally (this has its own minor issues, the biggest being that the game would only be available to one user unless they did a bit of monkeying, but it still works just fine).

In any case, Valve has already taken care of the first two challenges for their Mac release, and the third challenge shouldn't be a major issue. The only reason I can see them holding back on a Linux release is whether it would be worth the time and effort commercially. One could definitely say that yes, it is worth the effort, especially seeing the statistics various indie developers have posted about releasing games for Linux. The Linux gaming community is growing, and it will continue to grow, so while it may seem small right now, it won't necessarily be this way in the future.

So I'm not sure why Valve would not release a Linux version. Perhaps someone can point out an aspect of Linux game development which I have missed. I'm pretty sure I've covered them all, but I've never developed commercially, so I can't be certain.

I think the most important experience a child gets out of this is that they learn to solve their problems themselves, without adult help. If a child grows up relying on an adult to solve their problems for them, they will rely on external assistance when they have problems in their adult life. If the child steps up and resists the bully themselves, they will learn to rely in themselves in their adult life.

The way the child deals with the bully doesn't necessarily need to be violent. More often than not, bullies pick on those who provide the least resistance and are the easiest targets. If their victim starts resisting, they become too much trouble to bother with and the bully will abandon them as a potential target.

There are limits, of course. If a bully is too dangerous or resistance may end up with the child getting hurt badly (as opposed to just a mild beating), then an adult should be brought in to assist. But for the most part the child will be able to handle it themselves.

It would be great if we could get an open source CAM software to compliment it.

Thank you. You put it more clearly than I did. :D

Just to quickly clarify, when I say consolised, I mean that certain design decisions in the game were made to make the game easier to play on a console rather than a PC. While this is a good thing for the target console, it's generally not ideal for the PC version. This doesn't necessarily need to be a problem, if the PC version of the game eliminated these design decisions, but most developers don't have the time or the money to make proper platform optimizations in design, instead opting for focusing on the lowest common denominator (the console, since they have to make the control scheme work with a gamepad) and then tweaking this design to work with the PC.

But you are correct. It's the hybrids that end up sacrificing much, though I see that they tend to come out better on the consoles most of the time. (There are exceptions, of course. I hear that Mass Effect 1 was better on PC.)

I'm not arguing that console gaming is inferior in any way. There are plenty of console games that I enjoy playing with my buddies. I just enjoy PC games more, and when a game that should have been excellent on the PC has been compromised by the design decisions to make it work as a hybrid, I get somewhat disappointed. (Supreme Commander 2 is a recent example of this problem.)

Agreed. All the major PC games I purchased last year were PC exclusives, with the exception of Dragon Age. (And even there I was rather disappointed with some of the consolized design decisions, though it did do better than most of the other PC ports out there.) Companies like Stardock, Valve, and Blizzard prove that profits can be made in the PC gaming sector. (I don't even like most Blizzard games, but I'm glad they still support PC gamers, so I may consider giving them my money in support.)

Indie games are starting to really come to their own on PC, since it is an unrivaled platform for developing and distributing, especially since the profit margins for selling in the PC marketplace are so much better than something like XBLA. Plus there are tons of free games that are amazing as well. This past year I've spent more money on indie games than on big budget games alone.

I think the main issue for big-name developers is that they force themselves into huge budgets, trying to make games with hyper-realistic graphics, famous voice actors, etc. They just end up being so expensive that the only way to make a good profit on the game is to have big sales, and at the moment, consoles do indeed sell more because they're more accessible on a mass market scale. However, to have big sales, the game not only has to look good, but to appeal to the general gamer population, which means watering it down to be generic enough that a large amount of people will buy it. The result is a bland and uninteresting game with overblown production values.

The perfect example of where PC developers should be going is Sins of a Solar Empire. During development, the budget was limited, resulting in a game with slightly lower production values, but something that still looked fantastic, and as an added plus it ran on a wide variety of machines. Plus the core concepts of the game were still there, and while this focus meant that the game wouldn't appeal to the entire gaming population, it did appeal to a significant group. Add to the mix a lack of DRM, and there you have a game that was a dream for many PC players. The results show in the profit margins, which are higher than many of the large budget games out there. Granted you have beasts like Modern Warfare 2, but how many other big-budget games sell anywhere near as well?

And then there is the lock-in that a gamer experiences with console games. If the company decides to stop supporting the game, you just can't play anymore. (See Halo 1 and 2 on the XBox, and the whole slew of EA titles that lost support.) Meanwhile, I recently reinstalled Descent 2, a 15 year old game, and found a fairly active online community that still plays. (To say nothing of the Quake community.)

In any case, I've always been a PC gamer, have never had a console, and plan on staying that way for a long time to come.

I prefer Warsow as well, bit I see it as potentially having a similar problem to Nexuiz. The ownership of the game name is under the control of one person, and while the code for the game is open source, the media is under a more restrictive license. (The reason for this license is that some media contributors were unwilling to have their work under a share-alike license, so the dev team was forced to adopt the current license to appease them.)

This means that should the owner decide to sell off the game like Nexuiz's owner did, the Warsow community may have a similar problem. It may be even MORE challenging, since any fork of the game would require completely new media, as only the code could be forked. Fortunately, the owner of the Warsow name is actively involved in its development, and seems to be a pretty decent guy in general, so it's unlikely this situation would come to pass. Still, there is that potential danger, which does make some of the community a bit nervous over the state of the game . . .

For that project, I'd recommend they change the media license and remove those parts of the media that certain developers are unwilling to allow under a share-alike license, perhaps putting it in a separate "restrictive" download pack. Not only would this remove the risk of going the route of Nexuiz, but it would appease both the share-alike community and the devs that want a restrictive license.

What a pity. Ruse was one of the major RTSs that I was looking forward to this year. Pity Ubisoft is distributing it.
I guess I'll just have to keep my hopes on Supcom 2 and the next Total War game . . .

I've never tried Eclipse, so I wouldn't know how it handles in that area. I am quite happy with KDevelop though, and I only use Codeblocks because it has a Windows version (back when KDevelop was Linux only). In any case, it seems to me that in the end it's more a matter of people being used to VS, rather than other IDEs lacking in capability.

All of these things I've seen in the other IDEs I've used. C++ code completion is in all of them, and viewing the data in complex structures (including STL) is in most of the modern ones.

I used Visual Studio quite a bit, and I'm not sure why everyone seems to think it's so great. I've used Codeblocks and Kdevelop since then, and find that I much prefer those IDEs. Lately I've been working on using Vim as an IDE, and after a bit of adjustment, I'm pretty sure it will end up being my IDE of choice. As for debugging, gdb does an excellent job. (And those complaining about setting breakpoints . . . have you even used gdb?)

I'm rather curious though. What features does VS have that make it so "superior?"

I'm currently working on switching away from my IDE to vim. There are plenty of plugins to put it on par with most IDEs, and honestly, a lot of the stuff in modern IDEs is just fluff. As for loading down Vim with all the extra stuff, I don't have the plugins autoload, but rather load after I run a script to transition it to my own "IDE Mode." This keeps Vim small and fast when I'm doing ordinary editing. I'm still in the transition phase, so I may not have seen all the disadvantages yet, but as far as I can see, the advantages outweigh them.

I'm also aware that Emacs does it quite well, but I'm more of a Vim user, so I'll stick with that unless I run into a wall and have to use Emacs in Viper Mode instead.

In my experience, most Linux distributions come with wifi drivers that work for just about any machine nowadays. The main issue is the software, and often the default software is lacking for some activities. However, WICD is an excellent alternative to the default network managers, and it has always worked flawlessly for me.
(There was an issue with hidden static networks recently, but from what I gather, that's been fixed in the latest version.)