/* OT side note */
Actually, GCC's performance under windows *greatly* depends on the type of code being executed.
E.g. We (my company) uses GCC under both Linux and Windows, even though we support VC 2K5/8.
At least in our case, GCC (mingw-64) was ~10-20% faster than VC 2K5 and has far, far, far, broader features list (E.g. Very partial macro support, no in-line assembly, 'managed' version of CRT functions, etc)
Plus, can build the Windows binaries on our Linux build systems (a major plus) using Fedora's extensive MinGW support.

Per subject at hand, if you raise the warning level to the maximum (-Wall) and remove a couple of noise factors (-Wno-multichar), at least in my view, GCC tends to be far more informative than VC 2K5 - which in turn, tends to throw a lot of unused variable and deprecated use of CRT function warning, but nothing really major.

- Gilboa

I'll give you the benefit of doubt that you're not simply trolling.

In the last two years I've experience two SSD bricks on my main Xeon workstation (2 x X5680, 36GB RAM, 6+1 x 320GB enterprise SATA in software RAID6, running Fedora 19 x86_64).
On the other hand, the 5 (!) year old 320GB enterprise SATA drivers are working like new (hence I've yet to replace them).
Now, back when I had the SSD's I used them as a fast cache, but for the life of me I couldn't feel the difference. (Can same the same about the occasional breaking).
Sure, firefox would launch *marginally* faster, but:
1. I boot once every major kernel release (or major security issue).
2. With anywhere between 10-20GB of free RAM (depending on the number of active VMs) most of the software I used is cached.
3. Even when compiling a large project, CPU is usually the limiting factor (even w/ 48 jobs).

So, would I feel the difference on a single disk laptop? Sure!.
Do I feel the urge to add a third SSD to my workstation? Do I trust them enough with my work? Doubt it.
Guess I'll have to see how the Linux kernel's bcache works and how well it handles bricked SSD's.

- Gilboa

Semi-OT: A word of friendly warning:
A couple of months ago (year?) I bricked a 120GB Intel 520 w/ the latest firmware (not sure
if it was 400i) w/ ext4 on Fedora x86_64. (Second bricked SSD in 12
months)
A *very* short power shortage crept under my APC UPS and bricked the SSD.
Amazingly enough, the power shortage didn't crash the machine - which
continued working off the main HDD software RAID array.
Luckily for me I rather distrust SSDs (see below) and use it as fast
cache-of-sort, so I only lost a couple of hours of work. (If any)

IMHO SSDs have one huge drawback: Unlike HDDs that can be partially
recovered from more-or-less any type of damage by recovering data
around bad sectors or replacing a fried controller board, SSDs complex
write scheme and the resulting complex firmware usually means that any type of
damage / firmware error will completely bricks it leaving more or less zero
chance of getting the data back.
On the top of that, we (as in all of us) have 40+ years worth of
experience in predicting the life cycle (and death) of HDDs. There's
far less information about the life cycle of SSDs.

Case of point: A couple of days after this incident a family member lost one of his HDDs.
Unlike my dead SSDs, with some work I managed to recover 95% (or more) of his files.

Don't get me wrong. SDDs will replace HDDs in the end - but in the mean time, I'd keep SSDs for non-critical tasks.

- Gilboa

Back in 2001-2002, I had a GF3 (?) running on a A7M-266D which had some issues - most of them related to the default AGP driver which was rather funky.
The irony was that Windows 2K exhibited the same issues (BSODs).
It took a while for the machine to reach rock solid status. (On both OSs, though I slowly stopped using Windows all-together more-or-less at the same time).
By 2004, I no longer had any serious issues with nVidia drivers (at least as far as I remember).

All in all I must have installed nVidia cards on >100 different Linux machines. (Both for myself, friends, co-workers, etc).
Pretty solid track record if you ask me...

- Gilboa

Linus' screw you comment aside, I'm not certain the Linux users as all, consider nVidia to be anti Linux.
I'd image only a small minority stick to the "open or die" attitude.

- Gilboa

Note to self: Writing comments after 20h+ work is known to produce interesting results....
I meant 2002 :(

- Gilboa

Not sure I fually understand your main point, but I've been using nVidia Linux drivers since, 1992 (*gasp*) on *many* different machines, ranging from top of the line Xeon/Opteron workstations w/ Quadro cards down to ATOM notebook with ION chipset and all in all, nVidia Linux support has been nothing short of exemplary.

BTW, While not ideal, Optimus can be used with some pain under Linux, using bumblebee.
Me and my co-workers have been using it on our i7 laptops (running Fedora 18/x86_64).

- Gilboa

Actually, the IDF F4s, F15s, F16s and Kfir C-2s faced a lot of MIG-23's in the first Lebanon war.
As far as I recall the war ended at 86:0.

- Gilboa

". In the area of drivers, kernel"

I call bullshit.
As someone that in the past ~8 years have been maintaining a *separate* proprietary kernel tree that includes a fairly large OS dependent multi-platform kernel library and multiple drivers (all in all, > 250K LOC covering everything from files to networking) I can can only wonder if why this stupid claim haven't died a horrible, horrible death long, long ago..
All in all, I doubt that I spent more than 2 hours *per* kernel release to track the latest kernel API changes. *

BTW, when asked (by Phoronix, I think), nVidia Linux kernel engineers more-or-less shared the same experience. (And I assume that their code based is somewhat (...) bigger than mine).

Care to share opposite experience?

- Gilboa
* I which I could have said the same about maintaining a *small* portion of this code base across different Windows versions and even, at times, across different SP releases.

*Come-on* people. English may not be my first language, but anyone what basic fourth grade reading comprehension skills should have understood that "Do yourself a favor and read a book (or two) about the Holocaust before you compare *ANYONE* to Nazi Germany" means I was being sarcastic and that I **do not** believe the U.S. can be compared to Nazy Germany. This ain't rockets science.

Guess I should have marked the post with "Sarcasm" in huge, bold, capital letters...?

- Gilboa

Re-read my comment *SLOWLY*.

Now idea how this:
"Do yourself a favor and read a book (or two) about the Holocaust before you compare *ANYONE* to Nazi Germany. (And no, Mein Kampf is *not* what I meant, you illiterate pi^H^H^H^H^H^H.)" Could be understood as me comparing the U.S. to Nazi Germany.
(Quite the opposite, It was a sarcastic remark about the OP's "America is is just as bad as the Nazies" post)

English may not be my first language, but come on!

- Gilboa

... Because the Americans took millions of people, shove them into 3sq km Ghettos where they'll die, in the millions from hunger and disease.
Those who were lucky enough to survive the Ghettos (and God knows how many forms of random murders) were then taken to huge camps in the middle of NY state, where they were gassed.

Do yourself a favor and read a book (or two) about the Holocaust before you compare *ANYONE* to Nazi Germany. (And no, Mein Kampf is *not* what I meant, you illiterate pi^H^H^H^H^H^H.)

- Gilboa
P.S. I'm not even American. Not even close.

Nothing in the linked bug report suggests that Linux is being mis-threated and/or ignored.

- Gilboa

"Pros and cons. And if not happy about it buy an Android, competition is good :) "

In a perfect world, I'd most likely would have agreed with you.
However, given the fact that both MS and Apple are both doing their best to kill Anroid by using the err, justice (?) system (and having participated in writing more than one patent I'm well aware how awful/broken/absurd the patent system), let alone trying to block non-signed OS from being installed on ARM systems ('Secure"-boot, soon to be on x86_64, I'd imagine) - you too, should be *very* worried if this story is indeed true. (I've yet to RTFA)

- Gilboa

... While I don't use bitmap background in konsole, I use colored background / foreground -alot-.
I use a color coding system to visually identify the machine (localhost, SSH, telnet-to-serial-on-KVM-guest, remote-serial-console, etc), user (me, root, test, etc) and site (work, home, etc).
Now it might sound overkill, but when you have 10+ tabs open, you *really* need some way to make sure you don't type 'rm -rf $PWD' in the wrong tab....
I just may use bitmapped console background to tag dangerous tabs (E.g. pirate flag in root@X tabs)

- Gilboa