>>> 2021-01-16 psychic fiends network

I have read before an idea that there is a "innovator's disadvantage," in that the country that invents a new technology, if it's something that requires widespread adoption, is likely to end up with standards that are inferior to countries that adopt the technology later---because the later adopters have the advantage of incorporating benefits over the following years. That was sort of a tortured sentence, so let's instead try a more concrete example: broadcast television was first widely implemented in the United States. In the US, we ended up with NTSC. The European standard, PAL, was developed some years later, and so it took advantage of improvements in technology to provide a higher resolution.

The US had broadcast television first, but Europe got a better version of it.

I bring this up as a preface to the observation that this does not hold true in the area of phone number allocation. Perhaps through some excellence on the part of AT&T, but perhaps just through luck, the United States has enjoyed a coherent, well-ordered numbering plan for nearly the entire history of the dial telephone. In contrast, many later adopting countries have numbering systems that are relatively very confusing and imprecise.

When I refer to United States phone numbering I am, of course, talking about the North American Numbering Plan, which is also inclusive of Canada and some Central American and Caribbean countries (and formerly Mexico). One of the things that differentiates the philosophy of NANP from that of other national numbering schemes is NANP's strict insistence on geographical organization, rather than service-based organization.

That is, with few exceptions, NANP telephone numbers are based on where the telephone is, not what kind of service it is.

This scheme seems to be generally easier to understand and more useful, but it incurs the significant disadvantage that tolls must either be the same for all telephone numbers within a geography, or telephone users will be quite confused about what to expect on their next phone bill.

In this message, I'd like to explore some of the odd corners of telephone tolls and billing, and look at how industry for some time exploited these.

Let's start with a simple scheme of how telephone billing normally works: for many telephone subscribers (back in the landline era), calls within the same numbering plan area (NPA, commonly called area code) are free. Calls to other NPAs will incur an additional charge as toll-free. Calls to other countries require an international dialing prefix and will incur an additional charge as international.

Many things complicate this scheme, such as areas in which not all of the NPA is considered within the same calling area (technically speaking, calling areas/toll centers are separate from and do not necessarily match up with NPAs), and services like WATS (wide area telephone service) which complicate the definition of "long distance" further. But, that's the general idea.

A major exception to this simple system is telephone prefixes which incur special billing behavior. The most obvious example of this are numbers in the 800 NPA, and now the 855, 866, and 877 NPAs, which are "toll free." Toll free calling might be more descriptively referred to as "reverse charge" calling, because the special billing feature is really that the person called pays instead of the person calling, but the term "reverse charge" is usually reserved to describe collect calls that involve an operator to handle the billing exception, rather than the surprisingly complex infrastructure behind toll free numbers.

Another exception, which is rarely discussed these days, is NPA 900. While it historically served other purposes, NPA 900, or "1-900" numbers, was allocated to "premium rate" services by the '80s. "Premium rate" services charged a per-minute access fee, which was handled by the telephone company---so that it appeared on the normal telephone bill of the caller. These fees were sometimes rather substantial, with $3 and $4 a minute being not uncommon.

As you can imagine, 1-900 numbers were highly subject to abuse. Sex lines seem to be the best remembered today, but more clearly malicious was the trend of television commercials encouraging children to call 1-900 numbers to rack up fees for their parents.

In a clear reflection of the government and telephone industry's surprising inability to actually control the telephone system in any way, this was a more or less accepted practice for quite some time. While a clear scam, it involved no real fraudulent or deceptive behavior. The "third party billing" system was working exactly as designed, with telephone companies passing on charges that were incurred by the "customer" intentionally calling in. The controversy just revolved around how aware the "customer" was of what was actually going on.

As you can imagine, the situation slowly grew into a bigger and bigger scandal, particularly with the revelation that telephone carriers were largely "in on" the scam and made an appreciable profit off of it. Eventually, the government took action, and a series of regulations were implemented which made 1-900 billing abuse more and more difficult in practice.

What gets a bit more interesting is what happened afterwards.

It turns out, with 1-900 billing restricted, creative entrepreneurs with relaxed morals were able to find a series of interesting new ways to third-party bill the caller. These are fun.

One of the earliest methods tapped into a classic malicious exploitation of what might be considered a flaw in NANP: as I have said before, NANP was originally envisioned as a global numbering scheme, not a national one. For that reason, Canada and the US share a country code. This tends to not be too big of a problem, because Canada has reasonably reliable telephone providers and calls from the US to Canada are not usually so expensive as to cause an uproar.

What is a little more problematic is that a lot of people don't realize that a number of small Caribbean nations also share that country code. Long lines to these countries are relatively expensive to install and maintain, leading to high international calling rates. And further, the small telephone carriers in these countries are often more amenable to corruption than the large and heavily regulated ones in the US and Canada.

This has lead to the purely malicious activity of tricking people into calling one of these countries and getting a surprise bill, but how can it be worked to the advantage of former 1-900 scams? That's where the corruption comes in.

Foreign telephone carriers have a certain de facto ability to third-party bill US subscribers who call them, because the overseas telephone carrier can require a high toll and then split that collected toll with the company that directed the traffic towards them. Effectively, this is just another premium-rate number, but without the 900 prefix that consumers had come to know.

This same scam exists today, although in a somewhat modified form. The use of television commercials and especially late-night infomercials to direct callers is no longer as effective, particularly since telephone carriers have started requiring that callers dial the international calling prefix to make most international calls within NANP. This makes it much less likely that a caller won't realize something is strange about the number they're calling.

That said, to this day you will occasionally find cases of people being tricked into calling an overseas number and paying a high international calling toll, which the foreign telephone company then splits (as a kickback) with the person who tricked them into calling. You may also encounter a similar but slightly less malicious version of this scam with domestic numbers, as various toll-sharing agreements allow US carriers to earn some money merely from receiving calls, but the dollar amounts involved are far smaller.

In the era of peak premium rate scams, though, the requirement to dial with an international calling prefix was not necessarily a major deterrent. From the Internet Archive's VHS collection, I've seen several examples of late-night infomercials for phone dating or phone sex lines from the '90s that gave an outright international number with 011 prefix. It's likely that they were taking advantage of telephone users who never called internationally and so didn't realize that 011 indicates an international call.

This seems to represent the late stage of the international calling workaround, and although it produced some truly incredible infomercial programming I don't think that it was especially successful. A lot of people wouldn't have even had international calling enabled on their telephone plan, and the whole scheme requires the cooperation of an overseas telco which makes it more difficult to stand up.

The use of international calling was fairly short lived, and I'm not aware of any specific technical or policy actions taken to close this "loophole," so I tend to suspect that the abuse stopped because... it just didn't work that well. People rob banks because that's where the money is, after all.

Of course, telephone scammers are creative people, and other solutions were found. One that I find particularly interesting is the use of dial-around or 1010 calling. For those who haven't seen me mention this before, dial-around was a feature introduced by regulation that resulted from lobbying by the new industry of competitive long-distance carriers, which wanted to reduce the advantage that AT&T held by being the "default" long-distance carrier.

Essentially, dial-around calling consists of entering the prefix 101 followed by a four-digit number (which often starts with 0) that identifies a long distance carrier. You then enter the number that you want to call, and the call will be placed using the long-distance carrier you selected. This allowed telephone users to "shop around" and select specific long-distance carriers depending on their rates to specific areas, and made the whole long-distance industry much more competitive.

Experience has shown, though, that small telcos can't be trusted in the United States either. Telephone scammers created a series of "long distance carriers" that really just served as feeders to the same type of content that had formerly been placed on premium rate lines. Television commercials told people to dial an oddly long phone number that included a dial-around prefix. Since the "selected long distance carrier" had the right to bill the caller for the long-distance rate, they could simply charge a high long-distance rate and split it with the operator of the phone number (which was very likely the same person anyway).

This abuse of the system is a particularly interesting one, because it's a case where scammers took advantage of the system by actually creating what was, nominally, a telco---but was in reality just a front. This is oddly fascinating to me. Phone phreaking has always elucidated this wonderful idea that the telephone system is a mysterious place full of hidden corridors and strange rooms, and that rarely seems more true than when you look into fraudulent telcos that set up telephone switches just to trick people out of a few dollars.

For all the problems we have today with spam calls, we have to remember that malicious engineering of the phone system is in no way new. People have been up to things with telephones since Alexander Graham Bell first wired one up.

A very similar phenomena has occurred with toll-free numbers and the strange world of RespOrgs, which I will talk about in the future. There are gremlins in the toll-free system as well. I also plan to talk about a few other cases of "unusual" NPAs that break the general rule of NPAs corresponding to a physical area, and that have interesting billing properties.

>>> 2021-01-12 taking this serially

Conceptually, if we want two computer systems to communicate with each other, all we need is a data link over which we can send a series of bits. This is exactly what serial interfaces do. You can probably quickly imagine a simple and effective scheme to send a series of bits in order, which is precisely why there are a thousand different standards, many of them are confusingly similar to each other, and the most popular are remarkably complex.

So, in this message, I will try to break down what exactly a "serial port" is. I will only be talking about the hardware standards in this case, not the software side of a COM port in Windows or a tty device in Unix derivatives. That's an interesting topic, and I hope to write about it some time, but it will be A Whole Thing. The software situation is at least as complicated as the hardware side.

With that warning in place, let's look at this strictly from a consumer perspective. Most computer users, or at least those with experience working with serial ports, are familiar with serial in the form of a DE9[1] connector, and often as opposed to a parallel port, which uses a truly enormous DB25 connector in order to send eight bits at a time. These were the two primary peripheral interfaces of old computers. Actually, that's not quite true; it's more accurate to say that these two were the primary peripheral interfaces of early personal computers that managed to survive into the modern era, basically because they were adopted by various iterations of the IBM PC, which is the platonic ideal of a personal computer.

To simplify the history somewhat, the pseudo-standard parallel port was designed in order to simplify the construction of printers. Although that advantage basically disappeared as printer technology changed, parallel ports remained conventional for printers for many years after. In practice they had few advantages over serial connectors and so basically died out with the printers that used them. We should all be glad, the time it took to send a rasterized page to a laser printer over a parallel interface was truly infuriating.

It would be surprising to run into a parallel interface in use these days, although I'm sure there are a few out there. It is quite common, though, to find serial ports today. They're remarkably durable. This is partially because they are extremely simple, and thus inexpensive to implement. It is mostly because they are predominantly used by the kind of industries that love to have weird proprietary connectors, and serial is the ultimate way to have a weird proprietary connector, because it is one of the least standardized standards I have ever seen.

Serial ports on computers are vaguely related to an EIA/TIA standard called RS-232. In fact, a number of computers and other devices label these ports RS-232, which is a bold move because they are almost universally non-compliant with that specification. There are usually several ways that they violate the standard, but the most obvious is that RS-232 specifies the use of a DB25 connector, with, you guessed it, 25 pins. "Good god, 25 pins for a simple serial connection?" you say. That's right, 25 pins. It is precisely because of that bourgeois excess of pins that personal computer manufacturers, as an industry, decided to trash the standard and use the smaller DE9 connector instead.

In order to understand RS-232 and it's amusingly large connector specification better, we need to understand a bit about the history of the standard. Fortunately, that will also help a bit in understanding the baffling complexity of actually making serial interfaces work today.

RS-232 was originally introduced to connect a terminal (originally a TTY) to a modem. The specification was actually rather specific to that purpose, which shows when we look at all the bonus pins. More generically, RS-232 is designed to connect "data terminal equipment" (DTE) to "data communications equipment" (DCE). As you often run into with these sorts of cabling, the TX pin of one computer needs to connect to the RX pin of the other, and vice versa. For this reason, the two devices on a serial connection should have their RX and TX pins reversed compared to each other.

The terms DTE and DCE are usually used to identify these two different configurations. That said, it was sometimes necessary to, for example, connect two computers to each other, when both used the same interface. Further, some manufacturers made (and continue to make) inconsistent decisions about whether the computer or peripheral should be DCE or DTE. This necessitates using a "null modem" cable, which is the equivalent of "crossover" for Ethernet before GbE specified a far more flexible MDI.

Trying to figure out whether you should use a null modem or straight through cable, which is usually easiest to do by experimentation, is just the first of the many fun steps in successfully using a serial device.

Conceptually, RS-232 functions in an extremely simple way. To transmit a one, you put a high (positive) voltage on the TX pin. To transmit a zero, you put a low (negative) voltage on the TX pin. This is in reference to a ground pin, which is usually connected right to local ground.

This gets us to our second bit of serial complexity, after figuring out whether or not we need to add an extra swap in the RX and TX wires: clock recovery. In most cases (we'll get to the exceptions later maybe), there is no explicit clock information provided by a serial connection. Instead, the receiving device must heuristically recover the clock rate. Some serial devices work this out by expecting the transmitter to always send a certain preamble (common in some industrial control and other situations), but the problem is solved more generally by the convention of sending a "start bit" and "stop bit" of one and zero successively, before and after each byte. This ensures at least one transition and helps with detecting the timing of the whole byte.

Most devices expect one and one bit. Some devices expect two of each. Some devices expect none at all (although they then usually use a protocol that expects a preamble).

From this mess, you might think that the RS-232 standard does not specify any method of clock synchronization. In fact, it does. It's just not implemented on PC serial interfaces.

So I said 25 pins. Now we know what our first five are: we have ground, tx, rx, and two pins that are used for synchronization, one in each direction. That's 5. What about the other twenty?

Well, some are just for stuff that no one uses any more. There's a pin to select the data rate (rarely used and unimplemented on PCs). There's a pin for a transceiver self-test feature (rarely used and unimplemented on PCs). But most of all, there is telephone modem arcana.

Remember, RS-232 was designed fairly specifically for a terminal to communicate with its modem. Modems at the time had some fairly peculiar requirements and restrictions. An obvious one is that the modem needs to signal the terminal when it is ringing (in the sense of a phone), and there's a pin for that. There's also a pin to indicate that the DCE has established a connection with a remote DCE. There are two pins that the DTE can use to essentially conduct a handshake with the DCE in preparation for sending data, a requirement due to the half-duplex nature of modems. There are two pins for similar, but different readiness negotiation in the other direction.

Most entertaining of all, there is an entire second serial connection. That's right, the RS-232 standard specifies pins on the cable for a complete second data path with its own data pins and control pins.

Add all this up and you get somewhere near 25, but not quite, because there are a few unused.

When early PC manufacturers (but mostly IBM) were hunting around for a fairly general-purpose interface to connect peripherals, RS-232 looked like a pretty good solution because it was fairly simple to implement and provided a good data rate. The problem is that it was over complicated. So, they just took the parts they didn't like and threw them in the trash. The result is "RS-232 lite," a loosely specified standard that carried RS-232-esque signaling over a smaller DE9 connector.

Here are the pins of the DE9 connector:

1. Data carrier detect (DCD)
2. Rx
3. Tx
4. Data terminal ready (DTR)
5. Ground
6. Data set ready (DSR)
7. Request to send (RTS)
8. Clear to send (CTS)
9. Ring indicator

This has the ground and two signal pins that we know we need, and then many, but not all, of the control pins specified by RS-232. Notably, no clock pins, meaning that properly synchronous serial standards (like several early computer network standards) cannot be carried on these RS-232 interfaces. Don't worry, this didn't stop anyone from trying to do general-purpose networking with these things.

Quick sidebar: I said positive and negative voltage earlier. The RS-232 standard is really unspecific about these and in newer revisions they can range from 3 to 25 volts, either positive or negative. As a de facto norm, most computer "RS-232-ish" interfaces use 13 volts, but there are exceptions. The standard requires that all interfaces tolerate up to the full 25 volts, but I would not trust this too far.

So what about all the control pins that PC serial interfaces retain... well, this gets us into the world of flow control. Often, when communicating with a peripheral or another computer, it is necessary to somehow signal when you are capable of receiving data (e.g. room in buffer). This is conventionally done on serial ports by using the RTS and CTS pins to indicate readiness to receive data by the DTE and DCE respectively, which is consistent with which ends of the connection "own" those pins in the proper RS-232 specification. This is all fine and good.

Except for it's not, because there are a number of serial devices out there which do not implement the RTS/CTS pins for whatever reason (mostly money reasons, I assume). So, a second convention was developed, in which the two ends send bytes at each other to signal when they are ready to receive data. These bytes are referred to as XON and XOFF.

These are referred to as "hardware flow control" and "software flow control" formally, but are often referred to as RTS/CTS and XON/XOFF flow control. They are also not the only two conventions for flow control, but they are the dominant ones.

With flow control, of course, we wonder about speed. While RS-232 specified a scheme for speed selection, it was quickly outdated and is not implemented on the DE9-type serial interface. Instead, the transmitter simply needs to select a speed that it thinks the receiver is capable of. Moreover, because RS-232 and even the DE9-type serial interface predate 8 bits being a universal word length, the length (bits) of a word in serial are typically understood to be variable.

Finally in our tour of "Imitation RS-232 Product" frustration is the consideration of error detection. Some serial devices expect a parity bit for error detection, others do not.

So, in the world we live in, connecting two devices by serial requires that you determine the following:

1. Physical interface type (null modem or straight through)
2. Word length
3. Stop bits, usually 2, 1, or 0.
4. Parity, on or off.
5. Speed.
6. Flow control, software or hardware.

These are often written in a sort of shorthand as "3200 baud 8N1," meaning, well, 3200 baud, 8 bit words, no parity, 1 stop bit. Not specified in this shorthand is flow control, but I feel like it's sort of traditional for random serial devices to tell you some, but not all, of the required parameters. There's often a bit of slack in these specifications anyway, as the serial transceivers in peripherals often actually support a number of different modes, and almost always any arbitrary speed up to their maximum.

Of course, don't count on it, because there are plenty of oddball devices out there that either autodetect nothing or only support one or a couple of combinations of parameters. It's not unusual on older devices for speed to not be autodetected and for it to be necessary to set the speed on the peripheral for example by DIP switches. I own a couple of devices like this. Also fun are devices that always initially start at a low speed (e.g. 1200 baud) and then allow you to send a command to tell them to switch to a higher speed.

To make things extra fun, it is not entirely uncommon for devices to use the serial port that don't really support serial communications at all. Instead, they just check the voltages put on the different control pins. For example, a common brand of adapter used to allow a computer to key up a radio transmitter (I'm not protecting the innocent here, I just can't remember which one I'm thinking of for sure, I think it's the RigBlaster) was originally just a transistor or relay or something that closed the push to talk circuit on the radio whenever the serial RTS pin was set high.

Software running on a computer had direct control of these control pins, so these sorts of things were pretty easy to make work[2]. Wikipedia notes that many UPSs had a similar situation where they just lit up different control pins based on their state, which is completely consistent with my opinion of APC's engineering quality.

The ring indicator pin on PCs is often (but not always) hooked up to the interrupt controller, which was super handy for input devices like mice. Later, the industry abandoned peripherals being able to trigger interrupts, then several years later rediscovered it.

The bottom line is that the "RS-232" port on your old PC is not actually RS-232, and even if it was it would still be frustrating as the RS-232 spec is very allowing of different, incompatible applications. It's also that way back when people designing interconnects just threw a ton of pins in there. Serial data connection, hey, let's use 25 pins, I'm sure we'll find uses for them all. By the time PCs were taking off economy had seeped in and it was cut to 9 pins, but then USB cut it down to 4! But of course that didn't last, because the need was quickly found to stuff a whole lot more pins in.

To anyone who's dealt with trying to interconnect serial devices before, none if this is really new information, but it might make it a little bit clearer why the situation is so complex. But I didn't even really start typing this with the idea of going into such depth on RS-232, instead I wanted to contrast it with some other standards in the RS serial family which appear often in industrial, embedded, robotics, and other applications. Standards that are similar to (and based on) RS-232 but different.

Although none of these are especially glorious, they serve as the underlying physical media for a huge number of common embedded and automation protocols. The takeaway is that even if you've never heard of these, you've almost certainly used them. These things get used internally in cars, in commercial HVAC, access control systems, all over the place.

RS-422

RS-422 is very similar to RS-232, identical for most logical purposes, but makes use of differential signaling. This means two pins each for TX and RX, which for electrical engineering reasons means things like longer cable runs and better EMI rejection.

Another very interesting enhancement of RS-422 over RS-232 is that it specifies a multi-drop feature in which one transmitter can address multiple receivers. This allows for the beginning of an RS-422 "network," in which one controller can send messages to multiple devices using a shared medium (a la coaxial Ethernet). The fact that RS-422 only supports one transmitter is sometimes worked around by having the device capable of transmitting (the driver) sequentially poll all of the other devices and route messages for them. This pops up sometimes in industrial control applications with the odd consequence that there is one particular box that must be turned on or the entire thing dies. It's not always obvious which one.

For some people, it may be slightly surprising to hear that RS-232 does not support multi-drop. It doesn't, but that has in no way stopped people from devising multi-drop systems based on RS-232. I have a couple such devices. There are various ways of doing it, all of them non-standard and probably unwise, but commonly each device has an RS-232 transceiver that repeats everything it receives on one interface to the TX pin on another. This allows a "daisy-chained" RS-232 situation which is often seen in, for example, POS systems.

RS-423

RS-423 is a minor variation on RS-422 that requires fewer wires. It really is pretty much that simple.

RS-485

RS-485 is very similar to RS-422, but with the significant enhancement that a modification to the underlying signaling (they rummaged in the couch cushions for another state and made it tri-state signaling) allows multi-drop that is not just multi-receiver but also multi-transmitter.

This means you can have a proper network of devices that can all send messages to each other using RS-485. This is a powerful feature, as you can imagine, and results in RS-485 being used as the underlying medium for a large number of different protocols and devices.

Unholy Matrimony

Because these standards are so similar, it is not at all unusual to mix and match. RS-232 to RS-422 and RS-485 translators are readily available and are often used in situations where two devices use RS-232 but you want a longer cable than you can reliably get to work with RS-232's simple non-differential signaling.

Of course, one of the great things about networks is that you can put anything over them if you are willing to make enough compromises. And so naturally, RS-232 over IP is also fairly common, especially where legacy equipment has been modernized by putting it on the internet and making it a Thing.

Because the principle of RS-232 signaling is so simple, it is extremely similar to a variety of other serial communications formats. For example, the UARTs often present in microcontrollers are largely the same as RS-232 except for using different signaling voltages (usually 0 and 3.3 or 0 and 5). This means that you can generally convert your UART's output to RS-232 with some discrete components to herd electrons and some software work to support whichever of the grab bag of serial features you want to implement.

"Universal" serial bus

The DE9 serial port largely disappeared on personal computers due to the rising dominance of USB, which is electrically not really that dissimilar from RS-232 but comes with a hugely more complex protocol and set of standards. This added complexity has the huge upside that you can generally plug a USB device into your computer without having to spend a lot of time thinking about the details of the interconnect.

Fortunately, USB-C, Thunderbolt, and Lightning have come along to fix that.

Coming up, I will talk a bit (and complain a lot) about the world of interconnects that replaced the trusty fake RS-232. Some of them also have fun alphanumeric names, like Generic Brand IEEE 1394 Product.

[1] These connectors are often referred to as DB9, which is technically incorrect for reasons that are not especially interesting. For our purposes, know that DE9 and DB9 are the same thing, except for DB9 is wrong.

[2] Parallel ports basically offered this same capability but on steroids. Since there were 8 Tx pins that would just have the values corresponding to whatever byte you sent to the port, they could basically be used as 8 pins of GPIO if you looked at it right. I had a board for a while with eight relays that switched 120vac based on the Tx pin values on a parallel port. This was a very outdated way of doing this by the time I had it, but it sure was fun.

>>> 2021-01-04 happy new year

Once upon a time, an impending new year spurred quite the crisis.

When I was a high school student, I volunteered (actually "interned", but the unpaid kind) at the thrift shop of a nonprofit electronics recycling organization. This is the kind of experience that leaves you with quite a few stories, like how before using the public WiFi you had to agree to a terms of service that was actually just a weird ramble about how WiFi might give you cancer or something. But, there is one story that is apropos to the new year: I maintained a small collection of power strips labeled "Y2K Compliant" that I had priced $5 higher than the other, presumably non-Y2K compliant ones. I like to think that the "Y2K Compliant! +$5" sign is still up at the thrift store but like many of my efforts I assume it is long gone. Last time I was there they had finally made the transition to thermal receipt printers I had labored to start, eliminating the 30 second time to first page/awkward pause on the laser printers that had been used for receipts.

I'm not sure who it was now, but judging by the number of them we had on hand it was a fairly large manufacturer of power strips that started putting "Y2K Compliant" on their labels. This is, of course, complete nonsense, and ultimately Y2K ended up having very little impact compared to the anticipation. Nonetheless, people who dismiss Y2K as having been a hoax or somehow fake are quite incorrect. Successfully navigating the year 2000 transition required a concerted effort by software engineers and IT analysts throughout various industries.

The tedious work of validating software for Y2K compliance was one of several things lampooned by the film Office Space. I'm not sure that that many people in software today even understand how Y2K was a problem, though, so I will give a brief explanation.

The common explanation of the Y2K problem is that programmers decided to save space by only storing two digits of the year. This is basically true, but many people in software today might find that sentence a bit nonsensical. An int is an int, which is today 32 bits, right?

Well, sure, but not historically.

Many early business computers, most notably but not at all limited to various IBM architectures such as the influential System/360 family, made extensive use of either Binary Coded Decimal (BCD) or a slight optimization on the same format (Packed BCD). That is to say, these computers did not use the power-and-significand exponential representation that we think of today for floating point numbers (e.g. IEEE floating point). Instead, they stored numbers as a sequence of base 10 digits. That is, essentially, as a string.

It's sort of funny how, to a lot of CS students and programmers today, the idea of using BCD to represent numbers is absurd. Representing the quantity 10.35 as a sequence of bytes encoding 1, 0, 3, and 5, with a value that is either an offset to the decimal or an exponent (base 10) depending on how you look at it, feels similar to string typing, which is to say that it is practically blasphemous, even though today's most popular software stack uses something which is largely more confusing than string typing.

I would argue, though, that it is IEEE floating point notation which is the eccentric, unfortunate choice. Consider this: floating point operations often pose a subtle challenge in software engineering largely because the precision properties of modern floating point representations are decidedly unintuitive to humans. The resolution with which IEEE floats represent numbers differs with the magnitude of the number and is difficult for humans to determine.

This leads to concepts like "machine epsilon" which attempt to quantify floating point precision but are difficult to actually apply to real-world situations. Similarly, floating point numbers can be made more precise by allowing more bits for the representation, say, 64 instead of 32. This is still fairly confusing though, and very few people have any intuitive or even rote sense of how much "more precise" a 64-bit float is than a 32-but float.

The reality is that power-and-significand floating point representations are just plain confusing.

BCD, on the other hand, is not.

BCD represents floating point numbers the exact same way that humans do, in terms of a set of digits. This means that the precision properties of BCD are very easy to understand: adding additional words (bytes, etc) to the end of a BCD number increases the significant digits (in decimal) terms of the number. This is really very easy to follow, and often makes it very easy to make choices about how long the representation needs to be.

While the underlying reasons are somewhat complex, it is an accurate summary to say the reason we use power-and-significant floating point representations rather than BCD today are... "technical reasons." IEEE representation is amenable to highly optimized implementations of a variety of operations, has the property of a fixed size regardless of magnitude which is extremely convenient for implementation, and ultimately is very amenable to implementation on RISC systems[1]. This is all to say that IEEE representation is better for every purpose except interaction with humans.

Good thing the evolution of computing has rarely, if ever, actually had any regard for user experience.

So this was all basically a preface to explain that the Y2K bug, to a large extent, is a direct result of BCD representation.

In particular, the Y2K bug tends to emerge from the use of COBOL[2]. COBOL is a very interesting language that deserves a lengthy discussion, but one of the interesting properties of COBOL is that it has a data serialization format as a key feature. In a fashion somewhat similar to modern libraries like protobuf, COBOL programs include as part of their source a description of the data structures that will be stored. These data structures are described not so much in terms of types, but instead in terms of the actual byte-wise serialization of those types.

Although COBOL now supports IEEE floating point, BCD representations are much more typical of the COBOL ecosystem. So, COBOL programs typically start by describing the numbers they will store in terms of the number of digits.

So, to summarize, to a large extent the source of "the Y2K bug" is that a large number of computer systems were implemented in COBOL and specified a serialization format in which the year was stored as a two-digit BCD value. This made sense because storage and memory were both very expensive, and in the '80s there hadn't been software for long enough for there to be legacy software, so few engineers probably realized that the heap they had written would still be in use in the next century.

"Fixing" the Y2K issue, as parodied in Office Space, basically entailed modifying all of this COBOL software to specify four digits instead. Of course, not only was this a considerable amount of effort for large codebases, you also either needed to convert all stored files to the new format or modify the software to detect and handle both the old and new serializations. What a headache.

I'm not sure if there's some moral to draw from this story, it just came to mind since we hit the new year. The good news is that no one makes mistakes like this today. Instead, Sony GPS receivers stop working because there were too many weeks in the year and block storage drivers stop working because there was a leap day in the year and ultimately a ton of software uses a 32-bit counter of seconds since 1980 that's going to overflow in 2038, so clearly we've all learned our lesson about not accommodating numbers having slightly higher values than we had once expected.

Most of why I write about this is because I, personally, miss BCD. Poul-Henning Kamp once wrote for ACM that he believed the choice of null-terminated strings (over length-prefixed strings) for C to be the most expensive single-byte mistake ever made in computer science. Along this same vein of thinking, one wonders if the success of IEEE floating point representation over BCD has been a mistake which has lead to huge cost due to the numerous and subtle errors caused by the sharp edges on the representation.

At the cost of less performant and more complex implementation, BCD would nearly eliminate a huge class of errant software behavior. Never again would we get an unexpected .00000000000000001 or have algebraically equal numbers compare as non-equal. On the other hand, we would gain a new class of errors related to more frequent overflow of numbers since an additional digit is required each power of ten.

Would we all be better off now if BCD had won? Perhaps. I mean, the next world-ending crisis it would cause wouldn't be until the year 10000.

[1] While there are plenty of exceptions, it's a good generalization to note that BCD number representation tends to be associated with systems that make extensive use of abstraction between instructions and the actual machinery. In the modern era we would tend to call this "microcoding" but I am actually referring to things like the SLIC in IBM architectures, which is somewhat analogous to the microcode in the x86 architecture but tends to be significantly "thicker." Consider that the SLIC in modern IBM systems is essentially a virtual machine implemented in C++, not so dissimilar from say the JVM. Since arithmetic operations on BCD are fairly complex and have very variable runtime, it is much easier to implement them as machine instructions in highly abstracted systems (where the "instruction set" is really more of a high-level interface implemented by underlying software) than in RISC systems like x86 (where the "instruction set" is really more of a high-level interface implemented by underlying software but we all feel bad about this and try not to discuss it too much).

[2] The use of BCD is of course not at all limited to COBOL and plenty of Y2K non-compliant software was written in assembly or other languages. I use COBOL as the nearly exclusive example though, because it is fairly easy to find examples of COBOL software today demonstrating the allocation of two BCD digits to the year field, while it's fairly difficult to find such examples today in other languages. I also like to bring up COBOL because the idea of a serialization format as the core data structure of a language is something which fell out of fashion, and so is rarely seen today outside of legacy COBOL. Compare MUMPS. Sorry, err, the "M Programming Language."

>>> 2020-12-30 I trained a computer to do math

Here's an experiment: a briefer message about something of interest to me that's a little different from my normal fare.

A day or two ago I was reading about something that lead me to remember the existence of this BuzzFeed news artice, entitled "We Trained A Computer To Search For Hidden Spy Planes. This Is What It Found."

I have several naggles about this article, but the thing that really got me in a foul mood about is their means of "training a computer." To wit:

Then we turned to an algorithm called the random forest, training it to distinguish between the characteristics of two groups of planes: almost 100 previously identified FBI and DHS planes, and 500 randomly selected aircraft.

The random forest algorithm makes its own decisions about which aspects of the data are most important. But not surprisingly, given that spy planes tend to fly in tight circles, it put most weight on the planes turning rates. We then used its model to assess all of the planes, calculating a probability that each aircraft was a match for those flown by the FBI and DHS.

To describe this uncharitably: They wanted to identify aircraft that circle a lot, so they used machine learning, which determined that airplanes that circle a lot can be identified by how much they circle.

I try not to be entirely negative about so-called "artificial intelligence," but the article strikes me as a pretty depressing misapplication of machine learning techniques. They went into the situation knowing what they were looking for, and then used ML techniques to develop an over-complicated and not especially reliable way to run the heuristic they'd already come up with.

Anyway, this is an interesting problem for other reasons as well. The article Police helicopters circling a city are environmental terrorism makes a case for the harm caused by persistent use of aerial surveillance by police. Moreover, If you'd seen NextDoor around here, you'd know that the constant sound of the Albuquerque Police Department's helicopters is one of the greatest menaces facing our society. This increasingly common complaint has got some press, and although they're no longer keeping me up at night with loudspeaker announcements the frequency with which helicopters circle over my house has been notably high.

Moreover, late last night I went for a walk and there was an APD helicopter circling over me the entire time. You know, being constantly followed by government helicopters used to be a delusion.

So, I decided to explore the issue a bit. I dropped a few dollars on FlightAware's API, which they excitedly call "FlightXML" even though it returns JSON by default[1], in order to retrieve the last week or so of flights made by all three of APD's aircraft[2]. I then trained a computer to identify circling.

No, actually, I wrote a very messy Python script that essentially follows the aircraft's flight track dragging a 1.5nm x 1.5nm square around as the aircraft bumps into the edges. Any time the aircraft spends more than six minutes in this moving bounding rectangle, it deems the situation probable circling. Experimentally I have found that these threshold values work well, although it depends somewhat on your definition of circling (I chose to tune it so that situations where the aircraft makes a single or only two revolutions are generally excluded). I plan to put this code up on GitHub but I need to significantly clean it up first or no one will ever hire me to do work on computers ever again.

On the upside, maybe recruiters will stop emailing me because they "loved what they saw on GitHub." Actually, maybe I should put it up right now, with a readme which declares it to be my best work and a specimen of what I can achieve for any employer who cold-calls me ever.

You can see the result here. Incidents of circling actually seem more evenly distributed through the city than I had expected, although there is a notable concentration in the international district (which would be unsurprising to any Burqueño on account of longstanding economic and justice challenges in this area). Also interesting are the odd outliers in the far northwest, almost Rio Rancho, and the total lack of activity in the South Valley. I suspect this is just a result of where mutual aid agreements are in place, Bernalillo County has its own aviation department but I don't think the Rio Rancho police do.

This is all sort of interesting, and I plan to collect more data over time (I only seem to be able to get the last week or so of tracks from FlightAware, so I'm just going to re-query every day for a few weeks to accumulate more). Maybe the result will be informative as to what areas are most affected, but I think it will match up with people's expectations.

On the other hand, it doesn't quite provide a full picture, as I've noticed that APD aircraft often seem to fly up and down Central or other major streets (e.g. Tramway to PdN) when not otherwise tasked. This may further complaints of low-flying helicopters from residents of the downtown area, but isn't quite circling. Maybe I need to train a computer to recognize aircraft flying in a straight line as well.

It would also be interesting to apply this same algorithm to aircraft in general and take frequent circling as an indicator of an aircraft being owned by a law enforcement or intelligence agency, which is essentially what BuzzFeed as actually doing. I made a slight foray into this, the problem is just that, as you would expect, it mostly identified student pilots. I need to add some junk to exclude any detections near an airport or practice area.

Anyway, just a little tangent about something I've been up to (combined with, of course, some complaining about machine learning). Keep using computers to answer interesting questions, just please don't write a frustrating puff piece about how you've "trained a computer" to do arithmetic and branching logic[3].

With complete honesty, I hear a helicopter right now, and sure enough, it's APD's N120PD circling over my house. I need to go outside to shake my fist at the sky.

[1] I would have preferred to use ADSBExchange, but their API does not seem to offer any historical tracks. FlightAware has one of those business models that is "collect data from volunteers and then sell it," which I have always found distasteful.

[2] Some context here is that APD recently purchased a second helicopter (N125PD). This seems to have originally been positioned as a replacement to their older helicopter (N120PD), but in practice they're just using both now. This has furthered complaints since it feels a little but like they pulled a ruse on the taxpayers by not selling the old one and instead just having more black helicopters on the horizon. This is all in addition to their fixed-wing Skylane (N9958H).

[3] I will, from here on, be proclaiming in work meetings that I have "trained a computer to rearrange the fields in this CSV file."

>>> 2020-12-27 mainframe pos

One of the most entertaining acronyms in the world of specialty computing equipment is POS. Let's all get the chuckle out of the way now, in this discussion we will be talking about Point of Sale.

For those not familiar with the term, POS refers to the equipment which is used "at the point of sale" in retail and other businesses to track sales, handle payment, and other business functions. In essence, a POS computer is a more entitled cash register, and there is a very direct line of evolution from the mechanical cash registers of days past (that made that pleasant cha-ching sound) to the multi-iPad abominations of today.

I would like to talk a bit about how we got from there to here, and, in my opinion, just how bad here is.

As with most things I discuss, IBM is an important component of POS history. However, I will start by introducing yet another three-letter acronym into the fray. We'll start with a company that is somewhat, but not radically, older than IBM, and was focused on POS while IBM was busy tabulating census cards: NCR.

NCR is one of those companies where the acronym officially no longer stands for anything, but before they tried to modernize their branding it stood for National Cash Register. As the name implies, NCR was an early giant in the world of POS, and many of the old-timey mechanical cash registers you might think of were actually manufactured by NCR or its predecessors, going back to the late 19th century.

NCR entered the computing business around the same time as IBM, but with a decidedly cash-register twist. Many of their computer products were systems intended for banks and other large cash-handling institutions that handled totally transactions, since computers of the day were largely too expensive to be placed in retail stores. They did, however, make general-purpose computers as well, mostly as a result of an acquisition of a computer builder.

NCR's early machines like the Post-Tronic are actually interesting in that they were basically overbuilt electromechanical calculators designed to allow a banker to post transactions to accounts very quickly, by keying in transactions and getting a report of the account's new state. This sped up the end-of-day process for banks appreciably. I like these kinds of machines since they take me back to my youthful education in double-entry accounting, but unfortunately it's not that easy to find detailed information about them since their lifespan was generally fairly short.

I hope to one day write about the posting machines used by hotels, electromechanical calculators that at the late stage read punched cards reflecting various charges to a person's account (room, restaurant, etc) and updated the room folio so that, when the customer checked out, a report of all of their charges was ready. This greatly accelerated the work of the hotel clerks and the night auditor who checked their work; in fact, it accelerated the work of the night auditor so much that I understand that in many hotels today the title "night auditor" is almost purely historic, and that staff member simply runs the front desk at night and has no particular accounting duties. The problem is that these wondrous hospitality calculators were niche and had a short lifespan so there's not really a lot out there about them.

Anyway, back to the point of this whole thing. NCR racked up a number of interesting achievements and firsts in computing, including being a key developer of OCR and barcode reading and inventing the ATM. More relevant to my point though, NCR was also an early innovator in electronic cash registers.

It is also difficult to find especially detailed information about the very early generation of electronic cash registers, but they were essentially the same as the late-model mechanical cash registers but intended to be cheaper and more reliable. For an early electronic cash register, there was usually no networking of any sort. If central reporting was desired (as it very much was in larger businesses for accounting), it was common for the cash register to output a punched paper or magnetic tape which was later taken to a mainframe or midcomputer to be read. That computer would then totalize the numbers from all of the cash registers to produce a day-end closing report. This was an improvement on having to read and key in the totals from the cash registers by hand, but was not quite a revolutionary change to computer technology yet.

The situation becomes quite a bit more interesting with the introduction of networking. Now, what we tend to think of as computer networking today is quite a bit different from computer networking in the '80s when electronic cash registers really became predominant. In this era, "network" usually meant the connection between a terminal and a mainframe. Cash registers were not a whole lot different.

Reading patent 4068213 covering some very early plastic payment technology in the mid-'70s, we get some details. An NCR 255 cash register connected to an NCR 726 controller. Even within the patent text, the term cash register is somewhat flexibly interchanged with terminal. Indeed, the architecture of the system was terminal-and-mainframe: to a large extent, the actual POS system at the cashier's station was merely a thin terminal which had all of its functions remotely operated by the NCR 726, a minicomputer, which would be placed in the back office of the store. The POS terminals were connected to the minicomputer via a daisy-chained serial bus, and because the cash registers didn't really do any accounting locally, all of the store-wide totals were continuously available at the minicomputer.

As time passed, this made it possible to add extensive inventory control, lookup, and real-time accounting functions to the POS, which were really all performed at the central computer. This included things like looking up item prices based on barcodes, handling charge cards, and validating returns and exchanges.

This basic architecture for POS has persisted almost to the present day, although I would like to return somewhat to my comfort zone and transition from discussing NCR to IBM. In the mid-'80s, at perhaps peak computer POS, IBM introduced an operating system creatively named 4680. 4680 was a microcomputer operating system (based on a DOS written for the 286) that was specialized to run on a relatively "thick" POS computer, such that much of the computation and control was done locally. However, 4680 POS systems were intended to be in constant communication with a mini- or mid-computer which ran an application like IBM Supermarket Application to perform data lookup, accounting, and all of the POS functions which required access to external data and communications.

4680 was replaced by the even more creatively named 4690, and 4690 is perhaps one of the most influential POS systems ever designed. 4690 and its newer versions was massively successful, and is probably still in use in some places today. In a typical installation, a set of 4690 POS systems (running on hardware also provided by IBM) would be connected to an AS/400 or similar IBM midcomputer running in the back office. The AS/400 would often have a telephone or internet connection which allowed it to regularly report data up another level to a corporate mainframe, and retrieve updated stock information.

The architecture of 4690 systems is highly typical of POS in large retail environments to this day. A 4690 POS would be connected by multidrop serial bus (one of the various IBM pseudo-standard network protocols) to the store controller midcomputer. It would be connected via RS-232 serial to a thermal receipt printer. In an add twist, this RS-232 bus was also essentially multidrop, as the printer would have a passthrough connection to the pole display and the pole display was basically controlled by special-case messages to the printer. The printer also, incidentally, had a simple electrical connection to the cash drawer and triggered it opening. Details vary, but the credit card terminal was typically also connected to the 4690 by serial.

All of this is basically how conventional POS are cabled today, except ethernet is usually used for the back-office connection and sometimes also for the credit card terminal (which might also be USB). Serial is still dominant for the printer and pole display in conventional systems.

IBM sold off their retail division to Toshiba, and Toshiba continues to develop derivatives of the 4690 platform, although the POS side has essentially been rewritten as a Linux application. Whenever you go to WalMart or Kroger or another major retailer, check a look at the system the cashier operates. Not many IBM branded devices are still out there although you might catch one, more likely you will see a Toshiba microcomputer (usually under the desk) connected to an unusual peripheral that consists of a set of pleasantly clicky mechanical keys and a two-line matrix LCD display (although full on LCD touchscreens are becoming increasingly common at WalMart, and universal at for example Trader Joes. Note that these touchscreen LCD systems maintain the physical keys for numeric entry and common functions).

This whole system is, essentially, a modern 4690, using direct descendants of the original hardware. That said, many of these systems today either run more modern software from Toshiba (I believe still SuSE based although I am far from certain) or, in larger retailers, a custom application developed internally by the retailer. In fact, for large retailers, it is very common for nearly the entire POS stack to be running custom software, from the actual computer to the credit card terminal and even the printer. The vendors of this kind of hardware offer an SDK for developing custom applications, and this is the reason why physically identical credit card terminals made by Verifone or Ingenico often offer a frustratingly inconsistent user experience[1]. It doesn't help that some of the terminal vendors have decided that their products are nearly iPad-ish enough and introduced touchscreens of a size once reserved for televisions, that retailers clearly have no idea what to do with.

I am told that some major retails continue to use either an AS/400, a more modern System i, or an AS/400 emulator on x86 to run the back-office system. That said, there are now UNIX-based options (I mean all-caps UNIX, we are often talking HP UX or similar) that are presumably taking over.

So we've talked a bit about the technical history, which is likely striking you as painfully arcane... and it is. We live in the era of ubiquitous microcomputers and flexible, fast network protocols. These enable all kinds of simpler and yet more capable architectures for these devices. And yet... let's focus on the usability.

One thing you will likely have noticed is that retail POS are typically either very fast (in the case of an experienced cashier) or very slow (in the case of a new one)[3]. Interaction with a 4690-style POS is primarily through a barcode reading weighscale and a set of relegendable buttons. While large color screens are becoming more common, lots of retailers still stick to only a two-line text display. The learning curve to operate these systems, especially in less common cases, is fairly substantial.

And yet, they are very fast. For barcoded items any kind of interaction with the user interface is seldom necessary. For non-barcoded items like produce, once a lookup table is memorized it is a matter of keying in an item number and weighing. Often there are one-press functions provided for operations like repeating an item. There are few distractors, as there are little to no "system notifications" or other software to interfere with the POS operation.

The POS has the property of being built for purpose. It contains the features necessary for efficient POS operations, and no other features. It uses a physical keyboard for entry because these can be operated quickly and by feel. It expects the user to learn how to operate it, but pays out the benefit of seldom ever providing any kind of prompt the operator needs to read or context the operator needs to determine, allowing operation to become muscle-memory.

These are traits which are, today, thought of as archaic, obsolete, and perhaps worst of all, unfashionable.

Compare to the "modern" POS, which consists of an iPad in a chunky mount. If you are lucky, there is a customer-facing iPad Mini or even iPod touch, but more often it is necessary to physically rotate the iPad around to face the customer for customer interactions.

This is a system which is not built-for-purpose. It is based on commodity hardware not intended for POS or even business use. It has few or no physical peripherals, making even functionality as core as producing a printed receipt something that many businesses with "modern" technology are not able to do. Interaction with the system is physically clunky, with the iPad being spun around, finger-tip signatures, and a touchscreen which is not conducive to operation by touch or high-speed operation in general due to lack of a positive tactile response. The user interface is full of pop-ups, dialogs, and other modal situations which are confusingly not always directly triggered by the user, making it difficult to operate by rote sequence of interactions. Even worse, some of these distractors and confusers come from the operating system, outside the control of the POS software.

All of this because Square either cannot afford to or has made a strategic decision not to develop any meaningful hardware. It does keep prices down.

In many regards these iPad-based POS are inferior to the computer POS technology of the 1980s. At the same time, though, they are radically less expensive and more accessible to small businesses. Buying an iPad and using the largely free Square POS app is radically easier to reach than buying an AS/400 and a 4690 and hiring an expensive integration consultant to get any of it to work---not to mention the licensing on the back-office software.

I make a point of this whole thing because it is an example of this philosophy I have been harping on: the advancing of technology has lead to computers becoming highly commodified. This has the advantage of making computing less expensive, more accessible, and more flexible. The downside is that, in general, it also makes computers less fit for purpose, because more and more applications of computers consist of commodity, consumer hardware (specifically iPads) running applications on top of a general-purpose operating system.

The funny thing is that the user experience of these newer solutions is often viewed as being better, because they are far more discoverable and easier to learn. There is obviously some subjectivity here, but I would strongly argue that any system which a person interacts with continuously as a part of their job (e.g. POS) should be designed first for speed and efficiency, and second for learnability. Or at least this is what I repeat to myself every time the nice lady at the bakery struggles to enter a purchase of three items, and then I have to sign the screen with my finger.

I'm not necessarily saying that any of this has gotten worse. No, it's always been bad. But the landscape of business and special-purpose computing is slowly transforming from highly optimized, purpose-built devices (that cost a fortune and require training to use) to low-cost, consumer devices running rapidly developed software (that is slower to operate and lacks features that were formerly considered core).

This change is especially painful in the POS space, because key POS features like a cash drawer, printer, barcode reader, weighscale, and customer-facing display are difficult to implement by taping iPads to things and so are often absent from "modern" POS configurations, which has a significant deleterious impact on efficiency and customer assurance. Amusingly, many of these peripherals are completely available for iPad-based systems, but seldom used, I suspect in part due to uneven reliability considering the iPad's limited peripheral interface options.

There is technical progress occurring in the conventional POS space, with far more retailers adopting full-color LCD interfaces and taking advantage of the programmability of peripherals to offer features like emailed receipts. But as much as parts of silicon valley feel that they are disrupting the POS space... 4690's creaky decedents are likely to persist well into the future.

Postscript: I am trying out not eschewing all social media again, and I am using the new Pleroma instance at my janky computer operation waffle.tech. Topics will be diverse but usually obscure. If you're a fediperson, take a look: https://pub.waffle.tech/jesse.

[1] It is also usually painfully clear which retailers have invested in developing good UX for their payment terminals (McDonalds), vs made a half-assed effort (Walgreens), vs throwing their hands in the air and just adding a lot of red circles to an otherwise "my first Qt app" experience (Target).

[2] Receipt printers are only supported by Square on iOS for some reason, and Square is cagey about whether receipt printers not on their special list will work. It obviously does support the industry-standard ESC/POS protocol but I think the core issue is the lack of flexible USB support in iOS. Bluetooth devices frequently have reliability issues and are too often battery-based. IP-based peripherals are excessively expensive and can be painful to configure. Somehow, POS peripherals have gone from eccentric daisy-chained RS-232 to a worse situation.

[3] This also reflects a related shift in the computing industry I hope to focus on in the future, which is that often modern UX practices do not really do well with users being good at anything. Many modern user interfaces prioritize discoverability, ease of learning, and white space to such a degree that they are downright painful once you have more than two hours of experience with the product. I'm not very old at all and I remember using text-based interfaces that were extremely fast once you learned to use them... that were later replaced with webapps that make you want to pull your hair out by guiding you and hiding functions in menus. This is all part of the "consumerization" of business computing and increasing expectations that all software feel like an iOS app made for first-launch engagement, even if it's software that you will spend eight hours a day operating for the foreseeable future. A lot of software people really get this because they prefer the power and speed of command-line interfaces, but then assume professional users of their product to be idiots who cannot handle having more than four options at a time. But now I'm just ranting, aren't I? I'll talk about examples later.