An article in the Daily Aardvark points out that Netscape users have a hard time reading Passport Q&A.
This raising an interesting issue: What happens if a web browser fails to properly display a disclaimer (or other legal document)? For example, suppose the main site uses javascript to pop up the legalese. Further suppose that I browse the web with javascript disabled. So when I click on the link that says, "Click here to view limitations of the offer", am I able to interpret the lack of any limitations appearing on my screen as a complete lack of any limitations on the offer? What if I do have javascript enabled, but the text isn't displayed (or is displayed blank) due to an error in the web browser's interpretation of javascript?
Slashdot's attempts fell flat because, well, most were way too obvious
In addition to being too obvious, they were also a little too prolific. If you tell someone, in quick succession, that there's a spider on their back, aliens have just landed, and Elvis has just come out of hiding, then they aren't going to believe you when you claim something vaguely plausible, such as George W. signing an executive order mandating prayer in school as a means of dealing with school violence.
Besides, as I pointed out in this post in the "Slashdot During War?" thread, a number of the "legitimate" AskSlashdot's have been more absurd than the April Fool's Day ones.
Hell, if it weren't for the fact that the "What isn't on the Internet?" question claims "I have *never* not found anything I've searched for" (with a few exceptions), I would've pegged it as a normal, legitimate question (especially given that it got at least one serious, insightful reply here, talking about the lack of scientific papers that're available. It's just hard to peg a legitimate question with a legitimate answer as an April Fool's joke.
I really wish you'd include some sort of spoiler warning in the future before posting spoiler information for a movie. Personally, I've been waiting until after I can watch Star Wars Episodes 2 and 3 before watching 4, 5, and 6. I'm sure I'm not alone in the geek community for wanting to watch the movies in the "proper" order. As such, I was shocked and dismayed to have the movie ruined by the blaise manner in which you've ruined a film that I've spent my entire 24 years on this planet anticipating.
As a form of protest, I will be boycotting Slashdot, PT Cruisers, News, Nerds, Free Registration at the New York Times, Futurama (for shamelessly naming one of their characters after a SlashCode release), and Disney (What's a boycott if you don't include Disney?).
Furthermore, my boycott shall continue until one of the following conditions is met:
I receive personal apologies from jamie and alphaparadigm. All Slashdot editors sign a statement promising never, ever to post spoilers without sufficient warning.
I forget that I'm running a boycott.
Slashdot ships me enough alcohol in the next few minutes to allow me to completely trash my short-term memory and forget that I read these spoilers.
I start going into Slashdot withdrawl and decide to quietly end my boycott.
I can't believe how many people fell for this April Fool's joke.
Define "April Fool's joke". Are we talking about an Ask Slashdot that's so unbelieveably stupid, inane, or silly that there's no way it could be taken seriously?
If so, I'd like to point out the following non-April 1st "Ask Slashdot" entries:
Given that the "Slashdot during War" AskSlashdot is less absurd than some of the "legitimate" AskSlashdot's and could (potentially) serve as a catalyst for worthwhile discussion, the question becomes just who pulled a prank on whom?
Or, to put it more simply, is trolling trolls really trolling? How much wood would a woodchuck chuck if a woodchuck could chuck wood? Who is John Galt? What's keeping Godot? If a tree falls in the woods, will it knock out my Internet connection?
Most-to-all of the changes between 2.4.0 and 2.4.3 should be bug fixes (include an ext2 corruption bug, IIRC) and minor updates. Feature-wise, it should be mostly the same.
You've raised some interesting points, one or two of which I'm hard-pressed to come up with a clear-cut answer on.
As far as the first point goes (increased bandwidth due to users downloading the song left and right), I think you misunderstood my proposal. The web instance of the song would exist only to get authenticated via Napster. (Unless the person running the website chose to publish that address separately, possibly with the help of Napster -- in short, it'd be almost like your "real" email address entry for Slashdot; other users know it exists, but can't get to it.) So regular user downloads would take place via the traditional P2P mechanisms. However, when a Napster user's client goes to try and share the song, it'd send up an md5 hash (which, admittedly, would open the system to spoofing -- however, one could argue this is more robust than the current name-based system; as an added bonus, it could auto-name mp3s based on what the authenticator provided). That md5 hash gets checked by the Napster server to make sure it's in the database. If it gets a match, the song is considered okay for sharing (possibly with an extra info link for people to find out about the authenticator and his/her other authenticated songs -- this might be useful for someone who's authenticating, say, a large collection of copyright-expired music in a genre you're interested in).
The second point (the "I was hacked" defense) is one that I really don't have a good answer to. The best I can do is point out that someone could do the same thing with a web or FTP server that was acting as a direct-access illegal mp3 drop, and then do some handwaving, mumble a bit, hope it doesn't happen, and move on to the next point.
As for the third point (the "tax" of having a web site), I admit it's a problem. One solution might be to provide a number of alternatives for a copyright holder to provide authorization. There's also the possibility of using a service such as mp3.com as your hosting site -- if I'm not mistaken, it's free for non-premium users. While it wouldn't normally be in mp3.com's best interests to serve as an authorization drop-box for Napster songs, if we couple it with the earlier idea of having a link to the authorizing agent's site for each song, we suddenly have a means for mp3.com to help generate traffic back to their own site. Finally, the cost of a website would probably a lot cheaper than, say, the cost of officially registering your song on the RIAA opt-in list (and the latter wouldn't necessarily be open to people trading bootlegs of bands that don't object to recordings of their live shows).
On the fourth point (more bandwidth constraints and having the RIAA double-check authentication sites), you could greatly reduce bandwidth by having the song downloaded only once, with the HTTP ETag header being saved. From then on, it's just a simple HTTP HEAD request to verify the ETag (just like how browser caching works). No muss, no fuss, and bandwidth usage that (except for the initial retrieval) wouldn't even be noticeable.
As for your final "why bother with Napster, then?" comments, I do admit that it greatly reduces a lot of Napster's appeal. However, it does still provide two benefits: Bandwidth usage reduction (since people're still getting the songs via P2P) and shared interests/recommendations (where you see other songs you haven't heard before while browsing the shares of someone with similar interests).
How is this different from the current system, where anybody can have any mp3 on their system and make it available to other Napster users?
1 - The system would be a little less transient in nature. Napster users log in and out all the time. In theory, a file on a dedicated, stable web server would be verifiable at multiple times during the day, etc.
2 - The system would defer some of the blame. By only providing a distributed, selective "cache" for files that're out on the web, Napster has a better chance at convincing the RIAA to go after a web site.
3 - The system would cluster lots of blame on a single user. If Napster can say, "There were 5000 downloads of the file 'authorized' by http://www.someisp.invalid/~ted/Metallica.mp3," there exists a much more compelling motive for the RIAA to go after that single user than if it were 5000 downloads from 2784 different Napster users. Admittedly, it still fails the "go for the deep pockets" law suit rule, but it's at least better than before.
I admit that it's not perfect. But it is, at least, a potential idea to partially fit the difficult constraints of the problem in question.
through posting it to slashdot, you will overwhelm and outpace the sincere efforts to patch the problem that are being undertaken by the hapless victims.
However, to quote DoubleClick's Chief Privacy Officer (as listed in the story above), "Over the last week there have been unsuccessful attempts made to hack into DoubleClick's servers. Those situations were immediately corrected,". So everything's fine and good.
Besides, one could make the argument that leaving a known insecure system on the Net is at least mildly irresponsible. Leaving a known insecure system on the Net that contains all kinds of personal information about a lot of "customers" (which may or may not be the case; weeding through PR garbage is useless) is downright moronic and deserves to get them as much negative attention as necessary to convince them to correct the problem.
So I had this really great (well, maybe not great, but funny) idea of flooding the RIAA with opt-in requests by various indie artists (pronounced: Slashdot users with microphones) for their various songs (pronounced: renamed source "forks" of RMS's Free Software Song).
The one tiny problem is that RMS, who I had always pegged as being overly idealistic to the extreme, failed to place his song under the GPL. Instead, you're only allowed verbatim copying and distribution of the original article linked above (with no mention of whether or not you may produce recordings of the song, provided that you make the original sheet music still available).
So, instead, I offer the following (admittedly imperfect) lyrics distributed under the LGPL (for convenient mixing with commercial songs). If you have a problem with them, you're more than welcome to fork-and-fix.
We don't like all this opt-in stuff. It speaks of serious collusion. There's more to music than comercial fluff, Hillary Rosen is suffering from delusion.
This song is just a half-assed protest, it may not become a geek war cry. But putting aside all bits of jest, at least we did something to try.
Thanks to the Supreme Court decision in Campbell v. Acuff-Rose Music, Inc. we can create a spoof full of derision and stuff the cease-and-desist down the sink:
All our music fades to grey, getting further from us every day, as the RIAA marches on, soon the music might as well be gone *insert guitar riff here*
The RIAA attempts once more, to prepare for this copyright war and if we don't settle the score they'll continue suing forever more...
It could turn into an interesting registration system
How about requiring a copy of the mp3 to be published on a web server? This would provide some degree of traceability, but at the same time would still allow Napster to provide distributed serving (great if you're using a bandwidth-restricted web server) and "similar interest" sharing (I've noticed that Ted likes a lot of the same music I like; let's see what he has that I haven't heard of before).
I freely admit that it's less-than-ideal, but it does kinda solve a few of the problems. Personally, however, I'm not gonna cry if Napster crashes and burns. I've more or less given up caring after mp3's BeamIt system got neutered -- they had a system that had a predominantly fair use purpose and had taken fairly conscientious steps to minimize its usability for piracy.
Next time your knee jerks, don't let it hit you in the head and cause brain damage.
Amen! I think from now on, all Slashdot readers should restrict their commentary to the actual subject at hand and should adamantly refuse to speculate on the potential consequences of an action or to provide arguments for or against a later decision based on that action.
Thus, I will provide the following "safe" topics of discussion:
So who at the RIAA actually filed the court order?
Did they use good penmenship?
Oh wow! Another Hillary Rosen quote.
I, of course, will be anxiously awaiting the Slashdot story "Judge Deliberates On Previously Mentioned RIAA Request", so that people can finally post about such interesting topics as the potential restraint of trade.
As far as anyone can tell, this code does not propagate itself over the internet at all. It spreads to other applications on the same machine.
Err, last I checked, that pretty much made it a virus. Check out the alt.comp.virus FAQ, specifically question 3. This code hits all of the criteria. It's worth pointing out that merely infecting applications on the same machine is how a lot of older viruses (before the Windows-based email worms became popular) spread themselves. This is, more or less, one of the "classic" virus types.
Furthermore, while I don't disagree that the built-in security of Unix greatly restricts the flow of viruses, a cross-platform virus could wreak some serious havoc. A quick "find ~ -name \*.exe -print | wc -l" indicates that I've got 42 DOS executables sitting in my home directory. Some of these are for DOSemu, some are old files that'll never get run again (leftover CGIs from when work's website was NT-based), and a few sets of drivers that I downloaded for machines I was fiddling with. While I probably don't have anything to worry about in this case, it's not that hard to abstract it out to a case where it would spread.
Finally, even if the virus completely failed to spread on any and every Linux platform (which, IMO, is overly optimistic), its behavior on Windows would still classify it as a virus.
The more dangerous one would be if you were logged in as root with your windows drives mounted.
Why root? On an "everyday" system that has a lot of data crossing between Windows and Linux, it makes sense to give your regular user account read/write access to at least one Windows partition (as opposed to having to su to root every single time you want to copy a file). Out of convenience/laziness/whatever, this'll usually wind up resulting in read/write access to all the Windows partitions.
Ideally, I'd be able to specify read/write access to data and read-only access to the directories with program files. But between the fact that it's a VFAT partition and the fact that Windows likes to mix data, programs, and all sorts of other crap together, the grief would easily exceed the value.
I remember dragging my system, and my Midi cables, over to a friends house in 87 to play MidiMaze. The first LAN party!
Seven whole years earlier, Flash Attack was doing multi-machine head-to-head competition (although it wasn't an FPS) on the Commodore PET. I was into Apple ][s at the time, but played the later port that ran via MajorBBS.
Besides, you can't use cell phones in flight because they'll see too many cells at once from way up there.
If you had read the article, you'd know that the thing NASA is using is actually a satellite phone, so it shouldn't have that problem. The term "cell phone" apparently got added to the story in an effort to explain it to the masses.
I realize some people have "Less than Optimal" systems for gaming, and some hardware has some pretty bad support for DirectX, but any decent hardware is going to have good DirectX support
Just to add the this point, it wasn't that long ago that you had to worry about every single game/program supporting your hardware. As much as I dislike some of the things Microsoft has done, I really can't argue with how much easier game configuration has gotten. Gone forever are the days of having to continuously remember (and tell each game) that your SBPro was installed on IRQ 7, I/O address 220, DMA 1.
Re:Console factionism (a bit offtopic, but hey...)
on
XBox Tidbits
·
· Score: 1
I always wonder why a group of grown-ups on higher-than-average salaries want to bitch about which console will be best, fastest, make them look hard with their mates etc.
First off, the average salary of the Slashdot readership, as determined via the ultra-scientific, potentially patent-infringing polls is "CowboyNeal".
Slightly more seriously, the price of a console system is still a decent chunk of change, especially when multiplied across buying all the systems. Hell, the whole point beyond economic theory is that you must decide how to allocate finite resources. Even for someone with a higher paying job (where it's not an issue of "Playstation 2" versus this week's groceries), it's still a potential trade off between a Nintendo 64 versus another $99 toward a kick-ass surround-sound system or a harddrive upgrade for a TiVo or...
And that's ignoring all the Slashdot readers who're still in High School or College or who have kids to feed or...
I fall firmly into the "debuggers are a seductive waste of time" category. The effort of guessing what is wrong is good training that gives you more awareness and control of your programs.
I consider myself very good at understanding what's going on in the computer and then using that model to extrapolate back to what part of my code is buggy. I'll agree that the in-depth step-by-step debugging is a seductive time suck, but using the debugger to get a stack trace on where a non-trivial program core dumped has been insanely useful to me. That single bit of information, which requires almost no effort to produce (and only slightly more effort if we increase the likelyhood of it pointing at the true culprit by compiling with ElectricFence or a similar utility), is usually enough to make my mental model churn out a solution to the problem.
Not that I believe it's particularly relevant in this case (given that anything that they contribute to the Linux kernel at large would be in source form), but I believe you're referring to Ken Thompson's classic article Reflections on Trusting Trust. This is a must-read for anyone interested in computer security.
Machines on always-on connections are no more vulnerable than machines on dial-up. However, these machines are more likely to be attacked because they always have a network connection.
Well, yes and no. I know with a dial-up box, I'm less vulnerable to extended attacks (the evil cracker rooted my box, installed 12 backdoors, but couldn't find it again) and I'm more likely to notice an attack in progress (gee, the modem lights're blinking even though I'm not downloading anything).
However, that being said, dynamic IP "security" should be lumped into the same boat as "security through obscurity" -- all other things being equal, they help (admittedly, I'm stretching that "being equal" a bit to cover an equal amount of scrutiny for the obscured procedure as it would've gotten out in the open), but it's considered very bad form to rely on them as actual security.
Re:What the hell is this all about?
on
Hacking Biology
·
· Score: 2
They're trying to clone a Spice Girl? I don't understand.
SPICE is a circuit simulator used by the EE types to design circuits.
Why would you put a system with casters on top of your desk, out of curiosity? I keep my tower under the desk.
Well, mainly because what I wrote wouldn't have been nearly as silly otherwise. It was mostly tongue-in-cheek. However, I do think that it'd be easy enough to just load your case on to one of those little wheeled carts people use for luggage, rather than trying to add casters to the case.
Slashdot Mirror
This raising an interesting issue: What happens if a web browser fails to properly display a disclaimer (or other legal document)? For example, suppose the main site uses javascript to pop up the legalese. Further suppose that I browse the web with javascript disabled. So when I click on the link that says, "Click here to view limitations of the offer", am I able to interpret the lack of any limitations appearing on my screen as a complete lack of any limitations on the offer? What if I do have javascript enabled, but the text isn't displayed (or is displayed blank) due to an error in the web browser's interpretation of javascript?
In addition to being too obvious, they were also a little too prolific. If you tell someone, in quick succession, that there's a spider on their back, aliens have just landed, and Elvis has just come out of hiding, then they aren't going to believe you when you claim something vaguely plausible, such as George W. signing an executive order mandating prayer in school as a means of dealing with school violence.
Besides, as I pointed out in this post in the "Slashdot During War?" thread, a number of the "legitimate" AskSlashdot's have been more absurd than the April Fool's Day ones.
Hell, if it weren't for the fact that the "What isn't on the Internet?" question claims "I have *never* not found anything I've searched for" (with a few exceptions), I would've pegged it as a normal, legitimate question (especially given that it got at least one serious, insightful reply here, talking about the lack of scientific papers that're available. It's just hard to peg a legitimate question with a legitimate answer as an April Fool's joke.
As a form of protest, I will be boycotting Slashdot, PT Cruisers, News, Nerds, Free Registration at the New York Times, Futurama (for shamelessly naming one of their characters after a SlashCode release), and Disney (What's a boycott if you don't include Disney?).
Furthermore, my boycott shall continue until one of the following conditions is met:
Wil Wheaton, of course.
Define "April Fool's joke". Are we talking about an Ask Slashdot that's so unbelieveably stupid, inane, or silly that there's no way it could be taken seriously?
If so, I'd like to point out the following non-April 1st "Ask Slashdot" entries:
Given that the "Slashdot during War" AskSlashdot is less absurd than some of the "legitimate" AskSlashdot's and could (potentially) serve as a catalyst for worthwhile discussion, the question becomes just who pulled a prank on whom?
Or, to put it more simply, is trolling trolls really trolling? How much wood would a woodchuck chuck if a woodchuck could chuck wood? Who is John Galt? What's keeping Godot? If a tree falls in the woods, will it knock out my Internet connection?
Most-to-all of the changes between 2.4.0 and 2.4.3 should be bug fixes (include an ext2 corruption bug, IIRC) and minor updates. Feature-wise, it should be mostly the same.
As far as the first point goes (increased bandwidth due to users downloading the song left and right), I think you misunderstood my proposal. The web instance of the song would exist only to get authenticated via Napster. (Unless the person running the website chose to publish that address separately, possibly with the help of Napster -- in short, it'd be almost like your "real" email address entry for Slashdot; other users know it exists, but can't get to it.) So regular user downloads would take place via the traditional P2P mechanisms. However, when a Napster user's client goes to try and share the song, it'd send up an md5 hash (which, admittedly, would open the system to spoofing -- however, one could argue this is more robust than the current name-based system; as an added bonus, it could auto-name mp3s based on what the authenticator provided). That md5 hash gets checked by the Napster server to make sure it's in the database. If it gets a match, the song is considered okay for sharing (possibly with an extra info link for people to find out about the authenticator and his/her other authenticated songs -- this might be useful for someone who's authenticating, say, a large collection of copyright-expired music in a genre you're interested in).
The second point (the "I was hacked" defense) is one that I really don't have a good answer to. The best I can do is point out that someone could do the same thing with a web or FTP server that was acting as a direct-access illegal mp3 drop, and then do some handwaving, mumble a bit, hope it doesn't happen, and move on to the next point.
As for the third point (the "tax" of having a web site), I admit it's a problem. One solution might be to provide a number of alternatives for a copyright holder to provide authorization. There's also the possibility of using a service such as mp3.com as your hosting site -- if I'm not mistaken, it's free for non-premium users. While it wouldn't normally be in mp3.com's best interests to serve as an authorization drop-box for Napster songs, if we couple it with the earlier idea of having a link to the authorizing agent's site for each song, we suddenly have a means for mp3.com to help generate traffic back to their own site. Finally, the cost of a website would probably a lot cheaper than, say, the cost of officially registering your song on the RIAA opt-in list (and the latter wouldn't necessarily be open to people trading bootlegs of bands that don't object to recordings of their live shows).
On the fourth point (more bandwidth constraints and having the RIAA double-check authentication sites), you could greatly reduce bandwidth by having the song downloaded only once, with the HTTP ETag header being saved. From then on, it's just a simple HTTP HEAD request to verify the ETag (just like how browser caching works). No muss, no fuss, and bandwidth usage that (except for the initial retrieval) wouldn't even be noticeable.
As for your final "why bother with Napster, then?" comments, I do admit that it greatly reduces a lot of Napster's appeal. However, it does still provide two benefits: Bandwidth usage reduction (since people're still getting the songs via P2P) and shared interests/recommendations (where you see other songs you haven't heard before while browsing the shares of someone with similar interests).
1 - The system would be a little less transient in nature. Napster users log in and out all the time. In theory, a file on a dedicated, stable web server would be verifiable at multiple times during the day, etc.
2 - The system would defer some of the blame. By only providing a distributed, selective "cache" for files that're out on the web, Napster has a better chance at convincing the RIAA to go after a web site.
3 - The system would cluster lots of blame on a single user. If Napster can say, "There were 5000 downloads of the file 'authorized' by http://www.someisp.invalid/~ted/Metallica.mp3," there exists a much more compelling motive for the RIAA to go after that single user than if it were 5000 downloads from 2784 different Napster users. Admittedly, it still fails the "go for the deep pockets" law suit rule, but it's at least better than before.
I admit that it's not perfect. But it is, at least, a potential idea to partially fit the difficult constraints of the problem in question.
However, to quote DoubleClick's Chief Privacy Officer (as listed in the story above), "Over the last week there have been unsuccessful attempts made to hack into DoubleClick's servers. Those situations were immediately corrected,". So everything's fine and good.
Besides, one could make the argument that leaving a known insecure system on the Net is at least mildly irresponsible. Leaving a known insecure system on the Net that contains all kinds of personal information about a lot of "customers" (which may or may not be the case; weeding through PR garbage is useless) is downright moronic and deserves to get them as much negative attention as necessary to convince them to correct the problem.
The one tiny problem is that RMS, who I had always pegged as being overly idealistic to the extreme, failed to place his song under the GPL. Instead, you're only allowed verbatim copying and distribution of the original article linked above (with no mention of whether or not you may produce recordings of the song, provided that you make the original sheet music still available).
So, instead, I offer the following (admittedly imperfect) lyrics distributed under the LGPL (for convenient mixing with commercial songs). If you have a problem with them, you're more than welcome to fork-and-fix.
LameAnti-RIAASong, v0.1 (Proof-of-concept prototype)
Contributors: Cameron Perkins, DeAnna Janecek, Stevie Strickland
We don't like all this opt-in stuff.
It speaks of serious collusion.
There's more to music than comercial fluff,
Hillary Rosen is suffering from delusion.
This song is just a half-assed protest,
it may not become a geek war cry.
But putting aside all bits of jest,
at least we did something to try.
Thanks to the Supreme Court decision
in Campbell v. Acuff-Rose Music, Inc.
we can create a spoof full of derision
and stuff the cease-and-desist down the sink:
All our music fades to grey,
getting further from us every day,
as the RIAA marches on,
soon the music might as well be gone *insert guitar riff here*
The RIAA attempts once more,
to prepare for this copyright war
and if we don't settle the score
they'll continue suing forever more...
(Quoth Lars Ulrich, "...ever more.")
How about requiring a copy of the mp3 to be published on a web server? This would provide some degree of traceability, but at the same time would still allow Napster to provide distributed serving (great if you're using a bandwidth-restricted web server) and "similar interest" sharing (I've noticed that Ted likes a lot of the same music I like; let's see what he has that I haven't heard of before).
I freely admit that it's less-than-ideal, but it does kinda solve a few of the problems. Personally, however, I'm not gonna cry if Napster crashes and burns. I've more or less given up caring after mp3's BeamIt system got neutered -- they had a system that had a predominantly fair use purpose and had taken fairly conscientious steps to minimize its usability for piracy.
Amen! I think from now on, all Slashdot readers should restrict their commentary to the actual subject at hand and should adamantly refuse to speculate on the potential consequences of an action or to provide arguments for or against a later decision based on that action.
Thus, I will provide the following "safe" topics of discussion:
I, of course, will be anxiously awaiting the Slashdot story "Judge Deliberates On Previously Mentioned RIAA Request", so that people can finally post about such interesting topics as the potential restraint of trade.
Err, last I checked, that pretty much made it a virus. Check out the alt.comp.virus FAQ, specifically question 3. This code hits all of the criteria. It's worth pointing out that merely infecting applications on the same machine is how a lot of older viruses (before the Windows-based email worms became popular) spread themselves. This is, more or less, one of the "classic" virus types.
Furthermore, while I don't disagree that the built-in security of Unix greatly restricts the flow of viruses, a cross-platform virus could wreak some serious havoc. A quick "find ~ -name \*.exe -print | wc -l" indicates that I've got 42 DOS executables sitting in my home directory. Some of these are for DOSemu, some are old files that'll never get run again (leftover CGIs from when work's website was NT-based), and a few sets of drivers that I downloaded for machines I was fiddling with. While I probably don't have anything to worry about in this case, it's not that hard to abstract it out to a case where it would spread.
Finally, even if the virus completely failed to spread on any and every Linux platform (which, IMO, is overly optimistic), its behavior on Windows would still classify it as a virus.
Why root? On an "everyday" system that has a lot of data crossing between Windows and Linux, it makes sense to give your regular user account read/write access to at least one Windows partition (as opposed to having to su to root every single time you want to copy a file). Out of convenience/laziness/whatever, this'll usually wind up resulting in read/write access to all the Windows partitions.
Ideally, I'd be able to specify read/write access to data and read-only access to the directories with program files. But between the fact that it's a VFAT partition and the fact that Windows likes to mix data, programs, and all sorts of other crap together, the grief would easily exceed the value.
This reminds me of a news soundbite about one of the recent school shooters: "Even the picked-on kids picked on him."
Seven whole years earlier, Flash Attack was doing multi-machine head-to-head competition (although it wasn't an FPS) on the Commodore PET. I was into Apple ][s at the time, but played the later port that ran via MajorBBS.
If you had read the article, you'd know that the thing NASA is using is actually a satellite phone, so it shouldn't have that problem. The term "cell phone" apparently got added to the story in an effort to explain it to the masses.
Just to add the this point, it wasn't that long ago that you had to worry about every single game/program supporting your hardware. As much as I dislike some of the things Microsoft has done, I really can't argue with how much easier game configuration has gotten. Gone forever are the days of having to continuously remember (and tell each game) that your SBPro was installed on IRQ 7, I/O address 220, DMA 1.
First off, the average salary of the Slashdot readership, as determined via the ultra-scientific, potentially patent-infringing polls is "CowboyNeal".
Slightly more seriously, the price of a console system is still a decent chunk of change, especially when multiplied across buying all the systems. Hell, the whole point beyond economic theory is that you must decide how to allocate finite resources. Even for someone with a higher paying job (where it's not an issue of "Playstation 2" versus this week's groceries), it's still a potential trade off between a Nintendo 64 versus another $99 toward a kick-ass surround-sound system or a harddrive upgrade for a TiVo or...
And that's ignoring all the Slashdot readers who're still in High School or College or who have kids to feed or...
I consider myself very good at understanding what's going on in the computer and then using that model to extrapolate back to what part of my code is buggy. I'll agree that the in-depth step-by-step debugging is a seductive time suck, but using the debugger to get a stack trace on where a non-trivial program core dumped has been insanely useful to me. That single bit of information, which requires almost no effort to produce (and only slightly more effort if we increase the likelyhood of it pointing at the true culprit by compiling with ElectricFence or a similar utility), is usually enough to make my mental model churn out a solution to the problem.
Not that I believe it's particularly relevant in this case (given that anything that they contribute to the Linux kernel at large would be in source form), but I believe you're referring to Ken Thompson's classic article Reflections on Trusting Trust. This is a must-read for anyone interested in computer security.
Well, yes and no. I know with a dial-up box, I'm less vulnerable to extended attacks (the evil cracker rooted my box, installed 12 backdoors, but couldn't find it again) and I'm more likely to notice an attack in progress (gee, the modem lights're blinking even though I'm not downloading anything).
However, that being said, dynamic IP "security" should be lumped into the same boat as "security through obscurity" -- all other things being equal, they help (admittedly, I'm stretching that "being equal" a bit to cover an equal amount of scrutiny for the obscured procedure as it would've gotten out in the open), but it's considered very bad form to rely on them as actual security.
SPICE is a circuit simulator used by the EE types to design circuits.
Well, mainly because what I wrote wouldn't have been nearly as silly otherwise. It was mostly tongue-in-cheek. However, I do think that it'd be easy enough to just load your case on to one of those little wheeled carts people use for luggage, rather than trying to add casters to the case.
Assuming s/coasters/casters/, it sounds like a great idea until you manage to push your computer off of your desk while trying to eject a floppy.