My working life has mostly been in computer technology and software. Mostly as a technical writer but also as a SysAdmin and technology journalist.

And, in my time, I’ve lived and worked through four so-called tech booms:

1. The Internet/World-wide Web boom of the late-1990s;

2. The mobile computing and social media boom of the late-2000s (ie, the rise of the iPhone and then the iPhone clones running Android, all coincident with the rise of Facebook, Instagram, Twitter, &c);

3. The Blockchain/crypto boom; and

4. The LLMs-that-everyone-erroneously-calls-AIs boom.

And I think I’ve figured out what bothers me most particularly about the current wave of Railway Mania.

The grifters are so obviously in charge of this boom and yet millions of people and millions of businesses are still betting various farms on LLMs.

I don’t mean to suggest grifters weren’t a big part of the three earlier booms. Grifters, operating both inside and outside the framework of legality, are always a key driving force in booms.

But the Internet/World-wide Web boom, and the computer-in-your-pocket-plus-social-media boom both had real, and apparent even at the time, structural and technological change built in to them.

Even my reflexively-suspicious-of-all-grand-narratives-by-dint-of-my-upbringing-and-culture self understood that, the inevitable grift notwithstanding, these two booms were happening because significant technological change was happening at enormous scale.

By contrast, the Blockchain/crypto boom smelled off from the start.

The grifters were more apparent in this boom because the actual thing underlying the con — distributed databases with records linked by cryptographic hashes — was underwhelming, at best.

There was pretty clearly no steak, but there wasn’t even much sizzle. To paraphrase and re-purpose Gertrude Stein’s famous line, there was no there, there.

LLMs have much better sizzle than blockchains had (or have). So I get the interest and even the fascination. This stuff demos really well.

But the people at the helms of the companies promoting the sizzle, are so obviously grifting rather than selling.

It is depressing — but not surprising — to be reminded, again at enormous scale, that, thanks to our selected-for cognitive biases, we

1. still conflate confidence with competence and;

2. still treat the attention of the many as powerful evidence for the truth or intrinsic importance of the thing being paid attention to.

Filling out forms isn't high on most people's lists of fun things to do, even on a rainy afternoon. And web-based forms are less fun than most, despite their being electronic and theoretically amenable to all sorts of nifty automation.

The general lameness of web browsers as a user interface aside, my own irritation meter hits the red zone almost any time I'm called on to enter my address details. I live and work in Australia but many of my commercial dealings on-line are with firms outside the Lucky Country. This often makes filling in the address forms presented by these firms an adventure and occasionally makes it impossible.

Just kvetching about these forms, however, doesn't improve my on-line experience, although it does satisfy other, less noble, regions of the soul. So, in a vague imitation of the spirit of sharing (and in honour of the deadline I almost missed because this little project was more interesting, if not better paying) I offer the following basic form:

---

Billing & Shipping Address

Name:
Street:
City or Town:
Zip or Post Code:
State or Province:	Australia	in Australia? Click here. ACT NSW NT QLD SA TAS VIC WA
	Canada	in Canada? Click here. AB BC MB NB NF NS NT NU ON PE QC SK YT
	USA	in the USA? Click here. AK AL AR AZ CA CO CT DC DE FL GA HI IA ID IL IN KS KY LA MA MD ME MI MN MO MS MT NC ND NE NH NJ NM NV NY OH OK OR PA RI SC SD TN TX UT VT VA WA WI WV WY
	Other
Country:	Australia Canada Great Britain New Zealand South Africa United States of America Other

---

This first go at a multi-country friendly address entry form is deliberately biased towards residents of the English-speaking world. I've assumed an English-language form will be used primarily by English-speaking folk.

Adapting this form for use in other languages isn't difficult, however. On a Portugese-language site, for example, the country radio buttons and state pop-up menus would be switched to refer to Portugal and Brazil with those of us coming from elsewhere still able to fill out the form thanks to the 'Other' text-entry fields. Similarly with a Spanish-language site, where the radio buttons and pop-up menus should provide push-button convenience to folk in Mexico, Spain, Argentina and so on.

The goal is to make things as easy as possible for the majority of those filling out the form without unnecessarily inconveniencing visitors or customers coming from unexpected quarters.

If this form looks like something you'd be interested in using or at least twiddling with, please feel free. You can grab a copy using the Show Source or equivalent command in your browser or download just the form as either a StuffIt or PKZip archive. The StuffIt archive contains a BBEdit text file called form.html complete with Mac OS line endings (ie CR) and ready for use on a Mac OS box. The PKZip archive contains a generic text file called form.htm complete with DOS line endings (ie LF/CR), equally useable on a Mac OS box but better suited to folks using a PC.

Just in case it's not obvious, the above form isn't hooked into any back-end process. You can fill it in to your heart's content but it can't pass the data entered on to anything. The form also doesn't include much in the way of error-checking. It has a few front-end features which should make it relatively easy for any CGI to check for user errors but anyone wanting client-side error checking will need to re-write the form using ECMAScript or some such.

Also, before anyone asks, yes Great Britian has counties and South Africa has provinces, each of which are broadly equivalent to the states and provinces of Oz, the US and Canada. They aren't used as part of postal addresses, however. New Zealand, so far as I am aware, doesn't have administrative regions between the local (ie town and city) and national levels. For more information on address layouts used in various parts of the world the International Address Formats site maintained by the folks at BitBoost is an excellent starting point.

TraceRoute started life as a small utility developed by Van Jacobson in 1988. Originally developed for various flavours of Unix, and distributed as compilable C source code, there are now versions of the utility for VMS, Mac OS, Mac OS X, OS/2 and the various flavours of Windows.

Windows 95/98/Me and Windows NT/2000/XP all include a TraceRoute application, called tracert, as part of each OS's collection of TCP/IP utilities. In each case the application is available from a DOS prompt.

There are also Windows applications with TraceRoute functionality for folks uncomfortable with the DOS prompt, including Holger Lembke's 3d Traceroute and Visual Trace Route from IT Lights Software.

OS/2 includes a TraceRoute utility as part of the OS and like its Windows counterparts, the OS/2 TraceRoute tool is available from the OS/2 command line.

I understand, but have not specifically confirmed, Windows 3.11 users are catered for by the presence of a DOS-based TraceRoute utility with almost every WinSock-based TCP/IP stack.

Mac OS X, Linux and other Unix and Unix-like operating systems (eg *BSD, Solaris and Irix) all come with TraceRoute available at any shell prompt.

There is an X-Windows implementation of TraceRoute available -- Xtraceroute -- but it hasn't been updated since 1999 and has only been tested on a few Unix implementations (old versions of Solaris and Irix and a single Linux release).

On pre-OS X versions of the Mac OS, Brian Christianson's freeware WhatRoute provides Ping, Whois, Query, Monitor and Finger services as well as acting as a TraceRoute utilitiy. Alternatively, version 6.3 of Interarchy (the last version which runs on Mac OS 8.5 through 9.1) from Stairways Software includes a TraceRoute function in that application's Watch menu.

Both WhatRoute and Interarchy are also available in OS X-only versions and these versions provide TraceRoute functionality for Mac OS X-using folks uncomfortable with opening a shell prompt.

Usage

To create a traceroute log under Unix, Linux or Mac OS X simply type 'traceroute [destination]' (where '[destination]' is the IP number or domain name of the machine you wish to trace to) at any shell prompt and hit Enter or Return.

The process is similar under the CLI-based/DOS-based traceroute applications available under Windows or OS/2: fire up a DOS prompt and type 'tracert [destination]' (without the quotes and with the appropriate numbers or words in place of '[destination]') and hit Return.

WhatRoute and Interarchy for Mac OS both provide a text box in which you simply type the IP number or domain name you are heading for. Likewise with 3d Traceroute and Visual Trace Route under Windows. In all these cases, hit the Return key after you are done typing. (In WhatRoute also check the pop-up menu (which allows you to choose which service you want to access) is set to TraceRoute.)

Once TraceRoute has a machine name or IP number in hand it goes out and does its simple but rather nifty thing.

TraceRoute sends out very small (typically 40 byte) UDP datagrams with even shorter Time To Live (TTL) counters in the packet header. The TTL value in a packet header is the number of routers the packet is set to travel through before a router is allowed to throw it away (presuming it doesn't reach its stated destination beforehand of course).

Examples are always easier so, presume you are setting out to create a traceroute log for the router path between your machine and the ZDU home page at welcome.zdu.com. TraceRoute sends out a UDP datagram with its destination set to welcome.zdu.com and its TTL set to one.

The router at your ISP receives the packet and reduces the TTL value by 1. Since this reduces the TTL to 0, the router promptly discards the packet. At the same time it also creates an Internet Control Message Protocol (ICMP) error message (TIME_XCEEDED_INTRANSIT, to be precise) and sends this error to the sender address on the packet (ie, your machine).

TraceRoute receives this error message and does several clever things with it. First it pulls the IP number of the issuing router out of the ICMP, then it does a DNS reverse look-up on that router. Finally, it logs the time it took for the packet to make what is, in effect, the round trip.

TraceRoute sends out three such packets for each value of TTL specified. Almost invariably TTL=30 is the maximum number used, although it is possible to change that if you wish.

TraceRoute continues to send out its little three packet bursts (each burst with a TTL one higher than the previous) until it reaches the router marked as the destination in the IP packet header. TraceRoute's last trick is played here. The destination router un-wraps the packet to see what to do with it only to discover that the little datagram is aimed at port 33434, a ludicrously high port number with no known use. (By way of example, HTTP services -- ie web sites -- are commonly served up on port 80.) This also generates an ICMP error message, but not a TIME_XCEEDED_INTRANSIT error. Instead the final routers sends an invalid port error message, which traceroute interprets as the end of the line.

The end result is the TraceRoute log: a table of IP numbers, domain names (if they are returned by the reverse DNS look-up) and times. There are three times per router (ie per IP number/domain name) and said times are normally given in milliseconds.

Logs

To put this in concrete, consider the traceroute log I generated below from an HP-UX machine in Victoria, Australia to welcome.zdu.com.

The HP-UX box gets its TTL=1 packet back from its uplink router (cbl-gw.cpl.com.au) in about 4.27ms (averaging the three times logged). The round trip time for the TTL=2 packets varies rather wildly, with two packets taking about 85ms to make the trip and one taking only 28ms.

It's important to note that these times are not cumulative. The numbers returned are the round trip times taken for the packet to go from the originating machine all the way to the machine which kills the packet and returns the error message and back again.

Things go along pretty smoothly until we hit router 5, the first router outside Australia. Suddenly the round-trip is taking about six times as long as the trip to router 4. Moreover, I'm losing packets with monotonous regularity (the '*' entries in the table are packets which didn't make it back at all). Solid evidence that the Telstra to MCI link across the Pacific ocean is in dire need of an upgrade (as if more evidence was needed, but that's a whole political story for elsewhere).

More generally this points to the usefulness of traceroute logs for rooting out bottlenecks between you and your target. Any sudden increase in the round-trip time when hopping from one router to the next is a strong indicator of the latter router being a bottleneck. Lots of lost packets after a particular router are another indicator of problems, although lost packets are probably best investigated with Ping.

In the case above it's the Telstra-to-MCI gateway, which is why I personally use an ISP which doesn't use Telstra's US link at all (they have their own gateways to San Diego, London and several South-East Asian countries).

Connection Quality

Finally, traceroute can help get a sense of the quality of your personal Internet connection.

Run TraceRoute to the hostname of your ISP. So, traceroute to earthlink.com if you are an EarthLink subscriber; aol.com if you use AOL; telstra.com if you're stuck with Telstra; internode.com if you're with Internode and so on. (NB, you don't have to TraceRoute to your ISP's main host, but it does makes for a short trip, which gets results back to you quicker.)

Take note of the round-trip times for the second machine on the resultant list of computers between you and your ISP's main host. This second machine will likely be the router directing traffic between you and the outside world. (Especially if you have broadband, the first machine is almost certainly your own router, routing traffic from your home LAN or computer up the link to your ISP.)

If you have dial-up connectivity, a 300ms or so round-trip to this router is a sign of decent connectivity. Anything much over this and there is something slowing things down.

If you have broadband connectivity (eg a DSL, ADSL or cable connection), a round-trip to this 2nd machine shouldn't take more than 50ms or so.

It's important to note a single slow round-trip isn't automatically a sign there is something wrong. Even having all three packets take 'too long' to get back isn't a reason to call tech support. If, however, you get consistent slow returns over time, it's worth looking for a cause (remembering, of course, the problem may well be at your end: don't assume slow returns from your ISP's main router are your ISP's problem).