Sixth Episode, or sixth movie? You can argue that Anakin didn't really die at the end of Episode III when he became Vader, and that Vader died before Anakin when Luke brought his paw around at the end of Episode VI (the third movie).
Star Wars Encryption: Apply ROT-3 to the franchise numbering.
If copyrights worked they way they used to, those works would've been out of copyright, for more than 35 years. But, with the latest copyright extensions, I believe his works are protected for 70 years after his death, which would put that at, oh, the end of 2053.
I wouldn't say it's a parody, but rather a homage. That said, unless they incorporated his art directly, I don't see how copyright applies. You can't copyright a style. If Google's logo was incorporating art that wasn't Google's, they either need to license it or make a case for "fair use."
# Employing and/or providing software programs, browser scripts, or other technologies that serve to block or substantially impair the display of advertisements on LiveJournal pages.
Incidentally, you can soon add the Intellivision catalog of games to the list of games that will run on the GP2X. I worked with a GP2X early adopter to get my Intellivision emulator jzIntv ported to the beast. The port actually went very quickly once we determined that the SDL port was crap and started mistrusting it at each step. Once we stopped trusting it and tested what actually worked, we quickly converged on a working, full-speed port.
Right now he's sorting out bindings for all the buttons. Once that's sorted, look for binaries at the link above.
And, BTW, I could be mis-remembering the initial proposal. I didn't pay too close attention to the surf-to-other-blogs part, mainly because I don't do that real often.
Hmmm... It looks like they tweaked it. In the initial proposal, if you surfed over to an ad-supported blog, even paid members would get ads. Their reasoning was that clicking on a specific users blog (instead of, say, seeing their entries via your friends page) was notionally equivalent to going to another website, and so everyone doing that would see ads.
Now it says paid members who are logged in will never see ads. I'm a paid member, so I think that's much better... to a point.
I run ad-blocking software (it's called "Firefox," maybe you've heard of it?) and so I have a good portion of ads blocked by default. What happens if my LJ cookies expire (which they seem to do daily now), and I surf to an ad-supported blog. Do I get banned? Do I get banned for suggesting folks use Firefox? Do I get banned for describing the "Block images from..." feature of Firefox?
"RTFM" is still a response which turns off users and sends them back to Windows.
You know, that's why most corporations that vend technical products have a support staff that's completely separate from their development staff. Developers and newbies rarely mix. The difference w/ open source projects is that you often don't have that middle support layer to cushion things.
I personally consider myself to be part of the rare breed that can do both. I worked on the "computer hotline" when I was in college, and later had a mixed role as both a UNIX admin and customer support staff at a small ISP, so I've already had a trial by fire. The computer hotline gig was in the age when dmail and vi ruled the college email scene, rather than, say, Outlook Web Access. I think if I can explain vi to someone who has never really used computers, and not make them feel bad, I think I can claim patience with newbies.:-) (Or patiently explain to the umpteenth Mac customer that the cable that came with their Global Village modem isn't suitable for PPP because it lacks hardware flow control support, while keeping them from blowing up. *shudder*)
If someone does ask me a question, I'll take the time to patiently answer it. If the answer's fairly involved, I might explain the initial portion of it, and point to further references. (Thank the heavens for "vitutor.") Another skill that people should try to cultivate is "anticipating the next question." If you can do that, not only can you preemptively filter subsequent questions, but it also makes you a better documentation writer.
In my experience with other technical people, these skills are rare. I've met and worked with some very bright technical people that confuse their inability to explain something to another person with that person's ability to understand it. I've also met people that snap after getting the same question for the eleventy-billionth time. These people need layers of filters around them.
I kinda look at this in terms of the old "Give a man a fish"/"Teach a man to fish" saying. What we have here is a third action: "Laugh at him because he can't fish, and tell him to go back to McDonalds." Not really acceptable, is that?
FWIW, I said "couples." Couples, in the specific context of making babies, tend to be pairings of males and females. The same male could be paired with two different females, giving two couples, but 3 people. As someone else pointed out, though, you do need enough sperm to go around, and the time to make all these couplings.:-)
Those pedantics aside, I wanted to avoid the sometimes-called-misogynistic formulation that's somewhat more common. And, well, multiple births in this analogy are like data dependent cache misses--for certain cases, you run noticeably faster than average, but you can't really count on it when planning capacity.
In fact, in this particular problem, I was converting the algorithmic description of the edge connections into an explicit description.
Poorly worded. I meant: "In fact, the entire goal of this exercise was to convert the algorithmic description of the edge connections into an explicit form." (The end goal was to generate a databased that expanded the compact-but-slow form into a fast-but-eats-my-hard-disk form.)
Some problems are like the "baby" problem. It takes nine months to make a baby, no matter how many couples are assigned to the problem. BUT, if the task is to make 1000 babies, you can still do that in 9 months—if you can find 1000 couples. But, if you only need one, you're stuck. It's a parallelism granularity problem.
Other times you get stymied by serial bottlenecks in an application. Sometimes you can gain fractional benefit from additional compute resource by allowing various CPUs in the cluster compute redundant results in lieu of waiting for intermediate results from prior computation. For example, one problem I was working on recently had this problem. It was an optimization problem that built up "new answers" from "previous answers" in an attempt to find the shortest sequence of operations to meet some criterion. The kernel operation iterated over pairs of previous results, combined them, and determined if the new result was unique. (There are more details. I'll keep this brief.)
At its heart, the algorithm was effectively a breadth-first-search shortest path algorithm, where the edges in the graph are described algorithmically, not discretely. The issue is, when doing such a search, where the exits from a particular state (node) aren't known explicitly apriori, you can't mark the discovered states as "visited" to cull the traversal through the state space without serializing everything. In fact, in this particular problem, I was converting the algorithmic description of the edge connections into an explicit description.
The trick to parallelizing here is to periodically divide your work queue of "nodes to visit" among your compute nodes, and then merge the results back, knowing that you will have many redundant "node visits." You can filter these out with some other structure. In this case, my total state bitmap was 512MB--easily held in one node--so the merge process looks like a "Hey, have I seen this? Nope? Pass it on." Even the merge can be performed hierarchically, so eliminate redundancies in stages. At each level of the hierarchy, you can subdivide the state space you're merging to gain parallelism that way.
So, sometimes there ARE ways to speed up serial computations, but at the expense of computing redundant intermediate results.
I think the point you're trying to make is that anonymous, unmonitored travel will no longer be possible. That is a big con. It might be possible to design a system that keeps individual cars relatively anonymous with respect any traffic-planning computers that control them (look at similar efforts designed to retain anonymity for digital cash), but the politicians that specify and oversee the implementation of the system would find subverting it too tempting to allow it to succeed.
I mean, look at the congestion tax and omnipresent speed cameras (soon w/ automatic number-plate recognition) in Britain.
And nobody's ridden horses since the widespread adoption of the horseless carriage. Riiight.
Driving enthusiasts will always be able to drive, and with the larger market of potential driving enthusiasts that no longer have access to the open road, I think you'll find:
Fewer showboaters on the open road risking your life without your input.
Fewer (hopefully near zero) deaths on the open road.
A much richer experience when you do go to drive your vehicle for fun, because there will be more venues catering to a wider audience due to the greater demand.
From the sounds of the review, it seems that this kicks in only when the car is pushed beyond certain limits, and that it performs certain actions faster than a human driver might be able to because the sensors and feedback mechanism are inherently faster through the computer than they are through the human behind the wheel. Humans can outperform the computer only when they correctly anticipate all of the road conditions.
Correctly applied, this can allow the human to push the car further than would otherwise be safe because you have fine grain closed-loop compensation that is superior to pure open-loop anticipation. The driver can offload a few unknowns onto the car's compensating systems and really dig into it. For one thing, I don't think I've seen a car with human inputs for controlling the torque available on each of the four wheels. In contrast, several of these high-end systems can do tricks like partially applying individual brakes to force the differential to divert torque to non-slipping wheels. Last thing I want is four brake pedals.
This has some implications. First, for a performance car, this should be relatively easily disabled, or at least severely restrained for cases where the driver wants to perform some "trick driving" actions inconsistent with "going down the road fast and staying on the road." e.g. intentional donuts, spinouts and burnouts. Second, when active, the system better not fail when the driver is relying on it to take up certain slack since a driver accustomed to the computer compensation has mentally offloaded some of the burden to the vehicle.
I don't think this is about putting kid gloves and nerf on the car.
Erm... your math is dodgy. If one overclocked to 334MHz and the other overclocked to 335MHz, then sure, one overclocked by 100% more than the other, but they're still less than 1% away from each other in raw performance.
Actually, if your machine varies fan speeds with case temperature (and most do these days, especially laptops), then guess what? You're running the SMM code in question. If the attacker can get the System Management Interrupt (SMI) handler code in place, all they need to do then is run a tight loop that wiggles lots of bits to trigger the SMI.
Thing is, SMM is used for many other things, too. It seems like you could just co-opt the SMI handler and you'd get called pretty quickly for any number of reasons. Question is, how do you manage to overwrite the SMI handler, and how do you avoid racing with arriving SMIs while you're putting your code in place?
So I wasn't the only one reminded of the nth-complexity infinite binary loop? Oh, and get this, this backdoor is triggered how? By replacing the code the CPU runs when it overheats. So... hmmm... Hoax, or just a decade ahead of its time?
Slashdot Mirror
Sixth Episode, or sixth movie? You can argue that Anakin didn't really die at the end of Episode III when he became Vader, and that Vader died before Anakin when Luke brought his paw around at the end of Episode VI (the third movie).
Star Wars Encryption: Apply ROT-3 to the franchise numbering.
--JoePssst... Also, the Titanic sinks. Oh, and the Union wins the Civil War.
If copyrights worked they way they used to, those works would've been out of copyright, for more than 35 years. But, with the latest copyright extensions, I believe his works are protected for 70 years after his death, which would put that at, oh, the end of 2053.
--JoeI wouldn't say it's a parody, but rather a homage. That said, unless they incorporated his art directly, I don't see how copyright applies. You can't copyright a style. If Google's logo was incorporating art that wasn't Google's, they either need to license it or make a case for "fair use."
--JoeWhat if you want a better solution than the ones that are normally available?
Oh, and this gem:
So what exactly does "or any other means" mean? Exact quote:
--JoeIncidentally, you can soon add the Intellivision catalog of games to the list of games that will run on the GP2X. I worked with a GP2X early adopter to get my Intellivision emulator jzIntv ported to the beast. The port actually went very quickly once we determined that the SDL port was crap and started mistrusting it at each step. Once we stopped trusting it and tested what actually worked, we quickly converged on a working, full-speed port.
Right now he's sorting out bindings for all the buttons. Once that's sorted, look for binaries at the link above.
--JoeAnd, BTW, I could be mis-remembering the initial proposal. I didn't pay too close attention to the surf-to-other-blogs part, mainly because I don't do that real often.
Hmmm... It looks like they tweaked it. In the initial proposal, if you surfed over to an ad-supported blog, even paid members would get ads. Their reasoning was that clicking on a specific users blog (instead of, say, seeing their entries via your friends page) was notionally equivalent to going to another website, and so everyone doing that would see ads.
Now it says paid members who are logged in will never see ads. I'm a paid member, so I think that's much better... to a point.
I run ad-blocking software (it's called "Firefox," maybe you've heard of it?) and so I have a good portion of ads blocked by default. What happens if my LJ cookies expire (which they seem to do daily now), and I surf to an ad-supported blog. Do I get banned? Do I get banned for suggesting folks use Firefox? Do I get banned for describing the "Block images from..." feature of Firefox?
This is seriously uncool.
--Joe
You know, that's why most corporations that vend technical products have a support staff that's completely separate from their development staff. Developers and newbies rarely mix. The difference w/ open source projects is that you often don't have that middle support layer to cushion things.
I personally consider myself to be part of the rare breed that can do both. I worked on the "computer hotline" when I was in college, and later had a mixed role as both a UNIX admin and customer support staff at a small ISP, so I've already had a trial by fire. The computer hotline gig was in the age when dmail and vi ruled the college email scene, rather than, say, Outlook Web Access. I think if I can explain vi to someone who has never really used computers, and not make them feel bad, I think I can claim patience with newbies. :-) (Or patiently explain to the umpteenth Mac customer that the cable that came with their Global Village modem isn't suitable for PPP because it lacks hardware flow control support, while keeping them from blowing up. *shudder*)
If someone does ask me a question, I'll take the time to patiently answer it. If the answer's fairly involved, I might explain the initial portion of it, and point to further references. (Thank the heavens for "vitutor.") Another skill that people should try to cultivate is "anticipating the next question." If you can do that, not only can you preemptively filter subsequent questions, but it also makes you a better documentation writer.
In my experience with other technical people, these skills are rare. I've met and worked with some very bright technical people that confuse their inability to explain something to another person with that person's ability to understand it. I've also met people that snap after getting the same question for the eleventy-billionth time. These people need layers of filters around them.
I kinda look at this in terms of the old "Give a man a fish"/"Teach a man to fish" saying. What we have here is a third action: "Laugh at him because he can't fish, and tell him to go back to McDonalds." Not really acceptable, is that?
--JoeFWIW, I said "couples." Couples, in the specific context of making babies, tend to be pairings of males and females. The same male could be paired with two different females, giving two couples, but 3 people. As someone else pointed out, though, you do need enough sperm to go around, and the time to make all these couplings. :-)
Those pedantics aside, I wanted to avoid the sometimes-called-misogynistic formulation that's somewhat more common. And, well, multiple births in this analogy are like data dependent cache misses--for certain cases, you run noticeably faster than average, but you can't really count on it when planning capacity.
--JoePoorly worded. I meant: "In fact, the entire goal of this exercise was to convert the algorithmic description of the edge connections into an explicit form." (The end goal was to generate a databased that expanded the compact-but-slow form into a fast-but-eats-my-hard-disk form.)
--JoeSome problems are like the "baby" problem. It takes nine months to make a baby, no matter how many couples are assigned to the problem. BUT, if the task is to make 1000 babies, you can still do that in 9 months—if you can find 1000 couples. But, if you only need one, you're stuck. It's a parallelism granularity problem.
Other times you get stymied by serial bottlenecks in an application. Sometimes you can gain fractional benefit from additional compute resource by allowing various CPUs in the cluster compute redundant results in lieu of waiting for intermediate results from prior computation. For example, one problem I was working on recently had this problem. It was an optimization problem that built up "new answers" from "previous answers" in an attempt to find the shortest sequence of operations to meet some criterion. The kernel operation iterated over pairs of previous results, combined them, and determined if the new result was unique. (There are more details. I'll keep this brief.)
At its heart, the algorithm was effectively a breadth-first-search shortest path algorithm, where the edges in the graph are described algorithmically, not discretely. The issue is, when doing such a search, where the exits from a particular state (node) aren't known explicitly apriori, you can't mark the discovered states as "visited" to cull the traversal through the state space without serializing everything. In fact, in this particular problem, I was converting the algorithmic description of the edge connections into an explicit description.
The trick to parallelizing here is to periodically divide your work queue of "nodes to visit" among your compute nodes, and then merge the results back, knowing that you will have many redundant "node visits." You can filter these out with some other structure. In this case, my total state bitmap was 512MB--easily held in one node--so the merge process looks like a "Hey, have I seen this? Nope? Pass it on." Even the merge can be performed hierarchically, so eliminate redundancies in stages. At each level of the hierarchy, you can subdivide the state space you're merging to gain parallelism that way.
So, sometimes there ARE ways to speed up serial computations, but at the expense of computing redundant intermediate results.
--JoeMake some some characters to plop in this world of disaffection, and I think you have a concept for a comic strip!
Just don't give half the characters names ending in -bert. You might get sued.
Which... if you read TFA, is actually what he was using, sorta. (A == 4 up to Z == 26.)
Damn those mandatory freedoms. :-)
I think the point you're trying to make is that anonymous, unmonitored travel will no longer be possible. That is a big con. It might be possible to design a system that keeps individual cars relatively anonymous with respect any traffic-planning computers that control them (look at similar efforts designed to retain anonymity for digital cash), but the politicians that specify and oversee the implementation of the system would find subverting it too tempting to allow it to succeed.
I mean, look at the congestion tax and omnipresent speed cameras (soon w/ automatic number-plate recognition) in Britain.
--JoeAnd nobody's ridden horses since the widespread adoption of the horseless carriage. Riiight.
Driving enthusiasts will always be able to drive, and with the larger market of potential driving enthusiasts that no longer have access to the open road, I think you'll find:
--Joe
From the sounds of the review, it seems that this kicks in only when the car is pushed beyond certain limits, and that it performs certain actions faster than a human driver might be able to because the sensors and feedback mechanism are inherently faster through the computer than they are through the human behind the wheel. Humans can outperform the computer only when they correctly anticipate all of the road conditions.
Correctly applied, this can allow the human to push the car further than would otherwise be safe because you have fine grain closed-loop compensation that is superior to pure open-loop anticipation. The driver can offload a few unknowns onto the car's compensating systems and really dig into it. For one thing, I don't think I've seen a car with human inputs for controlling the torque available on each of the four wheels. In contrast, several of these high-end systems can do tricks like partially applying individual brakes to force the differential to divert torque to non-slipping wheels. Last thing I want is four brake pedals.
This has some implications. First, for a performance car, this should be relatively easily disabled, or at least severely restrained for cases where the driver wants to perform some "trick driving" actions inconsistent with "going down the road fast and staying on the road." e.g. intentional donuts, spinouts and burnouts. Second, when active, the system better not fail when the driver is relying on it to take up certain slack since a driver accustomed to the computer compensation has mentally offloaded some of the burden to the vehicle.
I don't think this is about putting kid gloves and nerf on the car.
--JoeYou're new here, aren't you?
Especially so when measuring the devices out side of the spec written on the label. *cough*
What is this--is "DDR2 667" just a wink wink, nudge nudge sort of spec?
/no sympathy for overclockers
--JoeErm... your math is dodgy. If one overclocked to 334MHz and the other overclocked to 335MHz, then sure, one overclocked by 100% more than the other, but they're still less than 1% away from each other in raw performance.
--JoeTFA wasn't terribly informative, I agree.
Actually, if your machine varies fan speeds with case temperature (and most do these days, especially laptops), then guess what? You're running the SMM code in question. If the attacker can get the System Management Interrupt (SMI) handler code in place, all they need to do then is run a tight loop that wiggles lots of bits to trigger the SMI.
Thing is, SMM is used for many other things, too. It seems like you could just co-opt the SMI handler and you'd get called pretty quickly for any number of reasons. Question is, how do you manage to overwrite the SMI handler, and how do you avoid racing with arriving SMIs while you're putting your code in place?
--JoeSo I wasn't the only one reminded of the nth-complexity infinite binary loop? Oh, and get this, this backdoor is triggered how? By replacing the code the CPU runs when it overheats. So... hmmm... Hoax, or just a decade ahead of its time?