"Top N" lists are always just media hype, since they're always just someones' opinions. (Even a poll is just a bunch of someone's opinions, but at least with a large enough sample size you can say something about aggregate taste. Similar logic applies to things like the Academy Awards.)
If every "N Greatest Whatevers" list instead said "N Great Whatevers", it would be way more honest, way more accurate, and would generate way less controversy. (People would still say "I can't believe X isn't on the list", but it would have more the tenor of "how weird that these people don't like X that much" rather than "this list is totally not authoratative since it doesn't have X". Yes, the list isn't authoratative. It's just an opinion. Stop posting to slashdot telling us it's not authoratative because it doesn't have X.)
This is true even when N=1, say Time's Man of the Year (or of the Century, and s/man/person/ as preferred). It's the opinion of Time's editor. I once participated in a conversation where people were debating who should be the Person of the Century. That's totally fine, and it's great if they can marshall arguments about why somebody was more important than someone else. But, guess what, when Time finally announces their choice, that doesn't make you right. That just means that a bunch of opinionated S.O.B.s happened to have the same opinion as you. Accurately predicting Time's choice is way less interesting than having actual knowledge and opinions about the nominees.
Who in the world generates code to the stack? Compiling code is expensive, so you want to cache it, that is, keep it around for a while, which means putting it on the heap.
The summary as written obfuscates, for no good reason, where it is that Michael Lynn works.
An anonymous reader writes "Michael Lynn, formerly a researcher for Internet Security Systems resigned today rather than..."
Just how "formerly" was it? Suppose Bob was most famous for having been a researcher at Xerox PARC, but he left and went to work at Microsoft, and then he quit? You might write "Bob, formerly a researcher at Xerox PARC, resigned today (from his job at Microsoft) rather than..."
Now, you might think this is picky and stupid and not really that ambiguous, but the thing is the submitter made it needlessly froofy and obfuscated by pushing the employer into a separate descriptive phrase, when it would have read just fine to say:
"Michael Lynn resigned today from his job as a reseacher at Internet Security Systems rather than..."
Your argument would be a lot more convincing if you wrote it like this:
Uh,
Whut iz thiz 'Englesh currect' dat you speek of? Kan U mi sehnnnd uh cope fo da foficial Anglesh stinkage bookhand? Non. Hrm. Wellll be-may cud ya appointenmentin' me da fofishal bawdy fof het guvanin Anguish stinkage. U mean, won hash French hand dozen Angst?
Bugglemeister:
Dren woh wu we kro dat corked Angstrom does? Rimmin, 'kirk' Angles spy federation 'mockin'' Angry? N! Bt thn wht wll ll ths sm-ntllgnt pdnts wh hvnt cght n t th fct tht 'shld hv' s n mr mnngfl thn 'shld f', bt tht 'shld f' s mch mr cmmn n spkn nglsh d? Wh knws!
Read "DVD" below as "whatever they end up calling this next-generation 'DVD'":
It will be a total pain in the ass, because somebody has to write a new crack for every different DVD. (Parent makes it sound like there's just one crack total, although it's not clearly written.)
Every DVD is going to come with its own Java byte-code that controls how the disk plays. Thus every DVD can differently obfuscate and whatever it's Java code to force the ads down our throats. Fixing this will require either burning a patching DVD, hot-patching the DVD after it's loaded via networking, or changing the firmware of the player to rewrite the offending bytecode on the fly. None of those sound particularly simple.
Side note: I've always assumed current DVDs already had some kind of interpreted program to handle the branching and overlays and what-not, but I've never seen any documentation or explantion of the details, and google has always failed me on this (as does wikipedia). But I suspect that that virtual machine is going to be much simpler than java bytecode. But nobody's been cracking that, have they?
No, they don't. Some engineers may understand some risks, but no single individual understands them all, and there is lots of evidence that NASA is not very good at synthesizing all the risks. Instead, further unrealized risks occur, such as those introduced by schedule pressure:
During the course of this investigation, the Board received
several unsolicited comments from NASA personnel regarding
pressure to meet a schedule. These comments all concerned
a date, more than a year after the launch of Columbia,
that seemed etched in stone: February 19, 2004, the scheduled
launch date of STS-120. This flight was a milestone in
the minds of NASA management since it would carry a section
of the International Space Station called "Node 2." This
would configure the International Space Station to its "U.S.
Core Complete" status.
At first glance, the Core Complete configuration date
seemed noteworthy but unrelated to the Columbia accident.
However, as the investigation continued, it became apparent
that the complexity and political mandates surrounding the
International Space Station Program, as well as Shuttle Program
managements responses to them, resulted in pressure
to meet an increasingly ambitious launch schedule.
[...]
After years of downsizing and budget cuts (Chapter
5), this mandate and events in the months leading up to STS-107 introduced elements of risk to the Program.
Fox delibrately purchases sci-fi series so it can shoot them in the foot.
I didn't say anything about it [...] purchasing them for the purpose of canceling them.
Yes you did, sheesh. That's what "so" means in this kind of construction, especially with "deliberately". (This dictionary defines it as "in order that", in this sense.)
Now, you can retreat to a totally different position:
I'm just saying that, at the time it purchases sci-fi, it already intends to kill it for some, as yet unknown, reason.
And of course you'd don't know that and it's an incredibly stupid theory. You have evidence which isn't unreasonable to interpret as Fox deliberately "destroying" Firefly, sure; but you have no evidence they intended to do that in advance (except that they "keep" doing it). Given the reality of stupid politics inside studios, those politics theories seem (a) to explain it, and (b) to make more sense.
Patterns and averages aren't the same. If a quake happened every 200+-20 years for the last 1000 years, then sure, you'd expect another quake somewhere between 180 and 220 years after the last one.
If, however, you expect a fair 20-sided die to roll a 17 every 20 rolls on average, and it's been about 20 die rolls since the last 17, you are not "due" for a 17; a 17 is no more likely in the next five rolls then a 17 was likely in the first five rolls immediately after the last 17. This is the gambler's fallacy, obviously.
So the question is just whether the grandparent post of yours meant the first kind of pattern by "average", or the second. The second situation is referred to as "the coin [or die] has no memory"--what happens later has nothing to do with what went before. Obviously, the ground does have memory--when an earthquake happens, the ground changes. It certainly sounds reasonable to suppose that after this "release of tension", tension builds up further overtime, thus introducing a bias to when the next earthquake occurs. And I believe this is what the parent to your post wrote:
I've heard people argue about how the stress is released after an earthquake and there's a relation. I think this is a very common misconception that seems intuitive, but doesn't really match the facts as we know. All the geophysicists I've spoken to have claimed that this is mostly fiction, though.
You seem to be asserting that these patterns do exist, and he seemed to be asserting that these patterns don't exist. I have no idea which of you is right, but I'm not sure Parkfield is great evidence when the prediction is wrong off by 50%. But whether these patterns exist in some cases or not ignores the question of whether your grandparent meant "time between successive quakes hews to this number very closely" or "the average time between successive quakes has been 200, with enormous variance", which is the nit that was actually picked.
The exact phrasing of the questions in a poll can make a huge difference. To understand a poll, it's useful to find out what the actual questions were.
The submitter unfortunately does us a huge disservice by misquoting the press release being submitted. Submitter says:
Are regular churchgoers less likely to believe life has evolved on other planets? Do more Democrats or Republicans believe in extraterrestrials? [...] These questions were asked on a poll released last week [...]
But of course those questions were not asked on the poll. TFA says:
Are regular churchgoers less likely to believe life has evolved on other planets? Do more Democrats or Republicans believe in extraterrestrials? [...] These questions and more are answered in a new national survey released today.
You might think that for every 'answered' there must be an 'asked', and in fact, that's true, but only in an indirect way.
Some people at the NGC asked themselves the question, "hey, do more Democrats or Republicans believe in extraterrestrials?"
Two questions along the lines of "Do you believe in extraterrestrials" and "what is your political affiliation" were included on the survey, and asked of the respondents, who answered those questions.
The cumulative results of the survey answered the original question, with some margin of error.
I'm reminded of some people on Usenet who couldn't remember whether the bookish girl in Scooby-Doo was named Velma or Thelma, and someone suggested it be put to a vote. It would be totally frivolous to ask someone "Are regular churchgoers less likely to believe life has evolved on other planets" if your goal is to know the truth of that question.
Consider a presidential election where everybody knows it's likely to be an 65-35 victory for Able over Cain. Now suppose we conduct a poll:
Who do you think will win, Able or Cain?
Who would you prefer to win, Able or Cain?
Who are you going to vote for, Able or Cain?
People may realize that even if they prefer Cain, Able is likely to win, and answer question #1 appropriately. Add a third-party candidate who people don't want to waste a vote on, and you'll start seeing a split between #2 and #3.
If your question is "who is going to win the election", the question you want to ask is #3.
I realize this is a total semantic nitpick about the submission, but in the case of talking about poll questions, since it's crucial to know what questions were actually asked, a summary like this is just bizarre. (Compare this kind of nitpick to a nitpick about the use of "on" in "on a poll" in the submission, and hopefully you'll see why this is a more significant nitpick.)
Also polling theory is a lot more interesting than this stupid poll.
Actually, this is the point of the cell processor. The cell is meant to allow lots of pipelined tasks to happen with little additional overhead. This means that the difference between a "simple" AI and a complex "AI" (in terms of performance) is little different.
The cell is all about streaming math-intensive tasks. It is not designed to execute object-oriented code or even traverse a linked-list. It is essentially useless for writing AI code. It's just a step up from a DSP.
Re:Silence or more noise?
on
Cubicle Privacy
·
· Score: 3, Insightful
Yeah, this is an incredibly poorly written summary--impressive since it's a one-liner.
What most of us want is a noise-canceling box for noisy neighbors.
What this is is a noise-creating box for nosy neighbors.
You might manage to get your company to pay to put the former in your cubicle. Since the only point of the latter seems to be for allowing personal calls, somehow it seems more likely to get outright forbidden.
There was no reason the submitter couldn't have mentioned it in the summary. Unless maybe the submitter was trying to drive traffic to the site for banner ad hits or whatever.
But obviously the submitter wouldn't do that and risk ruining his or her credibility on slashdot. Who submitted it, anyway? Oh, right. Anonymous reader.
Also the 1970 British TV series UFO (and here), which was mostly on Earth but had a nice moonbase and occasional space battles (which weren't like WW2 dogfights!). I dunno how it would stand up now, but I enjoyed it at 8.
Star Wars had a lot more context than people these days realize.
This slashdot story pisses me off for a simple reason: it follows the media in conflating and confusing a music player with a music subscription service. This has been going on for a while--Apple started it with iTunes. (See, technically, iTunes is a piece of software I use to track mp3s and download them to my iPod, whereas iTunes Music Store is some place that sells AAC files, a place I've never been. It may be that iTunes the software is the only way to access ITMS (I have no idea), but by owning an iPod I am (essentially) forced to use iTunes the software, so iTunes and ITMS are by no means linked).
Yahoo hops on the same confusion, introducing "Yahoo! Music Engine" and "Yahoo Music Unlimited". Slashdot says "Perhaps most interesting to the Slashdot crowd is that the Yahoo Music Engine is built on an open platform that facilitates plug-ins". But so what? Is this interesting if I don't care about "Yahoo Music Unlimited"? Winamp "facilitates" plug-ins too, so... so what?
I tried to read the Ian Rogers page, but it was all blah blah blah rah rah rah. He dives right in with why you should use Yahoo Music Engine with the first bullet point being "PRICE! $5/month subscription service"--but he's not talking about the music engine, is he? He's talking about Yahoo Music Unlimited. So what the hell, even the tech guy can't get this right? Or is he just buying entirely into the "I am a vehicle for PR too"?
Finally, Yahoo Music Engine doesn't run on Macs, and files downloaded from Yahoo Music Unlimited don't play on iPods, so why is this in the category "Apple"?
The test was designed to check the browser implementations of the newer CSS standards.
That's their pitch, and that's how everybody is reporting on it. Dig into the details, and discover that this isn't true:
In order for row 1 to be positioned correctly, we assume that fragment identifiers cause scrolling to occur up to the top padding edge (or maybe top border edge, that isn't tested) of the element, and not its top margin edge or top content edge. This is a common convention, but is not described in a specification.
In other words, you can correctly implement the standards, and still render this wrong. So it's not a test of standards compliance (in the sense of 'css standards'; a "de-facto standard" is not a standard in the sense people are talking about here).
I don't know how many more things like this they rely on that aren't standards; I read this particular one right at the beginning, for row #1, and bailed reading the rest of the doc.
I think the complaint is just the wording in the great-grandparent; in reality, modifying the guest OS is a workaround for the performance problems from full virtualization, not vice versa. I think you totally understand this and accept it; it's just that that particular phrasing comes across as spin.
In fact, the slogan "no security through obscurity" isn't even a good aphorism. "Obscurity" in this sort of context is another word for "secrecy", and guess what, secrecy is the fundamental building block of security.
This is pretty clear if you use the classic example, encryption.
Good: a well-tested published algorithm with a lot of bits in the secret key
Bad: a secret, private algorithm with however many bits in the key
But why is the one good and the other bad? The classic answer is "because the well-tested published algorithm is really secure, and the other one isn't". But that's not a good explanation; it's trivial to roll a no-less-secure (and possibly more secure) secret algorithm: just use a good published encryption algorithm, plus re-encrypt the results using whatever random crappy algorithm you've invented. (Or maybe in the other order is better.) This is no less secure for the obvious reason, and if you manage to keep your random crappy algorithm secret, most people are going to have more trouble breaking it. Maybe the NSA can still break it, but they'll have to work harder.
Here's the reality of the situation: bits are hard to keep secret. The fewer bits you have to keep secret, the better off you are. If you have some special custom crappy encryption algorithm, you have to express that in code and hand it off to the other people who need to encode and decode. That code is now bits you have to keep secret. So in addition to your, say, 256 key bits, you now have a, say, 16KB executable you're keeping secret. That means you need to keep 128,000 bits secret!
Even if you're using a custom crappy encryption that's not built on top of a published, secure one, and you're not an idiot, you probably will give your average DeCSS-level hacker a difficult time--if you can keep all the bits secret. But here's the point: maybe you'd be better off just using a 128,000 bit key with one of those well-published algorithms! (I realize this doesn't necessarily literally work, although you can do triple-DES-like stuff, though it might be too slow, but let's ignore performance since that's always going to change.)
What really matters is the ratio of quality-of-security to the amount of data you have to keep secret; the security-quality-per-bit (SQ/b). In the case of encryption, you are probably best off putting those bits into your secret key for a published algorithm, not into a secret algorithm. In the case of Google, nobody current knows of a magical "good solution to fraud prevention" for them to use, and their best solution is to keep their fraud detection measure secret. Yes, if those measures leaked (say, somebody at google ran off with them, or got socially engineered), they won't work very well, but there is NOTHING to be gained by leaking them, despite whatever bizarro world grandparent and the people who modded him "insightful" are living in. ("No one can gain by covering up the problem...no one, that is, but the people perpetrating the click fraud." wha? huh? Like parent says, publishing their fraud detection methods and the extent of the fraud isn't going to prevent "gain" on the part of the frauders, and certainly will increase the likelihood of current non-frauders being able to fraud.)
"Circumvent the copy protection"? The data is encrypted. You can copy it all you want; but you can't play it without decrypting it.
So they revoke a player model as follows (omitting lots of details that aren't important to the big picture, and oversimplifying):
Each player model gets its own key ("set of Device Keys" in the specification). Data on the disc is encoded with a disc-specific data key. Given N player models, there are also N encrypted master keys, one for each (non-revoked) player model.
If a player model is compromised and the key from it used in a DeCSS-like program, they will "revoke" that key and, on all future releases, not include a copy of the disc-data key encrypted for that player.
You're not reading it right. If somebody pries out a key from a device and uses that in a DeCSS-like software, they want to make that key no longer work--they want to revoke that key entirely. That's the only way this makes any sense.
With that in mind, it's clear that you can read what you quoted in the above sense, and indeed it's the plausible way to read it: it's not "causes a compromised device to be unable...", it's "causes a device with the compromised set of Device Keys to be unable...". Any device using this set of keys--whether it's superDeCSS or any particular machine of the sort that was compromised, or any other machine that shares the same set of keys--will no longer be able to view content--presumably only new content created after the revocation.
Related, from the spec:
The
set of Device Keys may either be unique per device, or used commonly by multiple devices. The license agreement describes details and requirements associated with these two alternatives. A device shall treat its
Device Keys as highly confidential, as defined in the license agreement.
It's not "clear cut" at all; "content management" is itself jargon (it's not self-defining). So is "version control", but at least most programmers know what it means already. So too is "workflow", apparently, since this thread isn't using it in the sense I'm used to (where it roughly means "the manner in which things get done", as in "Photoshop has good workflow for task A and poor workflow for task B"--it is easy and fun to do task A and annoying and hard to do task B; "having workflow", even taking that to mean "having a system that controls/manages/guides workflow", doesn't really make any sense with that meaning).
So, say, the use of "workflow" in this "content management" context might have a meaning along the lines of "if a piece of data has to get manipulated by multiple people, a workflow system can track where the data is in that workflow (who has it now, who's responsonle for it, etc.)"; but that's entirely guesswork. Maybe it's not multiple people, it's multiple programs (but in which case I'm not sure what exactly "workflow" is other than a script to run the piece of data through multiple programs, which is not exactly noteworthy technology).
And then "editorial review", well, obviously the program isn't doing editorial review, so I guess you mean the system is making sure the data goes through editorial review, but hey, that would be a "workflow" step in my above definition, so either I guessed wrong, or you were being redundant. I have no clue which!
So one sentence of mostly new buzzwords, and three paragraphs of just repeating back the original buzzwords and saying "it's obvious". Dude, pas de donut.
Slashdot Mirror
If every "N Greatest Whatevers" list instead said "N Great Whatevers", it would be way more honest, way more accurate, and would generate way less controversy. (People would still say "I can't believe X isn't on the list", but it would have more the tenor of "how weird that these people don't like X that much" rather than "this list is totally not authoratative since it doesn't have X". Yes, the list isn't authoratative. It's just an opinion. Stop posting to slashdot telling us it's not authoratative because it doesn't have X.)
This is true even when N=1, say Time's Man of the Year (or of the Century, and s/man/person/ as preferred). It's the opinion of Time's editor. I once participated in a conversation where people were debating who should be the Person of the Century. That's totally fine, and it's great if they can marshall arguments about why somebody was more important than someone else. But, guess what, when Time finally announces their choice, that doesn't make you right. That just means that a bunch of opinionated S.O.B.s happened to have the same opinion as you. Accurately predicting Time's choice is way less interesting than having actual knowledge and opinions about the nominees.
Who in the world generates code to the stack? Compiling code is expensive, so you want to cache it, that is, keep it around for a while, which means putting it on the heap.
No, this is for the benefit of lawyers.
(silver lining: at least that's one lawyer who isn't getting paid to file patents)
Just how "formerly" was it? Suppose Bob was most famous for having been a researcher at Xerox PARC, but he left and went to work at Microsoft, and then he quit? You might write "Bob, formerly a researcher at Xerox PARC, resigned today (from his job at Microsoft) rather than..."
Now, you might think this is picky and stupid and not really that ambiguous, but the thing is the submitter made it needlessly froofy and obfuscated by pushing the employer into a separate descriptive phrase, when it would have read just fine to say:
"Michael Lynn resigned today from his job as a reseacher at Internet Security Systems rather than..."
To actually answer your question usefully, this is in the official contest rules published by apple.
summary is wrong: the rules explain the promotion doesn't start until 480,100,000, so only 200 (actually 199) iPod minis.
Uh,
Whut iz thiz 'Englesh currect' dat you speek of? Kan U mi sehnnnd uh cope fo da foficial Anglesh stinkage bookhand? Non. Hrm. Wellll be-may cud ya appointenmentin' me da fofishal bawdy fof het guvanin Anguish stinkage. U mean, won hash French hand dozen Angst?
Bugglemeister:
Dren woh wu we kro dat corked Angstrom does? Rimmin, 'kirk' Angles spy federation 'mockin'' Angry? N! Bt thn wht wll ll ths sm-ntllgnt pdnts wh hvnt cght n t th fct tht 'shld hv' s n mr mnngfl thn 'shld f', bt tht 'shld f' s mch mr cmmn n spkn nglsh d? Wh knws!
JIiowefojmn kwmefoij powkefke kweopk[qp[dl fokw keok glrke elgk pwoefko, weifj pkoqfkopkwep gekp[wqij ksflk pergl pl wrgoko ewf kplkwefok wefkokohgokpekrlgmlm wef'okkwef' owkokpwefnkn wepfojm lkwefpom lmlwefpojoj ,mweflm po 'omwefom' owjopnknaxp.
+Mpoitch
Indeed, you appear to be in support of Humpty-Dumpty:
-- Through the Looking Glass, Lewis CarrollIt will be a total pain in the ass, because somebody has to write a new crack for every different DVD. (Parent makes it sound like there's just one crack total, although it's not clearly written.)
Every DVD is going to come with its own Java byte-code that controls how the disk plays. Thus every DVD can differently obfuscate and whatever it's Java code to force the ads down our throats. Fixing this will require either burning a patching DVD, hot-patching the DVD after it's loaded via networking, or changing the firmware of the player to rewrite the offending bytecode on the fly. None of those sound particularly simple.
Side note: I've always assumed current DVDs already had some kind of interpreted program to handle the branching and overlays and what-not, but I've never seen any documentation or explantion of the details, and google has always failed me on this (as does wikipedia). But I suspect that that virtual machine is going to be much simpler than java bytecode. But nobody's been cracking that, have they?
No, they don't. Some engineers may understand some risks, but no single individual understands them all, and there is lots of evidence that NASA is not very good at synthesizing all the risks. Instead, further unrealized risks occur, such as those introduced by schedule pressure:
If you haven't read the Columbia Acident Investigation Board report, you shouldn't make such claims. And if you have read it, you wouldn't.
Yes you did, sheesh. That's what "so" means in this kind of construction, especially with "deliberately". (This dictionary defines it as "in order that", in this sense.)
Now, you can retreat to a totally different position:
And of course you'd don't know that and it's an incredibly stupid theory. You have evidence which isn't unreasonable to interpret as Fox deliberately "destroying" Firefly, sure; but you have no evidence they intended to do that in advance (except that they "keep" doing it). Given the reality of stupid politics inside studios, those politics theories seem (a) to explain it, and (b) to make more sense.
Hyperbole.
That claim derives from cherry-picked data.
brief commentary, longer commentary
just remember that "its" works like "his"
If, however, you expect a fair 20-sided die to roll a 17 every 20 rolls on average, and it's been about 20 die rolls since the last 17, you are not "due" for a 17; a 17 is no more likely in the next five rolls then a 17 was likely in the first five rolls immediately after the last 17. This is the gambler's fallacy, obviously.
So the question is just whether the grandparent post of yours meant the first kind of pattern by "average", or the second. The second situation is referred to as "the coin [or die] has no memory"--what happens later has nothing to do with what went before. Obviously, the ground does have memory--when an earthquake happens, the ground changes. It certainly sounds reasonable to suppose that after this "release of tension", tension builds up further overtime, thus introducing a bias to when the next earthquake occurs. And I believe this is what the parent to your post wrote:
You seem to be asserting that these patterns do exist, and he seemed to be asserting that these patterns don't exist. I have no idea which of you is right, but I'm not sure Parkfield is great evidence when the prediction is wrong off by 50%. But whether these patterns exist in some cases or not ignores the question of whether your grandparent meant "time between successive quakes hews to this number very closely" or "the average time between successive quakes has been 200, with enormous variance", which is the nit that was actually picked.
The submitter unfortunately does us a huge disservice by misquoting the press release being submitted. Submitter says:
But of course those questions were not asked on the poll. TFA says:
You might think that for every 'answered' there must be an 'asked', and in fact, that's true, but only in an indirect way.
I'm reminded of some people on Usenet who couldn't remember whether the bookish girl in Scooby-Doo was named Velma or Thelma, and someone suggested it be put to a vote. It would be totally frivolous to ask someone "Are regular churchgoers less likely to believe life has evolved on other planets" if your goal is to know the truth of that question.
Consider a presidential election where everybody knows it's likely to be an 65-35 victory for Able over Cain. Now suppose we conduct a poll:
- Who do you think will win, Able or Cain?
- Who would you prefer to win, Able or Cain?
- Who are you going to vote for, Able or Cain?
People may realize that even if they prefer Cain, Able is likely to win, and answer question #1 appropriately. Add a third-party candidate who people don't want to waste a vote on, and you'll start seeing a split between #2 and #3.If your question is "who is going to win the election", the question you want to ask is #3.
I realize this is a total semantic nitpick about the submission, but in the case of talking about poll questions, since it's crucial to know what questions were actually asked, a summary like this is just bizarre. (Compare this kind of nitpick to a nitpick about the use of "on" in "on a poll" in the submission, and hopefully you'll see why this is a more significant nitpick.)
Also polling theory is a lot more interesting than this stupid poll.
The cell is all about streaming math-intensive tasks. It is not designed to execute object-oriented code or even traverse a linked-list. It is essentially useless for writing AI code. It's just a step up from a DSP.
What most of us want is a noise-canceling box for noisy neighbors.
What this is is a noise-creating box for nosy neighbors.
You might manage to get your company to pay to put the former in your cubicle. Since the only point of the latter seems to be for allowing personal calls, somehow it seems more likely to get outright forbidden.
But obviously the submitter wouldn't do that and risk ruining his or her credibility on slashdot. Who submitted it, anyway? Oh, right. Anonymous reader.
Star Wars had a lot more context than people these days realize.
Yahoo hops on the same confusion, introducing "Yahoo! Music Engine" and "Yahoo Music Unlimited". Slashdot says "Perhaps most interesting to the Slashdot crowd is that the Yahoo Music Engine is built on an open platform that facilitates plug-ins". But so what? Is this interesting if I don't care about "Yahoo Music Unlimited"? Winamp "facilitates" plug-ins too, so... so what?
I tried to read the Ian Rogers page, but it was all blah blah blah rah rah rah. He dives right in with why you should use Yahoo Music Engine with the first bullet point being "PRICE! $5/month subscription service"--but he's not talking about the music engine, is he? He's talking about Yahoo Music Unlimited. So what the hell, even the tech guy can't get this right? Or is he just buying entirely into the "I am a vehicle for PR too"?
Finally, Yahoo Music Engine doesn't run on Macs, and files downloaded from Yahoo Music Unlimited don't play on iPods, so why is this in the category "Apple"?
That's their pitch, and that's how everybody is reporting on it. Dig into the details, and discover that this isn't true:
In other words, you can correctly implement the standards, and still render this wrong. So it's not a test of standards compliance (in the sense of 'css standards'; a "de-facto standard" is not a standard in the sense people are talking about here).
I don't know how many more things like this they rely on that aren't standards; I read this particular one right at the beginning, for row #1, and bailed reading the rest of the doc.
I think the complaint is just the wording in the great-grandparent; in reality, modifying the guest OS is a workaround for the performance problems from full virtualization, not vice versa. I think you totally understand this and accept it; it's just that that particular phrasing comes across as spin.
This is pretty clear if you use the classic example, encryption.
Good: a well-tested published algorithm with a lot of bits in the secret key
Bad: a secret, private algorithm with however many bits in the key
But why is the one good and the other bad? The classic answer is "because the well-tested published algorithm is really secure, and the other one isn't". But that's not a good explanation; it's trivial to roll a no-less-secure (and possibly more secure) secret algorithm: just use a good published encryption algorithm, plus re-encrypt the results using whatever random crappy algorithm you've invented. (Or maybe in the other order is better.) This is no less secure for the obvious reason, and if you manage to keep your random crappy algorithm secret, most people are going to have more trouble breaking it. Maybe the NSA can still break it, but they'll have to work harder.
Here's the reality of the situation: bits are hard to keep secret. The fewer bits you have to keep secret, the better off you are. If you have some special custom crappy encryption algorithm, you have to express that in code and hand it off to the other people who need to encode and decode. That code is now bits you have to keep secret. So in addition to your, say, 256 key bits, you now have a, say, 16KB executable you're keeping secret. That means you need to keep 128,000 bits secret!
Even if you're using a custom crappy encryption that's not built on top of a published, secure one, and you're not an idiot, you probably will give your average DeCSS-level hacker a difficult time--if you can keep all the bits secret. But here's the point: maybe you'd be better off just using a 128,000 bit key with one of those well-published algorithms! (I realize this doesn't necessarily literally work, although you can do triple-DES-like stuff, though it might be too slow, but let's ignore performance since that's always going to change.)
What really matters is the ratio of quality-of-security to the amount of data you have to keep secret; the security-quality-per-bit (SQ/b). In the case of encryption, you are probably best off putting those bits into your secret key for a published algorithm, not into a secret algorithm. In the case of Google, nobody current knows of a magical "good solution to fraud prevention" for them to use, and their best solution is to keep their fraud detection measure secret. Yes, if those measures leaked (say, somebody at google ran off with them, or got socially engineered), they won't work very well, but there is NOTHING to be gained by leaking them, despite whatever bizarro world grandparent and the people who modded him "insightful" are living in. ("No one can gain by covering up the problem...no one, that is, but the people perpetrating the click fraud." wha? huh? Like parent says, publishing their fraud detection methods and the extent of the fraud isn't going to prevent "gain" on the part of the frauders, and certainly will increase the likelihood of current non-frauders being able to fraud.)
So they revoke a player model as follows (omitting lots of details that aren't important to the big picture, and oversimplifying):
Each player model gets its own key ("set of Device Keys" in the specification). Data on the disc is encoded with a disc-specific data key. Given N player models, there are also N encrypted master keys, one for each (non-revoked) player model.
If a player model is compromised and the key from it used in a DeCSS-like program, they will "revoke" that key and, on all future releases, not include a copy of the disc-data key encrypted for that player.
With that in mind, it's clear that you can read what you quoted in the above sense, and indeed it's the plausible way to read it: it's not "causes a compromised device to be unable...", it's "causes a device with the compromised set of Device Keys to be unable...". Any device using this set of keys--whether it's superDeCSS or any particular machine of the sort that was compromised, or any other machine that shares the same set of keys--will no longer be able to view content--presumably only new content created after the revocation.
Related, from the spec:
So, say, the use of "workflow" in this "content management" context might have a meaning along the lines of "if a piece of data has to get manipulated by multiple people, a workflow system can track where the data is in that workflow (who has it now, who's responsonle for it, etc.)"; but that's entirely guesswork. Maybe it's not multiple people, it's multiple programs (but in which case I'm not sure what exactly "workflow" is other than a script to run the piece of data through multiple programs, which is not exactly noteworthy technology).
And then "editorial review", well, obviously the program isn't doing editorial review, so I guess you mean the system is making sure the data goes through editorial review, but hey, that would be a "workflow" step in my above definition, so either I guessed wrong, or you were being redundant. I have no clue which!
So one sentence of mostly new buzzwords, and three paragraphs of just repeating back the original buzzwords and saying "it's obvious". Dude, pas de donut.