Posts by "Dead Eye" 12 publicly visible posts • joined 21 Sep 2010
...and come to think of it, if I recall correctly, we typed the "splodge" first, before the input happened, to avoid shoulder surfing as the password was typed but I can't be 100% certain off hand. One other point was that we couldn't turn off the echo for these specific input operations, or we would have done. In some cases the echo was done by the terminal itself, a.k.a. "half-duplex" operation.
It's nice to see people remember MAXIMOP fondly -- I'm one of the original authors.
Yes, we did overwrite passwords that way; but another lovely little thing we did when the terminal devices were all Teletypes was the "Chug". If you "printed" a "delete" character (ASCII code point 127) the Teletype would move the print head but atually print nothing on the paper. We did this every time your program ended a time-slot with no other output so you knew the system was still running for you. In one of our terminal rooms you'd hear sequences of these "chug"s coming from around the room and then repeat. We didn't panic until they stopped...
OTOH a few years later we couldn't tell the difference between real Teletypes and "glass teletypes" and overwrote the passwords on the "glass teletypes" as well. We justified this apparrent inefficiency by what later became known as "shoulder surfing"...
Incidentally, MAXIMOP ran on ICL 1900 series machines, but is still run occasionally on the ICL 2900 at the National Museum of Computing at Bletchley Park using the 2900 in a mode where it emulates the 1900. They can't do it too often because of the electricity costs...
Reading between the lines a bit it looks like: (1) The problem affects devices with particular BIOS implementations; (2) The problem affects particular hardware implementations only; (3) The problem affects particular Linux kernel releases that include particular versions of the Intel SPI driver; (4) The problem affects particular Linux distributions that perform operations that use the SPI driver in a way that upsets a BIOS that doesn't like a particular set of hardware design decisions. There's also a distinct possibility that individual choices of setting within the BIOS affects one or another of these layers of conditionality. There are also other reports of other non-Linux OSs that happen to perform similar operations over the SPI bus having the same problem on the same hardware platforms.
Canonical seem to be behaving responsibly and reacting quickly once they were identified as a possible cause even if they are not the only contributor to the total chain of "gotchas" that lead to end-user problems. I'm not so sure the same could be said of other players.
How much regression testing can we expect, and from whom?
Lenovo can't be expected to test every single OS, especially those that haven't been written yet.
Intel can't be expected to test every single hardware platform.
Canonical can't be expected to test every single hardware platform either.
The Linux community probably tests the widest variety of hardware platforms, but only by trying it and having occasional problems (like this one!).
You can expect BIOS implementations to test correct operation on correctly built hardware.
You can expect hardware designers to use reliable BIOS suppliers.
You should be able to expect hardware designers to build hardware that correctly connects up the chips they use.
But even that testing won't be 100% in practice, even though it should be.
In my opinion, if a machine won't allow the BIOS settings to be corrected, or it it allows the BIOS settings to be set to an invalid state, the machine builder is responsible even if only for the choice of BIOS supplier they made. They have no responsibility for preserving the correct operation of a non-supported OS, but do have a responsibility for ensuring it is possible to re-install a supported OS.
(And before anyone says so I don't think measures that allow a device to be deliberately "bricked" if stolen should be circumventable at all easily but do think it should be difficult to activate such facilities to make it very unlikely to activate them by accident.)
Actually, RISCOS (the Acorn one, that is) had all of:
1) the "Icon Bar" with two types of icon that worked in from both ends
2) Window "Title Bars" with icons in them to expand and collapse the window, &c
3) A "Start" buttin, called the"Apps" icon (on the icon bar) that contained applications is the ROM
as a starting point but also applications from the boot disc that were added to this set.
This last bit is the one that differed a nit form Window because it wasn't at either end of the icon bar, and it didn't support a menu structure for the applications -- but it was there.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
