No they haven't, and actually the VM seems to be pretty good.
True, 2.4 was an absolute nightmare up to around 2.4.16 as you said. The difference from then to now is, as I see it, that there were a few well focused attempts at solving that one huge problem, and then there was the general bugfixing going on meanwhile. Today, you have some general bugfixing going on, but all while that is happening, lots and lots of new features are added - core parts are touched in places where they (evidently) do not like to be touched, so to speak.
Sure, nobody (in their right mind) expected 2.6.0 to be bug free or even close. But I at least had an expectation that a stable 2.6 was the goal and the direction in which development would be going.
Again, I'm sure it will eventually. But until it does, for some uses 2.6 is just unusable.
(all is not bad; for example, my mother is using 2.6 on her desktop, and the hot-plugging works great - a lot of very good things are in 2.6, but for us people who need machines to have uptimes of more than 8 hours under heavy load, it's just not really good enough).
It is not that I have anything against the BSDs - but it is a simple matter of trust and expertise. What expertise we have, what we need to acquire, and in the end, what will it cost us to use a given OS.
Time is money.
I have yet to see a Solaris 8 or 9 on UltraSPARC crash. I have a lot of faith in that OS and the company that's behind. I don't remember crashing a FreeBSD (have crashed OpenBSD, have never run NetBSD), but then I have not run it for as long as I have Solaris.
Whatever I do, it's an investment - it's time I won't get back. I will go with the option where I believe I have the highest chance of "reasonable success".
Should the good ole Sun fail (too), chances are I'll go with FreeBSD, or go postal.;)
Ok, this is getting off-topic - but let's take this one and then I'll get back on topic near the end of the post:)
JDS you say. Frankly, I'm rather unimpressed by the Gnome effort (used it back in the 0.4 days till around 1.2.? or thereabouts, keeps seeing the new releases every now and then, but so far I have not seen anything that would compel me to switch back) - and JDS, well, it's a very pretty Gnome but it is still a Gnome;)
But heck, 90% of the day is spent in Emacs and a bunch of terminal windows so I'd get along in anything with virtual desktops as well... Not that religious:)
Back on topic:
What I am going to do though, is to try out Solaris 10 as NFS server. 2.4 is too slow on the hardware that I currently have, and 2.6 breaks in more ways than I can count, so I was thinking about getting some real iron and giving Solaris 10 a try there. You wouldn't by any chance have on-hand experience with the 3310 enclosure?:)
Linux is great on the desktop though - the tough environment is, ironically, the environment that Linus himself says is "boring" ("servers do the same thing all day", quoted from memory).
However, regression testing is only one half of the cycle; you also need to actually fix the bugs *without* introducing new significant ones. Linux has always had absolutely fantastic test coverage, the current development model just fails miserably on the "fixing *without* introducing" bugs part.
In 2.4 you can upgrade from 2.4.n to 2.4.(n+1) and expect things to work. Maybe 2.6 will be like that some time in the future, but that time is definitely in the future.
2.6 is currently a developer's dream and an administrator's nightmare.
It is a smoking pile of bleeding edge patchwork. It can do everything in double time and brew coffee concurrently, but it cannot serve a file reliably (for example - as outrageous as it sounds that last part is actually the truth).
The absolute major top-1 problem is the huge flux of patches; 4000 changesets between 2.6.9 and 2.6.10... One kernel fixes maybe 100 bugs and introduces the same number along with a heap of new features while it deprecates a few old interfaces.
If 2.6.5 is the latest stable 2.6 kernel for one particular use (which I know for a fact that it is for some uses), you're stuck with a local root vulnerability because most likely 2.6.11 which may have a fix for this one bug will crash with that workload (as 2.6.6-2.6.10 did).
And the examples I'm pulling out here (file serving and many unstable kernels in a row) are not unreported problems. They are not new problems. They have been worked on, partially fixed, etc. etc. but with the development model as it is, you just cannot expect fixes to have a very long life-time.
It is very very sad. But I think it will change as someone realizes how bad the situation is. Probably half a year or so from now, when people start getting really annoyed that you *still* cannot route, web-serve or file-serve in any significant volume with Linux 2.6.
Until then, it's Linux 2.4 and Solaris - both slow compared to 2.6 maybe, but at least they stay up over night:)
Dude, computers have not been even *close* to Von Neumann for several decades.
Von Neumann assumes uniform memory access times - this is largely untrue for any ordinary scalar processor with a cache - ten years ago processors had internal memory write buffers, l1 cache, possibly l2 cache and main memory - today it's even more complicated. But common for all of this is that even a simple hierarchical memory system with a single level cache and the main memory makes your computer very far from Von Neumann.
So, if Intel wants to present something that "isn't von Neumann at all", all they need to do is pull an i386 out of a hat and wave it at the drooling masses.
I completely agree with you - currently fission power is the way to go, along with funding of fusion research.
But this has nothing to do with the US negligence towards current environment protocols - having a bunch of tree hugging hippies oppose nuclear power is *not* an excuse for ignoring the Kyoto protocol.
Assuming the average user does not re-use passwords on multiple systems, that there is no wireless, and that the attacker won't simply automate the attack to log in (if possible back thru the firewalls) next time the user visits.
Sure, then you're sort of right I guess:)
Basically, you're safe because you're one fish in a million. The chance of getting eaten is very small.
Unless you're not just a little fish - if someone keeps a database of LM hashes (and user name, domain, machine name, IP,...) it should be pretty easy to narrow down on, say, '\\whitehouse\dubya', and then suddenly there is incitement for the attacker to actually spend some effort on finding uses for the password.
He is not joking. And he didn't tell the whole story either; there are several either tremendous stupidities in the LM hash which makes long passwords worthless, and relatively short ones easier to break than their length would otherwise indicate (separate grouping of characters, triple-DES'ed *independently*).
The fun part is that any default install of Windows (at least up to and including XP) will send out the current users LM hash if he tries to connect to a SMB share.
So, if someone placed a link on their homepage to a patched Samba which logged LM hashes, they could gather LM hashes from most of their windows using visitors.
This would *include* those behind many firewalls, because many default firewall setups will allow *outgoing* connections - and in this particular case, it is indeed the windows client that is initiating the connection to the remote web server in order to send away the current users LM hash (along with username, domain, local machine name and other goodies).
Yes, I told CERT about this some three years ago. They wouldn't touch it with a five foot pole. I then told Microsoft about it. Their response was something like "fixing that problem would require us to re-design our windows networking layer - therefore it is not a security problem".
Well, there you have it.
But hey, if you're on Windows you're fucked anyway, and none of this should really come as a shock to you:)
The major points in that article in relation to C++ in the kernel will be *) Rewriting good C to C++ will be bad C++ and that's not a change to the better *) Few (good kernel-) developers understand C++ or are willing to learn
However, it is interesting to see that Linus is working so much with the SParse tool - which, really, is just a type checking tool allowing to check annotated C types more strictly than the C language itself allows. This is one of the major benefits you get from C++ (and you can get this benefit with *zero* overhead compared to C - the stricter type system does not force you to use features that have overhead). Instead of developing SParse and running type checking in two steps (first the C compiler, then checking with SParse), they could move to C++ and have it all (and then some) in one go.
But again; I don't think rewriting the kernel to C++ would be reasonable - however, if you start up a new kernel project today, you'd be insane not to go with C++.
First Turbo Pascal, then x86 asm then C then C++ then SML then bash then Fortran then Perl then Scheme then Haskell then PA-RISC/UltraSPARC/Power2/Alpha asm
Today I'm ~85% C++, 10% C, and 5% asm(weird archs), Haskell, ML, Perl, bash, etc.
Pascal: Thanks for the good years - and good riddance.
You can write malfunctioning software in all languages.
I can make a Haskell program that deletes my home directory, either intentionally or by accident.
I can make PostScript consume all memory in my printer.
I can make Java or C# drop a database on the SQL server. And I can make them consume all memory on the machine where they run. Actually, their lack of memory management control (forcing GC on the programmer) makes it difficult for all programmers *not* to OOM the system, somewhat in the same way that C++ makes it difficult for the novice programmer not to cause GPFs.
The difference being; no matter how good you are, you cannot (portably) work around the inherent problems in a forced GC environment. So no matter how skilled you are, you will eventually run into memory problems with large scale software systems on Java and C#. With C++ you can actually become skilled enough to not cause GPFs.
Heck, if you're the kind of person who believes 'HTML' is a programmin language, you can even write HTML that will segfault your browser (again by consuming all memory in the system).
When foo() is exited, either when it completes, or because an exception is thrown in bar(), the auto_ptr destructor is called, and this will cause the dynamically allocated my_big_class object to be destroyed.
Simple, safe, and very very efficient.
typedefs of course can be used to make those awfully long names easier to type.
Sometimes, one just needs to take a step back and have a look at the big picture. But then, sometimes, when you're deeply involved in this whole thing yourself (making money, building rock-solid software), even the most obvious of explanations will elude you.
I fell victim to that. Thank you for the enlightenment!
I can now go on doing what I've done every day so far, but now, now I understand.
Thanks:)
Welcome stranger!
on
Java 1.5 vs C#
·
· Score: 4, Insightful
Welcome to planet earth - we also have a language called 'C++', but it is rather different from what you describe.
Here, we have compilers that can do bounds checking - avoiding buffer overflows, if you decide to use them.
However, the template feature of our C++ is so powerful, that when used together with structs and classes, one can produce beautiful code that is extremely powerful, yet so simple that it is easy to ensure it is not susceptible to said buffer overflows (or memory leaks or the thousand other plagues of much of the software that surrounds us).
This is why there is actually not anything fundamentally wrong with our C++. We are some who want template namespaces though, but outside of little issues (that do have workarounds) like that, the only things we really want is additions to the (already powerful) standard library, the STL.
One problem remains with our C++ though. We live on a planet inhabited mainly by clueless morons, people who do not like to learn, people who refuse to accept that maybe others have seen farther than themselves. This is why we, too, have a lot of problems with software in general - buffer overflows as you mention, among many other problems.
I am sure we can arrange for you to get a copy of our C++ standard - that will allow a clever individual, such as yourself, to write software without the problems we discussed. I would then suggest that we join our efforts, in teaching the unwashed masses how to actually use the language properly, so that we will not have to re-do all software in the world (both ours and yours) by ourselves.
1) Bullcrap - both environments can use from "fair" to "obescene" amounts of ressources
2) "Some" prefer TWM - now if TWM required the amount of petting that Gnome seems to require from the Slack people, they might consider dropping that too, regardless that I have a co-worker sitting right next to me with his TWM "desktop".
For me, the mouse is usually in the upper-right quarter of the screen - because, very simply, the mouse for me is a device I use to point at the terminal in which I am typing.
And, because I have other stuff on my desktop as well (overlapping gkrellm, a panel and some stuff), the upper-left terminal is the one where nothing will overlap and therefore the one I type in. I use the other terminals for top, vmstat, 'tail -f' etc. etc.
Scrolling: using 'j', 'k', 'h' and 'l' in Konqueror, the arrow keys in KMail. I have my hands on the keyboard - having to move them simply to scroll would be annoying.
Which leads me to another point; a UI which requires me to use the mouse just to scroll would piss me off. It may seem like a small deal, but scrolling is something I do thousands of times a day (like most other people I guess), and that does make such a little detail a big deal indeed.
Sure, you can make a survey prove anything you want. And frankly I don't care. Button ordering seems like a small deal for me - but I can vividly imagine that for some people this is a very big deal - and frankly I think the Gnome "let's play different from everybody else" attitude here is lame. Not that I care about it though... Back in the 0.4 days, I used Gnome, because it had a kick-arse panel. Today I really like that my mailer and my browser look alike, act alike, and integrate well - yep, I'm on KDE today.
No, I'm not just trying to be a tinfoil-hat-carrying left-wing anti-US conspiration theorist - but seriously, have you read a paper the past few years?
How this can be "news" is beyond me. How it ever became "news for nerds" that's a whole other story...
Please, can we go back to Xeon vs. Opteron bashing?
Welcome to planet earth - calling things a "game" comforts us, it makes it sound innocent, and that makes us feel that it's not really about something else, and we like that comfort.
We also have the "Olympic Games", and when referring to animals we kill for fun we call them "Game" too.
Slashdot Mirror
...what you can do in awk.
/usr/share/dict/words
Never do in awk what you can do in sed.
Never do in sed what you can do in tr.
tr cC kK <
No they haven't, and actually the VM seems to be pretty good.
True, 2.4 was an absolute nightmare up to around 2.4.16 as you said. The difference from then to now is, as I see it, that there were a few well focused attempts at solving that one huge problem, and then there was the general bugfixing going on meanwhile. Today, you have some general bugfixing going on, but all while that is happening, lots and lots of new features are added - core parts are touched in places where they (evidently) do not like to be touched, so to speak.
Sure, nobody (in their right mind) expected 2.6.0 to be bug free or even close. But I at least had an expectation that a stable 2.6 was the goal and the direction in which development would be going.
Again, I'm sure it will eventually. But until it does, for some uses 2.6 is just unusable.
(all is not bad; for example, my mother is using 2.6 on her desktop, and the hot-plugging works great - a lot of very good things are in 2.6, but for us people who need machines to have uptimes of more than 8 hours under heavy load, it's just not really good enough).
Honest question.
;)
It is not that I have anything against the BSDs - but it is a simple matter of trust and expertise. What expertise we have, what we need to acquire, and in the end, what will it cost us to use a given OS.
Time is money.
I have yet to see a Solaris 8 or 9 on UltraSPARC crash. I have a lot of faith in that OS and the company that's behind. I don't remember crashing a FreeBSD (have crashed OpenBSD, have never run NetBSD), but then I have not run it for as long as I have Solaris.
Whatever I do, it's an investment - it's time I won't get back. I will go with the option where I believe I have the highest chance of "reasonable success".
Should the good ole Sun fail (too), chances are I'll go with FreeBSD, or go postal.
Ok, this is getting off-topic - but let's take this one and then I'll get back on topic near the end of the post :)
;)
:)
:)
JDS you say. Frankly, I'm rather unimpressed by the Gnome effort (used it back in the 0.4 days till around 1.2.? or thereabouts, keeps seeing the new releases every now and then, but so far I have not seen anything that would compel me to switch back) - and JDS, well, it's a very pretty Gnome but it is still a Gnome
But heck, 90% of the day is spent in Emacs and a bunch of terminal windows so I'd get along in anything with virtual desktops as well... Not that religious
Back on topic:
What I am going to do though, is to try out Solaris 10 as NFS server. 2.4 is too slow on the hardware that I currently have, and 2.6 breaks in more ways than I can count, so I was thinking about getting some real iron and giving Solaris 10 a try there. You wouldn't by any chance have on-hand experience with the 3310 enclosure?
Linux is great on the desktop though - the tough environment is, ironically, the environment that Linus himself says is "boring" ("servers do the same thing all day", quoted from memory).
We, the users, do regression testing.
However, regression testing is only one half of the cycle; you also need to actually fix the bugs *without* introducing new significant ones. Linux has always had absolutely fantastic test coverage, the current development model just fails miserably on the "fixing *without* introducing" bugs part.
In 2.4 you can upgrade from 2.4.n to 2.4.(n+1) and expect things to work. Maybe 2.6 will be like that some time in the future, but that time is definitely in the future.
You're absolutely correct in what you say.
:)
2.6 is currently a developer's dream and an administrator's nightmare.
It is a smoking pile of bleeding edge patchwork. It can do everything in double time and brew coffee concurrently, but it cannot serve a file reliably (for example - as outrageous as it sounds that last part is actually the truth).
The absolute major top-1 problem is the huge flux of patches; 4000 changesets between 2.6.9 and 2.6.10... One kernel fixes maybe 100 bugs and introduces the same number along with a heap of new features while it deprecates a few old interfaces.
If 2.6.5 is the latest stable 2.6 kernel for one particular use (which I know for a fact that it is for some uses), you're stuck with a local root vulnerability because most likely 2.6.11 which may have a fix for this one bug will crash with that workload (as 2.6.6-2.6.10 did).
And the examples I'm pulling out here (file serving and many unstable kernels in a row) are not unreported problems. They are not new problems. They have been worked on, partially fixed, etc. etc. but with the development model as it is, you just cannot expect fixes to have a very long life-time.
It is very very sad. But I think it will change as someone realizes how bad the situation is. Probably half a year or so from now, when people start getting really annoyed that you *still* cannot route, web-serve or file-serve in any significant volume with Linux 2.6.
Until then, it's Linux 2.4 and Solaris - both slow compared to 2.6 maybe, but at least they stay up over night
That seems overly restrictive...
:)
As I see it, conversion tools are only necessary in the female-female scenario if both subjects must use both hands for eating at the same time.
Or am I missing something in your analysis of the (arguably special case) scenario?
If the Java garbage collector worked,
every Java program would delete itself immediately upon startup.
- me.
...to young rich maidens in need :)
Dude, computers have not been even *close* to Von Neumann for several decades.
Von Neumann assumes uniform memory access times - this is largely untrue for any ordinary scalar processor with a cache - ten years ago processors had internal memory write buffers, l1 cache, possibly l2 cache and main memory - today it's even more complicated. But common for all of this is that even a simple hierarchical memory system with a single level cache and the main memory makes your computer very far from Von Neumann.
So, if Intel wants to present something that "isn't von Neumann at all", all they need to do is pull an i386 out of a hat and wave it at the drooling masses.
I completely agree with you - currently fission power is the way to go, along with funding of fusion research.
But this has nothing to do with the US negligence towards current environment protocols - having a bunch of tree hugging hippies oppose nuclear power is *not* an excuse for ignoring the Kyoto protocol.
Assuming the average user does not re-use passwords on multiple systems, that there is no wireless, and that the attacker won't simply automate the attack to log in (if possible back thru the firewalls) next time the user visits.
:)
...) it should be pretty easy to narrow down on, say, '\\whitehouse\dubya', and then suddenly there is incitement for the attacker to actually spend some effort on finding uses for the password.
Sure, then you're sort of right I guess
Basically, you're safe because you're one fish in a million. The chance of getting eaten is very small.
Unless you're not just a little fish - if someone keeps a database of LM hashes (and user name, domain, machine name, IP,
He is not joking. And he didn't tell the whole story either; there are several either tremendous stupidities in the LM hash which makes long passwords worthless, and relatively short ones easier to break than their length would otherwise indicate (separate grouping of characters, triple-DES'ed *independently*).
:)
The fun part is that any default install of Windows (at least up to and including XP) will send out the current users LM hash if he tries to connect to a SMB share.
So, if someone placed a link on their homepage to a patched Samba which logged LM hashes, they could gather LM hashes from most of their windows using visitors.
This would *include* those behind many firewalls, because many default firewall setups will allow *outgoing* connections - and in this particular case, it is indeed the windows client that is initiating the connection to the remote web server in order to send away the current users LM hash (along with username, domain, local machine name and other goodies).
Yes, I told CERT about this some three years ago. They wouldn't touch it with a five foot pole. I then told Microsoft about it. Their response was something like "fixing that problem would require us to re-design our windows networking layer - therefore it is not a security problem".
Well, there you have it.
But hey, if you're on Windows you're fucked anyway, and none of this should really come as a shock to you
C++ is transparent - to anyone who understands the language.
;)
;)
Just like C is transparent to anyone who understands the language.
Neither language is transparent to those who do not understand. "Det er da ikke så svært at forstå, er det?" (see what I mean
Read:
C vs C++
written by yours truly.
The major points in that article in relation to C++ in the kernel will be
*) Rewriting good C to C++ will be bad C++ and that's not a change to the better
*) Few (good kernel-) developers understand C++ or are willing to learn
However, it is interesting to see that Linus is working so much with the SParse tool - which, really, is just a type checking tool allowing to check annotated C types more strictly than the C language itself allows. This is one of the major benefits you get from C++ (and you can get this benefit with *zero* overhead compared to C - the stricter type system does not force you to use features that have overhead). Instead of developing SParse and running type checking in two steps (first the C compiler, then checking with SParse), they could move to C++ and have it all (and then some) in one go.
But again; I don't think rewriting the kernel to C++ would be reasonable - however, if you start up a new kernel project today, you'd be insane not to go with C++.
My 0.02 Euro on that one
The way I learned the trade:
First Turbo Pascal,
then x86 asm
then C
then C++
then SML
then bash
then Fortran
then Perl
then Scheme
then Haskell
then PA-RISC/UltraSPARC/Power2/Alpha asm
Today I'm ~85% C++, 10% C, and 5% asm(weird archs), Haskell, ML, Perl, bash, etc.
Pascal: Thanks for the good years - and good riddance.
I managed maybe 20-25 reloads before the crash, with Konq 3.3.
?
You can write malfunctioning software in all languages.
I can make a Haskell program that deletes my home directory, either intentionally or by accident.
I can make PostScript consume all memory in my printer.
I can make Java or C# drop a database on the SQL server. And I can make them consume all memory on the machine where they run. Actually, their lack of memory management control (forcing GC on the programmer) makes it difficult for all programmers *not* to OOM the system, somewhat in the same way that C++ makes it difficult for the novice programmer not to cause GPFs.
The difference being; no matter how good you are, you cannot (portably) work around the inherent problems in a forced GC environment. So no matter how skilled you are, you will eventually run into memory problems with large scale software systems on Java and C#. With C++ you can actually become skilled enough to not cause GPFs.
Heck, if you're the kind of person who believes 'HTML' is a programmin language, you can even write HTML that will segfault your browser (again by consuming all memory in the system).
No. Destructors make dynamic allocations safe, when you are using exceptions. Example:
// may throw exception
void foo()
{
auto_ptr p(new my_big_class);
p->do_stuff();
p->do_more_stuff();
bar(p);
p->yet_more_stuff();
}
When foo() is exited, either when it completes, or because an exception is thrown in bar(), the auto_ptr destructor is called, and this will cause the dynamically allocated my_big_class object to be destroyed.
Simple, safe, and very very efficient.
typedefs of course can be used to make those awfully long names easier to type.
To the bone girl. To the bone :)
Thanks, really.
:)
That would explain a lot of things.
Sometimes, one just needs to take a step back and have a look at the big picture. But then, sometimes, when you're deeply involved in this whole thing yourself (making money, building rock-solid software), even the most obvious of explanations will elude you.
I fell victim to that. Thank you for the enlightenment!
I can now go on doing what I've done every day so far, but now, now I understand.
Thanks
Welcome to planet earth - we also have a language called 'C++', but it is rather different from what you describe.
Here, we have compilers that can do bounds checking - avoiding buffer overflows, if you decide to use them.
However, the template feature of our C++ is so powerful, that when used together with structs and classes, one can produce beautiful code that is extremely powerful, yet so simple that it is easy to ensure it is not susceptible to said buffer overflows (or memory leaks or the thousand other plagues of much of the software that surrounds us).
This is why there is actually not anything fundamentally wrong with our C++. We are some who want template namespaces though, but outside of little issues (that do have workarounds) like that, the only things we really want is additions to the (already powerful) standard library, the STL.
One problem remains with our C++ though. We live on a planet inhabited mainly by clueless morons, people who do not like to learn, people who refuse to accept that maybe others have seen farther than themselves. This is why we, too, have a lot of problems with software in general - buffer overflows as you mention, among many other problems.
I am sure we can arrange for you to get a copy of our C++ standard - that will allow a clever individual, such as yourself, to write software without the problems we discussed. I would then suggest that we join our efforts, in teaching the unwashed masses how to actually use the language properly, so that we will not have to re-do all software in the world (both ours and yours) by ourselves.
Deal?
1) Bullcrap - both environments can use from "fair" to "obescene" amounts of ressources
2) "Some" prefer TWM - now if TWM required the amount of petting that Gnome seems to require from the Slack people, they might consider dropping that too, regardless that I have a co-worker sitting right next to me with his TWM "desktop".
For me, the mouse is usually in the upper-right quarter of the screen - because, very simply, the mouse for me is a device I use to point at the terminal in which I am typing.
And, because I have other stuff on my desktop as well (overlapping gkrellm, a panel and some stuff), the upper-left terminal is the one where nothing will overlap and therefore the one I type in. I use the other terminals for top, vmstat, 'tail -f' etc. etc.
Scrolling: using 'j', 'k', 'h' and 'l' in Konqueror, the arrow keys in KMail. I have my hands on the keyboard - having to move them simply to scroll would be annoying.
Which leads me to another point; a UI which requires me to use the mouse just to scroll would piss me off. It may seem like a small deal, but scrolling is something I do thousands of times a day (like most other people I guess), and that does make such a little detail a big deal indeed.
Sure, you can make a survey prove anything you want. And frankly I don't care. Button ordering seems like a small deal for me - but I can vividly imagine that for some people this is a very big deal - and frankly I think the Gnome "let's play different from everybody else" attitude here is lame. Not that I care about it though... Back in the 0.4 days, I used Gnome, because it had a kick-arse panel. Today I really like that my mailer and my browser look alike, act alike, and integrate well - yep, I'm on KDE today.
...come on - what did you expect?
No, I'm not just trying to be a tinfoil-hat-carrying left-wing anti-US conspiration theorist - but seriously, have you read a paper the past few years?
How this can be "news" is beyond me. How it ever became "news for nerds" that's a whole other story...
Please, can we go back to Xeon vs. Opteron bashing?
Welcome to planet earth - calling things a "game" comforts us, it makes it sound innocent, and that makes us feel that it's not really about something else, and we like that comfort.
:)
We also have the "Olympic Games", and when referring to animals we kill for fun we call them "Game" too.
And that's just how we like it here