Silicon Valley Redneck

Wait, isn't this the twenty-first century?

So it turns out that train that went off the rails yesterday was going way over the speed limit for that section of track.

Amtrak has this thing called the "Advanced Civil Speed Enforcement System", but it wasn't installed in that stretch of track.

Wait... track????

Yeah.  Track.  It uses doohickeys installed in the track to inform trains of speed limits.

*Blinks*

*Shakes head*

Many's the year now we've had this thing called the Global Positioning System.  If your train is operating above ground, there's a pretty good chance GPS can tell it where it is.

And there are things called "maps"; you may have heard of them.  They can be represented in digital form, which rather small computers can read and interpret.  And, for vehicles which are (we hope) constrained to operate on specific, permanently-installed guideways, the maps can be pretty simple, even if you festoon them with extra data like, oh, permanent speed limits.  And surely there are easy ways of communicating temporary speed limits to trains; cellular data, anyone?  Or just dedicated radios at stations, for sending the updates?

One might almost suspect that these systems are designed to funnel money to contractors, by way of government agencies, rather than to solve problems with minimal cost and disruption.

Update: According to this NYT piece (via the WSJ), the automatic speed-limit system that's not yet deployed was begun in 2008.   So... well into the era of cheap commodity GPS modules, cellular data, and little bitty computers that are fully capable of managing map data and identifying the speed limit for a given location and direction.

But such a solution would cost maybe a couple kilobucks per engine*, plus a server, and of course the cost of developing the software for managing the rail map and speed-limit updates.  Wouldn't cost anything at all per mile of track (aside from data entry), and it would be rolled out pretty much all at once; what good is that?

* Depending on the number of engines to be so equipped, of course.  Probably needs to be built around automotive-spec components, which is a headache, and more so a few years ago.

Update 2: Oh... it was installed there, but not operating.  Because, it seems,

The aide said Amtrak informed the committee it has encountered delays turning the PTC on throughout its system because of the need to get the bandwidths required to upgrade the radios to a higher MHz, which improves reliability.

What is this I don't even...?!?!?!

Update 3: Sure appears to be a case of t3h stoopids here.  Seems Amtrak has been building out its own communication infrastructure along the track, and then trying to get the FCC to assign it some spectrum.

Hello?  Guys?

There's existing communication infrastructure covering most, if not all, of that area; certainly enough to send infrequent speed-limit updates.  Access to it doesn't cost all that much, especially if you're arranging a many-device deal with fairly small bandwidth demands (ask Amazon about the cellular Kindles).  If there are blank spots that absolutely must be filled in?  Well, make a deal with AT&T or Verizon or somebody to add a few extra cell towers; your passengers will appreciate it.

When there's good existing infrastructure, why build your own?  Got a bad case of specification creep?  Does it need to retain full functionality is a post-apocalyptic nuclear wasteland, so that commuters can still be delivered to the smoldering remains of the cities?

Or is there some really idiotic system architecture involved, driving a requirement for more bandwidth and reliability than the obvious solution?

Look! Numbers! And logic!

I've been suggesting (off-blog) for some time now that California needs to pay a few rice farmers to move from the California desert to someplace that has natural swamps.

I figure rice is a better target than almonds, what with taking only a couple of years to get back up to speed in a new location.

Well, looky here!  Scott Alexander went and gathered up some real numbers, and the proper target turns out to be ... alfalfa!  Yes, a huge amount of water is being used to grow a very-low-value annual crop.  Just the thing to be moved to someplace where it rains on a regular basis, thereby freeing up water for other uses.

Alas, the complex (and ancient and arcane) system of water rights in the western U.S. probably precludes this.

Garden grammar

My shopping list at the hardware store yesterday:

• One hoe.
• Two hoses.

I have the feeling there's something missing in between.

If I find myself with some spare time...

Maybe I should throw together a handy little Linux utility for finding Windows restore points, letting the user select one, and restoring a certain set of files.  Then create a little bootable ISO image that includes it, and put it out there for the world to download.

Because there doesn't seem to be a handy, low-skill solution for removing SYSKEY passwords after folks get taken in by those "tech support" phone scammers.

And the actual recovery process turns out to be pretty easy, once you figure out what you're doing (and assuming you have a Linux live CD handy), so semi-automating it oughtn't to be a big deal.  Probably a simple PERL script, for those who speak PERL... but I'm out of date on that, so I expect I'd use Ruby.

And... why the smeg doesn't Microsloth provide a way of using those restore points when Windows has become non-bootable?  Like, a "choose a restore point" option in the boot menu?

Family tech support

Yeah, got that more or less wrapped up yesterday.

After a couple of evenings spent getting the vintage PC back into pretty-much-working mode, and one spent helping my father pick out a brand-new one (a Dell, with a fourth-generation Core i3, enough RAM and disk space to last a good long time, and Windows 7 pre-installed), yesterday was turn-on-the-new-PC day.

I'd already copied all the files from the old PC onto an external hard drive using Linux, but having a Windows-format backup seemed a good idea.  I'd already tried using the backup "utility" that was bundled with XP, and discovered that, as had been the case back in the MS-DOS 3.2 days, Microsoft has never learned to write a backup program.

If memory serves, MS-DOS 3.2's backup program worked fine to dump my files... but MS-DOS 3.3's restore program didn't understand the legacy format.  Which made the whole exercise rather less than useful.

Last week, when I backed up the files using Linux, I hit a patch of bad sectors.  The same patch, three times in the process... so I assume it was some kind of NTFS metadata.

When I tried to use Windows backup, it aborted almost immediately with a message that amounted to "It didn't work."  There was also a text file with a page of boilerplate and "It didn't work."  Nothing in any way informative.

Well, yesterday morning I installed AOMEI Backupper, started a system backup, and took the dog for a walk.  On my return, I found an error message: "There's a bad sector on this disk, so I can't back up anything."

C'mon, guys!  I've seen this elsewhere in the Windows world, all too many times.  The old "Abort, Retry, Ignore?" thing has gotten lost, and any error results in the whole operation being unceremoniously terminated.

Well, at least Backupper could do a file backup of the "Documents and Settings" area.

Then!  Unplug the old machine, plug in the new one, and see what's on it.

Windows 7 Pro comes up.  Good!  But...

I'd left the old mouse connected, via a USB hub.  I'm reminded that Windows doesn't do class drivers worth anything: it spent a loooong time looking for the device drivers for the hub and the mouse, and meanwhile the mouse wasn't working.  I fetched the mouse that came with the new box and plugged in into a front-panel port.  Windows looked for the device driver, and found it before too long.  Moving the mouse to a different port resulted in yet another loading-device-driver incident.  Guys?  This is insane.  Hub class drivers and HID class drivers: look them up.  See how Linux has handled them since before there was Windows 98.  Eventually, the old mouse on the hub started working too.

McCrappee complained that it wasn't enabled, and then enabled itself.  Argh!  But at least uninstalling it worked... slowly.  Then: install Panda, enable the firewall, reboot, see that the hundred-and-one system updates are gonna take a while, run off to Fry's for a cheap 16GB thumb drive to hold a system recovery image, get back, wait for the last dozen system updates to install and the system to reboot, install the latest Thunderfox and Firebird, create user accounts, reboot (installing another dozen system updates), find the latest (Win7-compatible) software bundle for the printer, try to install that, have it abort right near the end but automatically find a solution (which will involve a reboot), manually invoke Windows Update to drag in yet anotherer set of updates, do the reboot, install the printer software successfully this time....

Then generate the emergency restore image onto the thumb drive, then switch to the family account, plug in the external hard drive, and commence copying the user data over from the backup I'd done using Linux.

That at least went smoothly.  Win 7 even helpfully recognized things whose canonical locations had moved, and offered to put them in the new places, merge directories, and otherwise Do What I Meant.

Then, the test!  Launch brand-new Firefox... and the bookmarks are all there!  Launch brand-new Thunderbird... and it opens the inbox!  So all's good to go on the web & mail fronts.

Install the latest OpenOffice, declare it Sufficient Unto the Day, and head home to dinner (and a worried menagerie).

Question of the day: why does turning on pre-installed Windows 7 take longer than installing Linux on a blank machine?

I'll still need to help with installing other software (some flavor of Photoshop Jr., MS Office (because Work), Acrobelfry, and probably also the GIMP, and Inkscape, and other useful things).

Eventually, I guess I'd better set them up with a 2.5"-format external hard drive (less likely to cook itself to death than the 3.5" form factor) and some sort of automated incremental backup, so there'll always be two copies of all the important documents and family photos.  Maybe even some sort of cloud-based backup?

Not finding an answer on Google...

Every so often, I hear a particular bird call.

It's highly distinctive, and definitely of avian origin.

Apart from the bird voice, the actual sound pattern is that of the oscillation overthruster from The Adventures of Buckaroo Banzai Across the 8^th Dimension.

Now, either some local bird picked up that call from the movie... or the sound in the movie was borrowed from a bird (presumably a species rather than an individual).

I'm kinda assuming the latter.  But I'm not finding anything on the Internets about the sound having been borrowed from a bird.

Any ornithocinematologists out there?

Mnfxt.

Up late last night, what with another evening of family tech support.

Slept with the bedroom door closed, with the vague notion of sleeping in a bit.

No such luck.

Just over an hour early, the alarm cat came knocking on the door.

Once admitted, he made absolutely certain I was alive (and awake, and up and moving) before going off to mind his own business again.

Wait, haven't I seen this movie before?

AMD just announced its new Intel Killer CPU, for general availability two years hence.

We all know how that works, right?  Sounds totally awesome when it's announced, but (as with the Fairchild Clipper CPU and the Architectural Performance Gap) by the time it actually hits the market, the competition will have gotten ahead of it again.

Now, here's the fun bit:

When the new Intel Killer does hit the market, and is found to be wanting, that's bad news for AMD, so AMD's share price will drop, briefly.

But it's good news for Intel, because it won't be losing market share to AMD, right?  So, when the attack fails, Intel's share price will rise?

Nope.  Not how it works.  AMD's flop is bad news for the technology sector, and especially the PC CPU subsector, and so we can expect Intel's share price to fall, probably more than AMD's.

Watch.  Two years from now, plus rollout delays.  It'll happen again, just as it has every time AMD has done this.

And if that suggests that our money is being managed by lunatics, perhaps there's a clue somewhere.

Some thoughts on the Garland Jihad Affair

Seems someone held an art event in Texas, with an "everyone draw Mohammed" theme.  A brace of jihadis (Unexpectedly!) showed up, and they were duly killed.

1. Isn't that called "hunting over bait?"

2. Naturally, the usual suspects are saying that those who draw, publish, or promote pictures of a guy with a beard and a turban* are asking for it.

Curiously, the same tribe that takes this position gets all bent out of shape about suggestions that a rape victim was asking for it.

And they think it perfectly fine (and ever so brave!) to publish the most vile caricatures of NRA members, secure in the knowledge that those caricatures are wrong and that those who publish them can count on remaining un-shot.

Yup.  Free speech is only free as long as it doesn't honk off murders, rioters, government officials, nor people with important connections.

 

* I keep wondering when the jihadis will start attacking Sikhs for wearing beards and turbans and thus looking like living depictions of ol' Mo.  Srsly: publish a drawing of some guy with a beard and a turban, and it must be Blasphemy Against The Prophet, because who else in the history of ever has had those two attributes?

Grrrrr.

Spent many hours so far trying to get a handle on how to debug a hodgepodge of third-, fourth-, and fifth-party C code.

Doesn't help that I can't seem to get useful trace information; the information can be generated, sure enough, but there doesn't seem to be a capability available, in this configuration, for having the debugger log trace events and proceed, so basically I see a hard-coded breakpoint for each event: not helpful, especially when the problem is timing-sensitive.

Some of this n-th party code uses some approximation of Hungarian notation for variable and type names.  Annoying.  And...!

I just discovered that some of the actual type names are less than useful.  There's a struct pointer being passed, which refers to a global variable, whose type is something long and semi-descriptive; that's typedef'ed to another such type name, and all this eventually resolves to...

...wait for it...

void *

Yup.  All the newfangled type checking in modern C, neatly bypassed.  But the names are ever so informative to a human reading the code... as long as it's the same human who wrote it, assuming he remembers what conventions he used.

And, of course, the debugger sees it as void *, and won't display the fields in the pointed-to structure.

Anyway, there's some timing-sensitive issue apparently involving uninitialized variables, and I still haven't determined whether it's really related to my attempt to migrate the code to a slightly different build environment, or some horrible bug that's been lurking all along and just hadn't surfaced until now, or something else entirely.

Yeah, there's a better way of handling pointers to various related structures, without making them all void *.  In AGROS, there's (for example) a data structure associated with each I/O device.  The first, minimal, part of this has a constant format for all device types, defined as struct iodev_data, so pointers are passed around as struct iodev_data *, and typecast to the device-specific type within the driver if necessary.

Arithmetic overflow

Seems Boeing has one.

In a safety-critical system, too, but at least the nature of the bug is such that it won't happen in a normal operation cycle.

Basically: an internal counter overflows at 2³¹ centiseconds from last power-on, and the controller gets a wedgie.

Given that an airliner is supposed to receive a major overhaul at intervals of rather less than 8 months, and that ordinarily results in everything being power-cycled, this isn’t likely to be a problem, but it's the sort of thing that gets worry-inducing, given the consequences of a (synchronized!) failure.

Remembering the evolution of AGROS...

I started with an unsigned 32-bit millisecond counter, not for actual timekeeping but for handling the sort of relative scheduling that's common in real-time systems.  This wraps every 1193 hours.

Then I started having to keep event logs, tracking cumulative runtime without regard to power cycles.  For this I added an unsigned 32-bit decisecond counter, good for 13.6 years, which is all the power-on time the product in question is rated for.  (Actually, the current firmware for that class of product has its own decisecond counters for power-on time and various sorts of operation time, so I should probably weed this particular artifact out of the AGROS system code, assuming AGROS itself has any future at this point.)  The 32-bit decisecond thing was a compromise among log storage space (originally a rather small EEPROM), resolution, and covering the life of the product.

When I added TCP/IP, I felt the need for a sub-decisecond counter that absolutely, positively would not wrap during operation, so I added an unsigned 64-bit microsecond counter (which in practice is incremented by 1000 every millisecond).  This has a range of 548 kiloyears.  In most cases, it's time since last power-on, though it could also be cumulative runtime or even time since the beginning of the Common Era.

But storing a 64-bit value takes up a bunch of EEPROM space, so the logs still use the old decisecond counters.

Compromises.  They're everywhere.

A timely reminder

Helston hath no furry like a bright May morn.

(There are songs for Beltane, and International Labor Day, and even Walpurgisnacht.  Any songs for Victims of Communism Day?)

Protecting the Greenwich Observatory chrono-monopoly

The High Court (UK) has ordered access to Popcorn Time blocked.

No longer may Brits dial 767-2676 to set their watches.

Wait, what?  It's some combination bittorrent client and video player app?

Never mind.