It's not only a question about opensourcing drivers.

It's also about them at least fixing their blobs to get the missing features working. Like having actual graphics on optimus laptops.
The necessary API and Hooks are here: DMA-BUF has been used to pipe GPU 3d-accelerated content onto non-accelerated USB displays.

IT just took them an eternity before starting to consider this.

Although Nvidia's binary driver tend to be rather fast,
Nvidia has been a rather bad citizen regarding drivers.

They don't offer any help for opensource drivers, at least not the desktop ones (well, at least things are starting to move for the Tegra, thanks to the strong dominance of linux in the embed market).

And they don't play well along other linux technologies. They prefer to do things their way (which is trying to do an as straigh as possible port of their windows code-base) which sometime leads to missing feature, instead to use the facilities which are developed by the kernel folk. (e.g.: the whole Linus' "Fuck You!" scandal). Optimus whould have been implemented much earlier, had Nvidia decided to start collaborating with other effort in that direction. (Well on the other hand, the OSS community wasn't that much helpful when they decided to finally try using DMA-BUF).

So although Nvidia's drivers are fast, they are just a monolithic bloc of proprietary secret and doesn't elegantly interface with everything else. They are not nice.

Doesn't matter. Just on the next line I suggested using end-to-end encryption.

You can log with any XMPP software that supports Off-The-Record to have end-to-end encryption on chat (for example Jisti, Pidgin, Adium, maybe Trillian too, but I'm not sure) you can log with any XMPP software that supports ZRTP to have end-to-end encryption on audio/video (jisti again).

Both OTR and ZRTP are standards, so as long as software at both ends support it you get encryption, you don't need to use the same software, only any software that does support it (for obvious technical reasons, Google's own web app client doesn't implement it so you're still transmitting with the same level of security as a post card if one of the peers is using this)

Google Talk. Works out of the browser.
Once web rtc hits mainline version of browser (soonish), it will work out of the browser without even a plugins.

Or you can install Jitsi and use that to log into your google chat instead of the webclient. And if the other end too has encryption (Off-The-Record on the message channel or ZRTP on the audio/video channels) (for exeample if the other end is using Adium to chat) the transmission is completely encrypted end-to-end with no way for google to intercept anything.

Of course the migration path from Win3.11 up to Windows 8 is almost impossible, I'm half joking. But I try to attract the attention to a few key points (yes I know. Don't explain the joke...):

- HairyFeet's challenge works more or less because he's cherry picked a few key point (I wanna have working wifi) and a specific time frame (very recent history of windows, where it is more or less the same kernel under the hood, with only relatively minor additions).

The thing is, before comparing, you have to decide which criteria you're using to compare in order to avoid comparing oranges and apples, and be sure you're on a common ground. What's constitute an actually good common ground can be somewhat subjective.

My joke is about breaking the test by changing these conditions. Selecting things which are completely unfair to Windows.

You mention that a machine able to run Win95 or even able to run Win3.11 is very unlikely to have the ompf to run Windows 8. Simply order of magnitudes differences in requirement.
Well, just think about Linux. It happens that you can run lots of modern distribution on *very old* hardware.
Of course, it does require some tweaking (during the "upgrade game", installer would probably suggest jumping from KDE 2.x to KDE 3.x and then KDE4.x because that's what most people needed back then. If you need to run your distro on out-dated hardware, you might need to prefer jumping to another DE with much lower requirement and stick to it. FXCE is a possibility, LXDE is another. There are even other environment with simpler requirement).
Linux has two big advantages: the ability for the end-user to tune its environment for much lower requirement, and better support for older hardware (older hardware for Linux means more time to get tested and better support. For windows it usually means the maker went belly up and nobody is here to write driver for newer versions of windows, so usually every big upgrade also means throwing away all your cheap old noname peripherals).

Starting with your "stay at the same millenia" criterium, I could also speak about "staying with approximately the same generation of technology".
Hairyfeet's challenge exactly as formulated is unfair to linux because, under the hood there's almost no difference between Windows 2000 and Windows 8. It's a nearly identical kernel with nearly identical APIs during the whole lifetime. The only minor changes are a few changes with the graphic driver model (but which isn't covered by the Hairyfeet challenge. But which regularily kick you back into non accelerated famre buffer mode at each major change - indeed breaking) and security having been overhauled around the time of XP SP3 and Vista, because microsoft was forcibliy dragged kicking and screaming into doing it, because of business needs. (For why just everything else stagnated, just refer to TFA - yes, I know, slashdot, etc.)
(If we had started earlier, we would go thourgh racidally different types of drivers, dos .SYS and win3x .DRV, then Win9x. VXD, then WinME's ugly hack, then WinNT's .SYS - 100% guaranteed breakage)

Meanwhile Linux has seen quite a few changes in architecture and its a miracle that you can actually upgrade accross so much distribution generation. This miracle is mostly due to package managers being clever (hal is deprecated by udev and everything is un-installed and re-installed as necessary, thank you RPM-/DEB-'s dependency checking !) and the software being opensource (at each generation switch, package manager can have access to almost everything needed to make sure that everything plays out nicely).
Only two exceptions exist:
- graphic drivers - they are produced by 3rd parties and not in control of the distribution's package manager. Distribution could play a little bit around (writing package which try to automatically pull the correct blob while leveraging the package dependency solving) but they are limited by lack of access to source and complex re-distribution licensing terms.
- wireless networking. Whereas the situation works nicely for ethernet cards (they have been used in servers since ages and thus strong pressure from community and makers to have everything work perfectly). But wireless has been a nightmare until recently. We've been going from "sorry no drivers for you", through "manufacturer ships a shitty half-working blob which require an exact specific kernel revision which is completely out-dated", through "here a wrapper which implements standard windows API and can try to tap into the win drivers", through "some opensource enthousiasts are trying to reverse engineer all this mess and write a coherent driver". It's only recently, with Linux getting widespread on home router and on portable devices (where the situation currently boils down to android on nearly everything except when it's running iOS), that manufacturer have started to pay attention to the situation and correctly collaborate with kernel developer to have decent wireless drivers. (Now you can even find drivers for ahteros where even the firmware running on the adapter is opensource).

So by choosing a certain time frame (say Windows XP to Windows 8) you can end up in a situation where nothing change on the Windows side (it's actually the exact same driver running. no need to upgrade, so as long as you don't break the hardware enumeration, upgrade will be problemless - at least for the for the WiFi) whereas the Linux situation is an awful mess (going through all the shit mentioned before).

On the other hand, you could very probably pass the hairyfeet test with flying colours if you start in a point of time where modern well written drivers are available and all the configuration is automatically handled by NetworkManager, and keep upgrading for the following 5 years.

just pick cyanogen mod to have a type of distribution (although using android user space instead of GNU - but still the same Linux kernel) where upgrading works perfectly, mostly because the manufacturer did care about writing decent drivers.

Hairyfeet will have to move his challenge to other target:
- graphic drivers can be a good target to pick on. By then, the Windows API will probably stabiliser around the version introduced in Vista (with probably minor new version introducing new capabilities, but basically the same framework so probably backward compatible). Whereas Linux is going to have quite a ride:
we're starting with a point where the current big companies (AMD and Nvidia) have a mix of proprietary blob more or less working and opensource drivers at various stage of completeness, overhauls in the 3D stack (kernel mode setting, modularised Gallium, etc.) and even big changes in the graphics environment (X stepping aside and letting Wayland coming in. And maybe Mir too if Cannonical can get their shit together in time).

But luckily that is currently also heading in the correct direction both thank to maker (Intel is 100% opensource, AMD helps opensource effort, Nvidia has at least recently started helping on embed) and to industry interest (Valve, lots of Indie developper, specially with Humble Bundle, lots of crowd-funded projects: all are moving into Linux. Valve has already helped fix or improved several things in Linux grahpical drivers)

So yeah. In my joke I'm comparing orange to apples, but hairyfeet's challenge is comparing pineapples to kiwis anyway.

Or Maybe :
".TheseArentTheBoobiesYoureLookingFor.HandWaving"

Still, the recent incursion of Valve and its Steam into the linux world, the big success that Humble Bundle has among Linux player (they are significant propotion of the buyers, and on average tend to pay the double than windows users*), and the fact the lots of the crowd-funded game project very easily reach their "Stretch goal: Linux support" (or has the most vote for that extra option), etc.
all these fact tend to disagree with your idea that linux is never going to have any luck at gaming.

There is a market already for linux games. It was just untapped because until now, the big corps behind AAAA title didn't bother paying attention. but recent trends in indie and crowd-funded development has shown that there is indeed a market, which in turn is getting picked up by big names.

Not to mention that Linux has pretty much won also the embed market since long (with Apple's BSD-distant-derivated system having also a significant share specifically with tablets and smartphones) Windows on ARM is just a joke.

And slowly, the graphic cards manufacturer are collaborating to make things better:
- AMD/ATI have been actively helping opensource driver efforts (to the point that now, the opensource driver is the preferred for most older GPUs).
- Although they don't help much on the desktop, nVidia have very recently started helping support opensource tegra, simply because they now that they need linux for the embed world and past mess of every company keeping their own fork at fixed old kernel revision just doesn't work anymore.
- Intel has always being opensource to begin with
- In the process of bringing source engine to Linux, Valve has collaborated and fixed bugs or brought amelioration to both open and proprietary driver stacks.

So no matter what you think, serious gaming IS coming to Linux.

*: Well for obvisous socio-economic reasons. Linux users are likely to be computer savvy, thus probably work at tech jobs and thus higher paid and can afford more. A Sysadmin is more likely to have more money to spend on games than some guy flipping burgers.

Well I for one, are introducing the "Reverse Hairyfeet Challenge".
You do the same with Windows. But with one little specific detail: you do it from the point of view not of a corporate user, but a at-home end-user.

So you try surviving going all the way from Win98, all the way though WinME, and end up with Windows XP Home. See if you can keep you sanity going through this mess.
(I could have been even worse, I could have asked to start the challenge at Windows 3.11 and end-up at Vista, but I would probably get arrested for violating international laws against torture just for suggesting this).
And even if you managed to keep sanity you would probably not keep the hardware: at each major jump you'll end up noticing that your hardware is from a noname aisan manufacturer who since long went belly up and didn't bother writting drivers for the newer OS architecture. Requiring you to buy another piece of hardware from another manufacturer).

For the record, the laptop on which I am writing this is happily running opensuse for more than 2 years now, each update being done simply by live-updating to the newer version - while the distro is still running and used at the same time.
And 2 years ago, this laptop wasn't installed clean from scratch. I simply carried over the disk content from its predecessor. (Yup, try doing that with windows without entering a world of pain: you take a running Windows XP from one laptop, then yank out the disk, plug it into another laptop, and have it start. On linux, its mostly without problems. On Windows, your only hope is to clear huge part of the registry and configuration, to put it back into a "fristboot mode" where all the hardware is scanned again).
And I've got probably desktop carrying over the same installation for much longer. I think the jump from 32 to 64 bits was the last time I did a fresh install, then kept simply ugrading over.
 

The technology is out there, witness the few korean dead-cheap dumb high-res screens.
They only cost more than similar lower, hd-res of the same featureless no-name brands.

What is lacking is a huge market, so economy of scales kicks in and produced ueber-high-resolution screens is worthy.
Currently the biggest chunk of all produced flat pannel end up in TV screens. It makes more sense economically for the constructor to just put the same pannels into computer screens, than to market a special different type of pannels with higher res targetting the small niche market of users who want a PC monitor *and* also want higher resolution.

At least we can count on Apple and their "retina" buzzword to make higher resolutions fashionable, and thus increase enough demand that the big brands will start noticing.
Meanwhile, try to get a no-name high-res IPS pannel imported from korea on ebay.

But the victims got a copy of the binary (although against their will) but did not recieve anything clearly identifying the binary, contact information, licensing of free/libre opensource components nor source code. In fact everything is done to clearly identify the binary as something completely false and different - masquerading as Mozilla's Firefox (hence the trademark violation I mention above).
Because Gamma tries to hide Finfisher from the victim, the victim isn't properly informed of her/his rights regarding source code and freedom to modify. This alone could be a violation of the GPL.

The various *GPL licenses go to a great deal to properly define what counts as "distribution". (Even with subtypes like AGPL for which making a service available over the network counts as distributing).
A binary was given to the victims - even if it was against their wishes. More precisely, a *copy* of the binary was made onto the disk of the victim (hence the *copy*right law kicking in). To be able to make such copy, either Gamma has to be the owner of the code (which isn't the case with 3rd party component like libGMP whose rights still belong to the original authors), or Gamma has to have a license (an authorisation given by the authors) which allows them to make said copy. The license coming with the LGPL components comes with very precise requirements about what should be made with the code and the freedom to modify it. Gamma didn't respect it, thus the GPL is void for them and they don't have any license. The copy made and written on the victims disk is unlawful.

Gamma needs either to conform with the current license, or ask all the authors and copyright holder of libGMP a different license. (Which might not even be possible: not all project transfer the right to a single entity. Very often, every contributor retains the rights over his/her own contribution. To ask the right-holders for a different license could in some circumstance mean having to ask every single developer who has ever contributed any line of code. Which is partically impossible (that's why the Linux kernel is still licensed as GPLv2) and nothing guarantee that absolutely all of them would accept to change a license to help a spy).

Without such steps, Gamma is violating copyright law and liable.

Even if they swap a few letters around, this is clearly made on the sole purpose of creating confusion and make the victim think it's mozilla's firefox.
That's exactly what trademark law was made against.

If Microsoft can sue anything containing "Windows" in the name, if Bethesda can sue anything containing "Scrolls" in the name, if even Apple can sue everything whose name merely begins with lower case 'i' letter... Then Mozilla could certainly sue a company whose product is designed to make use think it's Firefox.

under the GPL, making the source code available under some form is mandatory, no matter what.

So Gamma is violating because there's no way to get the source code of their copyleft parts.

In addition to that, the forensics using finfisher to spy are deploying it - thus distributing binaries, and should alsoprovide the parts of source code which are required by the license.

Failure to do so would be a copyright violation:
- Gamma can't copy libGMP without a license, and the license asks Gamma to provide some source.
- the Gamma clients/spies in turn aren't allowed to deploy the software on victim's PCs without a license. Again, the (L)GPLed parts ask for source.

It's a clear trademark law violation.

"Firefox" is a name owned and controller by Mozilla, and is used to clearly designate one specific product: the Firefox browser.
Gamma are abusing the same name, Firefox, to masquerade their surveillance tool as a browser. They use the same name with intent to create confusion.

This is not allowed by trademark law and is punishable. It's almost a textbook's case.

About loss of revenue: Mozilla might not be selling copies of Firefox to end-users, they are still getting paid (by Google, among other) to produce it.

If suddenly Firefox becomes knkown as a filthy malware (which is exactly what Gamma is doing, and which exactly against what trademark law was designed) Mozilla might lose revenue though from sponsors instead of end-users.

The firefox part has nothing to do with "open source" or GPL violation.
Gamma isn't using a single line of code from firefox.
Instead they are abusing Mozilla's trademark.
This is a simple classical violation of trademark law. (and a clear one).

The LGPL violations are regarding some subcomponent used by finfisher, namely libGMP.

Mozilla's case is a very clear one. Although the software (the source code) is free and open, the trademark (the branding) *IS* NOT. (Hence all the IceWeasel and similar source builds). Gamma company is clearly using a name registered to Mozilla to masquerade itself, and abuse end-users' confusion to make them think it's a Mozilla registered product. That's almost the book case for which Trademark was designed.
The only thing which could prevent Mozilla from winning at the court would be government meddling (although, this is likely as its a widely used *surveillance* tool :-( )

In theory, Gamma should have negociated a trademark licensing deal (just as do Linux distribution which provide their own branding on top of Mozilla's. The Firefox which comes with opensuse isn't the exact binary which is available at mozilla.org, but they are allowed to package their build and still call it "Mozilla Firefox" because they obtained a permission).
In practice, Mozilla will probably refuse to grant Gamma a license.

The libGMP case is much more interesting: they copied code which don't belong to them. Either they are violating its license and breaking copyright law. Or, they'll have to abid to the license and make their surveillance tool end-user- (or should it be more properly called "end-victim"- ) modifiable. (Either the whole package if its GPL or at least the LGPL parts if there are only LGPL parts in Finfisher).
Meaning that victims could without any restriction take-over finfisher by injecting their own libraries: it would end up completely legal and possible to tamper with a wiretapping device because the license of some part of it require the end-user to be able to customise them (in case of LGPL, or to customise the whole package in case of GPL).