IMO, there really are no alternatives to the service Netflix can provide. Specfically their ratings and recommendations model.
Did you see the Wired story about NetFlix? NetFlix recommendations are essentially for sale to the highest bidder. Studios can pay NetFlix to recommend movies, spuring DVD sales.
A quote:
As a Blockbuster sister company, it [Paramount] has no revenue-sharing arrangement with Netflix. So while Netflix stocks Paramount movies, it doesn't promote them in any way. No matter how many Mel Gibson romantic comedies you rate highly, What Women Want will never be recommended to you. The Netflix effect? What Women Want was the second-most rented film of 2001 overall but didn't even make the top 100 on Netflix.
The upshot: NetFlix's recommendation system exists strictly to earn NetFlix more money - even at the expense of helping you find movies that you like. It's a case where a company is willfully worsening their customer service in pursuit of profit - the opposite of the way capitalism is supposed to work.
Re:Linux's uptimes approaching Solaris'
on
Sun's Last Stand
·
· Score: 1
1) Linux boxes that have uptimes of 400+ days are still using kernels that have the uptime rollovers at ~497 days, when the 32-bit long unsigned integer used to count the number of uptime seconds resets to 0...
Except, of course, that a 32-bit unsigned integer would let you count up for 49,710 days if you were counting in seconds.
Perhaps the uptime software is counting hundredths of seconds? I don't know why anyone would bother, but there you go.
I feel every book on programming with long examples out to come with a disc containing all example programs, so that the reader can tweak and observe them as he sees fit, without typing in five pages of code. The best way to learn is often by example, and discouraging lazy people doesn't help the learning process along.
I've always found that I learn the stuff way better if I'm forced to type in the code, which makes me read it a lot more closely.
That aside, it does indeed sound like a dreadfully misguided book. "Hello World" may be hackneyed, but there's a reason it's used so often.
Code Complete does not recommend the Hungarian naming convention.
It has a chapter on naming things, and it has a lot of good guidelines for picking names. It strongly recommends settling on and using some standard, project-wide naming convention.
There is a a section describing the Hungarian naming convention. That section includes a frank discussion of it's drawbacks and caveats. A quote from that section:
Some of the versions of Hungarian that are in wide circulation... set up base types based on programming-language integers, long integers, floating-point numbers and strings. The result is a convention of little value... When you declare a variable to be an integer, you shouldn't have to change the variable's name if you change it to a long integer.
Most critics of Hungarian - like the author of the CodingStyle document, apparently - don't understand it. You actually are closest to the money with point #2. I don't know where you got your other points from; your point #1 is specifically listed as something not to do.
You're supposed to use the variable names to indicate abstract types, not programming language types. If you're merely using a prefixes to indicate programming-language types (i.e., int iQuantity, char chInput, etc.) then you're doing it wrong.
You should actually read - rather than skim - Code Complete. It's teriffic book, no matter what your favorite OS is.
I'm sorry if this post seems a little grumpy, but reading Code Complete was a revelation to me (Aha, I'm not crazy, these other people around me are doing it all wrong! No wonder this disorganized mess doesn't work!) and it's still one of my favorites.
G. Cooke, TX! Why, just the name is inviting. I've found these reviews to be a mini treasure! After diving in once, you won't be able to resist going back for more. These reviews will make a treasured gift, and keep you on your toes.
When you buy a computer from some manufacturer you don't come back with just your graphic card and demand a refund because you don't like it.
Why on Earth not? My Dell came with a modem that turned out to be junk. I sent the modem back, and got $90 credit.
Your other examples are far more extreme - changing the chip on a video card or the bumper on a car are non-trivial, because they are tightly integrated with the larger system. But expansion cards and software packages are deliberately designed from the beginning to be modular parts of a larger system - customizeable.
Marvel has reported millions of dollars in earnings from the film but has told Lee the company has seen no "profits" as defined by their contract.
Yeah, it seems pretty wrong that the guy who invented Spider-Man should get no bonus check when the movie is a success. But we haven't seen the contract - maybe he isn't due anything, legally speaking, according to its terms.
The funny part is that the media biz ends up looking pretty bad either way - the "artist's rights" that they wring their hands over so publicly obviously aren't really a top priority for them at all, not that we're surprised.
CD DA does NOT... have any EDC and ECC mechanisms...
I'm afraid you're quite mistaken.
Red Book audio CDs (CD-DA) use data redunancy, error correction codes, and special damage-resistant encodings extensively. Something like a third of the data on the disc is just redundant codes to allow for perfect error correction in most cases.
It's a common misconception in the computer biz. Comparing high-level specs for CD-DA and CD-ROM does indeed fail to show any data redundancy for CD-DA and does show some for CD-ROM. However, the data redundancy in the high-level CD-ROM specs is additional redunancy, over and above what the Red Book standard mandates. The special Red Book encodings are all handled at a very low level by a CD-ROM drive's firmware, so they just don't get mentioned in OS-level API type docs, and thus a myth is born.
Speaking of camera angle, am I the only one who finds this to be the biggest problem with 3D games? You effectivly have 2 choices: first person, which lacks good periphieral vision; or 3rd person, which gives pretty good periphieral vision, but then makes lining up a jump a real pain, also, if the controls are based on the camera they will often change on you while you are in mid-air, really screwing the jump.
Prince Of Persia 3D tried to use a fully-automatic camera, and it failed abysmally. I couldn't get anywhere in that game because I could never see what was going on. (And don't even get me started on the ponderous keyboard-only controls - what were they thinking? No wonder it ended up in the bins so fast.)
FAKK2, Alice, Oni, and Messiah, on the other hand, all used the 3rd person with a fixed or manually-adjustable camera - and they all worked much better. The Quake III based games (FAKK2 & Alice) in particular, allowed for just about perfect control for lining up jumps etc.
What I meant was, C and C++ are pretty permissive about mixing and matching various numeric types together in expressions. Sometimes the implicit conversions the compiler generates don't work the way the author of the code expects.
The problem is frequently exacerbated when C and C++ are used in environments that encourage or require liberal use of explicit casts. That throws a lot of possibly helpful type-checking out the window.
Well, I, for one, certainly do that. I like my code to actually compile when I'm done editing it. If one is too lazy to check the safety of a type change like this, HN will be the least of one's problems, IMHO.
Quite frequently such [search-and-replace] operations end up screwing things up because the SnR tool got confused.
You shouldn't be using fully-automatic search-and-replace in this case. You should be doing the replacements one at a time, verifying in each case that the name replacement is correct and that the new type is indeed safe in the old context. This second point is vital; it's easy to create new bugs in old code by changing, say, int to long or int to unsigned.
Second, you are driving changes in files that you shouldn't have to change. As a result, you clutter up your revision control system with a bunch of crap.
On the one hand, I can see your point here. On the other hand, VC's job is to track the changes; if you're changing varible types frequently, then your VC store is going to reflect this to some degree anyway.
Third, if you deal with any kind of QA department, they will insist upon verifying all code that you've changed - "But it was a simple search and replace" won't cut it (nor should it!). So you will have QA time being spend on verifying a bunch of things that you shouldn't have to verify.
When you change a variable's type, you are making a change to all of the code that refers to that variable. It doesn't matter if you change the variable's name or not - the code that uses it must be re-compiled and certainly should be re-verified.
I assert that the time saved by being able to tell that piFoo is a pointer to integer is much less than the time costs Hungarian notation imposes.
My experience has been otherwise, but this is something reasonable people can reasonably disagree on. One thing many HN critics overlook is that you don't have to buy in to the whole system all the time if you don't want to; you can scale it down to whatever level you find useful, and stick to that.
But even so, in C, C++, or any weakly-typed language, changing the type of a variable can introduce subtle bugs, particularly when dealing with unfamiliar code. It's a good idea to review references to a variable when changing its type, and that's a process that meshes well with search/replace anyway.
This isn't a problem with HN; it's a benefit, since you're forced, or at least strongly encouraged, to do the right thing.
And isn't this something of a canard, anyway? How often do you have to change a variable's type? If you're doing a lot of that, something is wrong. Compare this with how often you need to find a variable's type.
I remember reading some time ago, on this very site I believe, that RAM disks were often very disappointing in performance. The reason turned out to be that the RAM disk software was not well-optimized.
Modern OSes, including Linux and Windows, have highly optimized disk caches, because a good disk cache is better in most situations. It's self-tuning and self-sizing in nature, it speeds up pretty much everything (as opposed to speeding up a few apps carefully set up to take advantage), and if it's very smart, it can manage optimizations that might be tricky with a RAM disk.
The Windows disk cache, for example, makes it possible to run code directly from cache memory - so libraries and executables don't end up double-dipping into the memory pool. This is why, when you examine the memory usage for a Windows machine, you'll often see a ludicrous amount of memory devoted to the disk cache, even to the point where there is virtually no free RAM at all. (My old 128MB machine generally gobbled up 80MB for disk cache, leaving almost no free memory, yet it ran very well.) Yet the machine will run smoothly (well, as smoothly as Windows ever does), because code is transferred to the disk cache and run directly from it, with a minimum of memory-shuffling.
So I guess my point is, with a well-tuned, modern OS, you may be better off adding the memory and cranking the disk cache up (if you can). There might be some niche applications where the RAM disk would be faster, but an awful lot of effort has been invested in making the disk cache ultra-fast; most of the time, it's the way to go.
Over at cdrinfo.com, they often do some copy-protection testing and analysis when they review a new burner. Sometimes both for CD-R and audio CD copy-protection systems, even.
one mode of its operation allowed it to simply record keystrokes locally... then be recovered physically upon serving a warrant on the user.
This is a good point, but this mode of operation would limit the usefulness of Magic Lantern severely for a couple of reasons.
1) Assuming we're talking about a self-replicating or built-in-to-the-OS Trojan (and therefore widely distributed) implementation of Magic Lantern, I'd guess a local keystroke log would be discovered even quicker than phantom network traffic. A lot more folks are savvy enough to figure out there's some mysterious growing file on their machine than are savvy enough to analyze network traffic. If the file was hidden in some underhanded way, it's a good bet that a lot of virus detectors would flag that as generic virus-like behavior, no specific virus definition required.
2) If the Feds are required to get a warrant to retrieve the logged info, they've got to have some separate source of dirt on the suspect in order to get the warrant anyway. This makes Magic Lantern a lot less useful, since it can only be used to monitor people so suspect that a warrant can be obtained. In this case, why not just require a warrant for it's installation in the first place? If Magic Lantern were to secretly send logs back to the Feds over a network, on the other hand, those logs themselves could be used to obtain a warrant.
The whole thing gives me the heebie-jeebies, and at the same time, I have a hard time believing it will work, in either mass-distributed or targeted form. I have to wonder if the whole thing isn't just a scare-tatic hoax. Maybe the Feds are just hoping to scare would-be-criminals away from relatively difficult-to-tap communications systems (like PGP e-mail) toward relatively easy-to-tap ones (cell phones, coversations with wire-wearing informants, etc).
The top selling albums of 1999: BACKSTREET BOYS Millenium,BRITNEY SPEARS,...Baby One More Time, RICKY MARTIN, Ricky Martin. Not albums which the 40+ crowd are going to be buying.
I'm not going to argue that adults dig Britney, that's for sure. But check out the RIAA's consumer profiles: the 40+ set bought 34% of the records sold in '99, while the 19-and-under crew only accounted for 21%.
I still want to know how watermarked formats are expected to work.
I walk into a record store, plonk down $20 in green folding stuff, and get a shiny new CD. I can then convert that to MP3 and no-one can tell who did it. They can tell it came from disc #1485175. They might be able to tell the store that disc was sold from, but they can't tell who bought it.
I used to wonder this, too. I believe the idea is that a watermark-aware device (like a future version of the Diamond Rio) simply won't make a copy of a watermarked source. The watermark is simply a way of embedding a few bits of information into the music itself. All the information that's needed is "don't copy me!" Watermark-compliant units will comply. It's not much of a stretch from there to see that slightly more elaborate watermark schemes could be used for regional coding (like DVDs), limited replays for demo material (given a player smart enough to remember what it has played) or time-restricted play (don't play this stream after Dec 31st 2000, etc), and who knows what other unpleasantness.
Of course, the big challenge for the RIAA is to get SDMI enabled devices to be the accepted norm - to displace MP3s as the format of choice. That's going to be a toughie, eh?
Incidentially, I'm told that the way CDs are made now, there's no way to serialize them - they are stamped out like so many cookies, all the same - so there's no way to put unique serial numbers on each one. So they couldn't track a serialized disc to a particular store, either.
The biggest section of the CD buying public is teenage girls, who don't have credit cards, so you cannot limit purchasers to those who have credit cards.
Are you sure about that, or are you just guessing? I seem to recall seeing RIAA demographic figures, and adults - older adults, the 40+ crowd - were actually the biggest music buyers today, odd though it seems. There was a big flap about that stuff about a year ago, when the RIAA was claiming that profits were down because of MP3s (which was patently false according to their own figures, by the way). I don't have a link to that stuff anymore - anyone else?
I agree that the RIAA can't require buyer registration - for a number of reasons, not least because big chunks of the market are under-age.
You're right, it sounds scary from that political standpoint, and I'm very much against it, but consider:
It won't be long before photographs, video recordings, and audio recordings aren't considered proof of anything anymore.
It won't be long before the US$500 PCs for sale at Best Buy will put the finest graphical workstations now available to shame. With a few tens of GFLOPS on tap, even Joe Six Pack will be able to manufacture video, audio, and photographic "proof" of whatever the heck he wants - faces on Mars, the president is an alien, Nixon shot Kennedy, etc. Movie studios have used digital FX for years - and it looks, in some cases, better than photography of the actual event or situation would. TV networks are already capable of modifying live video (for ad insertion) in real time. In 10 years, Quake IX will probably require that kind of horsepower - it will be everywhere.
The government will have an easy time revising history if it wants - no help needed from a rule like this. They can simply claim that any recording that doesn't jibe with the "official" version is a fake. And the luncatic fringe will produce some fakes, anyway, strengthening the government's case.
Not to mention the orchestrated letter campaign from people in Japan, calling for the US to ban guns. (I wonder what they'd think of an orchestrated letter campaign in the US calling for Japan to ban knives - especially deadly assault katanas?)
Not that it's strictly relevant, but - katanas are more strictly regulated in Japan than guns are in the US. Katana owners not only have to have a license, they have to allow government inspections on a regular basis to ensure that the katana in question really is the licensed one. (So says my uncle who lives there, anyway.)
I can understand the homeowner in the Texas case being frightened. But you seem to imply that the Japanese letter-writers were engaging in some sort of hypocrisy, and it's not the case. They are guilty perhaps of thinking that their own standards are the One True Way, but aren't we all, from time to time?
It was *essential* to winning the game? I never finished Colossal Cave, so I wouldn't know. It certainly was handy, in any case, and you remember right - it was scrawled on the wall. For a while, I played a buggy port of CC that wouldn't let one into the cave at all, but I managed to get around that with XYZZY. I think there was at least one other magic word like it - "plugh" or something?
Paul has certainly done things in the past that could be grounds for dismissal, but this was retaliatory for him being among the "conspirators".
This sounds like Adrian and Kevin said to themselves: "Well, OK, we'll work on Doom III if that's what John really wants. But we aren't going to do it with that jerk Paul around, at least." If they've been wanting to get rid of him anyway, then doing so at the outset of the project is probably better than doing it in the middle. Maybe it isn't the fatal political bomb that it at first appears.
Well, you'd think so, wouldn't you? Yet Quake I (for example) was consistently criticized (by the press at least) for having "no plot." Some people do care, but I agree it doesn't make much sense.
If you want your children to grow up healthy and strong they must be exposed to viruses. Instead of clamping down on virus writers, we should reward them. Encourage a legalised virus industry.
This is where your analogy starts to break down, at least for me. Your body does not give any reward real viruses, it fights them all-out, tooth and nail.
You argue that legislation can never discourage all virus writers. You then argue that we must be exposed to viruses in order to learn how to better protect our systems. Somehow you conclude that we should encourage virus writers, even though your first argument makes it clear that no encouragement is required to expose us; we've got plenty of exposure without that.
Slashdot Mirror
Did you see the Wired story about NetFlix? NetFlix recommendations are essentially for sale to the highest bidder. Studios can pay NetFlix to recommend movies, spuring DVD sales.
A quote:
The upshot: NetFlix's recommendation system exists strictly to earn NetFlix more money - even at the expense of helping you find movies that you like. It's a case where a company is willfully worsening their customer service in pursuit of profit - the opposite of the way capitalism is supposed to work.
1) Linux boxes that have uptimes of 400+ days are still using kernels that have the uptime rollovers at ~497 days, when the 32-bit long unsigned integer used to count the number of uptime seconds resets to 0...
Except, of course, that a 32-bit unsigned integer would let you count up for 49,710 days if you were counting in seconds.
Perhaps the uptime software is counting hundredths of seconds? I don't know why anyone would bother, but there you go.
I feel every book on programming with long examples out to come with a disc containing all example programs, so that the reader can tweak and observe them as he sees fit, without typing in five pages of code. The best way to learn is often by example, and discouraging lazy people doesn't help the learning process along.
I've always found that I learn the stuff way better if I'm forced to type in the code, which makes me read it a lot more closely.
That aside, it does indeed sound like a dreadfully misguided book. "Hello World" may be hackneyed, but there's a reason it's used so often.
It has a chapter on naming things, and it has a lot of good guidelines for picking names. It strongly recommends settling on and using some standard, project-wide naming convention.
There is a a section describing the Hungarian naming convention. That section includes a frank discussion of it's drawbacks and caveats. A quote from that section:
Most critics of Hungarian - like the author of the CodingStyle document, apparently - don't understand it. You actually are closest to the money with point #2. I don't know where you got your other points from; your point #1 is specifically listed as something not to do.
You're supposed to use the variable names to indicate abstract types, not programming language types. If you're merely using a prefixes to indicate programming-language types (i.e., int iQuantity, char chInput, etc.) then you're doing it wrong.
You should actually read - rather than skim - Code Complete. It's teriffic book, no matter what your favorite OS is.
I'm sorry if this post seems a little grumpy, but reading Code Complete was a revelation to me (Aha, I'm not crazy, these other people around me are doing it all wrong! No wonder this disorganized mess doesn't work!) and it's still one of my favorites.
G. Cooke, TX! Why, just the name is inviting. I've found these reviews to be a mini treasure! After diving in once, you won't be able to resist going back for more. These reviews will make a treasured gift, and keep you on your toes.
So, this means that anything that possibly can go wrong no longer will! Hey, I'm all for that!
What? Moore's Law? Oh. Nevermind.
When you buy a computer from some manufacturer you don't come back with just your graphic card and demand a refund because you don't like it.
Why on Earth not? My Dell came with a modem that turned out to be junk. I sent the modem back, and got $90 credit.
Your other examples are far more extreme - changing the chip on a video card or the bumper on a car are non-trivial, because they are tightly integrated with the larger system. But expansion cards and software packages are deliberately designed from the beginning to be modular parts of a larger system - customizeable.
The story says, in part:
Marvel has reported millions of dollars in earnings from the film but has told Lee the company has seen no "profits" as defined by their contract.
Yeah, it seems pretty wrong that the guy who invented Spider-Man should get no bonus check when the movie is a success. But we haven't seen the contract - maybe he isn't due anything, legally speaking, according to its terms.
The funny part is that the media biz ends up looking pretty bad either way - the "artist's rights" that they wring their hands over so publicly obviously aren't really a top priority for them at all, not that we're surprised.
CD DA does NOT ... have any EDC and ECC mechanisms...
I'm afraid you're quite mistaken.
Red Book audio CDs (CD-DA) use data redunancy, error correction codes, and special damage-resistant encodings extensively. Something like a third of the data on the disc is just redundant codes to allow for perfect error correction in most cases.
It's a common misconception in the computer biz. Comparing high-level specs for CD-DA and CD-ROM does indeed fail to show any data redundancy for CD-DA and does show some for CD-ROM. However, the data redundancy in the high-level CD-ROM specs is additional redunancy, over and above what the Red Book standard mandates. The special Red Book encodings are all handled at a very low level by a CD-ROM drive's firmware, so they just don't get mentioned in OS-level API type docs, and thus a myth is born.
Here's a good overview.
Speaking of camera angle, am I the only one who finds this to be the biggest problem with 3D games? You effectivly have 2 choices: first person, which lacks good periphieral vision; or 3rd person, which gives pretty good periphieral vision, but then makes lining up a jump a real pain, also, if the controls are based on the camera they will often change on you while you are in mid-air, really screwing the jump.
Prince Of Persia 3D tried to use a fully-automatic camera, and it failed abysmally. I couldn't get anywhere in that game because I could never see what was going on. (And don't even get me started on the ponderous keyboard-only controls - what were they thinking? No wonder it ended up in the bins so fast.)
FAKK2, Alice, Oni, and Messiah, on the other hand, all used the 3rd person with a fixed or manually-adjustable camera - and they all worked much better. The Quake III based games (FAKK2 & Alice) in particular, allowed for just about perfect control for lining up jumps etc.
Perhaps I am abusing the term "weakly typed."
What I meant was, C and C++ are pretty permissive about mixing and matching various numeric types together in expressions. Sometimes the implicit conversions the compiler generates don't work the way the author of the code expects.
The problem is frequently exacerbated when C and C++ are used in environments that encourage or require liberal use of explicit casts. That throws a lot of possibly helpful type-checking out the window.
Well, I, for one, certainly do that. I like my code to actually compile when I'm done editing it. If one is too lazy to check the safety of a type change like this, HN will be the least of one's problems, IMHO.
Quite frequently such [search-and-replace] operations end up screwing things up because the SnR tool got confused.
You shouldn't be using fully-automatic search-and-replace in this case. You should be doing the replacements one at a time, verifying in each case that the name replacement is correct and that the new type is indeed safe in the old context. This second point is vital; it's easy to create new bugs in old code by changing, say, int to long or int to unsigned.
Second, you are driving changes in files that you shouldn't have to change. As a result, you clutter up your revision control system with a bunch of crap.
On the one hand, I can see your point here. On the other hand, VC's job is to track the changes; if you're changing varible types frequently, then your VC store is going to reflect this to some degree anyway.
Third, if you deal with any kind of QA department, they will insist upon verifying all code that you've changed - "But it was a simple search and replace" won't cut it (nor should it!). So you will have QA time being spend on verifying a bunch of things that you shouldn't have to verify.
When you change a variable's type, you are making a change to all of the code that refers to that variable. It doesn't matter if you change the variable's name or not - the code that uses it must be re-compiled and certainly should be re-verified.
I assert that the time saved by being able to tell that piFoo is a pointer to integer is much less than the time costs Hungarian notation imposes.
My experience has been otherwise, but this is something reasonable people can reasonably disagree on. One thing many HN critics overlook is that you don't have to buy in to the whole system all the time if you don't want to; you can scale it down to whatever level you find useful, and stick to that.
HN was invented for use with C, not C++.
But even so, in C, C++, or any weakly-typed language, changing the type of a variable can introduce subtle bugs, particularly when dealing with unfamiliar code. It's a good idea to review references to a variable when changing its type, and that's a process that meshes well with search/replace anyway.
This isn't a problem with HN; it's a benefit, since you're forced, or at least strongly encouraged, to do the right thing.
And isn't this something of a canard, anyway? How often do you have to change a variable's type? If you're doing a lot of that, something is wrong. Compare this with how often you need to find a variable's type.
Modern OSes, including Linux and Windows, have highly optimized disk caches, because a good disk cache is better in most situations. It's self-tuning and self-sizing in nature, it speeds up pretty much everything (as opposed to speeding up a few apps carefully set up to take advantage), and if it's very smart, it can manage optimizations that might be tricky with a RAM disk.
The Windows disk cache, for example, makes it possible to run code directly from cache memory - so libraries and executables don't end up double-dipping into the memory pool. This is why, when you examine the memory usage for a Windows machine, you'll often see a ludicrous amount of memory devoted to the disk cache, even to the point where there is virtually no free RAM at all. (My old 128MB machine generally gobbled up 80MB for disk cache, leaving almost no free memory, yet it ran very well.) Yet the machine will run smoothly (well, as smoothly as Windows ever does), because code is transferred to the disk cache and run directly from it, with a minimum of memory-shuffling.
So I guess my point is, with a well-tuned, modern OS, you may be better off adding the memory and cranking the disk cache up (if you can). There might be some niche applications where the RAM disk would be faster, but an awful lot of effort has been invested in making the disk cache ultra-fast; most of the time, it's the way to go.
Over at cdrinfo.com, they often do some copy-protection testing and analysis when they review a new burner. Sometimes both for CD-R and audio CD copy-protection systems, even.
one mode of its operation allowed it to simply record keystrokes locally ... then be recovered physically upon serving a warrant on the user.
This is a good point, but this mode of operation would limit the usefulness of Magic Lantern severely for a couple of reasons.
1) Assuming we're talking about a self-replicating or built-in-to-the-OS Trojan (and therefore widely distributed) implementation of Magic Lantern, I'd guess a local keystroke log would be discovered even quicker than phantom network traffic. A lot more folks are savvy enough to figure out there's some mysterious growing file on their machine than are savvy enough to analyze network traffic. If the file was hidden in some underhanded way, it's a good bet that a lot of virus detectors would flag that as generic virus-like behavior, no specific virus definition required.
2) If the Feds are required to get a warrant to retrieve the logged info, they've got to have some separate source of dirt on the suspect in order to get the warrant anyway. This makes Magic Lantern a lot less useful, since it can only be used to monitor people so suspect that a warrant can be obtained. In this case, why not just require a warrant for it's installation in the first place? If Magic Lantern were to secretly send logs back to the Feds over a network, on the other hand, those logs themselves could be used to obtain a warrant.
The whole thing gives me the heebie-jeebies, and at the same time, I have a hard time believing it will work, in either mass-distributed or targeted form. I have to wonder if the whole thing isn't just a scare-tatic hoax. Maybe the Feds are just hoping to scare would-be-criminals away from relatively difficult-to-tap communications systems (like PGP e-mail) toward relatively easy-to-tap ones (cell phones, coversations with wire-wearing informants, etc).
The top selling albums of 1999: BACKSTREET BOYS Millenium,BRITNEY SPEARS, ...Baby One More Time, RICKY MARTIN, Ricky Martin. Not albums which the 40+ crowd are going to be buying.
I'm not going to argue that adults dig Britney, that's for sure. But check out the RIAA's consumer profiles: the 40+ set bought 34% of the records sold in '99, while the 19-and-under crew only accounted for 21%.
I still want to know how watermarked formats are expected to work.
I walk into a record store, plonk down $20 in green folding stuff, and get a shiny new CD. I can then convert that to MP3 and no-one can tell who did it. They can tell it came from disc #1485175. They might be able to tell the store that disc was sold from, but they can't tell who bought it.
I used to wonder this, too. I believe the idea is that a watermark-aware device (like a future version of the Diamond Rio) simply won't make a copy of a watermarked source. The watermark is simply a way of embedding a few bits of information into the music itself. All the information that's needed is "don't copy me!" Watermark-compliant units will comply. It's not much of a stretch from there to see that slightly more elaborate watermark schemes could be used for regional coding (like DVDs), limited replays for demo material (given a player smart enough to remember what it has played) or time-restricted play (don't play this stream after Dec 31st 2000, etc), and who knows what other unpleasantness.
Of course, the big challenge for the RIAA is to get SDMI enabled devices to be the accepted norm - to displace MP3s as the format of choice. That's going to be a toughie, eh?
Incidentially, I'm told that the way CDs are made now, there's no way to serialize them - they are stamped out like so many cookies, all the same - so there's no way to put unique serial numbers on each one. So they couldn't track a serialized disc to a particular store, either.
The biggest section of the CD buying public is teenage girls, who don't have credit cards, so you cannot limit purchasers to those who have credit cards.
Are you sure about that, or are you just guessing? I seem to recall seeing RIAA demographic figures, and adults - older adults, the 40+ crowd - were actually the biggest music buyers today, odd though it seems. There was a big flap about that stuff about a year ago, when the RIAA was claiming that profits were down because of MP3s (which was patently false according to their own figures, by the way). I don't have a link to that stuff anymore - anyone else?
I agree that the RIAA can't require buyer registration - for a number of reasons, not least because big chunks of the market are under-age.
You're right, it sounds scary from that political standpoint, and I'm very much against it, but consider:
It won't be long before photographs, video recordings, and audio recordings aren't considered proof of anything anymore.
It won't be long before the US$500 PCs for sale at Best Buy will put the finest graphical workstations now available to shame. With a few tens of GFLOPS on tap, even Joe Six Pack will be able to manufacture video, audio, and photographic "proof" of whatever the heck he wants - faces on Mars, the president is an alien, Nixon shot Kennedy, etc. Movie studios have used digital FX for years - and it looks, in some cases, better than photography of the actual event or situation would. TV networks are already capable of modifying live video (for ad insertion) in real time. In 10 years, Quake IX will probably require that kind of horsepower - it will be everywhere.
The government will have an easy time revising history if it wants - no help needed from a rule like this. They can simply claim that any recording that doesn't jibe with the "official" version is a fake. And the luncatic fringe will produce some fakes, anyway, strengthening the government's case.
Not to mention the orchestrated letter campaign from people in Japan, calling for the US to ban guns. (I wonder what they'd think of an orchestrated letter campaign in the US calling for Japan to ban knives - especially deadly assault katanas?)
Not that it's strictly relevant, but - katanas are more strictly regulated in Japan than guns are in the US. Katana owners not only have to have a license, they have to allow government inspections on a regular basis to ensure that the katana in question really is the licensed one. (So says my uncle who lives there, anyway.)
I can understand the homeowner in the Texas case being frightened. But you seem to imply that the Japanese letter-writers were engaging in some sort of hypocrisy, and it's not the case. They are guilty perhaps of thinking that their own standards are the One True Way, but aren't we all, from time to time?
It was *essential* to winning the game? I never finished Colossal Cave, so I wouldn't know. It certainly was handy, in any case, and you remember right - it was scrawled on the wall. For a while, I played a buggy port of CC that wouldn't let one into the cave at all, but I managed to get around that with XYZZY. I think there was at least one other magic word like it - "plugh" or something?
Paul has certainly done things in the past that could be grounds for
dismissal, but this was retaliatory for him being among the "conspirators".
This sounds like Adrian and Kevin said to themselves: "Well, OK, we'll work on Doom III if that's what John really wants. But we aren't going to do it with that jerk Paul around, at least." If they've been wanting to get rid of him anyway, then doing so at the outset of the project is probably better than doing it in the middle. Maybe it isn't the fatal political bomb that it at first appears.
Nobody cares about the "story line", anyway.
Well, you'd think so, wouldn't you? Yet Quake I (for example) was consistently criticized (by the press at least) for having "no plot." Some people do care, but I agree it doesn't make much sense.
If you want your children to grow up healthy and strong they must be exposed to viruses. Instead of clamping down on virus writers, we should reward them. Encourage a legalised virus industry.
This is where your analogy starts to break down, at least for me. Your body does not give any reward real viruses, it fights them all-out, tooth and nail.
You argue that legislation can never discourage all virus writers. You then argue that we must be exposed to viruses in order to learn how to better protect our systems. Somehow you conclude that we should encourage virus writers, even though your first argument makes it clear that no encouragement is required to expose us; we've got plenty of exposure without that.