The Rants, Raves, Gripes, and Prophecies of Paul R. Potts
Contents by Category
Contents by Date
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 email@example.com 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 smtp016.mail.yahoo.com (smtp016.mail.yahoo.com [126.96.36.199]) by ludo.dreamhost.com (Postfix) with SMTP id 710D928062 for <firstname.lastname@example.org>; Wed, 13 Aug 2003 05:43:24 -0700 (PDT) Received: from unknown (HELO 188.8.131.52) (email@example.com with login) by smtp.mail.vip.sc5.yahoo.com with SMTP; 13 Aug 2003 12:43:18 -0000 From: "firstname.lastname@example.org" <email@example.com> To: "Paul" <firstname.lastname@example.org> 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 email@example.com.
action=3Dhttp://scgi.ebay.com.sawcgi.eBayISAPI.dll. RegisterEnterInfo.RegisterConfirmInformation.dll. eBayISAPI.firstname.lastname@example.org/ eBayISAPidlldasSKJEDFKJSdsalkepoamncjfdsjKKdsjdxcmnzkjsjeLKKLKdsjnxs/ ksjdeISJJSjjISSdlldkDKJlLXcdcawerfDEurERRudsksalfkmcxXXlkdmfldll/ LKJDjedssjheflkcgieBaysadkKJEDjdfklluseridLKSKdskdmxskjdeEEdkjas7837sdkjd/ a.php
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 (184.108.40.206); 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.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:
KILLED IRAQUI MILITARY PERSONNEL, in numbers unknown, and which will probably always be unknown, but the number certainly can't be less than 10,000. We used massive ordnance, including cluster bombs, depleted-uranium weaponry, "bunker busters," and fireboms (napalm). The carnage is hard for us pampered, well-fed Americans to fathom. We did it. Us. America the beautiful.
KILLED IRAQUI CIVILIANS, The site Iraq Body Count (here) reports somewhere between 6,000 and 8,000 civilians killed, at least 20,000 injured, and a country littered with unexploded cluster bombs and radioactivity.
KILLED AMERICAN SOLDIERS. At least 52 have been killed by hostile fire since the declared "end" to the war; at least 112 have died of all causes, including suicide. At least 827 Americans have been injured; some sources say the number is in the thousands. The official number of combat deaths stands at 166, which is more than the American death toll in the first Gulf War. The total death toll is officially 248, including accidents. And more are dying almost daily. Some are even killing themselves.
KILLED HUSSEIN'S SONS. Rather than capture and put to trial ranking members of Saddam Hussein's administration, we prefer to kill them and exhibit their bodies, after some "facial reconstruction" to make them recognizable, following the use of 200 soldiers, assault helicopters, grenades, 50-caliber machine gun rounds, and ten anti-tank missiles - so much firepower that the house has now been declared structurally unsafe and demolished. (How many of you know that Saddam's grandson, Qusay's 14-year-old son, was also killed?) The weapons that Uday and Qusay and his son and their bodyguard had on hand are less clear, but apparently included at least one AK-47, and depending on the account, possibly pistols and grenades.
INFLAMED THE WORLD.
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?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.