Now think about it this way:
yes, indeed a retro flector always bounces signal back to the source, no matter it its orientation is perfect.

BUT a better aligned retroflector offers a bigger cross-section: it will occupy a wider spot in the field-of-view of the laser.
A perfectly aligned retroflector will offer 100% of its surface exposed to a laser.
A 45 retroflector, will only offer a fraction ( cos(45) = sqrt(2)/2 ) of its surface.

So orientation *has* an incidence on the quality of the return signal.

But as you mention:
- so does size
- so does quality (lunokhod2 got covered by dust, to the point of the radiator malfunctionning and the isotope thermal generator overheating the rover, some of that dust could cover the retroflector a bit)

Both Nvidia and AMD recent drivers (r600 and radeonsi) are 100% green on all OpenGL features that are currently officially supported (OpenGL 3.x)
They only have red spots for feature that are for OpenGL versions that aren't supported by mesa yet any way (OpenGL 4.x) - in other words, that's still getting worked on. And given the current pace of development, both cards will support all opengl 4.x feature with short time difference between each other.

(Note: the case of r300 is a bit different. It's an older card generation (The various Radeon 9600/9800/X) and actually lacks some features like unified shaders - unlike the nv50/nvc0/r600/radeonsi cards. So you'll never see 100% features support anyway. The hardware simply isn't there)

The problem aren't *features*. The problem is performance.

Except for the part that re-clocking is critical to get decent performance out of a card. And it doesn't work reliably yet. The usability is, according to current benchmark at phoronix, quite random.

That's not nouveau team's fault, though. Nvidia has started releasing documentation only very recently (and almost only about Tegra).
Without documentation Nouveau team has to reverse engineer almost everything, and that's not an easy task as shown by the actual realworld performance.

Except that real world test tend to show that the actual result will vary greatly between differnt cards.

And probably the other drivers will have it too around the same time frame...
(You know, the whole point of Gallium being modular and parts being re-usable. Once Mesa starts supporting a feature for one card, getting the other to support is a lot easier: basically only upgrading the backend)

It *IS* relevant. Without any help from Nvidia, the work for Nouveau developer is much harder (as seen with the current problems regard re-clocking), and more bumpy accross the landscape of varied graphic cards.

As AMD provides documentations to the radeonsi/r600 developers (in addition to having some developer on their own payroll), it's much easy for them.
To the point that AMD considers the opensource driver as a valid alternative for older hardware whose support has been dropped in recent catalysts.

Uh.... No. bitcoin is a protocol that anyone is free to use (or not).
There are no "places that create bitcoin", just lot of software instances using the bitcoin protocol to push BTCs around.

...except for the part that there is no company called Bitcoin. There is no "Bitcoin Inc." controlling how bitcoin work and collecting fees.
There's an optional concept of "fees" in the bitcoin world. But that's not collected by an entity, that's a tip for miner to encourage them into including your transaction into the next block of the chain.

You could be using payment processor that collect a fee, or you could be using entirely different ways to send BTCs around. That's up to you.

Whereas, PayPal, Visa Inc. and MasterCard wordwide are very real companies collecting fees as middle men.
Visa and MasterCard form a duopoly that basically has nearly control of every payment anywhere.

There are no such company controlling anything in the bitcoin protocol. If you're not happy with a payment processor (say you hate both big processors bitpay and coinbase) you're free to move to any other one. As long as the new one follows the same protocol, it's still usable and interoperable with anyone else.

bitcoin is mainly a protocol, open for everyone to implement.

The closest to it in the "classic payment" world is SEPA. SEPA is *NOT* a company (unlike Visa and Mastercard), it's a standard for fast payment between banks in Europe.
Any SEPA compliant-bank can quickly and easily send money to any other compliant bank. You don't need to use the same bank as a merchant, as long as yours supports SEPA, you can also quickly send payments to the merchant. You're not forced to deal with the same company at both ends.

Could you try the opensource drivers (radeonsi , etc.) I've read on Phoronix that it works decently with Counter-Strike.

Yup, the value of BTC does vary a lot. That doesn't make the bitcoin payment protocol any less valuable to exchange money around.
That only means that, if you want stability and predictibility, you'd better hold you value in a currency like EUR or USD, and exchange it to BTC only to do the payment (automatically by a payment processor - e.g. one of the listed 3 or any other one, or manually at an exchange).

But don't think this is about enabling BTC as yet another account currency at PayPal (in fact, that's not possible).

It's about a way to transfer funds to a paypal merchant. An alternative to using a credit card (an alternative to Visa or Mastercard).
And an alternative that gives you a freer and wider choice of middlemen to pick from (to pay by credicard on the internet, your basically restricted to only pick between Visa Inc. and MasterCard - to pay the bitcoin protocol, any solution that follows the protocol is acceptable. Bitpay. But also Coinjar. But also localbitcoins. But also convering your coins at BTC-e. etc.)

With a subtle difference difference:
if you pay with your VISA card, not only does paypal need to collaborate with a bank, that in turn collaborates with Visa Inc., but that requires you to also have an account in a bank that also works with Visa Inc.
By being at one side of the transaction (merchant) Visa Inc. forces itself on your side of the transaction (consumer). You have no choice.

if you pay with bitcoin payment protocol, you're free to pick your way of handling the payment:
enven if the merchant use PayPal partnership with bitpay, you're not required to be using bitpay too to send your BTCs.
You could be using Coinbase instead. You could be using one of paypal's competitor (OkPay also offers bitcoin support). You could be using a different payment processor not mentionned here (coinjar as a random example). You could get your BTCs form entirely different source (localbitoins, mining, exchange like BTC-e, etc.)
it's up to you, and the particular choice of middle men on the merchant side of the transaction doesn't force anything on you.

At least, because the bitcoin protocol is open, you can freely choose between *ANY* of the available middleman. And your choice isn't restricted by the choice of the other party.

Before bitoin:
- the merchant you buy from uses PayPal
- therefore, if you want to buy stuff, you need to use PayPal too.
(Note only that, but you're further forced down the line to use a credit card supported by PayPal, most probably Visa/Mastercard, so you're further forced to use one other middleman).

After bitcoin:
- the merchant you buy from, could be using PayPal's integrated support for bitcoins. Or the merchant could directly use one of the other 3rd party's coin processor. Or the merchant could be using an entirely different payment processor that wasn't mentionned already (random exemple: coinjar).
It doesn't matter, they can choose the middle-man of their liking, as long as the middle man support the bitcoin protocol.
- you the client needs to send your payment using the bitcoin protocol, sending BTCs as the intermediate form. You could be doing that with paypal's partnership with coinbase. Or you could have your own account at bitpay. Or you could have exchange EUR into BTC from a platform like BTC-e. Or you could actually be using a person-2-person service like localbitcoins, and gotten your BTCs in hand after having personally handed a EUR bill to a person you met in a cafe. Or you could have actually mined them, back when mining any significant amount was realistic. Doesn't matter. You're free to chose your own middleman as long as it follows the same protocol. Your choice is completely independant from what the other person has chosen.

This freedom of choice is bound to bring more competition between payment processor and other middle men, and encourage competing on quality, etc.

(Think like the advantage that SEPA system bring in Europe for payment between banks. Except it's a bit faster.)

Read again, he's not saying that his Sears TV is better *because it still works*. It's not survivor bias.
He's saying:
- back then, a TV was expected to be repaired and came with all the necessary information to do a repair.
- nowadays, things are made much more difficult for any one wanting to repair: good luck finding the schematics of any modern LED TV.

That's basically how teaching/learning mechanism on the whole did evolve. That's why lot of mammal have youngs observe the adult and copy behavious. That's why in some mammal species, the parent actively teach the young. That's why some mammals (humans, dogs, etc.) from very strictly hierarchical societal organisation, with the underling strongly following the alpha, etc.
That's also why memes work on the internet.

"Religion" itself, is just a side phenomenon, that happens to hi-jack this transmission of knowledge methode and packs together useful information ("Things to avoid eating not to get sick") with complete non-sensical mythology/legends. That all still gets perpetuated because "that what we've always been doing".

the cgroups functionnality existed in the kernel but wasn't really used that much before.
systemd, with its tasks in setup/startup of things can handle the creation of jails during lauch when needed.
whereas current /etc/init.d/apache can't without fumbling of shell scripts.

And thus each script end up fucking things up in its own original and different way.

None of which are the original sysvinit.
Either it's relying on LSB-extended script and a different core which starts the scripts. (Debian had a makefile based one)
Or it's an entirely new system anyway like upstart.

Or cron if it's time-based activation. Or udev if it's hardware based activation. Etc.
Why do we need 83 different way to start some code ?!
Wasn't the whole point of Unix philosophy having one piece of software which concentrates into doing one thing and doing it well?
With systemd, setup/startup/stop/teardown responsibilities are concentrated with PID1 and it's helpers.
Before, you'd have the same concept spread into a dozen of different systems, each only doing part of that functionnality.

I like systemd, it makes my work easier on desktop, on server, on virtual machines, etc. and although it used to have hiccups when it was introduced before in opensuse, by now it has had the time to mature.
no need to bash it. if you don't like it, don't use it.
and perhaps the fact that it's slowly gaining popularity in lots of mainstream distro might be due not because systemd is "a spreading cancer" but because systemd is actually useful and solves real world problem

And another thing I like about systemd:
- it groups into 1 single project: 1 single task (starting-up/seting-up things) that was spread accross way too many different project before.

Before systemd:

Want to start a service during boot-up ? Put it into sysvinit. Except if it's a file system, then it goes into /etc/fstab. Or if it's not a *service* but like of an interface like your terminal that should go into inittab (Except on distribution which do THE EXACT SAME THING but in init.d anyway).
The thing which start is related to actual hardware? the you need to put it into hal, no way we replaced that with udev... except that a few distro put them any way in init.d and thus your hardware might not work when plugged after booting... unless you also duplicate some code into modprobe.conf's post-runs.
And what if conditions for your code to start isn't "boot-up" nor "plug-in" ?
Then put it into inted/tpcd if it's network triggered. Except for code that doesn't work there, because the service needs to be compiled to use libwrap to work this way. So then you'll have to run the service constantly and fumble around with ip filtering to enable/disable it on demand.
Or put it into cron if it's time triggered.
And you need to start a service and the periodically monitor it for failure, and restart and raise alert if it has failed? Well either use an entirely separate custom system like djbdns's daemontools. Or write your own monitoring solution by writing a ton of scripts which tap into all those different ways to start/stop stuff and hope that it works.

And don't get me started about initialising containers (limited fonctionnality, tons of script), brokering access rights around (not really used. lot of interface must run as root and drop privileges, or lot of interface must be world accessible), handling situation as missing configuration or drivers in a system that hasn't fully booted up to the point where the GUI works and the user can fix things from here (huge tons of scripting to achieve way to detect that Xorg is failing and to propose solution to fix drivers)

All this written in shell script which can have their own pitfalls, and every single system using a different syntax.

After systemd:
PID1 and its herd of helpers take care of setup/start/stop/teardown.
Want to do *something*? Write a systemd config file, and describe which trigger (boot, after another service has started, on network, by clock, on device plug, etc.) should start it.
You can even call legacy systems from within systemd (cron can be reimplemented as a systemd service that runs periodically and reads/executes crontab, etc.)

You can have an LXC that is quickly setup. In fact you can quickly create throw-away container to jail any service separately (systemd is the kind of infrastructure that can boot a dedicated LXC jail to run Skype into, with restriction correctly setup so that no hidden backdoor could spy on you).
You can have systemd handle brokering the necessary rights (to the point that plugin an USB stick and having the currently active user access to it isn't a nightmare anymore).

If anything the handling of setup/startup/stop/teardown WAS NOT "unixy" before, it was "have 384 different programme which all do a different part of one single task in subtly different ways".

They are fundamentally different.

On one side you have turn-by-turn games, that progress in fixed steps, and thus simply paint the game field by putting varied wall graphics at exact predefined places.
It's really the discrete position on the map and cardinal headings that are specific,
(That's what you get in most classical RPG).
Could very easily be done back then with a few lines of code. The biggest chunk of work came from the *art* to have a big enough choice of wall to draw to make an interesting world (because it's mostly static, you'll be spending a lot of time at the same, and need something nice to look at).

Basically, the graphic engine has a fixed grid on screen and you put different sprites at said fixed grid positions.

On the other side you have game engines that try to have some actual notion of 3D built into them and allow smooth motion, with complete arbitrary position/headings.
(That's what you get in most FPS and real-time RPG like ultima).
There is really require more advanced coding. (With Origin more concentrating on making an imersive game, emphasis on beautiful graphics, and ID concentrating on make their engine fast and responsive, sacrificing any detail necessary for the sake of being able to make a fast paced game).

Basically, the graphic engine use geometric techniques like wolf's raycasting do determine what is visible where, and gives you total freedom (or at least tons more of freedom, as Carmack used limitation to beat Ultima in speed and fluidity).

From a basic visual composition, both categories have a first person perspective.
From a technical point of view, they are designed completely differently.

The dumbest of the dumb can only realise things are going badly when they can compare with things going well. To realise that the current government fucks everything up require to be able to realise that some things could be a little bit less fucked up, and the reason they are still so bad is the government's fault.

But if a country is shot down into dark ages, that gets much more difficult. See the reports about fugitive who have escaped extremely isolated dictature like North Korea. These people had probably the vague notion that perhaps here in the west, things are going a bit easier that in their country. (That's why they ran away in the first place)
But having so few information means that these people are just completely amazed by how far off their perception of the outside world has been, they knew that things could go in a different, better way. But they weren't able to realise that outside the totalitarian prison things are SO different.

It was alread *rejected* from pirate bay.
Look around for "10 millions emails yandex mailru gmail w passwords 2014".
It might still be in some cache (that's where I found it).
And it starts poping up around on other tracker.

Indeed, IB Times wins the record of the worst ever summary of microbiology subject.
(mixing virus and bacteria and toxins. And multiplication and dead cells. W.. T.. F.. )

(Also, the magnets have nothing to do with the removal. They are just the mecinal technique used to move the metal beads around. It's the manose-binding lecitin on them that hold the magic.
It's not "removing Viruses and bacteria using magnets" but "removing them using lecitins which happen to be moved around thanks to magnets").

The nature paper it self is good, and the method is typical technique used for extraction / purification (so the principle is solid).

The relative novelty of this method is that, instead of using an antibody as the binding agent (something that needs to be targeted specifically. In vertebrate they are part of the *adaptive* immunity : immunity that the body needs to train) this method uses manose binding lectins (something that isn't specific and bind to lots of targets: bacteria, virus, toxins, etc. In eukaryote, they are part of the *innate* immunity: immunity you are born with, you don't need to train. Your body will already produce lecitins against sugar patterns that aren't frequent in your body, even if you've never encountered them).

Thus, its able to purify and extract from a patient's blood bacteria, virus and toxin *THAT YOU DO NOT KNOW beforehand* (i.e.: anything that presents a pattern of sugar on the surface that isn't common in the body and for which they have the corresponding lecitin).
(Where classical extraction usually rely on antibodies targeting what you would like).

It's a bit equivalent to use coal to purify blood: coal will indiscriminately extract any big organic molecule without you needing to know it in advance and thus is a valuable tool in case of poisoning