COMPUTERS ARE BAD is a newsletter semi-regularly issued directly to your doorstep to enlighten you as to the ways that computers are bad and the many reasons why. While I am not one to stay on topic, the gist of the newsletter is computer history, computer security, and "constructive" technology criticism.
I have an M. S. in information security, more certifications than any human should, and ready access to a keyboard. This are all properties which make me ostensibly qualified to comment on issues of computer technology. When I am not complaining on the internet, I work in engineering for a small company in the healthcare sector. I have a background in security operations and DevOps, but also in things that are actually useful like photocopier repair.
You can see read this here, on the information superhighway, but to keep your neighborhood paperboy careening down that superhighway on a bicycle please subscribe. This also contributes enormously to my personal self esteem. There is, however, also an RSS feed for those who really want it. Fax delivery available by request.
--------------------------------------------------------------------------------
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.
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:
Data carrier detect (DCD)
Rx
Tx
Data terminal ready (DTR)
Ground
Data set ready (DSR)
Request to send (RTS)
Clear to send (CTS)
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:
Physical interface type (null modem or straight through)
Word length
Stop bits, usually 2, 1, or 0.
Parity, on or off.
Speed.
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.
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."
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."
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.