I'm not heavily into P2P at all, so I'm speaking out of some
ignorance, but: do we now accept the RIAA's definition that
P2P is synonymous with piracy? It seems to me that, even if
all sharing of copyrighted music were discontinued,
P2P would still have a perfectly valid place in our spectrum of
networking possibilities.
(As an example, I'd like to see P2P used to maintain
collaborative anti-spam blacklists, so that there wouldn't be
single-point-of-failure central repositories.)
"Why blame the vendors of the e-mail filters for these bounces? It's not their fault. All we have to do is educate the users not to click on the viral attachments in the first place."
If companies made it a rule to... properly instruct people to never open email attachments from people they don't know...
This is outdated, poor advice, given that SoBig and all the recent viruses forge the From: lines.
The person in the From: line isn't the real sender, so the attachment mught well be from "someone you know" and yet still be a virus.
The only way to spread this is to open the attachment and run it. How is Microsoft supposed to stop people from opening attachements?
Opening attachments, or running attachments?
It's Microsoft's fault because running an executable attachment is simply too easy.
All it takes (I gather) is a single click, and it's just too easy to do that accidentally, especially since clicking on things becomes a reflex when it's all you do in your GUI all day long.
It's Microsoft's fault because only Microsoft is in a position to definitively do something about the problem. You can blame the users all you want, but face it: it's obvious by now that user education is never going to work, that large numbers of people are going to keep getting tricked into clicking on each new virus.
If we don't want to be stomping out new viruses next week and next month and next year, we're going to have to take an approach other than reactively filtering them, or hoping users won't click on them. We've got to somehow dismantle or remodel the infrastructure which made these viruses possible in the first. That infrastructure was carefully and deliberately erected by Microsoft, despite the huge danger (obvious to anyone who understands security) of its making malware like this possible, which is why we hold them (partially, but significantly) responsible.
The only sensible way to kill these worms is to block them at the mail server.
That's not a way to kill worms. That's a way to block the ones you already know about.
It won't do a thing about the ones you don't know about yet.
The only way to kill the ability of these worms to propagate is to get rid of e-mail clients which make it easy for users to run executable attachments with single clicks. As long as it's easy, we'll continue to be plagued by these things, because even educated users will accidently click on things once in a while.
You would think almost 40 years later we would know how to stop this
from happening.
It turns out we do and we don't.
There've been lots of posts about "How could one generator going down ripple to the whole grid?"
and "Why don't they just isolate the dead section before it snowballs?" They do -- or, they try to.
But it's a really big, really dynamic, really energetic system, and even the best models don't always cope properly. (And remember, you can't have automatic mechanisms that are too eager to isolate "dead" sections, or there'd be too many false positives.)
Darn good question. (One of the most important there is, I'd say, because variants of it underlie all sorts of crucial design decisions.)
I've got two answers. The first (even though it sounds like a stupid cliche, of the sort that Dilbert's PHB is wont to mutter) is: "work smarter, not harder". See if you can't do the Correct & Proper thing, in the same sort of compressed timeframe that you were afraid was forcing you into the Quick & Dirty thing. You're a code jockey, right, with the latest high-productivity development tools? So show us what you can do! Why should Correct & Proper have to take so long?
Yeah, I know, sometimes it does, especially if you're not so much writing brand-new code, as figuring out and trying to fix a bunch of old, broken, legacy code. So the second answer is: when you're forced by schedule pressure to take a Quick & Dirty shortcut, that you're probably gonna have to go back and do right later, at least make sure it will be possible to do it right later!
Far, far too many Quick & Dirty shortcuts end up being impossible to get rid of, because they have far-ranging repercussions. Perhaps the quick&dirtiness is exposed via an API, in such a way that fixing it would require rewriting all callers. Perhaps the quick&dirtiness shows up in a data file format, meaning that you can't fix it without invalidating (or having to convert) all the existing data files. Etcetera.
So when you find yourself doing the Quick & Dirty thing, take some time to think about the Correct & Proper thing you'd rather be doing. (You've already done some of this, or else you wouldn't be asking the question in the first place.) Figure out how the Correct & Proper thing would interact with the rest of the system, and make sure that your Quick & Dirty shortcut either interacts the same way, or that there will be a graceful migration path available.
The only thing worse than an ugly, Quick & Dirty shortcut is an ugly, Quick & Dirty shortcut that can't be fixed later, no matter what, even if you do find yourself with the resources and the motivation to fix it, because it's become ossified in some way. (Think 8.3 filenames for but one example.)
...forcing the maintainer of
Stormaster.com to shut down...
I can understand ROM images to some extent, but 25 year
old coin-op operator/tech manuals?
Well, I notice that the IDSA letter does not demand that those 25
year old manuals be taken down, or that the site be shut down --
the letter refers only to a list of 7
"game products" (which are presumably ROM images).
Me, I'm what you might call a "high-powered C programmer", but a huge portion of the coding I do -- and this definitely includes the day job -- involves shell scripts. (And when I drop down into C, it's usually to write a new general-purpose tool for one of my scripts to use, not to write a special-purpose C program for solving one problem.)
Of course, I have the luxury of working for a small company where we can choose to use what works, not what's dictated by some myopic corporate standard.
But anyone who discriminates against a "scripter" -- (first time I've even heard the term) -- is an idiot. It's pathetic how much time is wasted on handcrafted "real programs" which are 90% wheel reinventions, when a competent programmer could whip together a script in 10% of the time.
How many of you fucking idiots are going to keep posting the same bullshit?
Strong words there, Zig.
Whether or not this is true, it is *not* HTTP pipelining, keep-alive or any other *HTTP* level method of persistent connections...
It's a TCP level hack.
Depends on what you mean by "this".
Certainly what the original blog alleged was a TCP level hack.
But the allegation doesn't hold water.
What's really going on is almost certainly that, yes, IE is using plain ol' HTTP persistent connections, and that when squinted at the result merely looked like low-level TCP hacking.
(No, this doesn't make for nearly as nice a conspiracy theory, and yes, it means that the original blog discussion was completely off-base.)
Don't hold your breath waiting for Microsoft to make it easy to create interoperable documents, since that would dismantle one of their key strategies for market domination. They have by now successfully shanghaied every single one of their users into being a salesman for them, since every Word document, Excel spreadsheet, and Powerpoint presentation that's ever created and absent-mindedly attached to an e-mail effectively requires that the recipient also own that Microsoft app (and of the correct version, since Microsoft apps don't even interoperate with different versions of themselves). It is very much not in Microsoft's interest for them to make it easy for their customers to create documents that can easily be read by people who aren't Microsoft customers.
One way testing can hurt is if developers assume that it's the tester's jobs to catch the bugs. Developers who don't have testers to lean on have (potentially) more of an incentive to figure out how to introduce fewer bugs in the first place.
The CBDTPA is not copy protection legislation.
The existing DMCA is all the copy-protection legislation we (or, more precisely, the media industry) could ever want.
The CBDTPA is business promotion legislation:
it's hard to jumpstart a new technology, due to chicken-and-egg problems:
it's not profitable to create content in the brave new copy-protected, rights-managed format until people have players for it, but nobody's going to get the players (never mind how unattractive they'd be) if there's no content for them. So this law simply forces everyone to get the new players, so that the media industry can begin selling us all that glorious new content in their glorious new (for them) formats.
If a "state of the art" application is one that's bloated and buggy, then yes, a "state of the art" IDE is indispensible for creating it: old-fashioned tools are simply incapable of churning out vast swaths of buggy code at the rates which current fashion seems to demand.
Now, if what you want to churn out is high-quality, error-free, maintainable programs, then I'd say it's the CLI tools that are indispensible. If you want to get clever, and invent new tricks no one has tried before for, say, having the code write and test itself (using your own special-purpose table-driven code and test case generators and the like), you're going to have an easy time integrating your brand-new tools and automated build procedures into a good, old, utterly general-purpose make-based build procedure, whereas you're likely to have an arbitrarily hard time integrating it into some hyperfancy all-in-one IDE which, like any graphical tool, makes it slick'n'easy to perform those tasks the tool's designer thought of and designed for, but impossible to do anything else.
I could go on, but since I'm in the middle of reading The Pragmatic Programmer (which is not where I got these ideas, but it presents them well), I'll just refer you to it. See especially section 42, "Ubiquitous Automation".
Don't get me wrong, there are some tasks that IDE's (like any graphical tools) are quite good for.
But saying "it is impossible to create 'state of the art' programs with command-line tools" (with the implication that IDE's are infinitely superior) is simply infantile; it's as bogus an argument as claiming that vi is infinitely superior to emacs (or ed).
As always, use the right tool for the job, and don't try to claim that one tool or set of tools is either perfect or unequivocably superior to its counterpart from the other side of the tracks.
Re:We can do something about this kind of thing.
on
Launchcast Sued
·
· Score: 1
...start your own little recording studio with a Mac and a Tascam or Roland MultiTracker. Nobody has any more control over you than what you give to them.
I agree with this, and it's quite true, if the standards for creating media stay open. If, on the other hand, various industry factions succeed in various of their nefarious schemes, such as copy-protected hard disks, or CD players that play only officially-watermarked disks, where does that leave any would-be small-time content creator who isn't privy to the official licenses and secret keys...?
(1) If all you do is stamp out spammers, it's an eternal game of whack-a-mole. Arguably, if you really want to stop spam by making it nonviable, you also have to shut down the channels by which responses come back to the spammers from their victim/customers. Since one way those responses come back is by hits on web pages, you can try to get the web pages shut down. Indeed, many AUPs prohibit web pages which are advertised using spam.
But shutting down web pages is obviously a dicey issue. So the second issue is (2) the RBL is a bit too monolithic. If you want to limit yourself to putting just one toe in the dicey water of censorship, if you want to shut down the IP addresses actively involved in sending spam but if you're not ready to take the much more contentious step of shutting down every IP address of any web server that hosts, among its many pages, one pointed to by a spam message, last time I checked, you can't do that with the RBL. Subscribing to it is all-or-nothing; once you're using it, you're elminating everything its maintainers want to eliminate.
Don't get me wrong. I'm not pro-spam, or anti-RBL. But if I were using the RBL, I think I would want to use it in this one-toe-in-the-water mode; I'd want to know why each address on it was on it, so that I could choose to block traffic to/from only the active spam sites, not the passive spam victim target sites.
This scares me.... If they use their lobbiests... We will be fighting an even greater uphill battle than we are now.
Naahh. If they keep smoking whatever they're smoking, and actually try to do anything along these lines, the resulting outcry (and the blinding glare of publicity that the affair would throw on their unimaginably greedy and self-serving strongarm attempt) would do far more to educate the world about the realities of open source software (and about the realities of Microsoft's intentions) than we could ever achieve otherwise.
There's no possible way anyone could try to ban open source software (what a meaningless concept!) that would have any remotely deleterious or stifling efffect on open source software. Any of these attempts would just make Microsoft look like Yosemite Sam to the open source community's Bugs Bunny, with the putative ban the stick-of-dynamite "cigar" that has just blown up in Sam's face.
If sites are having to choose between standards compliance versus bass-ackwards compatibility with old, broken browsers, then yes, that's a problem, and we should see if we can't find ways to help those sites justify doing the Right Thing (which is of course to lean strongly towards compliance).
But backwards compatibility with prior versions of the HTML standard is a very different thing, and twisting the arms of users of old browsers (especially if those old browsers are compatible with HTML version N-1) to try to force them to upgrade is clearly insane.
There are far too many reasons why someone might want or need to keep using an older browser.
Trying to lock users into some kind of a faster update cycle (18 months already seems quick to me, and that's what they want to shorten it from?) is a tremendously misguided notion, and would be of far more benefit to those who want to hasten the conversion of the Web into the new TV (taking yet more power and control out of the hands of the end user/browser) than it would be to web designers who would like to have an easier time of creating cutting-edge yet widely portable HTML.
I'm going to be blunt here:
The problem is not the "increased fracturization of the internet". The problem is webmasters like you who don't have the faintest idea how to make use of kewl new HTML version N+1 features while also maintaining compatibility with the least common denominator. It's not that hard. The only thing worse than your frenetic attempts to "maintain layout compatibility" by using "four levels of nested tables" is the webmasters who are detecting browser versions and using big switch statements to hand-tailor their gunky overtweaked HTML for 57 different varieties of the two popular browsers, leaving poor old Jon Postel (or any other besotted old troglodyte who once believed in the mythical concept of interoperability) spinning in his grave.
It was clear to me a couple of years ago when I first read about the RBL, and this case & its ensuing discussion confirms it for me absolutely, that a tool like the RBL needs to offer at least two separate lists: (1) IP's that are blacklisted because of sending spam, and (2) IP's that are blacklisted because of hosting spam-promoted websites. Yes, there are good arguments in favor of blocking spam-hosted websites, but there are also good arguments in favor of not doing it, and it's an endlessly debatable point which will never be settled (as this/. discussion thread amply proves!). Subscribers to the RBL ought to have a choice whether they buy in to the heavier-handed kind of censorship.
The third option is to go for the least common denominator and that is forgetting about all those cool new ways of doing things simply because of the pain in the ass it is to write the code two or three times.
If people would write for the least common denominator more often, instead of (a) rushing to embrace all those cool new ways of doing things or (b) writing the code two or three times, the world of computing would be a much better place.
Slashdot Mirror
Right! And where's the rampant, bring-the-net-to-its knees exploit that alerts everyone to the fact?
(As an example, I'd like to see P2P used to maintain collaborative anti-spam blacklists, so that there wouldn't be single-point-of-failure central repositories.)
Excuses, excuses.
This is outdated, poor advice, given that SoBig and all the recent viruses forge the From: lines. The person in the From: line isn't the real sender, so the attachment mught well be from "someone you know" and yet still be a virus.
Opening attachments, or running attachments?
It's Microsoft's fault because running an executable attachment is simply too easy. All it takes (I gather) is a single click, and it's just too easy to do that accidentally, especially since clicking on things becomes a reflex when it's all you do in your GUI all day long.
It's Microsoft's fault because only Microsoft is in a position to definitively do something about the problem. You can blame the users all you want, but face it: it's obvious by now that user education is never going to work, that large numbers of people are going to keep getting tricked into clicking on each new virus. If we don't want to be stomping out new viruses next week and next month and next year, we're going to have to take an approach other than reactively filtering them, or hoping users won't click on them. We've got to somehow dismantle or remodel the infrastructure which made these viruses possible in the first. That infrastructure was carefully and deliberately erected by Microsoft, despite the huge danger (obvious to anyone who understands security) of its making malware like this possible, which is why we hold them (partially, but significantly) responsible.
That's not a way to kill worms. That's a way to block the ones you already know about. It won't do a thing about the ones you don't know about yet.
The only way to kill the ability of these worms to propagate is to get rid of e-mail clients which make it easy for users to run executable attachments with single clicks. As long as it's easy, we'll continue to be plagued by these things, because even educated users will accidently click on things once in a while.
It turns out we do and we don't. There've been lots of posts about "How could one generator going down ripple to the whole grid?" and "Why don't they just isolate the dead section before it snowballs?" They do -- or, they try to. But it's a really big, really dynamic, really energetic system, and even the best models don't always cope properly. (And remember, you can't have automatic mechanisms that are too eager to isolate "dead" sections, or there'd be too many false positives.)
I've got two answers. The first (even though it sounds like a stupid cliche, of the sort that Dilbert's PHB is wont to mutter) is: "work smarter, not harder". See if you can't do the Correct & Proper thing, in the same sort of compressed timeframe that you were afraid was forcing you into the Quick & Dirty thing. You're a code jockey, right, with the latest high-productivity development tools? So show us what you can do! Why should Correct & Proper have to take so long?
Yeah, I know, sometimes it does, especially if you're not so much writing brand-new code, as figuring out and trying to fix a bunch of old, broken, legacy code. So the second answer is: when you're forced by schedule pressure to take a Quick & Dirty shortcut, that you're probably gonna have to go back and do right later, at least make sure it will be possible to do it right later!
Far, far too many Quick & Dirty shortcuts end up being impossible to get rid of, because they have far-ranging repercussions. Perhaps the quick&dirtiness is exposed via an API, in such a way that fixing it would require rewriting all callers. Perhaps the quick&dirtiness shows up in a data file format, meaning that you can't fix it without invalidating (or having to convert) all the existing data files. Etcetera.
So when you find yourself doing the Quick & Dirty thing, take some time to think about the Correct & Proper thing you'd rather be doing. (You've already done some of this, or else you wouldn't be asking the question in the first place.) Figure out how the Correct & Proper thing would interact with the rest of the system, and make sure that your Quick & Dirty shortcut either interacts the same way, or that there will be a graceful migration path available.
The only thing worse than an ugly, Quick & Dirty shortcut is an ugly, Quick & Dirty shortcut that can't be fixed later, no matter what, even if you do find yourself with the resources and the motivation to fix it, because it's become ossified in some way. (Think 8.3 filenames for but one example.)
Well, I notice that the IDSA letter does not demand that those 25 year old manuals be taken down, or that the site be shut down -- the letter refers only to a list of 7 "game products" (which are presumably ROM images).
The virus comes in as a
Designing a mail client that automatically executes attachments is a stupefyingly obviously fundamentally wrong idea. No excuse. n
Of course, I have the luxury of working for a small company where we can choose to use what works, not what's dictated by some myopic corporate standard.
But anyone who discriminates against a "scripter" -- (first time I've even heard the term) -- is an idiot. It's pathetic how much time is wasted on handcrafted "real programs" which are 90% wheel reinventions, when a competent programmer could whip together a script in 10% of the time.
Strong words there, Zig.
Whether or not this is true, it is *not* HTTP pipelining, keep-alive or any other *HTTP* level method of persistent connections... It's a TCP level hack.
Depends on what you mean by "this". Certainly what the original blog alleged was a TCP level hack. But the allegation doesn't hold water. What's really going on is almost certainly that, yes, IE is using plain ol' HTTP persistent connections, and that when squinted at the result merely looked like low-level TCP hacking. (No, this doesn't make for nearly as nice a conspiracy theory, and yes, it means that the original blog discussion was completely off-base.)
Don't hold your breath waiting for Microsoft to make it easy to create interoperable documents, since that would dismantle one of their key strategies for market domination. They have by now successfully shanghaied every single one of their users into being a salesman for them, since every Word document, Excel spreadsheet, and Powerpoint presentation that's ever created and absent-mindedly attached to an e-mail effectively requires that the recipient also own that Microsoft app (and of the correct version, since Microsoft apps don't even interoperate with different versions of themselves). It is very much not in Microsoft's interest for them to make it easy for their customers to create documents that can easily be read by people who aren't Microsoft customers.
Paging Sylvester McMonkey McBean...
One way testing can hurt is if developers assume that it's the tester's jobs to catch the bugs.
Developers who don't have testers to lean on have (potentially) more of an incentive to figure out how to introduce fewer bugs in the first place.
The CBDTPA is not copy protection legislation. The existing DMCA is all the copy-protection legislation we (or, more precisely, the media industry) could ever want. The CBDTPA is business promotion legislation: it's hard to jumpstart a new technology, due to chicken-and-egg problems: it's not profitable to create content in the brave new copy-protected, rights-managed format until people have players for it, but nobody's going to get the players (never mind how unattractive they'd be) if there's no content for them. So this law simply forces everyone to get the new players, so that the media industry can begin selling us all that glorious new content in their glorious new (for them) formats.
Now, if what you want to churn out is high-quality, error-free, maintainable programs, then I'd say it's the CLI tools that are indispensible. If you want to get clever, and invent new tricks no one has tried before for, say, having the code write and test itself (using your own special-purpose table-driven code and test case generators and the like), you're going to have an easy time integrating your brand-new tools and automated build procedures into a good, old, utterly general-purpose make-based build procedure, whereas you're likely to have an arbitrarily hard time integrating it into some hyperfancy all-in-one IDE which, like any graphical tool, makes it slick'n'easy to perform those tasks the tool's designer thought of and designed for, but impossible to do anything else.
I could go on, but since I'm in the middle of reading The Pragmatic Programmer (which is not where I got these ideas, but it presents them well), I'll just refer you to it. See especially section 42, "Ubiquitous Automation".
Don't get me wrong, there are some tasks that IDE's (like any graphical tools) are quite good for. But saying "it is impossible to create 'state of the art' programs with command-line tools" (with the implication that IDE's are infinitely superior) is simply infantile; it's as bogus an argument as claiming that vi is infinitely superior to emacs (or ed). As always, use the right tool for the job, and don't try to claim that one tool or set of tools is either perfect or unequivocably superior to its counterpart from the other side of the tracks.
I agree with this, and it's quite true, if the standards for creating media stay open. If, on the other hand, various industry factions succeed in various of their nefarious schemes, such as copy-protected hard disks, or CD players that play only officially-watermarked disks, where does that leave any would-be small-time content creator who isn't privy to the official licenses and secret keys...?
There are two basic issues, I think.
(1) If all you do is stamp out spammers, it's an eternal game of whack-a-mole. Arguably, if you really want to stop spam by making it nonviable, you also have to shut down the channels by which responses come back to the spammers from their victim/customers. Since one way those responses come back is by hits on web pages, you can try to get the web pages shut down. Indeed, many AUPs prohibit web pages which are advertised using spam.
But shutting down web pages is obviously a dicey issue. So the second issue is (2) the RBL is a bit too monolithic. If you want to limit yourself to putting just one toe in the dicey water of censorship, if you want to shut down the IP addresses actively involved in sending spam but if you're not ready to take the much more contentious step of shutting down every IP address of any web server that hosts, among its many pages, one pointed to by a spam message, last time I checked, you can't do that with the RBL. Subscribing to it is all-or-nothing; once you're using it, you're elminating everything its maintainers want to eliminate.
Don't get me wrong. I'm not pro-spam, or anti-RBL. But if I were using the RBL, I think I would want to use it in this one-toe-in-the-water mode; I'd want to know why each address on it was on it, so that I could choose to block traffic to/from only the active spam sites, not the passive spam victim target sites.
Naahh. If they keep smoking whatever they're smoking, and actually try to do anything along these lines, the resulting outcry (and the blinding glare of publicity that the affair would throw on their unimaginably greedy and self-serving strongarm attempt) would do far more to educate the world about the realities of open source software (and about the realities of Microsoft's intentions) than we could ever achieve otherwise.
There's no possible way anyone could try to ban open source software (what a meaningless concept!) that would have any remotely deleterious or stifling efffect on open source software. Any of these attempts would just make Microsoft look like Yosemite Sam to the open source community's Bugs Bunny, with the putative ban the stick-of-dynamite "cigar" that has just blown up in Sam's face.
If sites are having to choose between standards compliance versus bass-ackwards compatibility with old, broken browsers, then yes, that's a problem, and we should see if we can't find ways to help those sites justify doing the Right Thing (which is of course to lean strongly towards compliance).
But backwards compatibility with prior versions of the HTML standard is a very different thing, and twisting the arms of users of old browsers (especially if those old browsers are compatible with HTML version N-1) to try to force them to upgrade is clearly insane. There are far too many reasons why someone might want or need to keep using an older browser.
Trying to lock users into some kind of a faster update cycle (18 months already seems quick to me, and that's what they want to shorten it from?) is a tremendously misguided notion, and would be of far more benefit to those who want to hasten the conversion of the Web into the new TV (taking yet more power and control out of the hands of the end user/browser) than it would be to web designers who would like to have an easier time of creating cutting-edge yet widely portable HTML.
I'm going to be blunt here: The problem is not the "increased fracturization of the internet". The problem is webmasters like you who don't have the faintest idea how to make use of kewl new HTML version N+1 features while also maintaining compatibility with the least common denominator. It's not that hard. The only thing worse than your frenetic attempts to "maintain layout compatibility" by using "four levels of nested tables" is the webmasters who are detecting browser versions and using big switch statements to hand-tailor their gunky overtweaked HTML for 57 different varieties of the two popular browsers, leaving poor old Jon Postel (or any other besotted old troglodyte who once believed in the mythical concept of interoperability) spinning in his grave.
It was clear to me a couple of years ago when I first read about the RBL, and this case & its ensuing discussion confirms it for me absolutely, that a tool like the RBL needs to offer at least two separate lists: (1) IP's that are blacklisted because of sending spam, and (2) IP's that are blacklisted because of hosting spam-promoted websites. Yes, there are good arguments in favor of blocking spam-hosted websites, but there are also good arguments in favor of not doing it, and it's an endlessly debatable point which will never be settled (as this /. discussion thread amply proves!). Subscribers to the RBL ought to have a choice whether they buy in to the heavier-handed kind of censorship.
And don't forget that about half of the dimensions in stock HTML are specified in pixels. Time to start weeding those out, too.
If people would write for the least common denominator more often, instead of (a) rushing to embrace all those cool new ways of doing things or (b) writing the code two or three times, the world of computing would be a much better place.