If so many distributions, including several major ones (openSUSE, Fedora, Debian, etc.) are ALL switching to systemd (and before that to network manager and pulseaudio), and some of them since quite some time (openSUSE has been using it for 4 iterations) without switching back, and some are even eager to jump in as start using future project from the same source (Google has expressed interests in KDBUS), there might be 2 explanations:

- either Lennart is an Evil-Über-Wizard-Super-Mutant who is mastering the art of mass mind-control, and it forcing every distro to switch using hypnosis.

- or maybe, perhaps systemd is actually USEFUL, solves real-world problems (to the point that most distribution have decided to use it), and isn't as problematic as the detractor want you to believe (don't base your opinion on what the first beta was years ago). Some of purported evils of systemd have no base in reality (detractors tend to forget that systemd is not only PID1, but a whole constellation of helper softwares and daemons).
Systemd might have enough objective qualities, so that even if a very vocal minority doesn't agree with it, a silent majority has considered interesting enough to give it a try.

Also, online I hear a lot of people complaining about systemd and calling for boycott, but I see very few actual useful work:
- Gentoo *DID* write their own init system (OpenRC).
- Uselessd is an attempt at an alternative using as few components as possible.
- SystemBSD is an attempt to offer the same API but rewritten from scratch for BSD (so Gnome and other software which relies on systemd can run there).

But outside of there 3 exceptions, it's basically only people complaining and whining, and not much effort to actually avoid systemd and propose another alternative.

I'm interested, in which jurisdiction can you get fined for NOT violating rules ?!

That certainly not the case anywhere here in europe.

Technically, it's the other way around: If having a biological womb you've been born with isn't a requirement for human reproduction anymore, it's the *MEN* who don't need women any more.

The male geek could get implanted with the necessary womb to give birth to children without ever needing to meet a girl (and an advantage: in mammals, mixing male genetic material can give birth to both male and female offsprings (you have both X and Y sex chromosome to pick from) unlike when mixing female (only X available) ).

Now, if your point is having *intercourse* with a girl, that's a different set of problems (And I would suggest that you either start working on your social skill and start go out and socialize during hobbies where you can meet potential partners) (Or I suggest to move to a country where the paid-for alternative is considered as just another kind of job (with tax, social security and insurance) rather than a crime worthy of imprisonment).

Indeed, odds are low that actual shit will actually happen.

In fact, we could even spin your president's argument:

"When so few children are actually in danger at any given moment: predators, crooks, bullies and thieves needs to be able to take advantage of every government-sponsored backdoor to hack into computers to quickly find vulnerable children and potential targets to abuse/mug. It is worrisome to see companies ready to leave backdoors and giving ability to create exploits" -- Mirror universe Obama (The one with the evil goatee)

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