The code from the main project I worked on out in Marlboro (for Digital Equipment Corporation Large Computer Software Engineering) is up on the web!
This proves that I really have been using source control systems since the 1980s (I think this was DEC CMS), and that I wrote BLISS code, and that I wrote many metric fuck-tons of comments.
Possibly the weirdest bit is this floating-point number conversion code. It handles pdp-11/vax 32 and 64 bit floating point, and PDP-10 36 and 72 bit floating point, and can convert anything to anything (within format limitations). It’s at http://pdp-10.trailing-edge.com/bb-r775d-bm_tops20_ks_upd_4/01/sources/dixfp.bli.html
Although the declaration of the character tables for various character sets might be a runner-up. (Bliss had far and away the most powerful macro facilities of any language I’ve ever used.)
Both for the call buttons at each floor, and the floor buttons in the elevator car, we expect them to respond to pushing by some change in state to show that our command has been received. Nearly always this is some form of a light coming on (background of the button, surrounding the button, rarely a little light right in the button). I will refer to this as the “state indicator”.
In addition to acknowledging our immediate command, the state indicator conveys information to other users of the elevator. When we come to the doors we can see from a distance that the “up” call button has already been pressed, so we don’t have to force our way through the crowd to push it ourselves; and the same thing for the floor button once we’re in the car.
All these buttons have to talk to a central controller (well, or to distributed controllers which talk to each other, thus achieving the same goal as a central controller). For the elevator to actually come when the “up” call light is on, the elevator car itself has to move to that floor, stop, and open its doors. For me to arrive on the 11th floor after pushing that button, the car has to go there, stop, and open its doors.
But there’s a weird thing that happens with many elevators, including the ThyssenKrupp elevator system at the DoubleTree Park Place (where I was for Fourth Street Fantasy Convention last weekend, and where Minicon will be for the first time this coming Easter). Often, if I push a button rather briefly, I will see the state indicator come on briefly, and then go off and stay off. My push does not seem to have “taken”, at least the central controller has not accepted it. (If I wait, the elevator never comes in response to the call I thought I made, but which after the brief blink is not acknowledged. It may of course come to the floor to drop somebody off, and may then continue in the direction I want, but it never comes empty, so I feel safe in saying I have not managed to log my request with the controller.)
How can this happen? The most obvious way to set it up is to have the state indicators simply controlled from the central controller. Thus, if it comes on, the central controller does have the request, and if it doesn’t, it doesn’t (well, or the indicator is burned out, or there’s a wiring fault, or…oh, the heck with it; it doesn’t).
The evidence appears to suggest that this isn’t how it works, for whatever reason.
Okay, rampant speculation based on very little knowledge (said to be a dangerous thing; though actually that’s “learning”) coming up. It’s worth remarking that elevators are fairly old technology, that they’re safety-critical, and that they have been heavily regulated for most of the time they’ve existed. This can tend to limit implementation or design choices sometimes in bizarre ways.
One theory is that getting the request logged in the central controller and the response back to the state indicator is slow enough that people were reacting weirdly (they’d push the button, nothing would happen and then just as they tried again the state indicator would come on, for example). If this is seen (as it probably should be) as a user interface fault, maybe somebody had the bright idea of turning on the state indicator locally briefly, for long enough that the central command to turn it on would have arrived before the local command expired.
But that then raises the question of why the brief push is enough to trigger the local turn-on but not the central controller; surely it makes no sense for the two to have independent access to the exact details of the analog button-press and to make independent decisions about it based on different rules! The local module should decide if the button has been pressed or not, and then both take local action and communicate with the central controller, so they would never be in conflicting states.
It’s possible that, either in these particular elevators (which are fairly old), or in elevator designs by tradition, or perhaps by old regulatory fiat, this approach was adopted at a technological era when it was economically beneficial to put all the intelligence in one central place, and then do extremely simple things locally to work around it (I didn’t test carefully, the local turn-on of the state indicator may be as simple as “while the button is pressed”).
Or it could be weirder and much more interesting; we can always hope.
Speculation, as above, is cheap. Does anybody actually know anything about elevator control systems?
This particular behavior bugs me because the light coming on instantly tends to influence me to making shorter button pushes (I see confirmation!), which makes it more likely that I haven’t actually held the button down long enough to log my request properly.
It was just too ugly. Even for a temporary server. Especially when you consider all those wires flapping around would impede airflow.
Only took about half an hour of work to rewire it, although waiting for cable tie anchor pads to set (the adhesive wants 24 hours, ideally; and this batch I’ve had pull off in many situations, to the point where if it happens again I’m throwing the rest out) slowed down the elapsed time.
It also made getting the side panel back on easier (this case has a shroud connecting the CPU cooling fan directly to the outside, on the removable side of the case) since the wires were held back. That’s also why the sloppy wiring would work, though—those wires that look like they’d get into the CPU cooler wouldn’t really, once the side panel was on properly.
Cooling is working excellently (the external fan in front of the expansion bay probably helps; that’s held on with cable ties and tape too).
It really probably doesn’t make any sense for businesses with deadlines to meet and a shortage of time to hack around with servers the way we do. On the other hand, we’re keeping quantities of data safe that many of those businesses couldn’t contemplate, for a very small fraction of what they pay for semi-enterprise servers. (Real enterprise storage, from Isolon or people in that tier, is safer, much more available, faster, and so hugely more expensive you can hardly imagine.)
A lot of this works because FreeNAS is built on FreeBSD and uses the FreeBSD port of ZFS. I originally started using ZFS when Sun first released it, using the free version of Solaris. After Oracle took over that became less practical, and after a while running old software I eventually converted to FreeNAS, and we build the rest of the Beyond Conventions servers on FreeNAS from the beginning.
ZFS and FreeBSD let us get away with skating closer to the edge. ZFS was famous from the beginning for finding disk problems in old toy systems (where a lot of people first installed it, to try it out without committing to it) and reporting them as clearcut hardware errors rather than very rare mysterious failures. That’s a good thing—it shows ZFS is zealously guarding your data (it has its own data block checksums, rather than depending entirely on the hardware the way conventional RAID systems do). And it lets us scrimp on disks, especially in the backup arrays. We’re actually using “white label” drives mostly in the backup array, and we need to have multiple redundancy anyway.
I would rate FreeNAS as a clear step above Synology and Netgear and Drobo and those players in the small-server market, both in reliability (unless you skimp too hard on the hardware) and in features.
Rebma 3, the disk server over at Corwin’s, in its current incarnation is an 8+2x4TB array, meaning double redundancy and 32TB usable. Fsfs 4, my server, has a 3x6TB mirror, so just 6TB usable, but that’s enough for photos and books and such, just not huge piles of video (which live at Corwin’s). Zzbackup is currently being used to build an 8+2x6TB backup array which, when the data is replicated to it (locally! it’s a bit big to replicate over the Internet), will come over here, the drives will be transferred into Fsfs (which has capacity for 13 drives), and it will be kept up-to-date via ZFS replication over the internet. My production array in Fsfs is already replicating onto Rebma over the Internet; so when the last step is complete, we’ll have this huge pile of disk with redundant local storage plus continuous off-site replication. The production servers, though not zzbackup, even have ECC RAM, one further little bit of protection for the data.
The new Rebma cost vaguely $500 excluding disks (we didn’t spend it all at once, Rebma 3 has the same motherboard, processor, and memory as Rebma 2, but a new case with more drive slots and much better cooling), not the $1450 a roughly comparable Synology server would cost. And I do think FreeNAS with ZFS has many advantages over the Synology software. In either case the disks are the expensive part at this level.
(I can’t resist reading “Synology” as a very clever brand name for “Chinese server”; I wonder if that has anything to do with it really?)
Here’s some of the hacking I’ve done while assembling the current version of zzbackup:
To boot from a USB flash drive, that is. This old motherboard (ASUS P5P43TD) is bizarrely fussy about booting from USB keys.
Or the one directly under it. But none of the other 4 on the back.
Not absolutely sure on this one.
If you use the wrong port, you get some name relating to the particular USB key instead of “Removable Dev.” Then, putting that device first doesn’t boot from it. (However, to confuse you, if you select the boot menu instead of setup, and choose to boot from that device name, it works.)
I haven’t encountered anything quite this idiotic with more recent motherboards, at least.
Possibly now I’ll be able to find this information if I need it again.