The Rants, Raves, Gripes, and Prophecies of Paul R. Potts

Contents by Category

Contents by Date

Favorite Links

My Wiki: main entrance
Boing Boing
Gwydion Dylan
Paul Graham
Richard P. Gabriel

Wed, 13 Aug 2003 Fraudulent eBay Mail

I've been receiving mail allegedly from eBay containing HTML and a form requesting my user ID and password, with the following text:

Dear eBay User,

During our regular update and verification of the accounts, we could not verify your current information. Either your information has changed or it is incomplete. As a result, your access to bid or buy on eBay has been restricted. According to our site policy you will have to confirm that you are the real owner of the eBay account by log in and complete the form that will pop up or else your account will be suspended without the right to register again with eBay.

I've been using the Internet since before it was the Internet, and so this immediately said "a cheesy fraudulent attempt to harvest passwords." I reported it to along with full headers. This is just a reminder to my loyal reader that reputable companies will never attempt to harvest information in this way.

The headers are suspicious, to begin with:

    Received: from 
    ( [])
        by (Postfix) with SMTP id 710D928062
        for <>; Wed, 13 Aug 2003 05:43:24 -0700 (PDT)
    Received: from unknown (HELO (unrinocer@ with login)
        by with SMTP; 13 Aug 2003 12:43:18 -0000
    From: "" <>
    To: "Paul" <>
    Subject: eBay Verification Request

Note the "received from unknown" with a raw IP address rather than a verifiable hostname. It looks like it may be going through an open mail relay at Yahoo, which is very strange and suspicious, so I have also reported this to

The page contains a lot of JavaScript, and pulls graphics directly from eBay's site, but look here:


Note the super-long URL, with a bunch of fake ".dll" script names given, and then a bunch of crap designed to fill up the address line in your browser, so that the end of it is hidden. It looks like this is actually running a PHP script (a.php) on a server with a given IP address (; the garbage is just to "decorate" the URL sufficiently so that it looks like an eBay URL, and so that you'll be unlikely to notice that the address isn't a real eBay address. If you hit this address with the "decorated" URL, it redirects you to eBay after processing. The raw IP address seems to belong to "ValueWeb: An Affinity Company" which seems to be an ISP, but who knows who it really is. Let's be careful out there.

[/root/geeky/life] permanent link

Thu, 07 Aug 2003 Impeachment's Too Good for Them

So, to politics and the "war." It is hard to describe my level of anger these days: every day, the situation becomes more unbelievable. It is very hard to just lapse into utter cynicism. I've been giving more thought to emigration. What the hell has become of this country's leadership? More importantly, what has become of this country's "followership" that we are not rioting?

The president has now claimed "personal responsibility" for everything he said and did. That's great. So when will the trials begin? Impeachment is too good for this crew. An international war crimes tribunal along the lines of the Nuremburg trials is in order. That may seem like an outrageous statement, but let's review:

First, we are not "at war." No one has declared war on us; we have not declared war on anyone. The power to declare a state of war resides in Congress. They have not done so; instead, they gave the president authorization to use force to conduct the "war on terror." Please remember that every time an administration official uses the excuse that "this is a war," or "we are at war," this is inflated rhetoric and not literal truth. The Pearl Harbor attack had a sovereign nation behind it; the September 11th, 2001 attacks had a shadowy, stateless cabal.

Second, we were not at risk from Iraq. Every element of the administration's case that Iraq represented an imminent threat to the security of the United States has been shown to be false or grossly exaggerated. The case the administration made regarding the danger of Weapons of Mass Destruction, far from being just sixteen words in the State of the Union address, was hammered home consistently and repeatedly on many occasions. Make no mistake, this was a big, big lie, not just an exaggeration on an occasion or two. The case for links between Iraq and al-Quaeda was also a lie.

It was on these grounds that that administration led us, not "to war" exactly, but to the violent invasion, occupation, and demolition of a sovereign nation. This is a war crime on a scale virtually without precedent, known in international law as aggression.

Based on these lies, the United States did this to a nation with which we were not at war. We did not just "liberate the Iraqui people." We:

What did we achieve? What do we expect to achieve? Is this the way to do it? If our case was to end the suffering of the Iraqui people under Saddam Hussein's administration, was this the way to do it? If this was our real agenda, we've done a shockingly poor job of it. If it wasn't our real agenda, what was? Can this really be all about control of oil? If so, we've done a pretty piss-poor job of that, too. Support for Israel?

One thing should be glaringly obvious: a tissue of lies cannot justify this naked aggression. To go to war, declared or not, to invade a sovereign nation and kill its people -- this is pretty much the gravest act a nation can undertake. A decision to do what we have done should never be taken lightly. I believe it is possible for military action to be justifiable, but if ever there was a case in which it was not, this is it.

Liberia has been begging for American intervention. We ignored them for months. A humanitarian disaster zone demanding "regime change," we've said "we're going to let the U.N. handle this one." (Apparently, we've now got a few advisors on the ground). Is this the same U.N. that we declared "irrelevant" because it would not rubber-stamp our rush to invade Iraq?

This appears to me to be the most openly and blatantly corrupt and corporatist administration America has ever seen. We've got Richard Perle, the unelected antichrist, threatening to sue people for telling the truth about his profiteering. We've got Paul Wolfowitz, who has suggested that liberating the Iraqui people was "not a reason to put American kids' lives at risk, certainly not on the scale we did," but that allowing the U.S. to withdraw troops from Saudi Arabia was a "huge" factor and that WMD was chosen for "bureaucratic" reasons. But does this make any sense? Most of the 9-11 hijackers were Saudi, and the administration has been hiding intelligence regarding Saudi Arabia's role in 9-11 -- even over Saudi Arabia's strenuous objections.

We've got secret blacklists of American dissidents. We've got fiscal policy that seems to involve playing chicken with bankruptcy. Radio and television stations that run anti-Bush ads are being threatened with revocation of their FCC licensing. Free speech and civil liberties are becoming increasingly things that exist only for the right kind of people.

We've got the most blatant and openly corrupt and criminal administration in American history lying, manipulating, cheating, and profiting. If this is not a case for impeachment, then no such case can ever be made; if it is not a case of criminal wrongdoing, then no act by a government official could ever be criminal. Is this what it has come down to?

[/root/iraq] permanent link

Tue, 05 Aug 2003 Dylan

So, it has been a while since my last entry... please bear with me. I've been putting in evenings and weekends trying to build a large proof-of-concept in code, using the Dylan language. Aside from politics, it has been uppermost on my mind, so here are some words on Dylan.

Although the language has yet to prove itself commercially viable (Apple pulled the plug on its Dylan implementation and closed the Cambridge R&D lab which developed it; the Gwydion project is now open-source, and Functional Objects, which spun off the Functional Developer IDE from Harlequin has announced its intent to open-source the rest). Although the various implementations have flaws, Dylan remains my personal favorite language and should be, I believe, considered the worthy heir apparent to Common Lisp.

Its most obvious difference from Scheme and CL is a Pascal-like infix syntax, rather than the familiar prefix, parenthesized notation. One could argue that it is the Lisp syntax, or lack thereof, that makes code-as-data S-expressions and language extension via macros possible. It certainly makes it simple to implement, but Dylan has proved that it can be done without the Lisp syntax. Hardcore Lispers will argue that the syntax is "just syntax" and therefore irrelevant, but Apple calculated, quite rightly I believe, that to improve the acceptability and promote the language beyond the existing Lisp community, a more familiar syntax would be necessary. I think this is true, but of course this has been "necessary but not sufficient" to promote widespread acceptance; many other factors, obviously, are involved in language acceptance.

Like many things Apple developed during the 1990s (QuickDraw GX typography, OpenDoc, system-wide encryption, and a long list of others), the implementation could not keep up with the concept. Apple's Dylan IDE, implemented in Macintosh Common Lisp, ran painfully slowly on a Quadra 800 with 40 megabytes of RAM (this machine sported a 68040 at 33 MHz). I've never had a complete explanation of why this implementation ran so slowly, but it has something to do with an inefficient implementation of an object database for all source records and compiled code objects. Apple's IDE was far ahead of its time; ten years later, IDEs have not yet caught up, although I have had the pleasure of using systems such as IBM's VisualAge for Java which have gotten part of the way there. To see my notes and screenshots of Apple Dylan, take a look at these pages on the Dylan Wiki.

Both the two major current implementations, Gwydion Dylan and Functional Developer, are a little bit rough around the edges, especially in error-reporting and ease of configuring projects. Dylan has an extremely sophisticated module system that gives you fine-grained control over how bindings are imported and exported; it is much more advanced and flexible than C++ namespaces, but it extracts a certain penalty in overhead when building a complex, multi-module project out of text files. Refactoring code under the Gwydion system becomes somewhat painful when I must adjust "use" declarations, "export" declarations, .lid files, and module headers at the beginning of source files. Not to mention the makefiles. Failure to get it right results in somewhat opaque, and sometimes downright childish, errors ("puked when trying to load module..."), ("can't handle hairy classes yet,") and claims that I'm trying to define a class in a circular manner. Clearly it is still a bit of a hackers' tool, and user-friendly error messages are not its strong point, but it does the job. And unlike some scripting languages, generating efficient code, and providing a clean interface to C, are design goals that have been achieved. d2c generates C code, essentially creating a virtual stack and named locals for temporaries, as if C were its machine language, and executing very low-level C constructs. It is a case study in optimization. Providing type specifiers allows the compiler to generate very optimized code; leaving everything open provides maximum flexibility for the developer. (In the Lisp tradition, variables don't have types, but values do; Dylan allows you to give your variables types, and the compiler will enforce them).

Although Dylan's module and type system should enable exact tracking of dependent changes and thus minimal recompilation, the d2c compiler seems to always recompile each file in the project, and as the maintainers note, "d2c generates fast code slowly." I've been trying to ameliorate this situation by building libraries, but library support is off-the-bat slightly broken under MacOS X; the Carbon library is slightly broken as well. I've found a few bugs, and already received one patch from the maintainers. I've had to work around some strange behavior. I've had to revise some of the distributed libraries. I've managed to patch these things up, but communication with the maintainers via the mailing list has been flakey as well. I can't exactly complain; It is an open-source project; I can contribute fixes to the maintainers. But contributing patches to an extremely sophisticated compiler requires a pretty deep understanding of the compiler internals, and despite its failure to be user-friendly to questionable code, this is a very advanced optimizing compiler.

As open-source projects go, no one would claim this is a good starter project. Most of my working time is committed to paid work, but I am still going to do what I can to contribute. I've wanted to see Dylan succeed for almost ten years now. Even if it succeeds for no one but me, that's a strategic advantage and an opportunity to write code at a higher level.

Functional Developer is a more polished implementation, although it is still capable of bringing my Windows ME machine to its knees after a bit of use. (This is probably more a comment on Windows ME than on FD). Its error messages are also sometimes a bit confusing, and there are some slight differences between what d2c finds acceptable and what FD does. The interactive debugger is a bit baroque. But it works; I was able to port a lot of code, checking it into CVS from a Gwydion Dylan project and checking it out on the PC.

There's a great potential for someone to coordinate a serious development effort here. Dylan is languishing, and it doesn't deserve to. It already provides, in a formal and sophisticated way, what scripting-language writers are struggling to provide. It has higher-level functions; it has multi-methods; it has advanced capabilities for optimization. It has a macro system. What it lacks is a user base and a supported commercial implementation worthy of the language design itself. That sophisticated module and export system? It cries out for a graphical tool. (That's how I keep track of my exports and imports: I draw them with OmniGraffle, a great graphing tool for MacOS X, and let it lay out the graph for me). The error handling? It cries out to be polished up, not abandoned. Did you know that four books on Dylan have been published? Probably not. They are all out of print, although you can still get copies of two of them. But they aren't the last word. The language cries out for an O'Reilly book. Maybe I'll be the one to write it.

[/root/geeky/programming/dylan] permanent link

Creative Commons License

Viewable With Any Browser