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.
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
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.
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.)
Please elaborate. I've been using OpenAL for a long time now, and I've come to prefer it to any other audio API. It may be lower-level than most, but it's fast, robust, and cross-platform. (Of course, it depends on what you're developing for, but to say that it's a joke of an API, you imply that it's useless. From what I've seen in the industry, it seems to be gaining quite a bit of momentum.)
The situation is not quite that bad, though the summary makes it seem so. From what I gather, it wasn't a major part of the development team that was released, but rather 3-4 people in a small satellite team. Of course, there would definitely be bitterness about this, especially in this economic climate, but the job cut definitely wasn't extensive.
As for AA3 being flawed, the only major issue it's had is that the authentication servers have been overloaded by the hoards of new players trying to log in and play the game all at once. Obviously something like this can't be predicted, so no one is to blame. (I'm sure many of us recall Quake Live being hammered when it was released in open beta for similar reasons. And Demigod as well.)
The game itself is a LOT smoother and cleaner than any of its previous iterations. There are some occasional bugs and glitches that need ironing out, but thus far I haven't seen anything drastic.
(Yes, I am an AA player, and I have enjoyed for quite a long time. No, I'm not at all interested in joining the US Army. I realize it's a recruitment tool, but that doesn't mean there's any reason for me to shun it as a game.)
I used DevC++ for quite some time until I found out that it was out of date as well. Since then I've used Code::Blocks, and I find it to be quite an improvement. Since it's cross platform, working on different operating systems is pretty easy too.
KDevelop is my alternative choice. For all intents and purposes, KDevelop is my favorite IDE, but since it's only on Linux at the moment, Code::Blocks is my best choice for now. (Still, KDevelop is quite powerful, and I'm eagerly awaiting the cross-platform release.)
Eclipse is also a great choice, though I haven't used it nearly as much. I feel it's a little more focused on Java development, but many/.ers swear by it, so it's probably worth a try.
And on a final note, I've been using Vim a lot more often lately, and with the IDE plugins detailed in the Ars Technica article, I may make that my IDE of choice in the near future. (For others, there's Emacs. Both are great, take your pick.)
I work at Office Depot currently, and I can assure you this is not standard practice where I work, and certainly wouldn't be allowed by any of the managers or corporate. With regards to the issue about people lying about laptops being out of stock, yes, there were some salespeople who were doing that. As soon as it was found out, the practice was halted and everyone was informed that under no circumstances was it to be allowed. (And logically, even selling a laptop without the extended warranty is better than not selling it at all.) I so know that if any of this happened at the place I work, the employee responsible would be fired with no hesitation.
It is true that Office Depot does tend to push for these warranties, add-ons, etc, but you'll find that just about every other store, from Best Buy to Fry's does the same. Like it or not, that's how the business is run. As a customer, it's annoying, but you just have to put up with it and move on in life, just as you put up with club cards, coupons, mailers, and all the other little annoyances that just about every store dumps on you these days. As an employee, it can be stressful, but it's unlikely that you'll get fired if you don't contribute to the "quota." (And remember, this is retail. Working in retail sucks in general.)
And just as a final word, I'm not a manager, or corporate, or any higher up at OD. I'm just a lowly employee working there to pay for my textbooks because the hours are flexible enough to accommodate for my classes. I don't particularly have much company loyalty, but it does tick me off that people are spreading what is essentially tabloid journalism without giving any thought as to whether it's a widespread practice, or just some individuals who are giving the company a poor image.
Agreed. The Total Annihilation engine was definitely one of the most moddable. While I'm not much of a fan of Spring, the mods Uberhack, then Absolute Annihilation, and now TA: Twilight have been the most influential TA mods in my book. While the original TA was revolutionary in its own right, these mods brought the game above and beyond many of the RTS games in the years to come. I hope their legacy is continued in Supreme Commander.
The only real problem that's plaguing it is that people are assuming that it's the complete product, rather than a work-in-progress as the development team has repeatedly pointed out. Granted denoting it as "4.0" was a questionable decision, but the reasons given by the devs were logical.
The devs had the choice of either completely rewriting the KDE framework to keep it up to date, or stick with the old system and suffer the problems that are plaguing other projects, such as X. They chose the former, and thus it will take some time to reach maturity. Meanwhile, users are free to stick with KDE 3.x, which is still being maintained.
Thankfully, there are distros like Ubuntu who are refraining from making KDE 4.0 the default until it is mature. Thus, for those who are having problems with 4.0, the problem really lies with the user, as the user would have had to make the choice to move to 4.0 in the first place. (Unless it was a distro that embraced KDE 4.0, in which case the maintainers are to blame.)
If Gnome 3 also allows for some radical changes to its framework, I expect there will be similar complaints, unless it is kept in beta until a mature version is released. This, however, could result in slower development for the exact reasons that convinced the KDE team to name their latest release 4.0.
I'm not really sure why C++ is so ill-favored lately. It may not be fully OO, but there are many times when a fully OO solution is counterintuitive. Instead, C++ allows the developer to choose whether they want an OO solution or not. I also see a lot of complaints about C++ performance in comparison to C performance, but really, when properly implemented there is little difference. The same goes for garbage collection. Granted you have to write it yourself, but program-specific garbage collection will ALWAYS be more efficient than automatic garbage collection.
I think it's generally agreed that C and C++ aren't going anywhere anytime soon, since a lower-level programming language will always be needed. However, sidelining C++ in favor of C is definitely not a good idea, as C++ does offer many advantages that C lacks. (Yes, even for kernel development.)
Slashdot Mirror
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
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.
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.)
Please elaborate. I've been using OpenAL for a long time now, and I've come to prefer it to any other audio API. It may be lower-level than most, but it's fast, robust, and cross-platform. (Of course, it depends on what you're developing for, but to say that it's a joke of an API, you imply that it's useless. From what I've seen in the industry, it seems to be gaining quite a bit of momentum.)
I have, and I love it! The Ubuntu Studio guys do a great job of putting together their distro, and I hope they continue to support it for a long time.
The situation is not quite that bad, though the summary makes it seem so. From what I gather, it wasn't a major part of the development team that was released, but rather 3-4 people in a small satellite team. Of course, there would definitely be bitterness about this, especially in this economic climate, but the job cut definitely wasn't extensive.
As for AA3 being flawed, the only major issue it's had is that the authentication servers have been overloaded by the hoards of new players trying to log in and play the game all at once. Obviously something like this can't be predicted, so no one is to blame. (I'm sure many of us recall Quake Live being hammered when it was released in open beta for similar reasons. And Demigod as well.)
The game itself is a LOT smoother and cleaner than any of its previous iterations. There are some occasional bugs and glitches that need ironing out, but thus far I haven't seen anything drastic.
(Yes, I am an AA player, and I have enjoyed for quite a long time. No, I'm not at all interested in joining the US Army. I realize it's a recruitment tool, but that doesn't mean there's any reason for me to shun it as a game.)
I used DevC++ for quite some time until I found out that it was out of date as well. Since then I've used Code::Blocks, and I find it to be quite an improvement. Since it's cross platform, working on different operating systems is pretty easy too.
KDevelop is my alternative choice. For all intents and purposes, KDevelop is my favorite IDE, but since it's only on Linux at the moment, Code::Blocks is my best choice for now. (Still, KDevelop is quite powerful, and I'm eagerly awaiting the cross-platform release.)
Eclipse is also a great choice, though I haven't used it nearly as much. I feel it's a little more focused on Java development, but many /.ers swear by it, so it's probably worth a try.
And on a final note, I've been using Vim a lot more often lately, and with the IDE plugins detailed in the Ars Technica article, I may make that my IDE of choice in the near future. (For others, there's Emacs. Both are great, take your pick.)
I work at Office Depot currently, and I can assure you this is not standard practice where I work, and certainly wouldn't be allowed by any of the managers or corporate. With regards to the issue about people lying about laptops being out of stock, yes, there were some salespeople who were doing that. As soon as it was found out, the practice was halted and everyone was informed that under no circumstances was it to be allowed. (And logically, even selling a laptop without the extended warranty is better than not selling it at all.) I so know that if any of this happened at the place I work, the employee responsible would be fired with no hesitation.
It is true that Office Depot does tend to push for these warranties, add-ons, etc, but you'll find that just about every other store, from Best Buy to Fry's does the same. Like it or not, that's how the business is run.
As a customer, it's annoying, but you just have to put up with it and move on in life, just as you put up with club cards, coupons, mailers, and all the other little annoyances that just about every store dumps on you these days.
As an employee, it can be stressful, but it's unlikely that you'll get fired if you don't contribute to the "quota." (And remember, this is retail. Working in retail sucks in general.)
And just as a final word, I'm not a manager, or corporate, or any higher up at OD. I'm just a lowly employee working there to pay for my textbooks because the hours are flexible enough to accommodate for my classes. I don't particularly have much company loyalty, but it does tick me off that people are spreading what is essentially tabloid journalism without giving any thought as to whether it's a widespread practice, or just some individuals who are giving the company a poor image.
Agreed. The Total Annihilation engine was definitely one of the most moddable. While I'm not much of a fan of Spring, the mods Uberhack, then Absolute Annihilation, and now TA: Twilight have been the most influential TA mods in my book. While the original TA was revolutionary in its own right, these mods brought the game above and beyond many of the RTS games in the years to come. I hope their legacy is continued in Supreme Commander.
The only real problem that's plaguing it is that people are assuming that it's the complete product, rather than a work-in-progress as the development team has repeatedly pointed out. Granted denoting it as "4.0" was a questionable decision, but the reasons given by the devs were logical.
The devs had the choice of either completely rewriting the KDE framework to keep it up to date, or stick with the old system and suffer the problems that are plaguing other projects, such as X. They chose the former, and thus it will take some time to reach maturity. Meanwhile, users are free to stick with KDE 3.x, which is still being maintained.
Thankfully, there are distros like Ubuntu who are refraining from making KDE 4.0 the default until it is mature. Thus, for those who are having problems with 4.0, the problem really lies with the user, as the user would have had to make the choice to move to 4.0 in the first place. (Unless it was a distro that embraced KDE 4.0, in which case the maintainers are to blame.)
If Gnome 3 also allows for some radical changes to its framework, I expect there will be similar complaints, unless it is kept in beta until a mature version is released. This, however, could result in slower development for the exact reasons that convinced the KDE team to name their latest release 4.0.
I'm not really sure why C++ is so ill-favored lately. It may not be fully OO, but there are many times when a fully OO solution is counterintuitive. Instead, C++ allows the developer to choose whether they want an OO solution or not. I also see a lot of complaints about C++ performance in comparison to C performance, but really, when properly implemented there is little difference. The same goes for garbage collection. Granted you have to write it yourself, but program-specific garbage collection will ALWAYS be more efficient than automatic garbage collection.
I think it's generally agreed that C and C++ aren't going anywhere anytime soon, since a lower-level programming language will always be needed. However, sidelining C++ in favor of C is definitely not a good idea, as C++ does offer many advantages that C lacks. (Yes, even for kernel development.)
I'd go into more depth, but this article really does a good job of explaining it:
http://unthought.net/c++/c_vs_c++.html