Another point is that the blind often use lynx, since it can be joined with software to read out text aloud.
While it is true that Lynx can be "joined" with software to read out text aloud, it's a myth to believe IE or Netscape can't. There's pretty decent (Windows based) software out there that reads out anything that uses fonts. Including IE.
Lynx had it's day but do we really have to keep supporting it?
Yes. Not because it's Lynx, but if your webpages are geared towards a specific display (and then you might as well have used a medium other than HTML), your pages won't be useful in many other situations. Text-based browsers are not old technology, nor used by poor people who cannot afford a decent PC (as many people designing commercial websites believe). Handheld devices (like some Nokia phones) and certain cars (some expensive German cars have this option) have web browsing capabilities, without the pictures. And then there's the (UK based) 'www-by-phone' service. And let's not forget the indexers and web-spiders. Scooter and friends are blind.
As far as I know, text-to-speech software that blind people use does _not_ work very well with programs like Netscape or IE.
Wrong. My blind friends prefer IE over Lynx, as navigating with Lynx is much more difficult. Major problems with Lynx: frames and forms, although the latter is difficult on IE as well.
Can anyone think of a useful application of this sort of thing?
Privacy. The signal between the computer and monitor is another signal that can be tapped. Perhaps not relevant if you typing a letter to your grandma at home, using a cable between the box and the monitor, but for some cooperations it is a concern, specially if they are using wireless communication between the computer and the display.
I don't understand why the/. crowd is so eager to protect privacy when it comes to sending data over the Internet, but this is dismissed as "we don't need this".
I disagree. It is important to the tourist whether Korean or Japanese is easier and if there are thousands (or millions) of potential tourists, it should be important to people who care about how many tourists visit their country.
Care to point out a country who designed their language such that it would attract more tourists? Or, since languages tend to be established a while ago, has a organizing body steering the language such that it makes it easier for tourists?
My point it that languages aren't made for tourists, languages are made for users.
Thus it is great to force people within a team to use the same indentation conventions.
I don't really agree that it is great, but Python is not helping you to force the same indentation levels throughout your program, let alone between versions.
The only thing that makes sense to me is to always use one tab for one indentation level. To how much space a tab expands, everyone can choose for himself (and doesn't affect the contents of the file).
Setting tab stops any other than 8 seems like a dumb idea to me. While most editors allow you to twiddle the length of a tabstop, other programs don't. Furthermore, there's no excuse of lines over 80 characters. But a twice indented line of 70 characters will fit in the 80 char limit if the tabstop is 4, while it won't fit it the tabstop is 6 or 8. Furthermore, it still doesn't solve the problem of some editors using leading spaces and others leading tabs on auto-indented lines. It just makes the problem worse.
IMO, the only "rule" that makes sense when it comes to indenting styles is: no tabs, ever.
makes it clear what 'r' is, and what documentation I should look up.
Eh, no. The documentation of func should tell you what r will be. Unless of course you use a language with a more sophisticated "context" than Perl has.
Named parameters are trivially simulated in Perl. Both the style where the caller uses positional placement of the arguments, and the style where the caller does something like: func (name1 => $value1, name2 => $value2,..)
The former takes one line of extra code: sub func { my ($param1, $param2,...) = @_;
The latter takes two extra lines of code: sub func { my %args = @_; my ($param1, $param2,...) = @args {qw/name1 name2.../};
But when it comes time to write the final implementation, why should I care about syntactic sugar vs readability and documentation.
Syntactic sugar is very important for readability. If you have a function, whose core consists of 10 lines, the function is a lot clearer if it only has 2 extra trivial lines instead of having the 10 important lines burried into 50 lines of mallocs, checking return values of mallocs, garbage collection, painstakingly building lines of text out of fragments, and other braindead lines that are better left to a compiler to add.
There is a program that *comes with Python* (pindent.py) that looks for things like 'endif' and formats your Python correctly, then deletes them. Maybe it can handle { } too.
That defeats the entire purpose of having indentation rules, doesn't it?
For an occasional scripter, I think Python is hands down easier to read than Perl (and not because of indentation)
But the occasional scripter is irrelevant. That's like saying "Korean is easier to read for the occasional Western tourist than Japanese". It's a meaningless statement.
I often want to do things like make an array of hash tables or a hash table of arrays. In Python these things compose in the obvious way. In Perl, they do not.
Strange. I must be doing something wrong then. Each time I look at Python, I think "they build nested datastructures almost same way as in Perl". The most important thing to remember is that in Python you have by default a reference to an array or a dictionary and have to use extra punctuation if you want a copy of the values, where in Perl it's the other way around. Although you can do it all with references in Perl without using more punctuation.
$x->{'y'} versus x.y -- and let's not forget about x.__class__=mypackage.MyClass. Can you even do the latter in perl?
$x->{'y'} isn't the same as x.y. $x->{'y'} indexes in a references to a hash (dictionairy). In Python, all you have is a reference anyway, and you would index it as x ["y"]. A bit shorter than the Perl equivalent, but in Perl you can drop the quotes. But in Perl, you can easily embed the $x->{'y'} in a string, which you can't in Python.
As for x.__class__=mypackage.MyClass, in Perl you would bless a variable into a class. Not a significant difference.
Perl also makes heavy use of punctuation marks to mean things which are not only not immediately obvious, they can be confusing.
Oh, yeah, right, punctuation is scary, confusing, and makes thing difficult to read. Take a novel, for instance "Oliver Twist" by Charles Dickens. Now, remove all punctuation in the book. Does it become easier to read? Would it become easier to read if you replace the punctuation by something else? I don't think so. Your example above of x.__class__=mypackage.MyClass contains 7 punctuation characters. The Perl equivalent bless $x, mypackage::MyClass contains 4, 42% less punctuation characters. Python uses puctuation characters as well, and they aren't exactly rare either.
Perl is not as readable as python
Bollocks. There's a lot of bad Perl out there. But that isn't due to the language, it's due to the programmer. If you know the language, and you don't have a sucky programmer, Perl is as readable as Python is, for someone who knows the language, and has code written by a competent programmer. Of course, there are people that will claim that Chekhov isn't as readable as Hemingway, when they just mean they don't understand Russian.
I've been to the perl equivalents, and I've never seen them advertising readability or maintainability
Perhaps you should read some of the documentation that comes with Perl then. For instance, perlstyle(1). I'd like to point out to a Python equivalent, but my Python 1.5.2 came with a whopping 8k of documentation compared to the several megabytes of Perl documentation. (Yes, I am aware of that you need to separately install it, but python.org doesn't have plain text or man page formats for the docs - oouch).
Djee, that's almost what you would write in Perl. Minimal changes needed: $x = ['a', 'b', {'c' => 'd', 'e' => ['f', 'g']}, ['h', ['i', 'j']]]
The syntax gets really hideous and doesn't mean what it looks like it should.
Well, since it almost looks the same as Python, should we conclude then that Python is as unreadable as Perl? Or maybe you should learn a bit more Perl before you write things like this again.
There's a lot that needs to be improved in Perl, but readability isn't one of them.
Python cares if you are consistent about it within the block. it does not have to be a tab.
Well, yes, however, isn't one of the virtues of Python that it makes it easier to maintain other peoples code? It's easy for a single programmer to be consistent - but Python forces consistency (to some degree) upon you, to make it easier to work with multiple people on code. With multiple coders come multiple editors. With multiple editors come different ways of indentation. While most programmers will use editors that will automatically indent as much as the previous line (usually, some editors will extra indent if the previous line ends with an opening brace/paren, or a colon), but they aren't consistent on how to pad the new line. Some editors will only use spaces, other editors will use as many tabs as possible. And while on programmer has a tabstop of 8, another has it set to 4.
Using a consistent indentation is good. But forcing it upon the programmer is, IMO, not the best solution. It's not necessary if there's only one programmer, and inconvenient when there are multiple programmers.
OTOH, save of vertical space does have merit. I usually don't care much about it; it isn't too hard to live by, although it sucks if all you want to do is a quick cut-and-paste job. For me, it's not a reason not to program in Python.
Actually, a better statistic is whether Women CS majors are declining at the same rates as Men. I mean, most of the schools I talk to are losing attendees to the industry faster than they can enroll.
Anita Borg was talking about a decline in percentage, not in absolute numbers.
I wish you'd clarify what your position actually is! Are you referring to DoS utilities, or security exploits?
Both.
Publishing an exploit is not INTRINSICALLY immoral.
Of course not. I never claimed it was. What I argue against is handing out the tools to exploit a hole (be it a DoS or a security breach) to anyone who wants it.
Hirohito did not politic his way into power for the express purpose of totalitarian government and world domination, he was the hereditary ruler. Much as the English monarchy today, he actually had very little political power.
Until the end of the war, Japanese Emperors were seen as gods, a status no English monarch ever achieved.
Although the Japanese troops had a well deserved ugly reputation for brutality (especially in Nanking China), the Japanese never embarked on a Hirohito-led genocide.
Ask that to the Koreans. Ask that to the few survivors of the slaves that build the Burma railroad. I'm too young to have experienced the war, but the generation before me did. And from that generation, I know many people that lived in Indonesia in the early 40s. (I am Dutch, and Indonesia was a Dutch dependency at the time). I know many people who spend a significant number of years of their childhood in prison camps. I know people who lost their fathers/brothers/uncles in Japanese labour camps. I know people who were tortured by the Japanese, and suffered the rest of their lives from the consequences. I know people who, after more than 50 years, *still* wake up during the night with nightmares. All done in name of the emperor of Japan.
If Hirohito was as bad as Hitler, then why did he never stand trial as a war criminal, a la Nurenberg?
I've no answer for this twisted US political agenda point. It certainly had not unanimous support from its allies, but given the US dominance, what could they do about it?
A final point. When Hirohito died in 1989, why did the U.S. send dignitaries to the funeral if he was as bad as Hitler?
Economical and political reasons. The US was never (partially) occupied by Japan, nor did it have a significant number of civilians that suffered or died in prison and labour camps.
Let me rephrase that question. Why was it that the Netherlands, who more than any other country in the world depends on foreign trade for its economy, which has Japan as one of its biggest trading partners, and which, like Japan, is a monarchy did not send any dignitaries? No member of the royal family, no political hotshot? Just a tiny delegation from the embassy. And while there were dignitaries a month later during the inauguration of the new emperor, it was a rather small one, and didn't include the queen or her spouse, because the entire concept of "emperor of Japan" is considered tainted.
Suppose we contact the company, and their response is `you are lying, the doors are perfectly adequate for the purpose', then is it not the case that revealing this weakness in the doors serves the public function of expoing false claims?
Perhaps, but that's not the issue. The analogue would be to hand out sledgehammers to everyone who wants one. Which is totally different than singling out a single door for a presentation.
Though, the KGB attacking may be an extreme and unlikely scenario, it could also be a devastating one. More likely, and somewhat less devastating, would be terrorists and the like using it in somewhat less coordinated attacks. Or industrial theft, espionage, etc. carried out against virgin targets.
Should we also hand out machine guns to gangs, so we will be aware in case of an attack by another country?
Just because it is important to protect yourself and make your site and connections secure doesn't mean it is ok to hand out tools to make attacks easy.
Between your first statement and this one, I can't understand why you would think that Mixter is any more responsible for the actions of lamer miscreants than the admins of the sites that got hit. After all, as you say, these holes have been known about for 25+ years. Aren't the admins morally responsible for leaving open a means of disrupting their sites'?
No, the weakness lies (partially) in the protocol. It's not really feasible for an admin to say "oh, let's get rid of IP4, and use nothing but IPv6".
Doors have weaknesses too. They don't hold against the attack of a tank. And as long as noone starts building tanks and leave them on the street for grabs, that isn't a problem.
But what about cases such as Microsoft's one-time pretence that certain security vulnerabilities did not endanger their users? A case can be made that, on balance, CDoC releasing BackOrifice was a good thing, because it forced recognition of the issue.
That's like saying "hand out untraceble guns so the goverment will speed up the gun control laws". It's a dangerous, irresponsible attitude. I lock my doors not because people can get it - I lock my doors because there are thieves. And I don't fancy the idea to have to hire a security guard because someone is handing out sledgehammers, just to prove the point that doors have weaknesses.
Yes, one of the things that killed OS/2 and Betamax was that they came to late. If you already have a VHS and a collection of tapes, you aren't going to invest in a new VCR, specially not if your current equipment still works fine. And if you are buying a VCR for the first time, and many of your friends have VHS, the interoperatibility (exchanging tapes) is more important than a better quality.
Technical superiority isn't important for most people. Browser plugins and the ability to send word documents by email to your kids are.
Some may argue that it is not necessary to actually create a trivial exploit that script kiddies can exploit. While this may have some merit (I even agree somewhat with this approach, it depends largely on the circumstances and the vendor), it has been shown with MS (and a few others), time and time again, that they'll simply dismiss a vulnerability as "theoretical", or even "impossible", unless you make it known that you're going to create an exploit for it--and have demonstrated your abilities to make it a reality before.
I disagree with that. It has been publically known for decades that doors don't stand a change against an attack by a tank. My landlord isn't going to put an anti-tank ditch around my apartment. Why? Because only a few have the expertise to create a tank, and those that do, don't leave them on the streets for anyone to grab. And that's more than enough to keep my stuff safe from an attack by a tank.
As long as people behave irresponsible, be it by making actual attacks, or by putting the means into the hands of anyone who feels like it, "hackers" will keep a bad name. Nor is it going to help any open source movement at all. Whining about being portraited in a negative way in the media here on slashdot isn't going to solve that. Do you really think Joe R. Websurfer gives a damn "it's ok to make the tools available", "this attack shows that people have to spend more time and money in securing their sites", etc? No. He notices that his favourite websites were unavailable for some hours. And that the same crowd that wants him to run Linux instead of Windows (partially) defends the actions.
Slashdot Mirror
While it is true that Lynx can be "joined" with software to read out text aloud, it's a myth to believe IE or Netscape can't. There's pretty decent (Windows based) software out there that reads out anything that uses fonts. Including IE.
-- Abigail
Yes. Not because it's Lynx, but if your webpages are geared towards a specific display (and then you might as well have used a medium other than HTML), your pages won't be useful in many other situations. Text-based browsers are not old technology, nor used by poor people who cannot afford a decent PC (as many people designing commercial websites believe). Handheld devices (like some Nokia phones) and certain cars (some expensive German cars have this option) have web browsing capabilities, without the pictures. And then there's the (UK based) 'www-by-phone' service. And let's not forget the indexers and web-spiders. Scooter and friends are blind.
-- Abigail
Wrong. My blind friends prefer IE over Lynx, as navigating with Lynx is much more difficult. Major problems with Lynx: frames and forms, although the latter is difficult on IE as well.
-- Abigail
Privacy. The signal between the computer and monitor is another signal that can be tapped. Perhaps not relevant if you typing a letter to your grandma at home, using a cable between the box and the monitor, but for some cooperations it is a concern, specially if they are using wireless communication between the computer and the display.
I don't understand why the /. crowd is so eager to protect privacy when it comes to sending data over the Internet, but this is dismissed as "we don't need this".
-- Abigail
Care to point out a country who designed their language such that it would attract more tourists? Or, since languages tend to be established a while ago, has a organizing body steering the language such that it makes it easier for tourists?
My point it that languages aren't made for tourists, languages are made for users.
-- Abigail
I don't really agree that it is great, but Python is not helping you to force the same indentation levels throughout your program, let alone between versions.
The only thing that makes sense to me is to always use one tab for one indentation level. To how much space a tab expands, everyone can choose for himself (and doesn't affect the contents of the file).
Setting tab stops any other than 8 seems like a dumb idea to me. While most editors allow you to twiddle the length of a tabstop, other programs don't. Furthermore, there's no excuse of lines over 80 characters. But a twice indented line of 70 characters will fit in the 80 char limit if the tabstop is 4, while it won't fit it the tabstop is 6 or 8. Furthermore, it still doesn't solve the problem of some editors using leading spaces and others leading tabs on auto-indented lines. It just makes the problem worse.
IMO, the only "rule" that makes sense when it comes to indenting styles is: no tabs, ever.
-- Abigail
makes it clear what 'r' is, and what documentation I should look up.
Eh, no. The documentation of func should tell you what r will be. Unless of course you use a language with a more sophisticated "context" than Perl has.
-- Abigail
Named parameters are trivially simulated in Perl. Both the style where the caller uses positional placement of the arguments, and the style where the caller does something like: ..)
func (name1 => $value1, name2 => $value2,
The former takes one line of extra code: ...) = @_;
sub func {
my ($param1, $param2,
The latter takes two extra lines of code: ...) = @args {qw /name1 name2 .../};
sub func {
my %args = @_;
my ($param1, $param2,
-- Abigail
Syntactic sugar is very important for readability. If you have a function, whose core consists of 10 lines, the function is a lot clearer if it only has 2 extra trivial lines instead of having the 10 important lines burried into 50 lines of mallocs, checking return values of mallocs, garbage collection, painstakingly building lines of text out of fragments, and other braindead lines that are better left to a compiler to add.
-- Abigail
So, you never cut-and-paste after you typed python without arguments on the command line?
-- Abigail
That defeats the entire purpose of having indentation rules, doesn't it?
-- Abigail
But the occasional scripter is irrelevant. That's like saying "Korean is easier to read for the occasional Western tourist than Japanese". It's a meaningless statement.
I often want to do things like make an array of hash tables or a hash table of arrays. In Python these things compose in the obvious way. In Perl, they do not.
Strange. I must be doing something wrong then. Each time I look at Python, I think "they build nested datastructures almost same way as in Perl". The most important thing to remember is that in Python you have by default a reference to an array or a dictionary and have to use extra punctuation if you want a copy of the values, where in Perl it's the other way around. Although you can do it all with references in Perl without using more punctuation.
-- Abigail
$x->{'y'} isn't the same as x.y. $x->{'y'} indexes in a references to a hash (dictionairy). In Python, all you have is a reference anyway, and you would index it as x ["y"]. A bit shorter than the Perl equivalent, but in Perl you can drop the quotes. But in Perl, you can easily embed the $x->{'y'} in a string, which you can't in Python.
As for x.__class__=mypackage.MyClass, in Perl you would bless a variable into a class. Not a significant difference.
Perl also makes heavy use of punctuation marks to mean things which are not only not immediately obvious, they can be confusing.
Oh, yeah, right, punctuation is scary, confusing, and makes thing difficult to read. Take a novel, for instance "Oliver Twist" by Charles Dickens. Now, remove all punctuation in the book. Does it become easier to read? Would it become easier to read if you replace the punctuation by something else? I don't think so. Your example above of x.__class__=mypackage.MyClass contains 7 punctuation characters. The Perl equivalent bless $x, mypackage::MyClass contains 4, 42% less punctuation characters. Python uses puctuation characters as well, and they aren't exactly rare either.
Perl is not as readable as python
Bollocks. There's a lot of bad Perl out there. But that isn't due to the language, it's due to the programmer. If you know the language, and you don't have a sucky programmer, Perl is as readable as Python is, for someone who knows the language, and has code written by a competent programmer. Of course, there are people that will claim that Chekhov isn't as readable as Hemingway, when they just mean they don't understand Russian.
I've been to the perl equivalents, and I've never seen them advertising readability or maintainability
Perhaps you should read some of the documentation that comes with Perl then. For instance, perlstyle(1). I'd like to point out to a Python equivalent, but my Python 1.5.2 came with a whopping 8k of documentation compared to the several megabytes of Perl documentation. (Yes, I am aware of that you need to separately install it, but python.org doesn't have plain text or man page formats for the docs - oouch).
x=['a','b',{'c':'d','e':['f','g']},['h',['i','j']] ]
Djee, that's almost what you would write in Perl. Minimal changes needed: $x = ['a', 'b', {'c' => 'd', 'e' => ['f', 'g']}, ['h', ['i', 'j']]]
The syntax gets really hideous and doesn't mean what it looks like it should.
Well, since it almost looks the same as Python, should we conclude then that Python is as unreadable as Perl? Or maybe you should learn a bit more Perl before you write things like this again.
There's a lot that needs to be improved in Perl, but readability isn't one of them.
-- Abigail
Well, yes, however, isn't one of the virtues of Python that it makes it easier to maintain other peoples code? It's easy for a single programmer to be consistent - but Python forces consistency (to some degree) upon you, to make it easier to work with multiple people on code. With multiple coders come multiple editors. With multiple editors come different ways of indentation. While most programmers will use editors that will automatically indent as much as the previous line (usually, some editors will extra indent if the previous line ends with an opening brace/paren, or a colon), but they aren't consistent on how to pad the new line. Some editors will only use spaces, other editors will use as many tabs as possible. And while on programmer has a tabstop of 8, another has it set to 4.
Using a consistent indentation is good. But forcing it upon the programmer is, IMO, not the best solution. It's not necessary if there's only one programmer, and inconvenient when there are multiple programmers.
OTOH, save of vertical space does have merit. I usually don't care much about it; it isn't too hard to live by, although it sucks if all you want to do is a quick cut-and-paste job. For me, it's not a reason not to program in Python.
-- Abigail
Anita Borg was talking about a decline in percentage, not in absolute numbers.
-- Abigail
Both.
Publishing an exploit is not INTRINSICALLY immoral.
Of course not. I never claimed it was. What I argue against is handing out the tools to exploit a hole (be it a DoS or a security breach) to anyone who wants it.
-- Abigail
Until the end of the war, Japanese Emperors were seen as gods, a status no English monarch ever achieved.
Although the Japanese troops had a well deserved ugly reputation for brutality (especially in Nanking China), the Japanese never embarked on a Hirohito-led genocide.
Ask that to the Koreans. Ask that to the few survivors of the slaves that build the Burma railroad. I'm too young to have experienced the war, but the generation before me did. And from that generation, I know many people that lived in Indonesia in the early 40s. (I am Dutch, and Indonesia was a Dutch dependency at the time). I know many people who spend a significant number of years of their childhood in prison camps. I know people who lost their fathers/brothers/uncles in Japanese labour camps. I know people who were tortured by the Japanese, and suffered the rest of their lives from the consequences. I know people who, after more than 50 years, *still* wake up during the night with nightmares. All done in name of the emperor of Japan.
If Hirohito was as bad as Hitler, then why did he never stand trial as a war criminal, a la Nurenberg?
I've no answer for this twisted US political agenda point. It certainly had not unanimous support from its allies, but given the US dominance, what could they do about it?
A final point. When Hirohito died in 1989, why did the U.S. send dignitaries to the funeral if he was as bad as Hitler?
Economical and political reasons. The US was never (partially) occupied by Japan, nor did it have a significant number of civilians that suffered or died in prison and labour camps.
Let me rephrase that question. Why was it that the Netherlands, who more than any other country in the world depends on foreign trade for its economy, which has Japan as one of its biggest trading partners, and which, like Japan, is a monarchy did not send any dignitaries? No member of the royal family, no political hotshot? Just a tiny delegation from the embassy. And while there were dignitaries a month later during the inauguration of the new emperor, it was a rather small one, and didn't include the queen or her spouse, because the entire concept of "emperor of Japan" is considered tainted.
-- Abigail
Perhaps, but that's not the issue. The analogue would be to hand out sledgehammers to everyone who wants one. Which is totally different than singling out a single door for a presentation.
-- Abigail
Should we also hand out machine guns to gangs, so we will be aware in case of an attack by another country?
Just because it is important to protect yourself and make your site and connections secure doesn't mean it is ok to hand out tools to make attacks easy.
-- Abigail
No, the weakness lies (partially) in the protocol. It's not really feasible for an admin to say "oh, let's get rid of IP4, and use nothing but IPv6".
Doors have weaknesses too. They don't hold against the attack of a tank. And as long as noone starts building tanks and leave them on the street for grabs, that isn't a problem.
-- Abigail
Hirohito was not not a noble man. He wasn't anything better than Hitler.
-- Abigail
That's like saying "hand out untraceble guns so the goverment will speed up the gun control laws". It's a dangerous, irresponsible attitude. I lock my doors not because people can get it - I lock my doors because there are thieves. And I don't fancy the idea to have to hire a security guard because someone is handing out sledgehammers, just to prove the point that doors have weaknesses.
-- Abigail
Oh, really? They would have 2 cities turned into nuclear waste piles less to worry about.
-- Abigail
Yes, one of the things that killed OS/2 and Betamax was that they came to late. If you already have a VHS and a collection of tapes, you aren't going to invest in a new VCR, specially not if your current equipment still works fine. And if you are buying a VCR for the first time, and many of your friends have VHS, the interoperatibility (exchanging tapes) is more important than a better quality.
Technical superiority isn't important for most people. Browser plugins and the ability to send word documents by email to your kids are.
-- Abigail
I disagree with that. It has been publically known for decades that doors don't stand a change against an attack by a tank. My landlord isn't going to put an anti-tank ditch around my apartment. Why? Because only a few have the expertise to create a tank, and those that do, don't leave them on the streets for anyone to grab. And that's more than enough to keep my stuff safe from an attack by a tank.
As long as people behave irresponsible, be it by making actual attacks, or by putting the means into the hands of anyone who feels like it, "hackers" will keep a bad name. Nor is it going to help any open source movement at all. Whining about being portraited in a negative way in the media here on slashdot isn't going to solve that. Do you really think Joe R. Websurfer gives a damn "it's ok to make the tools available", "this attack shows that people have to spend more time and money in securing their sites", etc? No. He notices that his favourite websites were unavailable for some hours. And that the same crowd that wants him to run Linux instead of Windows (partially) defends the actions.
-- Abigail