First, kudo's on your careful quoting, you just don't see that enough on slashdot. Secondly, I guess we're in broad agreement on the key points: total bans against a technology per se is dumb and the GPL v.3 needs to be better worded.
I think though I can imagine non-evil situations where it would be good for even an Administrator to accept 3rd party restrictions on data: for example, a distributed computing project where the 3rd party project mangers wanted to guard against data tampering or duplication. SETI@home solved this problem in other ways, for example by leveraging its huge user base to process blocks multiple times, but you could imagine that DRM might help with that. Or giving researchers limited access to medical data: after an ethics committe approves their project, a research team could be sent a DRM'd copy of $Hospitals complete medical records to data mine, but they can't pass those records on to another unapproved group, except in piecemeal fashion, or perhaps access could be automatically expired at the end of the investigation, reducing the likliehood of a privacy leak.
I guess what I'm trying to say is that even trying to specify non-technical effects and ends might prove horribly difficult and perhaps better suited to other forums, such as legislative efforts, than the GPL.
I think it's also worth noting that at CES, there was a panel of congressmen discussing digital rights issues, all of whom happened to be Republicans, and all of whom seemed to agree the DMCA was flawed, in that it didn't accomodate Fair Use properly, and were thinking about legislative changes, so the GPL v.3 language may end up being moot anyway.
But the difference between public and private is purely contextual, external to any technology involved: there may be a big difference between using a video camera in your home and the use of surveillance cameras in public spaces, for example, but the basic technology is the same. And so, any blanket approach to DRM, which fails to take into account the context in which the technology may be applied, raises significant questions as to its general applicability and utility.
But you're right: the market will choose: the proof here will be in the rate of adoption of v.3 licenses and software. Personally, I suspect v.2 software will be alive and kicking for some time. Just as most people do choose to use ISPs that enforce DRM on email users, and do rely on DRM-enabled systems to maintain their security and privacy, and look dimly any system that doesn't enable DRM, a la Stallman's apparantly cherished ITS.
I agree the GPL v3 does not cover unix permissions -- but I believe this is because v.3 doesn't actually prohibit any DRM, beyond attempting to torpedo anyone attempting to apply the DMCA in relation to GPL v3 code. However I'm still not sure that any real technical difference does exist between DRM schemes and, e.g. unix permissions, and that the difference is purely social. In a similar manner, both awful EULAs and the GPL rest on the same legal foundation -- they're all licenses, a form of Legal Rights Management. I agree some DRM may be odious and deserving of opposition, just not on technical grounds (saving that which can be demonstrated to be technically identical to malware), but time will tell -- so long as DRM is not defined circularly: "We disgree with DRM. DRM is any method of preventing reading and/or writing bits that we disagree with."
As for 2) well, the Linux kernel -- about which Linus has already made his position on DRM clear -- may be the proof of the pudding there. In fact, it appears that much of the motivation for the v.3 language was because people were making succesful products (.e.g Tivo) that met the GPL requirements but which enabled 'bad' DRM. Again, time will tell which of us is right.
Anyhow, nice to have a discussion that didn't devolve into a flame war! Cheers.
I'm not speaking about the precise language of the v.3 draft, which as noted has very little to say of substance about DRM except for the DMCA issue, but about comments from FSF spokespersons, such as Moglen, or Stallman, where I haven't seen any attempt to distinguish between good and bad DRM -- or even acknowledge that such a thing as good DRM might exist. And the statements use of of the word "user" is unhelpful too: I'm a user on an email system, but I can't turn off the good DRM that stops me from reading everyone else's mail. If user is really meant to mean "owner or administrator", why did Stallman deliberately leave out support for the 'wheel' group in the GNU implementation of su?
Okay, now see, that's a useful technical distinction, whatever your personal comfort level on, say, iTunes is (personally, I'm fine with it), -- there's good DRM and there's bad DRM. But notice that it's still all DRM, and also note the FSF seems reluctant to draw distinctions between Good and Bad DRM, instead referring to DRM in exclusively negative, monolithic terms. While the GPL v3 draft doesn't really appear to put any teeth into this position, beyond an attack on the DMCA, I'm struggling to see how the FSF can be seen to be opposing all DRM, even the good kind, and not run afoul of the standard security provisions we all expect.
Sure, Apple will tell you today how to get root, but they could stop doing so tomorrow if they wished, and I'd be right back to relying on a 3rd party to circumvent those permissions. And even if CSS keys became freely available, CSS software would not magically stop being DRM software.
The intent of permissions vs. the intent of CSS is not the issue. The issue is whether or not all DRM is bad. You're making an interesting case that would allow people to distinguish between good DRM and bad DRM (and so perhaps engage in useful lobbying against the later), but not that permissions are instrinsically technically seperate from DRM -- as you point out, your argument for differentiation substantively relies on "legal issues" not technical ones. In my examples of Apple above concealing the root instructions and CSS keys becoming available, not a bit of software has changed, but they've still swapped places on the good/bad divide due to factors entirely external to the software. Thus attempting to 'hardcode' anti-DRM language into a universal software license seems problematic, and more a relic of AI Lab thinking, circa 1970, than something appropriate for the networked world.
Comparable as in "You can compare them", not comparable as in "Pretty much exactly the same".
Comparable as in "Most consumers using an external hard drive aren't really going to notice a difference between Firewire and USB 2.0" A really big transfer for most consumers would be, for example, a complete back up of their iTunes library. Say that takes 10 minutes with Firewire. Granting you as much as 20% difference in speed, which would mean a lot to an enteprise user, or hard core techie, for the consumer that translates to an 12 minute transfer on USB 2.0, which just isn't enough of a difference to matter, especially since the consumer wandered off make a cup of tea round about minute 2 anyway.
I don't know about you, but I want a machine that runs at it's best _now_
I guess we're talking past each other, because I'm explicitly talking about the future of USB and firewire, not as things stand today. And I'm not talking about Moore's law as an "analogy": I'm talking about Moore's law directly in its economic context: technical elegance is nice, but it's far from the determining factor about which technology is best, particularly when that translates into concrete decisions such as which chipsets should a manufacturer put into a device, or which combination of features represents the best value hardware buy for my money.
But in any case, no one cares what numbers say the performance should be, what matters is what the performance actually _is_
Almost, but not quite. What matters is what the performance actually is relative to people's actual needs. If performance was the only factor, screw Firewire, I'm going straight to fiber-optics! For most people, USB 2.0 already offers more than good enough performance, is cheaper than Firewire (because of the manufacturing economies of scale if nothing else) and will soon be available in a wireless flavor.
It's worth noting that FireWire 400 is present and accounted for on the MacBook Pro, so no need for USB->FireWire dongle adapters. Yet.
You're right, I should have written "future" instead of "new," as I meant "new" as in the next rev, not the current crop being released. In any case, I think it'll linger on in prosumerville, in much the same way that I have a minidisc recorder.
I don't know what implementation of Firewire and USB your external hard drive and/or computer is using, but it's doing a poor job of at least one of them: according to the specs, Firewire 400 should deliver 400 Mb/s vs USB 2.0 480 Mb/s. True, compression, etc, can skew those numbers, but the speed is comparable. (And sure, there's Firewire 800, but the only 800 port I have is on my Powerbook and I've never plugged anything into it ever in two years or so of daily use.) Even if USB does eat up more CPU cycles, it won't matter to most users given the economics of Moores' Law. But I do agree Firewire will be around for a long time for users with specific needs -- but not in a standard, every-computer-will-have-one mass market way that USB will be, in the same way that today I have a minidisc recorder for my specific job needs, but CD players/burners are what you'll find on every machine. Or how, say, SCSI never became much more than a niche high-end player.
Yes, but the only place I've ever seen a Firewire 800 port is on my 15" Powerbook and in two years I haven't used it once. Most consumers don't access terabytes of data -- if they can pull data across the wire fast enough to, say, watch High Def quality video in real time, they're happy. Hence the economic incentive for hardware that supports higher data rates is greatly diminished. It's not a technical issue, it's an economic one, and the economics seems to indicate that Firewire will go the way of classic SCSI -- lingering on, but a niche player, like minidiscs or MIDI. Plus, as I mentioned, Firewire doesn't come in a wireless flavor. At CES I saw wireless USB kit that's available today.
I think that's exactly what they're doing -- the most recent iPod rev doesn't have a Firewire interface for example. It seems that USB 2.0 may have eaten Firewire's lunch -- speeds are comparable, and -- as of pretty recently -- USB comes in a wireless flavor. Even when Firewire was going gangbusters, not every machine (I'm speaking now in the broader universe of all consumer computers, desktop and laptp, not just Apple Powerbooks) had Firewire, but they all had USB. I suspect that firewire will stick around for certain applications, but that if you really want to use it with new Mac laptops, you'll need a Firewire-USB dongle adapter.
I think part of the difficultly in finding an optimum solution (or least-pessimistic solution perhaps) is that you may be running together two problems, which both manifest the same symptoms -- people endlessly bitching about submitters in the story comments -- but actually have different causes.
Beatles Beatles is in one problem set: a submitter sends in reasonably well-written, blurbs with direct and relevant links. The only fly in the ointment is that he links his name back to a web site that raises the hackles of slashdot readers who believe he's Googlewhoring for Fun and Profit, and thereby gaining an unfair advantage over Joe Slashdot. I think the solution there is to keep an eye on people who've had a lot of stories accepted, and try to make sure that, going forward, those stories you accept from them really are just the ones that he/she, and he/she alone, have uniquely submitted. Even though slashcode's weakness when it comes to searching could make implementing this less than perfect, any attempt at it would reduce the howls of "Hey -- why does XYX get another PageRank boost over me when I submitted the same story!"
I realize this policy could be seen a punishing "good submitters" -- why shouldn't you have the at least same chance as getting random story X published as a dozen other submitters, many of whom may never have contributed to the community before, if you're a good submitter? -- but good submitters will still get their unique stuff up there (and if they're really good, this will translate to a fair number of stories accepted), and you're increasing the number of voices that are being heard, always a good thing on a community driven site (other venues, such as blogs, do exist if I really want to hear one specific person's take on things.)
Roland is in the other problem set: there the objection is that the links within the blurbs themselves are not so direct and relevant, but place an annoying layer of intermediate submtter opinion that doesn't add anything of substanstance to my understanding of the story or its context. (and my needs for superficial submitter opinion are ideally already satisfied by the blurb:) ). Dealing with this is trickier -- some Blogs can add substantial value to a raw link and should be granted their intermediary position, while others Just Don't and readers would be better served with a direct link. However, assuming there are no other submissions availble with a direct link, I don't think you should just take the link, bin the submssion, write up your own blurb and post it with no attribution.
Instead, for links to things like blogs which are commentaries on some further linked item (rather than original content, a la Russinovich's infamous Sony BMG DRM post), you could make it a policy -- as part of the normal "submission clean up" process -- to add a direct link to the ultimately linked item into the blurb. Those that want to read the commentary can do so, others can bypass it.
I guess what I'm saying is that the solutions are to be found not in the realm of tech fixes, such as nofollow tags or even more baroque meta-uber-moderation constructs, but in non-technical things like editorial policies and judgement that relate do directly to the value you deliver to Slashdot readers I which I think is entirely within your remit and avoids some of the issues you've been concerned about in other threads.
This is completely OT, but I didn't want to undo my moderation in the "Gender Gap in Computer Science" thread. I just wanted to say your well-articulated insight into the issue was appreciated. Cheers.
Well, let me see. There was a) the complete and utter disregard for the basic laws of physics and large chunks of biology (see Phil Plait's Bad Astronomy site for more), b) the retread of plot elements from 2001:A Space Odyssey and many other places, c) the plot holes (Why would the aliens go to another Galaxy when Mars was threatened? Why not go live on Earth, instead of just stopping by to drop spores all over it? Also, why have an astronaut killing defense system at all?) d) the aforementioned poor acting (with the honorable exception of Don Cheadle who gave it the old college try) -- it's not that the cast are bad actors per se, but these weren't great performances -- and e) stodgy dialogue.
Because even bullshit costs a hellava lot more money when produced by professionals. Consider, say, Mission to Mars, which is my standard example of Worst Movie Ever. However, lets ignore the wooden acting, bland direction and painful script for now. All the actors are in focus. They all have competently applied make up. The picture isn't grainy. You can't see any plywood poking out from behind the fairely extensive sets. The costumes look realistic. The audio is fine: you can hear the actors' lines without the music, sound effects, or ambiant noise drowning them out. There's a score. The custom 3-d modelling is competent. You can't see bits of camera equipment or sound booms in the frame, and so on. Sadly the same can't be said for many things put together with a DV and a bootleg copy of Final Cut. Just to to reach a minimal production threshhold costs money: professionals aren't cheap.
Anyhoo, I suspect that your idea of what's crap may not exactly match up with what's mine, or others', raising the question of which 60% gets cut. I suspect that a lot of crap is actually responsible for some of the highest profits in the industry, so the exec's wouldn't exactly be saving billions in any case.
An apropos 1796 reference? I had considered trying to go as far back as the great Airship Hysteria of 1896-7, but couldn't link it mind control. I tip my hat to you sir!
I believe the tinfoil hat thing is a manifestation of one of the broader charateristic delusions of paranoid schizophrenia, i.e. that external forces are controlling one, or inserting thoughts directly into one's mind. Different manifestations pop up depending on the milieu: today it's radio signals from government controlled satellites, but in the late 1940's Shaver's tales of "Dero rays" being emitted by a race of evil subterranean dwellers proved a popular framework for the delusion.
You know, to be fair, I tried this last weekend, and it worked. I was halfway through upgrading my win98 box to XP when the installer borked (I think because of an odd CD-ROM setup I have). As we all know, this is usually the worst possible moment for something to go wrong, as the system is between two (theoretically) stable configurations, but when I crossed my fingers and rebooted the machine, I was given a useful(!) error message, that gave me a clue as to the problem, a suggested work around, and the option to restore my Win 98 system. To my surprise my old system restored perfectly, I was able to set up the work around, and then installed XP with no more problems. It didn't even try to beat up on my GRUB loader.
Slashdot Mirror
First, kudo's on your careful quoting, you just don't see that enough on slashdot. Secondly, I guess we're in broad agreement on the key points: total bans against a technology per se is dumb and the GPL v.3 needs to be better worded.
I think though I can imagine non-evil situations where it would be good for even an Administrator to accept 3rd party restrictions on data: for example, a distributed computing project where the 3rd party project mangers wanted to guard against data tampering or duplication. SETI@home solved this problem in other ways, for example by leveraging its huge user base to process blocks multiple times, but you could imagine that DRM might help with that. Or giving researchers limited access to medical data: after an ethics committe approves their project, a research team could be sent a DRM'd copy of $Hospitals complete medical records to data mine, but they can't pass those records on to another unapproved group, except in piecemeal fashion, or perhaps access could be automatically expired at the end of the investigation, reducing the likliehood of a privacy leak.
I guess what I'm trying to say is that even trying to specify non-technical effects and ends might prove horribly difficult and perhaps better suited to other forums, such as legislative efforts, than the GPL.
I think it's also worth noting that at CES, there was a panel of congressmen discussing digital rights issues, all of whom happened to be Republicans, and all of whom seemed to agree the DMCA was flawed, in that it didn't accomodate Fair Use properly, and were thinking about legislative changes, so the GPL v.3 language may end up being moot anyway.
But the difference between public and private is purely contextual, external to any technology involved: there may be a big difference between using a video camera in your home and the use of surveillance cameras in public spaces, for example, but the basic technology is the same. And so, any blanket approach to DRM, which fails to take into account the context in which the technology may be applied, raises significant questions as to its general applicability and utility.
But you're right: the market will choose: the proof here will be in the rate of adoption of v.3 licenses and software. Personally, I suspect v.2 software will be alive and kicking for some time. Just as most people do choose to use ISPs that enforce DRM on email users, and do rely on DRM-enabled systems to maintain their security and privacy, and look dimly any system that doesn't enable DRM, a la Stallman's apparantly cherished ITS.
I agree the GPL v3 does not cover unix permissions -- but I believe this is because v.3 doesn't actually prohibit any DRM, beyond attempting to torpedo anyone attempting to apply the DMCA in relation to GPL v3 code. However I'm still not sure that any real technical difference does exist between DRM schemes and, e.g. unix permissions, and that the difference is purely social. In a similar manner, both awful EULAs and the GPL rest on the same legal foundation -- they're all licenses, a form of Legal Rights Management. I agree some DRM may be odious and deserving of opposition, just not on technical grounds (saving that which can be demonstrated to be technically identical to malware), but time will tell -- so long as DRM is not defined circularly: "We disgree with DRM. DRM is any method of preventing reading and/or writing bits that we disagree with."
As for 2) well, the Linux kernel -- about which Linus has already made his position on DRM clear -- may be the proof of the pudding there. In fact, it appears that much of the motivation for the v.3 language was because people were making succesful products (.e.g Tivo) that met the GPL requirements but which enabled 'bad' DRM. Again, time will tell which of us is right.
Anyhow, nice to have a discussion that didn't devolve into a flame war! Cheers.
I'm not speaking about the precise language of the v.3 draft, which as noted has very little to say of substance about DRM except for the DMCA issue, but about comments from FSF spokespersons, such as Moglen, or Stallman, where I haven't seen any attempt to distinguish between good and bad DRM -- or even acknowledge that such a thing as good DRM might exist. And the statements use of of the word "user" is unhelpful too: I'm a user on an email system, but I can't turn off the good DRM that stops me from reading everyone else's mail. If user is really meant to mean "owner or administrator", why did Stallman deliberately leave out support for the 'wheel' group in the GNU implementation of su?
Okay, now see, that's a useful technical distinction, whatever your personal comfort level on, say, iTunes is (personally, I'm fine with it), -- there's good DRM and there's bad DRM. But notice that it's still all DRM, and also note the FSF seems reluctant to draw distinctions between Good and Bad DRM, instead referring to DRM in exclusively negative, monolithic terms. While the GPL v3 draft doesn't really appear to put any teeth into this position, beyond an attack on the DMCA, I'm struggling to see how the FSF can be seen to be opposing all DRM, even the good kind, and not run afoul of the standard security provisions we all expect.
Sure, Apple will tell you today how to get root, but they could stop doing so tomorrow if they wished, and I'd be right back to relying on a 3rd party to circumvent those permissions. And even if CSS keys became freely available, CSS software would not magically stop being DRM software.
The intent of permissions vs. the intent of CSS is not the issue. The issue is whether or not all DRM is bad. You're making an interesting case that would allow people to distinguish between good DRM and bad DRM (and so perhaps engage in useful lobbying against the later), but not that permissions are instrinsically technically seperate from DRM -- as you point out, your argument for differentiation substantively relies on "legal issues" not technical ones. In my examples of Apple above concealing the root instructions and CSS keys becoming available, not a bit of software has changed, but they've still swapped places on the good/bad divide due to factors entirely external to the software. Thus attempting to 'hardcode' anti-DRM language into a universal software license seems problematic, and more a relic of AI Lab thinking, circa 1970, than something appropriate for the networked world.
Wow, a reference to The Quiet Earth! God, I loved that movie, never did figure out the ending...
Larry Page reckons it's just a matter of time... :)
Comparable as in "You can compare them", not comparable as in "Pretty much exactly the same".
Comparable as in "Most consumers using an external hard drive aren't really going to notice a difference between Firewire and USB 2.0" A really big transfer for most consumers would be, for example, a complete back up of their iTunes library. Say that takes 10 minutes with Firewire. Granting you as much as 20% difference in speed, which would mean a lot to an enteprise user, or hard core techie, for the consumer that translates to an 12 minute transfer on USB 2.0, which just isn't enough of a difference to matter, especially since the consumer wandered off make a cup of tea round about minute 2 anyway.
I don't know about you, but I want a machine that runs at it's best _now_
I guess we're talking past each other, because I'm explicitly talking about the future of USB and firewire, not as things stand today. And I'm not talking about Moore's law as an "analogy": I'm talking about Moore's law directly in its economic context: technical elegance is nice, but it's far from the determining factor about which technology is best, particularly when that translates into concrete decisions such as which chipsets should a manufacturer put into a device, or which combination of features represents the best value hardware buy for my money.
But in any case, no one cares what numbers say the performance should be, what matters is what the performance actually _is_
Almost, but not quite. What matters is what the performance actually is relative to people's actual needs. If performance was the only factor, screw Firewire, I'm going straight to fiber-optics! For most people, USB 2.0 already offers more than good enough performance, is cheaper than Firewire (because of the manufacturing economies of scale if nothing else) and will soon be available in a wireless flavor.
It's worth noting that FireWire 400 is present and accounted for on the MacBook Pro, so no need for USB->FireWire dongle adapters. Yet.
You're right, I should have written "future" instead of "new," as I meant "new" as in the next rev, not the current crop being released. In any case, I think it'll linger on in prosumerville, in much the same way that I have a minidisc recorder.
I don't know what implementation of Firewire and USB your external hard drive and/or computer is using, but it's doing a poor job of at least one of them: according to the specs, Firewire 400 should deliver 400 Mb/s vs USB 2.0 480 Mb/s. True, compression, etc, can skew those numbers, but the speed is comparable. (And sure, there's Firewire 800, but the only 800 port I have is on my Powerbook and I've never plugged anything into it ever in two years or so of daily use.) Even if USB does eat up more CPU cycles, it won't matter to most users given the economics of Moores' Law. But I do agree Firewire will be around for a long time for users with specific needs -- but not in a standard, every-computer-will-have-one mass market way that USB will be, in the same way that today I have a minidisc recorder for my specific job needs, but CD players/burners are what you'll find on every machine. Or how, say, SCSI never became much more than a niche high-end player.
Yes, but the only place I've ever seen a Firewire 800 port is on my 15" Powerbook and in two years I haven't used it once. Most consumers don't access terabytes of data -- if they can pull data across the wire fast enough to, say, watch High Def quality video in real time, they're happy. Hence the economic incentive for hardware that supports higher data rates is greatly diminished. It's not a technical issue, it's an economic one, and the economics seems to indicate that Firewire will go the way of classic SCSI -- lingering on, but a niche player, like minidiscs or MIDI. Plus, as I mentioned, Firewire doesn't come in a wireless flavor. At CES I saw wireless USB kit that's available today.
I can't imagine they'd abandon Firewire for USB.
I think that's exactly what they're doing -- the most recent iPod rev doesn't have a Firewire interface for example. It seems that USB 2.0 may have eaten Firewire's lunch -- speeds are comparable, and -- as of pretty recently -- USB comes in a wireless flavor. Even when Firewire was going gangbusters, not every machine (I'm speaking now in the broader universe of all consumer computers, desktop and laptp, not just Apple Powerbooks) had Firewire, but they all had USB. I suspect that firewire will stick around for certain applications, but that if you really want to use it with new Mac laptops, you'll need a Firewire-USB dongle adapter.
I think part of the difficultly in finding an optimum solution (or least-pessimistic solution perhaps) is that you may be running together two problems, which both manifest the same symptoms -- people endlessly bitching about submitters in the story comments -- but actually have different causes.
:) ). Dealing with this is trickier -- some Blogs can add substantial value to a raw link and should be granted their intermediary position, while others Just Don't and readers would be better served with a direct link. However, assuming there are no other submissions availble with a direct link, I don't think you should just take the link, bin the submssion, write up your own blurb and post it with no attribution.
Beatles Beatles is in one problem set: a submitter sends in reasonably well-written, blurbs with direct and relevant links. The only fly in the ointment is that he links his name back to a web site that raises the hackles of slashdot readers who believe he's Googlewhoring for Fun and Profit, and thereby gaining an unfair advantage over Joe Slashdot. I think the solution there is to keep an eye on people who've had a lot of stories accepted, and try to make sure that, going forward, those stories you accept from them really are just the ones that he/she, and he/she alone, have uniquely submitted. Even though slashcode's weakness when it comes to searching could make implementing this less than perfect, any attempt at it would reduce the howls of "Hey -- why does XYX get another PageRank boost over me when I submitted the same story!"
I realize this policy could be seen a punishing "good submitters" -- why shouldn't you have the at least same chance as getting random story X published as a dozen other submitters, many of whom may never have contributed to the community before, if you're a good submitter? -- but good submitters will still get their unique stuff up there (and if they're really good, this will translate to a fair number of stories accepted), and you're increasing the number of voices that are being heard, always a good thing on a community driven site (other venues, such as blogs, do exist if I really want to hear one specific person's take on things.)
Roland is in the other problem set: there the objection is that the links within the blurbs themselves are not so direct and relevant, but place an annoying layer of intermediate submtter opinion that doesn't add anything of substanstance to my understanding of the story or its context. (and my needs for superficial submitter opinion are ideally already satisfied by the blurb
Instead, for links to things like blogs which are commentaries on some further linked item (rather than original content, a la Russinovich's infamous Sony BMG DRM post), you could make it a policy -- as part of the normal "submission clean up" process -- to add a direct link to the ultimately linked item into the blurb. Those that want to read the commentary can do so, others can bypass it.
I guess what I'm saying is that the solutions are to be found not in the realm of tech fixes, such as nofollow tags or even more baroque meta-uber-moderation constructs, but in non-technical things like editorial policies and judgement that relate do directly to the value you deliver to Slashdot readers I which I think is entirely within your remit and avoids some of the issues you've been concerned about in other threads.
This is completely OT, but I didn't want to undo my moderation in the "Gender Gap in Computer Science" thread. I just wanted to say your well-articulated insight into the issue was appreciated. Cheers.
Actually, yeah. I kinda liked the Kilmer movie too, in a sort of guilty pleasure way.
I'd be inclined to take you more seriously if you didn't post as an AC.
Well, let me see. There was a) the complete and utter disregard for the basic laws of physics and large chunks of biology (see Phil Plait's Bad Astronomy site for more), b) the retread of plot elements from 2001:A Space Odyssey and many other places, c) the plot holes (Why would the aliens go to another Galaxy when Mars was threatened? Why not go live on Earth, instead of just stopping by to drop spores all over it? Also, why have an astronaut killing defense system at all?) d) the aforementioned poor acting (with the honorable exception of Don Cheadle who gave it the old college try) -- it's not that the cast are bad actors per se, but these weren't great performances -- and e) stodgy dialogue.
:)
So, there you go, just those five things.
Because even bullshit costs a hellava lot more money when produced by professionals. Consider, say, Mission to Mars, which is my standard example of Worst Movie Ever. However, lets ignore the wooden acting, bland direction and painful script for now. All the actors are in focus. They all have competently applied make up. The picture isn't grainy. You can't see any plywood poking out from behind the fairely extensive sets. The costumes look realistic. The audio is fine: you can hear the actors' lines without the music, sound effects, or ambiant noise drowning them out. There's a score. The custom 3-d modelling is competent. You can't see bits of camera equipment or sound booms in the frame, and so on. Sadly the same can't be said for many things put together with a DV and a bootleg copy of Final Cut. Just to to reach a minimal production threshhold costs money: professionals aren't cheap.
Anyhoo, I suspect that your idea of what's crap may not exactly match up with what's mine, or others', raising the question of which 60% gets cut. I suspect that a lot of crap is actually responsible for some of the highest profits in the industry, so the exec's wouldn't exactly be saving billions in any case.
An apropos 1796 reference? I had considered trying to go as far back as the great Airship Hysteria of 1896-7, but couldn't link it mind control. I tip my hat to you sir!
I believe the tinfoil hat thing is a manifestation of one of the broader charateristic delusions of paranoid schizophrenia, i.e. that external forces are controlling one, or inserting thoughts directly into one's mind. Different manifestations pop up depending on the milieu: today it's radio signals from government controlled satellites, but in the late 1940's Shaver's tales of "Dero rays" being emitted by a race of evil subterranean dwellers proved a popular framework for the delusion.
Try installing XP and "restoring" win98
You know, to be fair, I tried this last weekend, and it worked. I was halfway through upgrading my win98 box to XP when the installer borked (I think because of an odd CD-ROM setup I have). As we all know, this is usually the worst possible moment for something to go wrong, as the system is between two (theoretically) stable configurations, but when I crossed my fingers and rebooted the machine, I was given a useful(!) error message, that gave me a clue as to the problem, a suggested work around, and the option to restore my Win 98 system. To my surprise my old system restored perfectly, I was able to set up the work around, and then installed XP with no more problems. It didn't even try to beat up on my GRUB loader.
I wandered down the hall, and Steven said it was his understanding that the Skype detector looks for unencrypted packets making up part of the header.
can it still be detected as VOIP traffic at this point?
Yes. My colleague, Steven Cherry, at IEEE Spectrum, wrote about such software recently here.
Hee. You just made my day. (I'm an editor at Spectrum!).