Silicon Valley Redneck

Palo Alto Players bring the funny

Last night was opening night of Spamalot at the Lucie Stern Theater.  There I was, out past my bedtime, in the left front corner of the audience, all for reasons I don't care to explain.

For those who haven't been paying close attention, it's sort of a musical-theater adaptation of Monty Python and the Holy Grail.  How, you may ask, can that screen epic be adapted to the live theater?  Badly, you think?  By embracing the absurdity is how!

And, yes, it works.  For sufficiently silly values of works.  And, in these trying times, we can all use a dose of silliness, right?

One quibble about the production: maybe it was my location, but I had trouble making out the performers' words (especially the Historian's) over the music.  Could be they'll get that sorted out, if the rest of the audience was having the same difficulty.

Oh, yes.  Some of the bits seemed a tad anachronistic.  (No, not the song in Act II, Scene 2; that goes back to New Testament times.)  Try not to get too outraged over such details.

And speaking of outrage!  That fashion for inserting current politics into everything, and alienating half the potential audience?  Not to be seen here, except in passing and not too specifically.  No bashing the audience over the head (nor being-hit-on-the-head lessons, for that matter).  It's broadly offensive, as one ought to expect given its Python lineage, but (to paraphrase Roger Rabbit) only when it's funny.

Anyway: a delightful bit of silly entertainment for those of a certain age.  Young whippersnappers may not appreciate it.

Defining perceptions

The thought semi-randomly crosses my mind: how many Bond-movie villains were mad capitalists of one sort or another?

I don't have the answer offhand, but it seems like Western industrialists are greatly overrepresented in post-1970ish cinematic villainhood.

It's a long way from Amphioxus to the meanest human cuss.

Oh, this is going to take a long time to read.  And, probably, even longer to grok.

Over at Wait But Why: a lengthy piece on Elon Musk's wizard hat, and along the way on the evolution of the nervous system from that of a sponge (no nerves whatsoever) to the human brain and beyond.

Beyond?  Yes!  The human exo-nervous system (having evolved from gestures to speech to writing to printing to a globe-spanning instant communication and storage network) is truly a marvel.  Having a technical issue?  Maybe some young hacker in Egypt has already made progress on it, and published his notes for the world to find when needed.  Or maybe some geezer in Silicon Valley randomly mentioned the problem and a workaround in a blog post.

I'm maybe a quarter of the way in - around this bit.  It's interesting, but I gotta go do other stuff.  Must return to it later.

... Mind you, the global overmind is well and truly cluttered with nonsense, so if you go looking for answers without a good grounding in the subject at hand, you'll quickly be overwhelmed with negative understanding.  There's still no substitute for training your own brain to extract good information from among the dross.  Something about the Internet being the world's greatest library, but the books are scattered randomly around the floor, and some of them are on fire.  Also, most of the books were written by lunatics or propagandists of various sorts.

Appended: The expanded connectivity also interacts with global capitalism in fun ways.  Forgotten in most discussion of capitalism and free-market economics is the rather basic fact that free markets rest on voluntary cooperation for the mutual benefit of the participants.  By enabling direct, small-scale international commerce, the Internet and various platforms built on it allow minimally-funded entrepreneurs to pursue their ideas without the need to involve the Monied Powers - so, for example, I can get prototype gadgets built in Singapore, or buy laser modules from China, at incredibly low prices, without which I just wouldn't be doing these things at all.

Mind you, this doesn't do much for the working-class nontrepreneurs, but maybe in the coming years we'll see some reforms that reduce the cost of employment and allow U.S. manufacturing to be competitive again.  (If I get a gadget business properly started next year, I'll probably want to onshore at least some of the production, and certainly will need to hire people to handle test, calibration, packing, distribution, accounting, logistics, and so on.  Which may mean taking on some apprentices and training them.  What I really don't want to do is hire a dozen regulatory-compliance lawyers.)

Windows Technical Department is back!

With a vengeance.  I've had three calls already today, and it's barely past lunch hour.  There was another call I missed; might have been the same scam.

The name varies from call to call, but it's most assuredly the same old thing.

If the FBI, INTERPOL, and the international banking system can't shut these scammers down, what good are they?

If only The Donald hadn't wasted all those cruise missiles on the Syrians... hey, we still have a MOAB or two, don't we?  Or maybe we could secretly gain control over the NorK EMP satellites!  Deniability, yeah!

Update: Oh, great.  Now they know the name associated with this phone number.

Update 2: Even more calls.  If they can maintain a list of phone numbers with names associated with them (and prior to today I'd assumed they were just dialing at random), why can't they have a flag for the person who answers this number is angry and doesn't fall for our scam, so don't waste time calling it?

And... if the Feds can strongarm banks into cutting off services to legitimate businesses whose products some political faction doesn't like, why can't they cut off payments to these persistent scammers?

If Ol' Combover wants to score some serious points with ordinary 'murricans, maybe he can set the machinery of government in motion to squish this nuisance (and maybe the grandparents scam, and a few other forms of interstate / international wire fraud that keep people's phones ringing and cause panic (and sometimes financial loss) among the insufficiently-cynical).

Update 3: Apparently they've taken to demanding payment by gift card, with the gift card numbers read over the phone.  And stores that sell gift cards are fine with this.

Update 4: They really just don't stop, do they?  Add to shopping list: one of those pocket air horns.  Not that the full volume will carry across, but still.

What are the NSA and SAC good for, if they can't track down overseas scammers and deal with them appropriately?

Ain't technology wonderful?

Amazing news!  According to eSquire,

Trump has a button that he presses so a butler delivers him a Coke.

Wow!

Er.  Y'know... I could have a button to press when I want Amazon to deliver me a bag of kitty litter.  Those are a thing now.

Some people need to get out more.

NorK EMP Menace: Don't Panic. Yet.

Ah, another EMP fear piece, this time at PJ Media.

Point 1:

Fifty-five years ago, the U.S. tested a nuclear weapon high above the atmosphere over the Pacific. At the time, my father -- a nuclear weapons engineer -- was listening on our ham radio.

When the device exploded, we heard nothing in Albuquerque. But, in Honolulu, 1000 miles from the detonation, the sky turned red as streetlights and telephones went out. EMP (Electromagnetic Pulse) effects from the distant nuclear explosion had struck.

Point 2:

an EMP attack requires only a small, light nuclear weapon and the ability to launch it as a satellite.

Don't Panic:

Excuse me?  A small, light nuclear weapon?

Starfish Prime used a big nuke.  One-point-four freaking megatons.  That's a full-on H-bomb, not some little fission device.

OK, so the W49 in question was small and light, in terms of things that can totally incinerate a freaking city.  It was still a bloody great H-bomb.

When there's evidence that the NorKs have anything approaching megaton-range fusion devices, it'll be time to panic.

Update: It's come to my attention that fission bombs are much more effective at generating EMP than are fusion bombs (I have some uninformed speculation as to the reason for this; haven't read up on it in detail).  So... really, very little of the huge yield of that W49 actually went into generating destructive EMP, and a suitable warhead is maybe within North Korea's capabilities in the near future (assuming they can shrink it to a deliverable package).

Go ahead and panic.  A little.  Just how suicidal is Li'l Kimmy? Because I'm fairly confident that we have EMP-hardened second-strike resources.  Like, say, SLBMs.

One of those dreams.

Setting: A church of some sort.  No idea how I'd ended up there, nor what denomination it was.  The actual building was constructed of rough-hewn wood and rammed earth; the few people present were dressed to match.

It was vitally important that I sing something.  They needed someone for the choir, I needed to impress them, whatever.  A sample of a capella singing was in order.  So sing, already!

The only song I could even begin to remember was "Black Jack's Lady".

Which... apart from the glorious inappropriateness of it for the context, and perhaps the sticky issue of the artist?  Even on a good day, my voice was never up to it.

I couldn't have come up with something appropriately inappropriate.  Like, say, "Hope Eyrie" or "The Bard's Exhortation to the Salaryman".  Either of which I could sing just fine (allergies permitting), and, IRL, remember all the words in the proper order.

Note to self: stay out of churches.

Hmmm. Bit of a bother.

Back to the firmware project, USB and all that....

I just changed things such that (as it should be) the USB received-data callback shoves the bytes into a FIFO, whence the command-processing task extracts them.

Which ought, in a sane world, to do the trick.  Alas, it seems that using the highly-abstracted FreeRTOS queue system to implement a high-speed data FIFO ends up chewing through rather a lot of CPU cycles, leading to unreasonable delays.

I don't know for sure just how unreasonable, but maybe I can drop in code to tweak an I/O pin, and hook up an oscilloscope.   In any event, there's a serious case of not keeping up.  Like, it's taking a great many milli-freakin'-seconds just to get a few bytes of data into the processing task.

I'm using a general-purpose queue instead of a ring buffer because FreeRTOS doesn't speak ring buffer.  AGROS does have a fairly efficient implementation of a ring buffer (though I keep thinking it should have a special case for adding a block of bytes in one go, and then updating the counters and the semaphore).

Maybe I need to make it a queue of structures?  Each structure could have a 64-byte data buffer, a byte to hold the data count, and a flag byte (for indicating EOM).  Should save a fair bit of overhead.  Come to think of it, if I also have an offset byte... hm.  I could have a ring buffer of buffers, receive directly into them, and just pass the pointer to the just-processed buffer into the queue to the processing task.

Oh, well.  Off to a social gathering now.

Update: The problem turned out to be a combination of poorly-chosen task priorities and use of printf, which, despite using what I'd assumed to be a fast path to the debugger's message console, seems to be a serious sluggard.

The debugging messages having been eliminated and the priorities adjusted, it now runs at a maybe-reasonable speed, at least for simple messages.  But I still think I'd better go to a ring-of-buffers scheme.

What a novel idea!

Spotted here:

The Defense Department also maintains a policy, called the Predictive Avoidance Doctrine, of not shooting lasers at things unless the trigger-puller knows exactly where that beam will end.

Otherwise known as Rule Four, no?

...No, not that Rule Four.  This'n.

Well, there's one of the problems solved.

So I've got a partially-implemented USBTMC (USB Test & Measurement Class, for programmable test equipment) gadget, and a partially-implemented Ruby class for talking to such things using libusb....

The one thing that's been consistently frustrating remained: getting the permissions and/or ownership set properly on /dev/bus/usb/bus/dev, so that a normal user (or at least a member of group plugdev) would have full access.

I wanted a general solution, not one based on vendor and product IDs, because I'm trying to whip up a T&M framework, and I want it to have access to any TMC device that's plugged in, not just specific models.  What I want to look at is the bInterfaceClass and bInterfaceSubClass fields, really, but those don't appear to do what I want.

So!  Here, after much futzing around, is a udev rule to set the permissions appropriately, on the right file, to allow libusb access:

ENV{ID_USB_INTERFACES}==":fe030*", MODE="0660", GROUP="plugdev"

This is looking for the interface (which is where these fields live, on a TMC device) having a class of fe and subclass of 03, and the protocol starting with 0 (valid protocols are 00 and 01).

Anyway, it handles the one test case I've thrown at it, and my Ruby test no longer requires sudo, so that's a win for the moment.

More firmware head-bashery

Still / back to poking at Kinetis SDK 2.2, and the USB device protocol stack.

Doesn't help that MCUXpresso doesn't (yet) support configuring devices, selecting optional SDK features (like the USB stack) to be incorporated into projects, configuring USB descriptors, and crud like that.

Also doesn't help that the USB demo projects are all for bare metal (I need FreeRTOS), drag along their own copies of the USB stack (of uncertain vintage), and generally are not so exemplary.

But!  Today I managed to get the mouse-lite demo running with FreeRTOS, in a freshly-created project, using the current version of the USB stack.  So now I have a starting point that isn't dragging along too much code in support of device classes that NXP supports but I'm not using.

Yet to be done: much.  I guess the next thing is to replace the HID-mouse descriptors with TMC descriptors, adding the appropriate sorts of endpoints, and figure out what connects to the endpoints and where I intercept class-level activity on endpoint 0 and process the things required for TMC.

A certain amount of study and meditation is called for.

... just about to embark on the mysteries of the fuel injection system.

Update: By late evening, I have it being recognized by the usbtmc kernel driver, including a proper response to the class-specific GET CAPABILITIES request, and - finally! - receiving data from the host on the Bulk Out endpoint.

So now I need to do a bunch of structuring: shoving received data into a queue so a command-processing task can deal with it; buffering up responses; dealing with the pesky TMC message headers; setting things up so that the response data gets sent to the Bulk In endpoint; putting in application hooks for all the extra fiddly functions; hooking it up to my SCPI parser (which will probably need some restructuring); doing something or other with the Interrupt In endpoint (said something presumably being in accordance with the USBTMC-USB488 specs); ....

But none of this is mysterious.  Implementing my own class driver (of sorts) with this USB stack was mysterious.  The rest is pretty much routine, though a certain amount of architectural ponderment at this stage may save a lot of headaches later on.

And I still need to change the way the SCPI command tables are built.  I should have a Ruby script search through the C source files for magic comments containing XML, extract the XML, merge, and then spit out a properly structured table as a new C source file.

Your Chesterton quote of the day

Still making my way through What I Saw in America, in my odd bits of reading time.

In the chapter entitled "Wells and the World State", Chesterton addresses the folly of the fashionable notion, then being put forth by H. G. Wells and many others, that the world ought to be united under a single government.  In so doing, he neatly explains the problems with the European Union... back in 1921.

Along the way, he offers this tidbit, which seems especially topical now, nearly a century later:

To make all politics cosmopolitan is to create an aristocracy of globe-trotters.

And here's another fine annoyance.

Another year, another set of tax forms.

Getting ready to e-file, and the feds helpfully sent me a set of payment vultures for tax due (none this time) and quarterly estimated taxes.

California doesn't send ready-to-use vouchers (nor vultures).  Turbot Ax has some pretty wacky ideas about what the amounts should be, and doesn't believe in printing out the forms with the amounts left blank so I can write in numbers later.

So, I download this year's form 540-ES, and set about filling it in, as usual.  Surprise!  This year's PDF is apparently in a slightly different format, and Adobe Reader 9 (being the last version available for Linux) announces that it won't be able to save the filled-in document.  Which is not so good for records-keeping purposes, besides being inconvenient.  Well, I guess Acrobelfry is for bats more than vultures, eh?  Though it's been clear for some time that Adobe is for the birds.

Alternative PDF readers for Linux might or might not work - qpdf doesn't want to fill in the form at all - but all the ones I try show any un-filled form fields as solid black.  Dunno how those would print.  Toner doesn't grow on trees, you know!

Growf.  Download the latest Acrobat Reader (they're back to calling it that) from Adobe.  It's the new Document Cloud edition!  Excuse me, but I'd prefer to have my documents clear, not cloudy.

Well, anyway.  I can fill in the form on Windows, and print on Linux (printing from Windows being currently problematic).  Seems to get the job done.

Now... am I going to wade through 94 pages of forms before filing?

Update, Tuesday morning:  Did the e-file thing.  TurbotAx told me I still needed to print and mail some forms... but when I clicked on the applicable button, I got an error box explaining that there was a problem converting my forms to PDF.  Eep?  A bit of googlement led me to Roundtuit Intuit's web site, where someone had asked about the exact same thing a few days earlier, and been pointed to a FAQ dealing with printing problems, which was notably unhelpful.

Oh, well: guessing that it was a California thing, probably related to the payment voucher for the tax due but possibly something else, I saved the PDF of the file-for-records collection, opened that, looked at the California instructions, and determined that I had to print out two pages to be mailed, apparently, separately: forms 3582 (Californian for 1040-V) and 8453-OL (Online e-file Return Authorization plus a load of malarkey that I guess gets left blank).

Er... wait.  Says I need to sign and date form 8453-OL within 1 day.  But nothing about an address to which to mail it.  Top of the form says "DO NOT MAIL THIS FORM TO THE FTB".  So, er.  I'm required to sign and date the paper copy, and...?  Just stuff it in my files, or what?

Oh, here we go:

 

• What do I do with my forms FTB 8453, FTB 8453-OL, FTB 8453 (PMT), FTB 8879, FTB 8879 (PMT), FTB 8455, W-2, W-2G, and/or 1099-R?
  • Keep these forms with the copy of your tax return for your records.
  • Keep these forms for four years from the due date of the return or for four years from the date you filed, whichever is later.

  Important! Do not mail these forms to FTB.

 

All righty, then.

Wait, what?

Spotted here:

"On the left if you're consuming fake news you're 34 times more likely than the general population to be a college graduate," says Green.

Hello?  34 times more... um?

What's the probability that a randomly-selected member of the general population is a college graduate?

More'n 3%, right?*

So how can anything be 34 times more likely than that, hm?

I dunno what the quoted person actually said, but, as published, that statement is complete jabberwocky.

Those who write the news stories know nothing about everything.

* Google ⇒ Wikipedia: In the U.S., 32% or so have at least a bachelor's degree.  Was this compared to the world's teeming billions, maybe?  Or has the average lefty fake-news consumer graduated 10.88 times?

Incomplete madness

There's a moderate bit o' madness here, via The VaViperous One.  Fill up them hollow chocolate Easter bunnies with Jell-O and vodka?  Okaaaay....

But, why not take it one step further, and substitute (C₂H₅)₂O for C₂H₅OH?  And have...

...wait for it...

Chocolate / Jell-O Ether Bunnies!

Further Eclipse annoyances

Back to the firmware side of things, and setting up to create derivative projects based on the firmware for one particular gadget.

For hysterical raisins, the starting project refers to an ancestral project.  This is not good; apart from anything else, attempts to build the ancestral project now fail, and building the current project triggers an attempted build of the ancestral one, though the failure is then ignored.

(It doesn't help that the error messages flashes in the console window and a moment later is lost forever.)

Also, for no apparent reason, any build of the project results in a full build, rather than incremental (though the console output shows it being an incremental build), even if nothing whatsoever has changed since the last build.

So... I copy all the shared files over to a new project which exists purely as a place to keep the shared source files.  I then link this new shared project into the active project.  And...!

It's still bloody trying to build the ancestral project.

I search for the ancestral project, and to the name by which it was once referenced, and edit out all references I can find, using vi (the Eclipse GUI doesn't show them existing in the first place).

...still trying to build...

The attempt to build it (and none of the other projects in the workspace) is getting injected into the Makefile.  Why????

Then I rename the ancestral project (whose old name exists nowhere in the current project's directory).  Hey presto!  Eclipse is no longer putting its name in the Makefile, and all is well.  Except for the "incremental" build still insisting on rebuilding every-freakin'-thing, that is.

Just out of curiosity (and hoping to keep Subversion happy), I then restore the ancestral project's original name.  Whoopsie!  Now Eclipse wants to build it again.

Growf?

Oh, wait: maybe it's not in the project, but in the metadata, which is stored in the workspace directory?  Hm.  Well, the name does appear in various places that grep -r can find, so probably it's something to do with that.  Maybe the solution is to blow away the workspace, and re-import the projects?

And so much of this is due to Eclipse's resource management being half-baked.  I can selectively exclude source files from certain builds (which sometimes works and sometimes doesn't), but I can't selectively include files in just a particular build (and not have them included by default in new builds that will be created in the future), so I'm stuck with having a separate project for each gadget.

Update:  Huh.  Squirreled away under Properties ⇒ C/C++ Build => Refresh Policy (this last being a tab), there's a reference to the ancestral project.  Delete that, and... No Change.  Foo.

Reminder: Ruby is not C

Assuming foo to be an integer, in C

    if (foo & 0x80) {
        frob(bar);
    }

will test for bit 7 in foo being set, and do the frob thing if so.

In Ruby, on the other hand, (foo & 0x80) will always be a numeric value, and all numeric values are deemed true.  So, this construct will not behave as expected.  Gotta test for ((foo & 0x80) != 0) instead.

But!  That fiddly detail being sorted out - along with many others; my Ruby is rusty, and also of 1.8 vintage, and I'm trying to figure out an unfamiliar library and a new protocol - I just successfully used Ruby plus libusb to detach a TMC device from the driver, connect to it, send a *idn? query, request the result, and receive the result.

What didn't happen was the minor detail of returning the device to its default driver when the program exited.  Oh, well: cleanup-on-exit is something to worry about later.

Eventually, I'll release a usbtmc Ruby module as open source, so others in my position can see how this stuff works.  But it's nowhere near finished yet.  (Come right down to it, the whole project - the Ruby part, anyway - is meant to be open source, in the fullness of time.  Like, when it's useful.)

Update: I find myself introducing rather a lot of quirk flags to accommodate TMC/488/SCPI devices from the "budget" vendors.  The upper layers will have to worry about this cruft... but probably a lot of that will be handled in vendor- or model-specific subclasses quickly cobbled up from general templates ("look, here's how you deal with a generic 3-channel bench power supply; adapt as needed").

Actual application of the quirk flags may be mainly along the lines of catching things the instrument won't handle properly and throwing informative exceptions, instead of having the instrument beep and relying on someone to come along eventually with a :SYSTem:ERRor? query to note that there's been a 687 out of cheese error or whatever.

One of these things...

From this here article on yet another case of drug price gouging enabled by the U.S. regulatory system (complete with a call for that same regulatory system to impose price controls):

One single prescription pill can stop a contagious case of common pinworm, ringworm or even roundworm.

Hello?  Two points:

• Pinworms are roundworms, so what's with "or even roundworm"?
• Ringworm is a fungal infection, and has nothing whatsoever to do with actual worms.

Layers of editors and fact-checkers.  Right.

"Hello, Mrs. Premise." "Oh, hello, Mrs. Conclusion."

Had a restless night, featuring a hodgepodge of weird dreams.

The last bit involved some sort of mandatory indoctrination session, in which all were expected to agree with the following:

• Mankind must not be allowed to exercise unbounded power;
• Therefore, one specific man must be granted unbounded power, in order to keep the species in check.

Which, stripped to its essentials like that, is obviously looney.  So why do so many people seem to believe it, when the idea is slightly obfuscated, and the generic one specific man is replaced by one actual specific man, or a particular oligarchy?

Why bother?

Not that anyone actually reads the contract behind an airline ticket, but...

Turns out that reading it wouldn't help, because (as with so much in the wonderful world of law), it's apparently written in Humpty-Dumpty-speak, and none of the words mean what they say.

Seems, for example, that the term denied boarding, which looks clear enough, also includes allowed to board and then ordered to leave.  Which, in plain English, isn't the same thing at all.

The whole concept of contracts seems to have become meaningless, between the ubiquity of purported contracts to which people routinely "agree" with the click of a mouse button (and which are written entirely by teams of corporate lawyers, with no room nor opportunity for negotiation) and the incomprehensibility of those same contracts.

 

The Saxon is not like us Normans. His manners are not so polite.
But he never means anything serious till he talks about justice and right.
When he stands like an ox in the furrow – with his sullen set eyes on your own,
And grumbles, 'This isn't fair dealing,' my son, leave the Saxon alone.

        Kipling