They had a trademark on their brand. The feds decide they don't like the mark so they take it away. The owners end up being harmed economically all because the government didn't like the descriptive nature of the brand. They've effectively stifled the free speech of the owner by denying them the use of the mark.
Please read the decision. They have done no such thing, and haven't cancelled the trademark. They've removed it from the primary registry. The team still has full protected (TM) rights, and third parties won't be allowed to make knockoff jersey with the name on it or anything like that. It's just not a registered (R) trademark anymore.
From the decision: This decision concerns only the statutory right to registration under Section 2(a). We lack statutory authority to issue rulings concerning the right to use trademarks. See, e.g., In re Franklin Press, Inc., 597 F.2d 270, 201 USPQ 662, 664 (CCPA 1979).
The trademark exists to protect their business interest in the brand name. The feds aren't canceling the mark because other business entities want to use it, they're canceling the mark because the feds don't like it.
This is wrong. The feds aren't canceling the trademark, period. They are canceling its presence on the USPTO primary registry (where it's not allowed to be under the Lanham act), but it'll still be a (TM) trademark with court protection (just not an (R) registered trademark).
From the decision itself:
This decision concerns only the statutory right to registration under Section 2(a). We lack statutory authority to issue rulings concerning the right to use trademarks. See, e.g., In re Franklin Press, Inc., 597 F.2d 270, 201 USPQ 662, 664 (CCPA 1979).
The government is not restricting speech at all. The summary is hopelessly dumb: the decision doesn't strip the team of their trademarks, it simply removes them from the USPTO registry as required by the Lanham act. They'll still be protected (TM) trademarks that nobody except the owner is allowed to use, they just aren't (R) registered (which has implications on venue and damages).
From the decision itself:
This decision concerns only the statutory right to registration under Section 2(a). We lack statutory authority to issue rulings concerning the right to use trademarks. See, e.g., In re Franklin Press, Inc., 597 F.2d 270, 201 USPQ 662, 664 (CCPA 1979).
Redskins isn't being stripped of their trademark, the summary is completely wrong. They're just not being allowed on the primary registry. They'll still have (TM) protection, but not (R) protection.
awk is fine for one-liners and for simple takes on moderately large files can be 5-6x faster than Perl. For all that perl has the reputation for being a grep/sed/awk replacement, it's incredibly slow at the job. Sometimes that matters.
For anything larger than a one-off, I'd go with python/pypy (ruby and lua are also fine choices).
$ time awk '{print $1}' < f4.txt >/dev/null
real 0m0.296s user 0m0.288s sys 0m0.004s
$ time perl -pale '$_="@F[0]"' < f4.txt >/dev/null
real 0m1.920s user 0m1.896s sys 0m0.020s
$ time python -c "import sys;[sys.stdout.write(line.split()[0]+'\n') for line in sys.stdin]" < f4.txt >/dev/null
real 0m0.618s user 0m0.604s sys 0m0.008s
$ time pypy -c "import sys;[sys.stdout.write(line.split()[0]+'\n') for line in sys.stdin]" < f4.txt >/dev/null
I think that Slashdot ate some of your formatting (angle brackets?). I'm not sure how the hash table is used for messaging (you might want to consider Unix domain sockets for messaging, depending on what's going on). But...
You can basically grow shared memory segments on the fly. They're shared in the FS page cache, so if you create a "new" memory mapping on the same backing file that's just bigger, it'll contain all the same stuff in the original segment as the original mapping.
So you just:
a = mmap(..., 2 megabytes,...)
(Use for a while, realize that it's too small)
old = a new = mmap(..., 4 megabytes,...) a = new munmap(old)
You have to do that per-process, but you can either have the initial part of the memory indicate the mapping length (every time you use it, check the length and reallocate if you're off) or you can use a semaphore or socket message or other OOB message to indicate when to resize.
I don't see how this is (theoretically) any harder in C++ than in Java as far as the problem specifics go (I mean ignoring general reasons that C++ is harder than Java).
Also when they say that a python Manager object is slow, access to it should be considered similar to access to a synchronized method in Java. But reading large amounts of data over it can be problematic, depending on exactly how you're using it.
Depending on your access needs and where your bottlenecks are, I'd also consider using memcached or something like that if you think you might ever expand to multiple machines.
Go doesn't have support for fork without exec, or at least didn't last time I looked at it.
I need async execution of things with read access to lots of data, and write access to their own data.
This sounds like shared memory segments to me. You can enforce memory protection by having separate mappings per process that are only writeable by the owner, with the processes running as separate users. That's safest but requires separate users and can be a headache for some tasks. Alternatively you could rely on the open/map calls being right and use read-only mode there but run as one user (you'd still protect against random pointer bugs, mistakes about which data structures you're writing into, etc as long as the open calls were correct).
ALL I need is synchronization
What kind of synchronization? What are your performance requirements? You may want want to consider simple mutexes, spinlocks, token passing, or read-copy-update depending on what you're doing.
BTW the basic architecture choices are similar across most languages; whether it's C or Python or Lisp or C++ or whatever, you're looking at a handful of common primitives for synchronization and data sharing, often with thin language-specific wrappers around them.
The most common times that there's a major difference is when either in a highly functional language designed around concurrency (e.g. erlang) or a language that isolates you so much from the environment that you can't easily use common primitives (Java's inability to get to multiprocess calls is the most obvious example).
I'd need to know more about your app to make a real recommendation, but in general for multiprocessing I'd use fork without exec to spawn new processes; they will share memory in a copy-on-write manner, so the python interpreter itself and other read/execute only memory will be shared between all processes.
There are numerous approaches to data sharing--sockets/pipes for streaming data and memory-maps for shared memory segments (memory maps are generally preferrable to SysV shm segments, IMO), and either token passing via pipes or something like multiprocessing.Lock for synchronization.
Your cells may want an event-driven state machine model. It's tough to say without knowing more about the app.
Python's great for multi-processing, much better than Java (which has no built-in solution for multiple processes/tasks, requiring you to throw out the benefits of protected memory or resort to hacky multiple JVM solutions with home-brewed synchronization primitives in order to take advantage of multiple CPUs).
Java's better for multi-threading, but that's usually a poor approach to multi-processing and in the real world the GIL problems with Python are often (but not always) overstated--e.g. the GIL is released by C extensions, so if you're using numpy or PIL or something then it's a non-issue much of the time. And Python has excellent support for fork-without-exec, shared memory maps, and other things that are important to good multiprocessing.
Either: 1) You want to use the phone while driving, in which case you're not going to use such an app; or 2) You don't want to use the phone while driving, in which case you can simply not use the phone.
The first question should have been "Who are you and why should I care?".
He did the "Code Monkey" song, as you note. He also composed music for the Left 4 Dead 2, Portal, and Portal 2 soundtracks, and did the theme song for the TV show Mystery Diagnosis. He's featured weekly as the house musician/sometime question designer on NPR's game show "Ask Me Another".
And, yes, all Ask Slashdots should have a 2-3 sentence blurb with a link to a biography or wiki entry or something.
The client can detect it (on a plain install, view the cert for the page you're on and you'll see who signed it and whether it's a corporate cert or a self-signed cert). The "problem" at work is that once someone else has control of your hardware then it can't be trusted--they could as easily have installed a keylogger and screen scraper, or whatever. Or have installed a browser altered so that "view cert" shows a different cert from the one actually being used. The client isn't trustworthy, which means nothing at all is trustworthy.
You're relatively safe if you do your own OS install and keep things locked down, though even there the hardware manufacturer(s) could be snooping on things. At some point you have to weigh what is enough trust vs. having the tools you need to accomplish your goal (a powered down, non-networked machine is pretty trustworthy, but also relatively useless).
I wouldn't even say they were "inspirations". Star Control 2 was a spirtual successor to Starflight, except for some cool arcade combat added in--aside from that, the game is mechanically pretty similar with the same kind of intergalactic maps, system maps, planet exploration, etc.
They're close enough that I'd almost say SC2 is a rip-off of Starflight, except that Paul Reiche was one of the lead designers on both and I'm not sure you can rip off yourself. But it's a much closer relationship than just "inspired by".
Reiche also the primary guy responsible for Archon (which is in some ways an inspiration for the combat arena part of Star Control 2, though very much more a loose inspiration than an obvious predecessor) and was one of the early TSR Dungeons and Dragons guys.
The Halting problem still doesn't apply to an iphone, though. Or the 2036 equivalent thereof. Or anything that can ever be built, as far as I can see. It relies on infinite memory to make the set of programs it can run innumerable.
Well, there is one small difference. With an AI, one can always, precisely, deconstruct why and how the system makes the decision that it makes
This is false. There are whole papers dedicated to how useless deeply trained neural nets are in actually understanding intelligence, because they're so complicated that we can't understand why they make particular decisions post-training.
No, the sections I quoted are for the built in headset speaker used for calls. The numbers are all above average for call quality and average for volume. I'm not sure how their subjective judgement said "below average", given that every single one of the objective measurements was average or above. It's not the loudest or best speaker out there, for sure, but it's better than most.
I hope it isn't a mildly revamped G2! The G@ has a below-average loudspeaker
There are a lot of decent criticisms of the G2. The SlideAside is pointless (and doesn't work with a ton of common Android apps), the screen is too big for some people, the buttons on the back are something you can adjust to but they're needlessly quirky and more prone to accidentally being pressed in your pocket than side-buttons are. I'm still not sold on having the headphone jack on the bottom instead of the top.
But the speakers? The G2 has virtually perfect frequency response and a very low distortion level according to:
GSMArena, for one, actually measure the volume....who also measure frequency response and other components of sound quality.
They note that the speaker on the G2 is better than average sound quality, though average volume-wise. There's absolutely nothing in their tests indicating a below-average speaker:
The LG G2 showed nicely clean output in both parts of our traditional audio quality test. The smartphone got pretty decent scores, but was led down by its volume levels, which were only average. The scores stay close to perfect even when you plug in a pair of headphones. The stereo crosstalk worsens a bit but the rest of the readings are virtually unaffected (frequency response actually improves a bit). Unfortunately, the volume levels remained just as uninspiring.
Which seems like they're heavily over-weighting volume--unless you're hearing impaired enough that you normally max the volume on your handset, then maximum volume is far less important than the audio quality. But even by their weighting, it's still good audio quality with average volume level.
But the Nexus 5 will probably be half the price of the G2. And run stock Android and receive updates.
The last sentence is why I wrote "the Nexus 5, presuming it follows the Nexus pattern, will run a standard Android OS and UI (and get faster OS updates)".
I'm not making a case for either phone being better, simply saying that the idea that one is a mildly tweaked version of the other is laughable.
the Nexus 5 (or whatever it’s going to be called) seems like a mildly revamped version of LG’s G2.
No, it really doesn't. The two most-often mentioned features of the G2 are:
a) The gorgeous 5.2" screen; and b) A 3000 mAh battery; and c) The rear-panel placement of the only buttons (power/volume), as opposed to the traditional volume rocker on the side that most smartphones have.
This has none of those--it has a 4.95" screen and a 2300 mAh battery. And the buttons are laid out like a standard smartphone. Those things alone are significant alterations that make these phones different in the most visible and usable ways.
The G2 also has a 13 megapixel rear camera; this has an 8 mp camera.
The G2 also has a customized version of Android with knock-on and other features; the Nexus 5, presuming it follows the Nexus pattern, will run a standard Android OS and UI (and get faster OS updates).
Without digging into it for more than 30 seconds, I see a phone with a different screen, different camera, different battery, different physical button layout, and different UI, and with significantly different physical properties (e.g. wireless charging on the Nexus)--these might be distant cousins, but they are most decidedly not "mildly revamped" versions of the same thing.
Right, and then let's start mixing it into aids victims treatments, and then let's mix it into the food at homeless shelters, and then let's coat welfare checks with it, and then let's let's let's... And then let's... http://art-bin.com/art/omodest.html
For some reason, it's not considered an epidemic when a doctor being paid by insurance companies prescribes methamphetamine manufactured by a pharmaceutical corporation under the brand name "Desoxyn"
Yes it is.
NIH: "The original amphetamine epidemic was generated by the pharmaceutical industry and medical profession as a byproduct of routine commercial drug development and competition" http://www.ncbi.nlm.nih.gov/pmc/articles/PMC2377281/
Not true... I have no opinion either way, but it's entirely possible to have a very good understanding of how semi-random numbers affect cryptography, and also of how rdrand generates them, without having the programming background to be able to safely remove it from the kernel. Crypto is about math, not programming, and contrary to popular opinion (apparently), the two do not always go hand-in-hand.
RdRand could generate entirely non-random numbers and it still wouldn't make the output of/dev/random any less random. It's designed so that additional inputs can only increase the entropy, never decrease it. There's a danger if you over-estimate the amount of entropy that a particular input adds to the pool, but the bits mixed in from rdrand don't increase the entropy counter so that's not a problem in this case.
Slashdot Mirror
Please read the decision. They have done no such thing, and haven't cancelled the trademark. They've removed it from the primary registry. The team still has full protected (TM) rights, and third parties won't be allowed to make knockoff jersey with the name on it or anything like that. It's just not a registered (R) trademark anymore.
From the decision:
This decision concerns only the statutory right to registration under Section 2(a). We lack statutory authority to issue rulings concerning the right to use trademarks. See, e.g., In re Franklin Press, Inc., 597 F.2d 270, 201 USPQ 662, 664 (CCPA 1979).
This is wrong. The feds aren't canceling the trademark, period. They are canceling its presence on the USPTO primary registry (where it's not allowed to be under the Lanham act), but it'll still be a (TM) trademark with court protection (just not an (R) registered trademark).
From the decision itself:
This decision concerns only the statutory right to registration under Section 2(a). We lack statutory authority to issue rulings concerning the right to use trademarks. See, e.g., In re Franklin Press, Inc., 597 F.2d 270, 201 USPQ 662, 664 (CCPA 1979).
The government is not restricting speech at all. The summary is hopelessly dumb: the decision doesn't strip the team of their trademarks, it simply removes them from the USPTO registry as required by the Lanham act. They'll still be protected (TM) trademarks that nobody except the owner is allowed to use, they just aren't (R) registered (which has implications on venue and damages).
From the decision itself:
This decision concerns only the statutory right to registration under Section 2(a). We lack statutory authority to issue rulings concerning the right to use trademarks. See, e.g., In re Franklin Press, Inc., 597 F.2d 270, 201 USPQ 662, 664 (CCPA 1979).
Redskins isn't being stripped of their trademark, the summary is completely wrong. They're just not being allowed on the primary registry. They'll still have (TM) protection, but not (R) protection.
NWA never attempted to register, AFAIK.
awk is fine for one-liners and for simple takes on moderately large files can be 5-6x faster than Perl. For all that perl has the reputation for being a grep/sed/awk replacement, it's incredibly slow at the job. Sometimes that matters.
For anything larger than a one-off, I'd go with python/pypy (ruby and lua are also fine choices).
$ time awk '{print $1}' < f4.txt >/dev/null
real 0m0.296s
user 0m0.288s
sys 0m0.004s
$ time perl -pale '$_="@F[0]"' < f4.txt >/dev/null
real 0m1.920s
user 0m1.896s
sys 0m0.020s
$ time python -c "import sys;[sys.stdout.write(line.split()[0]+'\n') for line in sys.stdin]" < f4.txt >/dev/null
real 0m0.618s
user 0m0.604s
sys 0m0.008s
$ time pypy -c "import sys;[sys.stdout.write(line.split()[0]+'\n') for line in sys.stdin]" < f4.txt >/dev/null
real 0m0.531s
user 0m0.508s
sys 0m0.020s
If you have a CPU-intensive thing, you can use shared memory and binary structs to share it, no need to turn everything into a string.
I think that Slashdot ate some of your formatting (angle brackets?). I'm not sure how the hash table is used for messaging (you might want to consider Unix domain sockets for messaging, depending on what's going on). But...
You can basically grow shared memory segments on the fly. They're shared in the FS page cache, so if you create a "new" memory mapping on the same backing file that's just bigger, it'll contain all the same stuff in the original segment as the original mapping.
So you just:
a = mmap(..., 2 megabytes,...)
(Use for a while, realize that it's too small)
old = a ...)
new = mmap(..., 4 megabytes,
a = new
munmap(old)
You have to do that per-process, but you can either have the initial part of the memory indicate the mapping length (every time you use it, check the length and reallocate if you're off) or you can use a semaphore or socket message or other OOB message to indicate when to resize.
I don't see how this is (theoretically) any harder in C++ than in Java as far as the problem specifics go (I mean ignoring general reasons that C++ is harder than Java).
Also when they say that a python Manager object is slow, access to it should be considered similar to access to a synchronized method in Java. But reading large amounts of data over it can be problematic, depending on exactly how you're using it.
Depending on your access needs and where your bottlenecks are, I'd also consider using memcached or something like that if you think you might ever expand to multiple machines.
Go doesn't have support for fork without exec, or at least didn't last time I looked at it.
I need async execution of things with read access to lots of data, and write access to their own data.
This sounds like shared memory segments to me. You can enforce memory protection by having separate mappings per process that are only writeable by the owner, with the processes running as separate users. That's safest but requires separate users and can be a headache for some tasks. Alternatively you could rely on the open/map calls being right and use read-only mode there but run as one user (you'd still protect against random pointer bugs, mistakes about which data structures you're writing into, etc as long as the open calls were correct).
ALL I need is synchronization
What kind of synchronization? What are your performance requirements? You may want want to consider simple mutexes, spinlocks, token passing, or read-copy-update depending on what you're doing.
BTW the basic architecture choices are similar across most languages; whether it's C or Python or Lisp or C++ or whatever, you're looking at a handful of common primitives for synchronization and data sharing, often with thin language-specific wrappers around them.
The most common times that there's a major difference is when either in a highly functional language designed around concurrency (e.g. erlang) or a language that isolates you so much from the environment that you can't easily use common primitives (Java's inability to get to multiprocess calls is the most obvious example).
I'd need to know more about your app to make a real recommendation, but in general for multiprocessing I'd use fork without exec to spawn new processes; they will share memory in a copy-on-write manner, so the python interpreter itself and other read/execute only memory will be shared between all processes.
There are numerous approaches to data sharing--sockets/pipes for streaming data and memory-maps for shared memory segments (memory maps are generally preferrable to SysV shm segments, IMO), and either token passing via pipes or something like multiprocessing.Lock for synchronization.
Your cells may want an event-driven state machine model. It's tough to say without knowing more about the app.
But Python doesn't handle multi-processing well
Python's great for multi-processing, much better than Java (which has no built-in solution for multiple processes/tasks, requiring you to throw out the benefits of protected memory or resort to hacky multiple JVM solutions with home-brewed synchronization primitives in order to take advantage of multiple CPUs).
Java's better for multi-threading, but that's usually a poor approach to multi-processing and in the real world the GIL problems with Python are often (but not always) overstated--e.g. the GIL is released by C extensions, so if you're using numpy or PIL or something then it's a non-issue much of the time. And Python has excellent support for fork-without-exec, shared memory maps, and other things that are important to good multiprocessing.
Either:
1) You want to use the phone while driving, in which case you're not going to use such an app; or
2) You don't want to use the phone while driving, in which case you can simply not use the phone.
The first question should have been "Who are you and why should I care?".
He did the "Code Monkey" song, as you note. He also composed music for the Left 4 Dead 2, Portal, and Portal 2 soundtracks, and did the theme song for the TV show Mystery Diagnosis. He's featured weekly as the house musician/sometime question designer on NPR's game show "Ask Me Another".
And, yes, all Ask Slashdots should have a 2-3 sentence blurb with a link to a biography or wiki entry or something.
The client can detect it (on a plain install, view the cert for the page you're on and you'll see who signed it and whether it's a corporate cert or a self-signed cert). The "problem" at work is that once someone else has control of your hardware then it can't be trusted--they could as easily have installed a keylogger and screen scraper, or whatever. Or have installed a browser altered so that "view cert" shows a different cert from the one actually being used. The client isn't trustworthy, which means nothing at all is trustworthy.
You're relatively safe if you do your own OS install and keep things locked down, though even there the hardware manufacturer(s) could be snooping on things. At some point you have to weigh what is enough trust vs. having the tools you need to accomplish your goal (a powered down, non-networked machine is pretty trustworthy, but also relatively useless).
And they are basically Starflight "resurrected".
I wouldn't even say they were "inspirations". Star Control 2 was a spirtual successor to Starflight, except for some cool arcade combat added in--aside from that, the game is mechanically pretty similar with the same kind of intergalactic maps, system maps, planet exploration, etc.
They're close enough that I'd almost say SC2 is a rip-off of Starflight, except that Paul Reiche was one of the lead designers on both and I'm not sure you can rip off yourself. But it's a much closer relationship than just "inspired by".
Reiche also the primary guy responsible for Archon (which is in some ways an inspiration for the combat arena part of Star Control 2, though very much more a loose inspiration than an obvious predecessor) and was one of the early TSR Dungeons and Dragons guys.
The Halting problem still doesn't apply to an iphone, though. Or the 2036 equivalent thereof. Or anything that can ever be built, as far as I can see. It relies on infinite memory to make the set of programs it can run innumerable.
Well, there is one small difference. With an AI, one can always, precisely, deconstruct why and how the system makes the decision that it makes
This is false. There are whole papers dedicated to how useless deeply trained neural nets are in actually understanding intelligence, because they're so complicated that we can't understand why they make particular decisions post-training.
No, the sections I quoted are for the built in headset speaker used for calls. The numbers are all above average for call quality and average for volume. I'm not sure how their subjective judgement said "below average", given that every single one of the objective measurements was average or above. It's not the loudest or best speaker out there, for sure, but it's better than most.
I hope it isn't a mildly revamped G2! The G@ has a below-average loudspeaker
There are a lot of decent criticisms of the G2. The SlideAside is pointless (and doesn't work with a ton of common Android apps), the screen is too big for some people, the buttons on the back are something you can adjust to but they're needlessly quirky and more prone to accidentally being pressed in your pocket than side-buttons are. I'm still not sold on having the headphone jack on the bottom instead of the top.
But the speakers? The G2 has virtually perfect frequency response and a very low distortion level according to:
GSMArena, for one, actually measure the volume. ...who also measure frequency response and other components of sound quality.
They note that the speaker on the G2 is better than average sound quality, though average volume-wise. There's absolutely nothing in their tests indicating a below-average speaker:
http://www.gsmarena.com/lg_g2-review-982p8.php
Which seems like they're heavily over-weighting volume--unless you're hearing impaired enough that you normally max the volume on your handset, then maximum volume is far less important than the audio quality. But even by their weighting, it's still good audio quality with average volume level.
But the Nexus 5 will probably be half the price of the G2. And run stock Android and receive updates.
The last sentence is why I wrote "the Nexus 5, presuming it follows the Nexus pattern, will run a standard Android OS and UI (and get faster OS updates)".
I'm not making a case for either phone being better, simply saying that the idea that one is a mildly tweaked version of the other is laughable.
the Nexus 5 (or whatever it’s going to be called) seems like a mildly revamped version of LG’s G2.
No, it really doesn't. The two most-often mentioned features of the G2 are:
a) The gorgeous 5.2" screen; and
b) A 3000 mAh battery; and
c) The rear-panel placement of the only buttons (power/volume), as opposed to the traditional volume rocker on the side that most smartphones have.
This has none of those--it has a 4.95" screen and a 2300 mAh battery. And the buttons are laid out like a standard smartphone. Those things alone are significant alterations that make these phones different in the most visible and usable ways.
The G2 also has a 13 megapixel rear camera; this has an 8 mp camera.
The G2 also has a customized version of Android with knock-on and other features; the Nexus 5, presuming it follows the Nexus pattern, will run a standard Android OS and UI (and get faster OS updates).
Without digging into it for more than 30 seconds, I see a phone with a different screen, different camera, different battery, different physical button layout, and different UI, and with significantly different physical properties (e.g. wireless charging on the Nexus)--these might be distant cousins, but they are most decidedly not "mildly revamped" versions of the same thing.
Right, and then let's start mixing it into aids victims treatments, and then let's mix it into the food at homeless shelters, and then let's coat welfare checks with it, and then let's let's let's...
And then let's... http://art-bin.com/art/omodest.html
For some reason, it's not considered an epidemic when a doctor being paid by insurance companies prescribes methamphetamine manufactured by a pharmaceutical corporation under the brand name "Desoxyn"
Yes it is.
NIH: "The original amphetamine epidemic was generated by the pharmaceutical industry and medical profession as a byproduct of routine commercial drug development and competition" http://www.ncbi.nlm.nih.gov/pmc/articles/PMC2377281/
White House: "The Centers for Disease Control and Prevention has classified prescription drug abuse as an epidemic". http://www.whitehouse.gov/ondcp/prescription-drug-abuse
Not true... I have no opinion either way, but it's entirely possible to have a very good understanding of how semi-random numbers affect cryptography, and also of how rdrand generates them, without having the programming background to be able to safely remove it from the kernel. Crypto is about math, not programming, and contrary to popular opinion (apparently), the two do not always go hand-in-hand.
RdRand could generate entirely non-random numbers and it still wouldn't make the output of /dev/random any less random. It's designed so that additional inputs can only increase the entropy, never decrease it. There's a danger if you over-estimate the amount of entropy that a particular input adds to the pool, but the bits mixed in from rdrand don't increase the entropy counter so that's not a problem in this case.
http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=c2557a303ab6712bb6e09447df828c557c710ac9