Slackware ships on a DVD, and a full install is about 5-6 GB. But it certainly isn't bloated. It's one of the quickest and most stable distributions I've used, so I hesitate to say that adding more stuff to the Ubuntu install justifies people calling it bloated. Ubuntu's selection of software is still conservative in quantity. If anything would be blamed on bloat, it would be implementing it in such a way that it negatively affects your system's performance. So if they're adding unnecessary things to the system startup, or a lot of background processes that you don't use, then that would be bloat. (In Ubuntu's case, this has been happening, but it started long before they ever decided to ship a release that was too large for a cd.)

The original poster has a good point. However, I don't necessarily have an issue with closed source game releases for Linux, provided they don't have any sort of DRM involved. There's nothing wrong with closed source software (provided there aren't any ridiculous software patents involved), and having that software available for Linux gives the user the choice of buying it, or skipping it in favor of an open source solution. But that choice is important, as it provides the impetus for people using other platforms to migrate over to Linux.

But, I will admit that as much as I dislike OnLive, it's good that Linux users have the choice to use it if they wish, just like they have the choice to support closed source games.

I have 2 rules for any PC game I buy:

1. No DRM. No exceptions, not even Steam. I don't care how much I'm drooling over an upcoming game. If it has DRM, I'm not touching it.
2. No console ports. Said game must be developed for PC first. I don't care how well it was ported over from console, I'm not interested.

These rules are actually pretty easy to abide by, as nowadays I just don't have as much time for gaming as I used to. Plus there are a plethora of indie games, not to mention the whole catalog from GOG, that I can turn to if I want something to play.

How serious am I about all this? Deus Ex was my all-time favorite game. I'm not even considering DX3, because it fails to meet my criteria.

I started using Slackware with the 13.1 release last year, and I've been hooked ever since. I love the amount of control I'm given as well as the simplicity of the design. Plus it's fast, stable, and secure. The releases tend to be pretty up to date, and the packages that use an older version I really don't mind all that much. Granted the initial setup takes a bit of work, but once that's done, I never really have to touch anything else. The package system is actually pretty flexible and reliable. The official packages are guaranteed to work, and using the Slackbuilds website, third party packages are relatively easy to acquire. If worst comes to worst, it's easy to wipe everything back to the default package setup, as well as the default configurations.

I've installed it on my home desktop, my ancient laptop (for testing stuff out), and my netbook, and they all run quite well. I definitely recommend Slackware for anyone who wants more control and a better understanding of their system, without sacrificing speed and stability.

It warms my heart that even though there are so many overblown, superpowered, mentally gifted, overwritten superheroes out there that can fall into this category, many members of /. are dropping mention for a simple bumbling inventor whose inventions don't always work as intended. (It's probably because the stories tend to be more interesting that way.)

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.

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.