Greeks, too, have calculated the circumference of the globe (knowing distance between city and the height of the sun at midday on the same day).

The problem is not knowing how big the globe is. The problem is knowing what lies outside of the known parts.
Maybe it's only sea? That's what Columbus hoped.
But it turned out that there was a whole New-world continent hidden in-between.
Without a precise way to determine longitude (i.e.: without precise enough clocks), it's hard to tell how much one has travelled west-ward.

Perhaps all the circumference has been traversed, perhaps you've reached an unkown land half-way through.

And when the goal you advertised to your financial supporter was "finding an west route to India", you'd be all too eager to over-estimate the distance you've crossed and think you've reached the goal you've been paid for.

But then, that means you only have 1 point to change.

Want to lower the emission of you electricity production? You "just" replace the power plant with something else.
Then all the electric car can already run on the new system.

Want to lower the emission of your distributed cars exhaust? Now instead of changing 1 power plant, you need to change every single gaz-powered car.
A tiny bit more complex problem.

Not only have you moved around the emission, by centralizing you've abstracted them making future removal easier, and current car already compatible with future evolutions.

And that's just taking into account the US number about coal-based electricity production. Other countries (random example: Switzerland, Germany, Iceland, France ... ) my burn less coal and either count on renewable energy or nuclear energy (has its own set of problems, but CO2 and global warming arent among them).

Or do it like we do on europe:
rely on chip, instead of magnetic stipe.

(Which can't get skimmed).

The problem is that G-sync is a proprietary solution by Nvidia.

Whereas, Adaptive Sync is a VESA standard officially part of the DisplayPort 1.2a specs.

Found elsewhere:
NetworkManager, when calling dhcp trigger scripts fills these two variable:
DHCP4_FILENAME and DHCP4_DOMAIN_NAME
based on data received by the DHCP ACK.

So if a sever sets the domain name as "(){:;};rm -rf /", the laptop will be fried before even the script has a chance to check if that's actually a valid domain name.

(That's a bit like if an SQL injection could fry a server, because the php5 interpreter itself gets hijacked by it, before the php page had time to check and sanitize the inputs)

Though in the DHCP case, the DHCP client it self could do some preliminary input sanitization before handling the data out.

I'm not the original poster, but my idea goes like this:

- very often, when a laptop gets an IP from DHCP, it will launch a collection of helper scripts (that will in turn set-up lots of other thing. Random example: firewalling rules for the new interface)
- check which fields emitted by a DHCP server will end up in an environment variable during the call of these helper scripts.
Very obvisouly, the IP address will be in an environment variable, but that's not going to work because you can't put arbitrary data in there.
What else? Assigned network name? Some other data field?

Some of these data could have arbitrary form.
So you set it to "(){:;};rm -rf /".
Even before the helper script has had time to receive the data and do the necessary sanity check on it, bash will interpret the whole content (because it begins with () ) including the rm.

Any piece of software that:
- at some point of time runs helper shell scripts
- can receive arbitrary data that is placed in ENV variable while calling the scripts
is at risk.

Because BASH itself forgot to do its own input sanitation. (it should only load the function definition. It should not blindy eval any ENV variable beginin with (), it should only interpret the curly craces right after the () and stop once the body of the function is finished. Not call anything else).

That a REALLY nasty exploit.

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".