Silicon Valley Redneck

Iggle upgrade

My upgrade of EAGLE from 4.x to 5.3 arrived from CadSoft this morning.  Installation was straightforward.  Looks like it's going to behave itself.

I haven't started exploring the new features yet (what with there being real work to do today).  On a quick look, though, it's nice... and the bundled library collection has expanded quite a bit since version 4.1 (though a lot of them are user-contributed and contain only a few parts; a bit of central work on compiling master libraries would have been a good idea).

Update: the user interface is improved in various little ways (though I'm not sure I like the new delicate pastel look).  It has PDF export built in!  And cross-reference labels (though the mechanism is a bit awkward).  And... user-defined attributes!  Yippee!  That's a feature I'd really been missing.  I'll have to investigate just how this works in detail, but it should certainly allow me to tag passives with things like tolerance, voltage or power rating, dielectric type, and so on... normally leaving these blank, but having them available when I really need to differentiate things in the BOM.

The autorouter seems (based on a couple of quick tests) to work about the same as ever, and still doesn't deal nicely with user-defined power/ground fill (polygons may fall apart at the last minute), and still likes to route traces through the corners of SMD pads (I don't know that this is an actual problem, but it doesn't look right).  It seems to me that the overall result looks a bit cleaner than the old version's usual output.

I still need to try running some of my indispensible ULPs (slightly adapted from user-group programs) to make sure they still work... and then see how to incorporate the new attributes into the BOM program.

Grumble grumble modern WiFi grumble

Fry's had wireless grouters on sale for $15 again - the Airlink 101  AR430W - so I picked one up, on account of my existing access point being a mere 802.11(b) slowpoke, and me having the notion that fastish access to the house network with modern security features might be appropriate.  (What I actually want is an access point, not a router, but access points weren't on sale.  I may eventually get a nice access point and stick the cheap router behind my mother's PC so's to have secured wireless access at my parents' house.)

Anyway: set it up (pretty much trivial), give it 256 bits worth of /dev/random for the key (enabling WPA-PSH/WPA2-PSK), and....

The SSID shows up.  My shiny new (well, new in 2005) dinky laptop, running Debian-stable, doesn't know how to talk to it, even after I install wpa_supplicant from source; the supplicant keeps saying authentication timed out (and logging strange errors, including "operation not supported").  If I reboot in Windows, it works.  Hmmm....

Much futzing around.  Eventually I fire up the old laptop running new Kubuntu-Heffalump, plug in the PCMCIA WiFi card, move over the same wpa_supplicant.conf... and it works.  (Well, it connects to the router; then I need to do 'ifup ath0' manually at the moment.)

Well, it could be an ipw2200 driver issue; that's an old version of the driver.  Or, mayhap, a kernel issue.  Must be time to update that system; it's still on 2.6.18.  Or maybe I have to update the whole system to -unstable, which is really not something I want to do, as the configuration is somewhat brittle (though I suppose the current -unstable might actually have better support for that oddball laptop than the version I'm running now).

Update: fixed sources.list; did a dist-upgrade to the latest -testing (which, being a several-month upgrade, needed quite a bit of manual intervention); rebooted (which worked); now it's running the 2.6.26 kernel, and wpa_supplicant tells me that I need to use the wext driver instead of iw.  OK, so I do that, and try to set up the interface/supplicant using one of the newfangled utilities, which apparently doesn't work... but now, mysteriously, when I do an ifup on the WiFi interface, the supplicant wakes up and uses my configuration file, hooray!

So, I guess if you're using a reasonably current release of Linux, WPA does in fact work, though the mechanisms may be obscure.

I also (as long as I was working on it) installed a dinky USB Bluetooth adapter, and, attempting to follow someone's slightly dated instructions that didn't really match my system, eventually did manage to pair it with my cellphone, after which a minor change to the kppp configuration let me use EVDO with the phone still in my pocket.  So, the USB-to-cellphone cable is now optional, though potentially useful for charging the phone's battery.

Well, this is annoying.

What with Firefox 2.0.x having officially reached the end of its supported life, I switched to 3.0.4 last week.

There were a couple of transition annoyances - mainly, it lost many of my newer bookmarks until I deleted all my bookmarks and did an explicit import from the old 2.0 bookmarks file, and of course I had to go out and find compatible versions of some of the extensions I use.

There's an ongoing problem, though: duplex printing.  I don't find any references to this on the Web, so there doesn't seem to be an answer (if I find one, I'll post an update).

Now, here's the thing: I have a duplex-capable printer (Brother HL-5250DN), Linux (Debian-unstable), and CUPS.  The .ppd file and lpoptions quite clearly specify DuplexNoTumble as the default... and yet Firefox insists on defaulting to DuplexTumble every freaking time I go to print something.

It doesn't seem to be one of those KDE-vs-Gnome things, either; I just fired up the Gnome CUPS manager, and it thinks NoTumble is the default.  So, unless I switch to the Page Setup tab, and change the duplex setting every time, my printouts get formatted for flipping along the short edge instead of the long edge.

Ah, well... printing from browsers has been problematic for a long time (and not just Mozilla products, and not just under Linux), but this is just plain bad integration.

A session of slow-motion head-bashery winds down

On and off for the last few weeks (IMCFT, what with work being in Busy Mode), I've been trying to add support to AGROS for the USB device interface on the LPC2148 (and thence the LPC23xx and such).

Well, it's been frustrating.  The NXP documentation isn't very good, and the various sample code isn't set up to show just how the interface actually works.

Eventually, looking at Micrium's code, I figured out what I think is the last bit of magic: Set Address needs to have the command issued to the protocol engine once (so it takes effect on the next Setup packet), not twice (to take effect immediately), and the Set Address command needs to be ACKed with a zero-length packet.

Anyway, instead of seeing a half-second (or five-second) timeout and bus reset as with the various b0rked attempts, I'm now seeing a Get Configuration Descriptor command immediately after Set Address... and I'm not responding to it, because I haven't built a configuration descriptor yet.

Off to do some real work now (you know, the kind that pays the bills).  Once I get my USB driver working properly, I expect I'll post some nice sample code that shows just how the interface gets used.

Having USB device support in AGROS may come in handy for real work soon... toss in an ACM layer and a SCPI interpreter, and it looks like part of a line of quick'n'easy custom test equipment.

(Update: the USB class for something that speaks SCPI should of course be TMC, not ACM.  I think I have a copy of the TMC spec squirreled away somewhere... and it can't be any more perverse and incomprehensible than the ACM spec... can it?)

MomDSL update

A bit over a month ago, I mentioned the trouble I'd had trying, for the second time, to get my parents upgraded from dialup to AT&T/SBC/Yahoo DSL.

Well, I tried a third time, and succeeded, and a few days later their DSL installation kit showed up in the mail.  A few days after that, I went over to hook it up.

The actual installation was totally straightforward, though I admit I wasn't attempting to follow the instructions provided.

When it came time to do the bits where the software gets installed and configured, though, I had to resort to the CD

There was a lot of stupid stuff in the setup procedure.  There was some stuff that might have made some kind of sense, except that no explanation for it was offered (so, in many cases, I ended up taking wild guesses as to what to put in the blanks on the forms), and some that was just obnoxious, like demanding to know the magic number on the label on the bottom of the DSL modem (c'mon, now: it's coming in on the right phone line, isn't it?) and sundry other rigmarole involved in getting through the process.

Oh, and, as usual, there was nothing in the documentation that suggested what the lights on the modem mean, what state they should be in during normal operation, and what abnormal states might signify.

Then, with DSL running, I set up Thunderbird... and the mail server started sending nastygrams about connecting in an insecure fashion.  (C'mon, guys, it's connecting over your freakin' network!)  So, I had to do some futzing around to determine what combination of settings it wanter (SSL, not TLS, for both POP and SMTP, and the user name in both places has to be username@att.net, not just username.)

They do helpfully provide instructions for configuring a mail client... but only if the client in question is Outlook.  Outlook?  They're worried about security and they're encouraging people to use Outlook?  Oy.

Well, it all seems to be working now, and, for a change, Windows Update can finish running.  (As can Avira's update; I had to reinstall Avira, as the old version had gotten broken, probably through a protracted failure to update.)  XP SP3 doesn't seem to want to install, for reasons it can't, or won't, explain, but then it looks like it's failing to install on my lab machine too.

Putting the Iggle back to work, hooray!

I'd been kvetching about how some recent update to something on my Debian-unstable workstation had caused EAGLE (PCB layout / schematic-capture program from Cadsoft) to be terribly slow at doing anything window-related.  Window redisplaying and resizing were terribly sluggish.

Well, I'm actually needing to use EAGLE for real work, and the persistent slowness was getting to be enough of an obstacle that I did some further digging.

It's not Lenny, and it's not x.org (someone's suggested change to xorg.conf for a similar-sounding, but not EAGLE-specific, problem had no perceptible effect).  It's the Nvidia closed-source driver (173.14.09), which I believe I updated from an older, not-having-this-problem version to accommodate a new kernel version.

This discussion thread turns up the solution:

Big part of the problem is that nvidia driver is unable to set automatically this 'InitialPixmapPlacement' (whatever that means) to right value for the current system. It makes a HUGE difference setting that right for your system. At home on 8800 right value was 0 if I'm not mistaken, here at work on 6200 it is 2 and on my colleague's 6200 it is 0. And nvidia's setting is ALWAYS 1. So the driver just don't know what to set and they just hard set it to 1. So if You want to experiment try this 'nvidia-settings -a InitialPixmapPlacement=0 to 4' and running gtkperf after each setting to check if speed changes. Mine went from 60 sec total to 7 sec !!! (that of course depend much on the theme and fastest one is 'ThinIce'). And of course it SHOULD NOT BE USER'S problem to test which setting is best for their system and that default setting to be 90% slower than best making the whole system worthless ...

Well.

Not having gtkperf installed, I tried the nvidia-settings incantation with the suggested values, trying EAGLE after each.

A value of 2 turns out to be right for my system; EAGLE is back to its old zippy self.  A value of 4 might perhaps have been even a tad faster, but the results were wrong, making it rather non-useful.

The next suggested solution works too.  Set InitialPixmapPlacement back to 1, go into the menu editor, and change the invocation of EAGLE from

nice /opt/eagle/bin/eagle

to

XLIB_SKIP_ARGB_VISUALS=1 nice /opt/eagle/bin/eagle

(Assuming, of course, that EAGLE lives in /opt/eagle, and that you like to run it niced so autoroutes don't drag your web surfing down.)  This also seems to work fine.  Don't ask me why, nor what that xlib environment variable is doing.

Whoopsie!

It seemed like time to put the third PC - the one that runs Windows - into the new cabinet, so it would be there, ready for use.

This involved a bit of a struggle, what with the KVM cables being of limited length.

While I was tugging on the cables, something went POP! and there was a smell of Magic Blue Smoke.

Yikes!

Shut the workstation down, shut the server down, start sniffing... hmmm.  The lights are out on the USB hub for the Windows box.  The one that I'd plugged in first, because it was easy, before messing with the KVM connections.

This was one of a pair of Vakoss 7-port USB 2.0 hubs I'd bought on sale at Fry's as part of the Grand Reconfiguration Project.

Its wall wart was the source of the smell.  Cheap damn Martian power packs!

Find another 5V wall wart lying around, albeit a rather bulky one.  Substitute that.  Lights on hub come on.  Plug the host cable into the USB 2.0 add-in card in the Windows box.  Watch some lights come on.

Er... lights come on?

Yep.  These Vakoss hubs evidently leak power back up the host cable... so if the host isn't powered up, and doesn't protect itself against reverse power feed, the little wall wart winds up trying to supply power for everything in the PC that can draw current from the +5V rail.

Feh.

Afterthought: y'know, this wouldn't be a problem if the wall wart were plugged into a switched outlet.  Thing is, PCs haven't had switched outlets since the days of big red power switches.  PC, XT, AT: switched outlet on the back.  ATX: nope.  There's not even a control signal that could be used to operate a switched outlet strip.  (Not that anyone makes electrically-switched outlet strips, but adding an SSR to an outlet strip shouldn't be real difficult, if only there were a standard control signal on a standard connector to use for the purpose.  As in, "when the power is on, this pin sources +5V through a 220Ω resistor, relative to that pin, which is nominally at ground potential.")

"The telephone company does not want your die-um."

My parents are still on dialup Internet access.  Have been for years.  Back in the 90s, I got my mother signed up for a free e-mail account on Juno, then Juno started offering relatively cheap dialup TCP/IP, so she signed up for that.

Well, a heck of a lot of things become nigh-well unusable at 56K.  Windows, for one: those pesky security updates take for-freaking-ever to load.

So, it's past time to being them into the exciting new world of broadband.

I actually tried to do this several months ago: go to Yahoo's DSL page, and proceed through all the stages of signing up.  If I recall correctly, part of the signing-up process was going to involve a call either to or from the land line that was to be used for the DSL... which appeared problematic, given that we were using that line for the dialup access to sign up for the DSL.

I don't remember if that was what blocked our efforts for that day, or if we ran into a step of the process that had an "OUT OF ORDER" sign on it before getting to that point.

Anyway, today I took my travel laptop over there, plugged my cellphone into it - look, Ma, your phone works in the meantime! - and visited dsl.yahoo.com.

Well, Yahoo is still advertising the SBC/Yahoo DSL thing.  Except that it notes that SBC is now AT&T.  And, if you select AT&T as your existing land-line provider, you're promptly redirected to AT&T's web site (on sbc.com), which says nothing whatsoever about Yahoo.

Well, I didn't really see the need for dragging Yahoo into  it anyway.  So, punch in the area code and first three digits; get to the right page for the area; punch in the complete phone number (the site not bothering to remember what I'd told it earlier); find the $20/month no-commitment plan (plus $50 for the modem); click "Add to cart"....

Oops.  Add-to-cart gets a blank page.  As in, contains no HTML whatsoever.  Try again: same thing.  Does their site not know what to do about Firefox 3.0, so it just returns blankness?

Start over, in Konqueror.  Now add-to-cart works.  Select the $50 modem, self-install, sundry other questions... confirm this is what we want... click the "Checkout" button...

...and get a page that announces that the site is out of order.  Down for maintenance.  For your continued comfort and convenience, passengers will remain seated until the lemon-soaked towelettes arrive.

Grrrr....

Well, maybe they'll just have to call up Comcast and get Internet service added to their cable.  I've been avoiding that, as Comcast has a horrible reputation for customer service, and the last couple of times cable guys have come out to their place to install stuff, they've gotten it wrong.  (And, of course, the shiny new Digital Cable doesn't come with a user manual.)

I'm quite happy with my ISP (Raw Bandwidth Communications), but their low-end DSL is kinda overkill for my parents, and not cheap by today's standards.  It's looking suspiciously like the cheap basic household broadband is unobtainable, though.

The dangers of www-bling

I'd been meaning to comment on this for a while now - pretty much, ever since I started using NoseCrypt - but it's suddenly become topical, so here we go.

Have you even noticed that a lot of web sites - especially blogs and news sites (commercial or otherwise) take forever to load, and sometimes never finish loading?  How sometimes your CPU usage will go to 100% when you have a particular site open in your browser?

It's that darned bling.

Go on, install NoScript.  You should have it anyway.

Now, while you're perusing the Web and seeing "Javascript blocked" notifications, click on the little NoScript icon and see how many different domains are serving up scripty content for that one page.

And that's just scripts; chances are, there's non-script content being dragged in from several other domains, too.

Now, if you're building a web site, this presents a problem: when you bring in content from other sites, you no longer control exactly what the content will be... nor its availability.  So, if a user comes along and tries to view your site, and you're using content from a dozen servers, and one of those servers is down at the moment, your site is broken - at best, it'll mostly display OK but the browser will show the little "loading..." spinner forever; at worst, the whole site won't render properly because a chunk of the expected content is missing.

(I find it really annoying that some big commercial sites keep content scattered around multiple domains controlled by the same company.  Since its early days, Yahoo (for example) has kept images (and now scripts) under yimg.com.  Why not yimg.yahoo.com?  Why have a whole separate domain, and make life difficult for those who regard cross-site content (especially scripting) as a potential security problem?)

Anyway, what makes this topical is that, after getting the world and its dog to #include their code, the folks at Sitemeter apparently updated that code... adding a bug... which collides with a bug in IE7.  See here and here for information.

So you see: one programmer updates one script, and suddenly many sites are horribly broken.

Now imagine a malicious programmer making a change to some Javascript that's included by just about everybody.  Given how bloated and complex browsers have gotten, there have to be plenty of exploitable scripting vulnerabilities out there.  Or... imagine a DNS-spoofing attack, which substituted a fake Sitemeter (or whatever) with the malicious code for the real Sitemeter.  Yeah, the DNS flaw is supposed to be mostly patched now, but a month ago this would have been a real possibility.

"He's holding a thermal defenestrator!"

For a few years now, I've had this problem: the computers under my desk emit hot air, which builds up under the desk and in the office generally.  This keeps my knees toasty in winter, but, in summer, it's most unwelcome.

So, something over a year ago, I embarked on the construction of a thermal defenestrator: an arrangement whereby the hot air from the computers would be conveyed to the window, and thence dumped overboard.  The various bits and pieces have been taking up space in my garage for a long time now.

This month, I finally got serious about it.  With a few design changes, and working in the available bits of time when (a) I wasn't busy, (b) it wasn't too hot, and (c) it wasn't too dark, I constructed a cabinet sized to fit under the side table and accommodate three full-tower PCs and the two big UPSes, with an exhaust fan at the corner nearest the window.

This afternoon, I cut a last few holes in the cabinet, cleared out the space under the end table, put the cabinet there, pulled out several years' accumulation of cables and dust from behind the desk, moved the UPSes into the new cabinet, ran the various necessary cables hither and yon, put two of the three PCs in their places, booted them....

It looks a lot tidier in here now.  The thermal situation isn't improved yet, as I haven't yet run the dryer vent hose from the exhaust port to the window.  Also, I need to pick up a couple of long-tailed outlet strips (to bring server-UPS and workstation-UPS power out to things that need them outside the box), and a 15-foot DVI cable (using the analog cable via the KVM switch gives a blurry display on my nice high-res monitor).  While I'm at it, I need to hook up the speakers to the workstation (the speakers' cable wouldn't reach, and I didn't find a suitable extension cable until after I'd tucked things together, so I'm leaving that for tomorrow).  Then there's plugging in the third PC (the Windows box), and it'll all be nice and tidy.

I was leaving open the possibility of hanging a slitted plastic sheet over the front and grafting on a filtered intake fan, but that's not looking especially plausible now.  'Twould be nice to cut down on the dust the computers inhale, though.

Oh, and while I had the power off earlier, I turned off the UPS in the lab.  When I turned it back on, it started beeping about a sick battery.  Just a couple of weeks ago, I replaced the batteries in the workstation UPS. A month or so before that, I swapped UPSes around because both the lab UPS and its neighbor needed new batteries.  This must be the year for all the UPS batteries to go bad.  (Trying to remember how long ago it was that I replaced the server UPS batteries.)