I essentially agree with the article's contention but would expand on it with particular emphasis on the "War Games" genre; especially FPSs. Not only do they need more realistic violence, but also, more realistic plot lines. I'm tired of war games that are generally free of moral ambiguity with clear sides of good vs. evil. They completely fail to accurately depict the subject matter, namely the horrid realities of war, not to mention they tend to be boring.

War is by its very nature a horrible thing, and while one side might be preferable to the other, the harsh reality is both sides almost always commit atrocities, do things that are wrong or downright evil, and certainly the men on the ground do as well even if contrary to orders. That's not necessarily a "direct" criticism of those men, but merely the reality that war has a habit of bringing out the worst in people, that no other situation would. I'd love to see a war game that not only has more realistic violence, but has a correspondingly realistic plot line. I rarely see civilians in my war games, I rarely get orders that are perhaps less than moral, I rarely see my fellow soldiers do things that are less than reasonable. Yes, I'm asking for the opportunity to play a war FPS that lets me kill or even massacre civillians, that brutally depicts the horrific violence and injuries. I'm not asking this because I'd really enjoy it, but because much of what we have now is really just war reduced to an arcade shooter, and I find it somewhat distasteful, as it is in some respects demeaning to the target it is simulating.

I think it would be fascinating for example, to have a WWII FPS where YOU get to play a Nazi. Think about that for a minute. Not all Nazi's were evil, many were just loyal soldiers of Germany doing what they thought was right, even if right is the result of brainwashing and propaganda from the German war machine. You'd be killing Allied soldiers; that might make you uncomfortable. But the fact that you can kill thousands of Nazi's who had families of their own and may not individually have been bad people in every war game up till now says something as well. Hell, you could have the protagonist find out about what was going on Holocaust-wise and defect. At least we'd have a somewhat original and more interesting plot line. What about the Dresden bombings? Why haven't I seen those?

Please don't misconstrue my thoughts as me just wanting the opportunity to commit virtual atrocities from my armchair. I'm just tired of these simplistic, boring, and unrealistic depictions of war in video games, that strip from them much of what defines war in the minds of veterans and through them the public. For the record, Soldier of Fortune probably has the most realistic violence in a war game I've seen, and I (of course) heard about the Modern Warfare 2 terrorist scene, but I have trouble taking the latter seriously in a game with regenerating health and usually fairly cookie-cutter plot lines. Really, it sounded like more of an attention grab than as part of any sincere effort to depict the realities of war in a video game.

It's entirely relevant, Arthur Grumbine pointed out you can remove bloat from Windows with tools such as nLite, and you replied by pointing out that it doesn't remove bloat from the kernel. The implication being that the NT kernel is bloated. You may be right, but you haven't presented any evidence, and I'd be interested in hearing it.

The LOLLinux poster was sarcastically pointing out that the Linux kernel itself has been claimed to be bloated, presumably referencing Linus Torvalds. It's not really relevant to the discussion, but I'd wager he's misinterpreting what Linus Torvalds meant. I'm not sure Linus meant the kernel is bloated in the binary/memory footprint sense, but more that the source code has grown very large, probably from a proliferation of drivers (and architecture support?) that is perhaps somewhat redundant and could be better streamlined, perhaps by giving the codebase a bit of a clean-up? Yes, his comment could be interpreted as a troll, but he does have some sort of evidence on his side, even if I think he's taking it out of context. So, where's yours?

What evidence do you have of the NT kernel being bloated? The NT kernel itself is very modular as it has to be. I'd argue the vast majority of bloat in Windows is strictly userland.

Being a closed-source kernel they can't compile everything it needs to support in statically as it would be giant and impractical. Making it highly modular is essentially a pre-requisite considering their engineering requirements. Check Windows\System32\drivers to see all the kernel modules on your system. Most are probably 3rd-party, if most systems I've seen are anything to go by. The actual kernel itself is a combination of ntoskrnl.exe and hal.dll in System32, and consists purely of the base NT system services (commonly known as the Executive).

Swing is definitely a step in the right direction, and I've used it (in a basic capacity) in a few programs, but I gather it took a while to mature? I'm told by more experienced Java programmers that it took a while to really evolve into a toolkit that could be used extensively as a viable (at least partial replacement) for the AWT. They may be wrong, I don't know.

I'm of the opinion that part of the reason for Java's slower than many anticipated adoption is just how badly it integrated into the native GUI environment of the host. For a very long time, and still persisting into the present, Java apps often looked downright awful on many systems. You can frequently tell something's a Java app purely by how ugly and out of place it looks compared to the native apps. Sun has made progress in addressing this, but it may be too little too late. I think the language as a whole is pretty good, and somewhat unfairly maligned, but the importance of the apps looking at least reasonable seems to have been underrated by the Java developers.

On the other hand, .NET is pretty much guaranteed to look at least reasonable on Windows. Of course, the fact it was targeted at Windows clearly goes a long way to simplifying this. I doubt Microsoft was thinking "We need to design this so it looks great and integrates on Windows, Linux, OS X, and everything else". But, that being said, for many developers it looking good on Windows is all that matters, in that it may be the only platform they're intending to develop for or support, so why go to all the extra effort in Java to make it look presentable when .NET makes it so much easier? There's of course many other pros/cons to each language, but I doubt the proliferation of ugly-as-sin Java apps is particularly good for its image, even if it is a very facile way of judging a language.

Don't underestimate the importance of presentation!

Yes, I agree. I personally think that PowerShell is a superior shell to bash/csh/etc..., but it still has a way to go before it gets enough tools to really compete with the incredible power of the CLI on Unix platforms. This isn't really surprising, in that in many respects Windows and Unix lands are focused in opposite directions. Whereas Windows has traditionally been very GUI-centric, with CLI support an afterthought, the reverse could be said of Unix platforms where the CLI reigns supreme and the GUI was an afterthought. Obviously, each paradigm has its strengths, but I think both platforms are perhaps guilty of neglecting one in favour of the other.

In that respect, while much of Unix development (particularly Linux, and yes, technically it isn't Unix, but I'm not putting a "-like" suffix on everything) seems to be focused on improved GUI tools for management of the system so you don't need to dive into the CLI to perform various tasks (see: Fedora/Ubuntu/SuSE), Windows is trying to improve CLI support by finally replacing the archaic cmd shell with PowerShell and rapidly improving it to become a modern and viable CLI for Windows systems.

One thing I do find interesting about how MS is approaching this issue is that they are building the GUI management tools of many of their new server products (see: Exchange/SQL Server/Windows Server) on top of PowerShell itself. This is excellent, as it means that while you have your pretty GUI for those who wish to use it, underneath, it's really just using PowerShell scripts to get the job done. The direct result of this is everything that you can do in the GUI you can do in the CLI, and, I assume it reduces engineering costs as the GUI is naturally built on top of the CLI system, rather than being two separate entities with separate engineering.

Well, not bash, but they do ship their high-end editions of Vista/7 and most (all?) Server 2008/R2 editions with csh and ksh as part of Subsystem for UNIX-based Applications, an optional component. And, there's always Cygwin. But really, PowerShell is better than all of the above. Yes, I know I just pissed off a stack of people devoted to the inherent and forever eternal supremacy of the Unix command-line paradigm, and while I would have agreed with you until the advent of PoSH, I can't anymore. Those who have to administer Windows machines would be richly rewarded by learning it. Yes, I know the parent was comment in jest :)

The "none of the above" option is called turning up at a voting station, getting your name crossed off, and not voting; last I checked, this was legal.

And failing that, take your voting slip, leave it blank, and put it in the voting booth. You've fulfilled your obligation to vote, without voting for any candidate. While I think this is incredibly stupid, you can do it, so what are you complaining about?

I'm pretty sure IIS is factored into the cost of the licences of the versions of Windows that contain it (whether you use it or not) ;)

Correct, but interestingly enough, the Windows Server versions (definitely 2008 and on, possibly 2003) do not have it installed by default. In Windows Server 2008 and R2 it is one of many "Features" which you can choose to add to the server if you need it or as required as a dependency. It's unfortunate, as Windows Server 2008 and onwards has always seemed to be more "componentised" than its desktop counterpart, which takes more of a "install almost everything and remove stuff you don't want approach". I guess from Microsoft's view it's an ease of use argument but there are things in Windows Server 2008 that are not only not installed by default, but can't be removed at all on the desktop variant.

.....are you in marketting?

While I agree with much of what you say, it doesn't exactly help your case when you layer your own post with fairly fanciful and stupid assertions, while rebutting the exact same in the GPs post. For one, the BSA aren't Microsoft's enforcers anymore than the RIAA are the Bee Gees' enforcers. They are a group that exists to enforce copyright and software licences, and while I don't agree with much of their policy or their actions in enforcing it, suggesting they are some puppet of Microsoft's is just absurd. Check the BSA membership, it's full of huge industry giants many of them direct competitors of Microsoft's; IBM, Apple, Dell, Adobe, Symantec, RSA, to name just a few. Further, military style raids might be a slight exaggeration, like calling the GPL communist or anti-capitalist for example.

But one point in particular I'd like to address is your assertions on the Interix system. Firstly, I think it's absurd to suggest that Interix was "created solely for the reason of destroying UNIX". Where's your proof? What leads you to this conclusion? Or does providing compatibility now (much like a huge number of other projects, like Wine) automatically entail an objective of destroying the target platform? Unix (and Unix-like) systems have always played and continue to play a major role in computing, and this is a good thing, surely some degree of compatibility with these systems at the API level is a good thing? This is a large part of what Interix does, it provides a POSIX implementation on Windows as well as a Unix-like environment for development and productivity. So you have the POSIX API, Csh/Korn shells, a large set of Unix utilities, compiler, libraries and headers, and a lot more. The idea is to provide a Unix environment on Windows for migration, compatibility and development.

Cygwin I suspect wasn't "fixed" by Microsoft for several reasons. One would be that Interix/Cygwin began development around the same time, another would be whether the developers would be receptive to development efforts by Microsoft, another might be legal concerns and all the usual licensing crap, but perhaps most of all, the way they accomplish their functionality is very different. Cygwin provides a POSIX implementation and Unix-like environment _ON TOP_ of the Win32 API. This is done through a DLL (cygwin1.dll) which translates POSIX calls into Win32 calls which in turn call into the NT Native API. Interix by contrast does not use Win32 at all, but runs directly on top of the POSIX subsystem, thus, Interix apps go POSIX Subsystem -> NT Native API. Of course, you still have to use the Win32 API as that's what the Windows OS is primarily built on, but the POSIX subsystem runs alongside it and Interix on top of it. This is indeed the point of the NT Native API and much of the NT design; the Native API is (as the name implies) the base API for the NT OS and environment subsystems run on top of it providing an API for client applications. The Windows API is one such subsystem and the one that 99% of people use, POSIX is another, Win16 is another (I think?), and in the past there has been a (fairly crippled) OS/2 subsystem, and possibly others.

This affords some unique functionality for Interix in that it can do things at the API level that the Win32 API doesn't really support, simple example: fork(). The Win32 API to my knowledge has no real fork() equivalent, however, this is supported by the POSIX subsystem. The reason is that the Native API does support fork() but does not expose it through Win32 (but does through POSIX). Clearly, the Cygwin developers have worked around this, although how they've done it I'm not sure. Perhaps they translate fork() calls to loose Win32 equivalents? Or they call directly into the Native API (possible, but strongly discouraged)? Whatever, my point is the implementations of these two environments are very different, and I suspect they offer varying functionality as well as differing in actual POSIX implementation. I gather there's quite a nice Interix community, and Microsoft has put a lot of effort into Interix updating it in various areas, the result being something of an overhaul for Vista onwards.

Finally, why does the POSIX subsystem exist? Government requirements. I gather when NT was in development the US government mandated all government operating systems to have a functional POSIX implementation to be considered for government usage, and so, NT had to provide a POSIX API, and this was easily afforded through a POSIX environment subsystem. Admittedly, that isn't exactly altruistic (did you expect it to be?), but it has continued to be supported and the Interix system improved, so it does appear that Microsoft is committed to supporting it and evolving it. Note as well that it's now bundled as part of Vista/Win2k8 and onwards, where as in the past it was a separate and optional download, and for a while wasn't even free and publicly available, so if anything, it's gaining more attention from Microsoft judging from these developments. Finally, note that Interix was originally OpenNT, and Interix was bought up by Microsoft, and was renamed not too long ago to SUA (Subsystem for Unix Applications), but that timeline is mostly irrelevant in this posts context, and so I've just consistently referred to it as Interix.

Your post on the whole seems partly riddled with common anti-Microsoft paranoia, and the result is you get these deluded assertions with no factual basis scarcely better than the GPs you address.

FYI: Microsoft commits to support the version of IE that ships with "x" Windows release for as long as "x" Windows release is supported. For example, IE 6 was shipped with Windows XP and so will be supported until Windows XP ceases to be. What this means is IE 6 is guaranteed to at the very least receive security fixes and limited bugfixes until sometime in 2014 when Windows XP leaves support. Similarly, IE 7 was shipped with Vista and will be supported until Vista ceases to be; contrary to what others may say, this is likely to be a very long time, I'd wager a minimum of 1 decade from RTM.

That being said, XP users using IE 7 have upgraded to it either consciously or via Automatic Updates and Vista users I suspect are far more likely to have Automatic Updates enabled as the OS has the functionality baked-in from RTM and aggressively encourages the user to enable it. So, while it may be supported for a long time, its userbase may shrink rapidly in contrast to the glacial decline of IE 6.

The lack of the tiny telnet client binary in the default install is admittedly infuriating, not to mention that it takes forever to install through optional components, which I can't figure out.

Suggested solution: Just use PuTTY. It's small, free, and supports Telnet and various other protocols fine, despite the fact I suspect nearly everyone uses it purely for SSH.

Did you read my original post?