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.

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