Thursday, January 26, 2006
He's Out!
The Younger has left the hospital!
Thank God that's over.
And if The Younger ever eats another magnet again, I'll kill him! Sheesh!
(/= 2 2)
My recent post on Lisp generated some heat. First, from Zach:
From: Zach XXXXX <XXXXXXXXXXXXX>
To: Sean Conner <sean@conman.org>
Subject: (/= 2 2)
Date: Thu, 26 Jan 2006 10:56:38 -0500I came across your Lisp post today, and I wanted to comment on a couple things.
FIRSTandLASTare not analagous toCARandCDR;LASTreturns some part of the tail of a list (depending on its optional second argument). The list-oriented analogue ofCDRisREST. (You had that, but crossed it out.)As for 2 not necessarily being equal to 2, there are many equality predicates in Common Lisp. For example, comparing 2 and 2 with the
EQL,EQUAL,EQUALP, and=functions will all return true (or there is a bug in the implementation). It is only the object “same, identical” predicateEQthat will sometimes fail on two apparently identical numbers, and even then it's only likely when the number enters the bignum range. Fortunately, most documentation and tutorials give the good advice to useEQL(notEQ) as a default “sameness” test. A novice would have to take a fairly peculiar learning path to get burned by usingEQon numeric values.
We had a bit of an exchange and I ended up writing:
From: Sean Conner <sean@conman.org>
To: Zach Beane <XXXXXXXXXXXXX>
Subject: Re: (/= 2 2)
Date: Thu, 26 Jan 2006 15:18:07 -0500 (EST)Hmmm.
Odd thought just cross my mind. It may not be fully applicable to Lisp and it's half formed, but I'll try to get it out anyway.
Lisp is a dynamically typed language, and a lot of programmers like dynamic typing since it frees them from the burden of having to declare the type of a variable [1] (often times the excuse is “I'm prototyping—I don't know what types I'll end up using.” [2]). Having to declare the type of a variable is seen as pointless pedantry and something the compiler can keep track of [3].
I feel the same way about the equality functions in Lisp—pointless pedantry and something the compiler should keep track of.
- Yes, in Lisp, values have types, not variables.
- A weak excuse in my opinion. Strikes me as being muddle headed about what the program is supposed to do. I should mention that I actually liked Ada, and tend to prefer strict type checking, if only to make sure I don't make bone headed mistakes.
- Fair enough argument, but I'd prefer to state my intent to the compiler anyway. The more information it has, the better off it is.
Just how much of a pointless pedantry is Lisp's equality functions? Well, there are five defined in Common Lisp (quoted from Paul Graham's ANSI Common Lisp):
(eq object1 object2)- Returns true iff object1 and object2 are identical. [It doesn't say what it means by “identical” but given that
(eq 2 2)can be false in a conforming implementation of Common Lisp, I'm guessing “identical” means “same address”](eql object1 object2)- Returns true iff object1 and object2 are
eq, or the same character, or numbers that would look the same when printed. [So even here,(eql 2 2.0)is still false, at least, according to Rodney A. Brooks Programming in Common Lisp.](equal object1 object2)- Returns true iff object1 and object2 are
eql; or are conses [one element of a list] whose cars [first element] and cdrs [rest of the list] areequal; or are strings or bit-vectors of the same length (observing fill pointers) whose elements areeql; or are pathnames whose components are equivalent. May not terminate for circular arguments. [So, I guess this means that(equal 2 2.0)may be false as well](equalp object1 object2)- Returns true iff object1 and object2 are
equal,char-equal[um … I guess there are more than just the five equality functions then], or=; or are conses whose cars and cdrs areequalp; or are arrays with the same dimentions whose active elements areequalp; or are structures of the same type whose elements areequalp; or are hash tables with the same test function and number of entries whose keys (as determined by the test function) are all associated withequalpvalues. Reasonable to assume that it may not terminate for circular arguments. [So, if you want to compare arrays, you can't useequal, and still(equalq 2 2.0)is false.](= n1 &rest ns)- Returns true iff the difference between each pair of arguments is zero. [Finally! We have an equality test where
(= 2 2.0)may be true!]
Why so many? I don't even want to hazzard a guess (perhaps Lisp programmers like micromanaging equality whereas C programmers like micromanaging variable type information—oh darn, I hazzared a guess).
My friend Andrew wrote in:
From: Andrew XXXXXXX <XXXXXXXXXXXXXXXXXXXX>
To: Sean Conner <sean@conman.org>
Subject: An apology for Lisp
Date: Thu, 26 Jan 2006 14:58:44 -0500 (EST)If you still think Lisp is wrong, then consider this: is 2.0 equal to 2? Why or why not? I think reasonable people could disagree, and the designers of Common Lisp did too; that's why there are multiple equality predicates with different semantics.
As for avoiding lists to get “real speed”—you say that like nobody uses O(N) complexity data structures to do real work in C! Lisp lists are what they are; for many applications they're fast enough. Otherwise, Common Lisp has arrays, hash tables, and more.
Okay, but if there are languages out there that can do type inferences on data, then certainly languages can also do equality inferences with data as well. Or perhaps I've been corrupted with Perl and it's very lax approach to equality …
And to Lisp's other data structures? Most introductions to Lisp I'm familiar with start with lists, and rarely, if ever, mention any past that. For instance, Rodney Brooks' Programming in Common Lisp, a 12 chapter book and arrays are first mentioned in Chapter 12! (“Other Features of Common Lisp”). And even though Paul Graham mentions arrays, trees and hash tables in Chapter 4 of his ANSI Common Lisp, the chapter title doesn't do them any service in my opinion (“Specialized Data Structures”—I really didn't know arrays were a specialized data strcture). Also, the way lists are described ad-naseum in Lisp books, which special pains to point out the structure of the “cons cells” that it seems like Lisp is still stuck with a 60s implementation.
Oh, it's still useful, just not as useful as I expected
By using ltpstat
I've been able to see that the LaBrea tarpit isn't quite
as effective as I first thought. Yes, it does slow down scans, but not
quite as much as one thinks. I'm guessing that scanning software now
includes the “timeout” concept—if a connection takes too long, drop the
connection and move on.
A few days ago I added a feature to ltpstat to remove
entries that have not seen any activity for over an hour (default setting).
After running the tarpit for over a day, I see the following stats:
Jan 27 01:57:08 ltp ltp-report: Start: Wed Jan 25 17:27:55 2006 End: Fri Jan 27 01:57:08 2006 Running time: 1d 8h 29m 13s Jan 27 01:57:08 ltp ltp-report: Pool-max: 1048576 Jan 27 01:57:08 ltp ltp-report: Pool-num: 107287 Jan 27 01:57:08 ltp ltp-report: Rec-max: 1048576 Jan 27 01:57:08 ltp ltp-report: Rec-num: 107287 Jan 27 01:57:08 ltp ltp-report: UIP-max: 1048576 Jan 27 01:57:08 ltp ltp-report: UIP-num: 2558 Jan 27 01:57:08 ltp ltp-report: Reported-bandwidth: 32 (Kb/sec)
Okay, I've “captured” 107,287 connections. But how many of those are still active?
Jan 27 01:58:32 ltp ltp-report: Removing records with no activity for the past 1h Jan 27 01:58:32 ltp ltp-report: ... keeping 11180 records with activity since Fri Jan 27 00:58:31 2006
Well then. Over 96,000 connections were no longer “active” and of the 2,558 machines doing the scanning, some 2,200 had moved on.
So it looks like the LaBrea tar pit is really only useful to see what's
being attacked, and which machines on the Internet are really doing the
attacking (so far, 24.73.129.197 seems to be quite tenacious in
scanning).
And the ports being scanned? Again, it's the Microsoft specific ports as usual. No use making a chart this time.
