Silicon Valley Redneck

"Geek social graces"

Linus went to the Osberts and met various celebrities he couldn't identify.

Puts me in mind of the first time I attended Making Orbit (a space-access convention).  Failing to spot the registration desk, I (rather brusquely) buttonholed a pair of obvious convention-goers to ask where registration was.  A couple of hours later, I found out the people I'd accosted were Poul and Karen Anderson.

Yes, I know perfectly well who some of these people are by name; I'm just really bad at matching faces with the names.

Heck, if I met Linus, I wouldn't recognize him without an introduction.

 

Grumble (perennial)

Continuing with this Qt thing....

Using table views and standard items turns out to be reasonably straightforward... but... there's a nuisance in there.

As with Java 's widgets (any flavor) there's no easy way of embedding widgets in a table, nor of formatting a column to be represented using a standard type of widget.

I guess the same is true of GTK, 'cause in the two places I've built tables with widgets as cells, the tables were actually grid-layout things, not table views, and accordingly the header scrolls along with the contents instead of staying put like a header should.

After much futzing around, I figured out how to use a Qt delegate thingy to use a combo box as the editor function for a column in a table view... but the user has to double-click on the cell before the editor appears, which is annoying.  What I really want is to have the combo box there all the time... or, for the case at hand, to have the cell be a checkbox, since it's a boolean field.  Apparently, though, one can't simply delegate rendering and editing to an existing widget type.

Hmph.  Well, I suppose I could build my own custom table mechanism around a grid layout, and somehow synchronize the widths of header cells to the widths of grid columns.... but that's a bunch of work, and I'd be fighting the toolkit instead of working with it.

 Update: Qt provides a form layout thing that's kinda-sorta what I want, except that it's strictly two columns, and it doesn't have the combination of scrolling body and non-scrolling header.  Actually, it's almost exactly not what I want.  The SQL relational delegate is vaguely related to what I want, in terms of formatting a table column as a combo-box widget, but it's way too specific.

Guess I'm stuck writing my own table-of-widgets widget, 'cause the delegation mechanism appears to involve way too much wheel-reinvention for each delegate.

While I'm at it, though, I may as well include a mechanism for referring to rows and columns symbolically, thus getting rid of the annoying proliferation of hard-coded numerical column IDs that have to get changed if you insert a column in the middle.

 

Confoozled.

Consider:

class Flibble < Qt::Widget
  def initialize(s, &action)
    super()
    
    @action = action
  end
end

q = Flibble.new("zonk") do |f|
  STDERR << "Flibble #{f.inspect}\n"
end

Now, what I expect to see on STDERR is exactly nothing, since the action block never gets called.

Instead, what I see is the action block being invoked during the call to super(), when the Flibble object has not yet been initialized.

If I make Flibble a subclass of, say, String, it behaves as expected, i.e., the action block never happens.  If it's a subclass of a Qt4 widget, the action block does happen.

This example is obviously silly, but in real life I like to have Ruby classes for things like pushbuttons that are invoked like so:

    btn2 = ToggleButton.new(ToggleSwitchUp, ToggleSwitchDown) do |b|
      led.value = b.value
    end

And, as a rule, I don't expect the block to execute during initialization, nor to be called on an uninitialized object.

I can't catch the miscall in the class code, as it's happening outside my code, somewhere in the Qt4 binding.  If it matters, it needs to be checked for inside the block that's only supposed to be called when an interesting event has happened, such as the button being clicked.

Grrrr.

Update:  Stepping away from the computer for a few minutes led to inspiration.  Apparently the Qt initializers execute whatever block they're given, and the superclass inherits the block given to the subclass even if it's not passed along as a parameter.  So, we simply override the upward inheritance by passing an empty block, thusly:

    super(){}

 Update 2: Yeah, you can do spiffy & stylish stuff with Qt, pretty easily once you get past a few peculiarities.  Much more coherent & convenient than GTK+.  Being as how Qt is under LGPL these days (licensing doubts having been my main reason for starting out with GTK+ a few years back), I think I'll be migrating to Qt for my GUI needs.

Yeah, it's silly... but it's testing some gussied-up widgets that were a bunch harder to write, and less useful, in the GTK+ world.

Still need to figure out how to do a few more things, like a drawing area with interpolated curves on it, but I think the features I need are there.

 

Another drear and drizzlesome day

Yeah, we do need more rain this season; there'd been a dry spell after the wet start.

And the new berry bushes are looking happy, sitting out there in their nursery pots waiting for me to dig up the strip alongside the patio so they can be planted properly.  (I decided to rip out the mixture of elderly and ill-maintained rosebushes, street-tree seedlings, honeysuckle, and weeds, and vacciniumate that strip, to which end I bought an assortment of blueberry and huckleberry bushes last weekend.  Replacement rosebushes for filling in the areas that are destined to remain roses will happen later... but can't wait too long, as many of the plants seem to believe it's spring already.)

And there's plenty of indoor work I should be getting done.

But still: I've only managed to get out for morning walkies once this week, and I really do need regular exercise.

And it's not like there's room at my desk for a pedal-powered generator to run the computers.

Hmph.  Well, assuming we get the promised break in the rain this weekend, I should get some exercise tearing up that strip for re-planting.  And there's a fencepost that needs reinforcing, which can't happen until the biggest of the street-tree seedlings has been well and truly eradicated.  So, there's much pickaxe work to be done, most of it at awkward angles.

(And why isn't the canonical pickaxe called a pickadze?)

 

Putting the new server together

Most of the bits are there: a case (another Cooler Master mesh-front mid tower), power supply (Thermaltake 430W, way overkill and quiet), motherboard (a cheapie that'd been lying around since a hardware shuffle a couple of years back, but it does have a pair of SATA300 ports and gigabit Ethernet), CPU (bargain-basement Core 2 Duo, likewise from a couple of years back), 2 GB of RAM (Crucial), a 1.5 TB hard drive (WD Caviar Green, on sale at Micro Center), a second Ethernet card (just 10/100, an $8 special), and the cheapest video card I could find (a $40 fanless PCI-E 1.0 critter with an Nvidia chipset, Fry's returned special marked down to $24).

Actually, that's the fourth video card that's been in the system.  The first was similar but slightly up-spec, and was lying around for some reason, but I completely failed to get VGA video out of it (and didn't try hooking up the DVI, since hooking up another DVI source to my main monitor would be a pain).  The second was an ancient PCI card with an S3 chipset; the Debian installer (graphical or text) set it to some mode my monitor didn't like, and the Ubuntu (10.10, Meretricious Manatee or whatever) installer ran out of video memory a third of the way down the screen.  The third was a slightly less ancient S3 Virge PCI card, which actually worked fine, but as long as I'm mucking about with Linux installations, I wanted to see how the desktop stuff is coming along, since I'll probably want to update my workstation eventually.

Note the lack of an optical drive.  The current server has a DVD burner that was used, once, to read the FreeBSD install CD.  Since that time, it's been drawing power and accumulating dust.  So, since modern-ish BIOSes support booting from external drives, I'm using a USB DVD drive as the boot device for installation.

First thing to install: shiny new Debian 6.0 ("Squeeze"), AMD64 flavor.  The installation process would, I think, have gone smoothly if I'd had the DVD drive's supplemental power cable plugged in.  (As it was, the installer would occasionally decide that the drive no longer existed - perhaps because it didn't - and ask for its DVD back.  As a result of this, I started with a rather minimal install, with no desktop stuff.)

Looking at the partition table Squeeze created automagically, the first partition is tiny and unused.  Hmmm... could it be that the installer recognized my Advanced Format drive and aligned the partitions appropriately, all by itself?  Good.

Now, usually the first additional package I install is kpackage, which I then use to select everything else.  No kpackage?  Argh.  Do some looking around: what's the alternative?  Oh, synaptic.  Doesn't that suck?  Try it anyway (over ssh from the workstation, so there's an X server available and also so I can do other stuff while packages are installing).  Hey, it's gotten good!  Must have taken lessons from the old kpackage.

Install lots of stuff, much having nothing whatsoever to do with the eventual server function (which will call for a fresh install, with manual partitioning).  This goes smoothly, once I figure out about getting enough power to the DVD drive.

Try to run kdm.  No soap; some complaint about (dang, I misplaced the error message) something that's supposed to be replaced by Desktop Base.  Install desktop-base and try again.  Same thing.  Eh?  OK, so try "/etc/init.d/kdm start" instead.  Success!

So, how goes the KDE4 suck race with Apple and Microsoft?  Actually... not so bad.  A little fiddling reveals that one can get back to something like the classic appearance, and right-clicking on the K-start button gets the option of returning to the old menu format.  A little "back to the good old days" configuration and a little getting used to the new stuff, and I'll probably come to like it.

On a reboot: it comes up fast.  I didn't time it, but the whole power-on to sign-in screen to KDE ready to use sequence seemed much faster than I'm used to... though a distressing amount of the time came after the KDE splash screen disappeared and before the taskbar was fully populated and the menu was ready to respond.

Oh, and X configuration?  Forget it.  As in, It Just Worked.  Came right up with the right server for the card, and the right resolution for the monitor.

On the server front, I notice Apache has sprouted a new(ish) MPM option: mpm-itk.  This brings back the ISP-friendly capability that Apache 1.3 used to have, of making each virtual host run under the owner's user ID.  I anticipate using this to handle, for example, multiple instances of a web-based bug-tracking system, keeping the one for AGROS entirely separate from client-related ones (and with no need to store database passwords at all, if I'm remembering PostgreSQL's authentication options correctly).

Anyway, there's a bit more tinkering to be done, and I need to stuff one more Ethernet card in the box before declaring the hardware complete and buttoning it up.  And, maybe, a second high-capacity hard drive for internal backups.  Then a huge external hard drive, and that trio of probably 1 TB portable drives, with one connected to collect data, one in reserve, and one in the safe-deposit box (which I just got yesterday, and haven't put anything in yet, but it is big enough for a portable hard drive plus the other stuff that really ought to be kept in an official Safe Place).

And then there's final server software configuration to be done before I make the switch.  My firewall rules will need translating from ipfw to iptables, my BIND configuration (and that pesky dynamic stuff) will need bringing over, and DHCP, Exim, and Apache configs will all need some massaging.

And I need to make sure the NFS and Samba exports are all set up so the rest of the machines will be happy....

Then there'll be Migration Day, with services shut down, data getting copied over (including all the data from Subversion, and PostgreSQL, and all those other things), and trying to get the new server on line.  That sounds like a first-Sunday-in-March sort of project.

Anyway: looks like I'll probably be sticking with Squeeze for the server, which is after all meant to be Stable for several years.  During playing-around time, though, I guess I'll install Manatee and see how that goes; I may end up using that on the workstation (and if I use it on the workstation, I'll probably put it on the laptops too).

 Oh, yes: a Linux annoyance resurfaces as I contemplate server / bastion host use.  It's like the eternal problem with USB.  How do you keep the network cards straight?  On FreeBSD, I used three different network cards with three different chips, and got interfaces called rl0, dc0, and vge0, named based on which driver was involved.  On Linux, they'll just be eth0, eth1, and eth2, regardless.  I suppose I could write my own init script that identified the interfaces by MAC address and initialized them and set up the firewall rules and DHCP configuration accordingly... or I can determine which is which by trial and error, label them, and hope no future update decides to number them differently.

Or I can test my Google-fu and see if someone's come up with a solution for ensuring that the interface names remain pegged to the correct hardware.  (Hm.  Looks like, if they use different drivers, I can use 'alias' in the module configuration to define which is which.  So, I just need to ensure that the third card doesn't use the same driver as either of the first two, and muck about with device aliases.)

Oh, here we go.  The solution I need... In the Futuuuure!

 Update: second huge internal hard drive it is.  I was thinking Seagate (on the theory that it and the WD primary drive probably won't fail at the same time).  Found a 2 TB Barracuda LP on sale.  Lotsa space!  Actually, I'm thinking it gets used for a combination of critical-data backups and general storage of big, non-critical files.

Still need a big USB drive, and that trio of slightly less big mini drives that'll fit in the safe-deposit box.  Seems to be a fair selection of both on offer.

I have no intention of trying to back this stuff up on old-school media, like 1600 BPI 9-track tape or 5 MB removable packs.

 

Microsoft. Phooey.

The folks over at the toaster factory are getting one of the new models ready for shipment.  This involves, inevitably, a flurry of feature requests for the controller firmware.

This model is nominally controlled using SCPI-over-TCP-over-Ethernet, but for test purposes it has a web interface that provides a handy GUI front end; sort of AJAX-ish, except that instead of XML it uses SCPI.

Anyway, the performance had been fine in my testing, using a Linux browser, ever since I fixed a bug in my TCP flow-control implementation.

With a Windows client, though... as the feature creep set in, the time to load the HTML page and the associated Javascript file got annoyingly long.  As in, multiple seconds.

So, once again, I did a Wireshark capture.  No protocol bobbles highlighted.  OK, so let's trace through the exchanges and see where the time is.

Um.

See, what with this program running on a fiddly little microcontroller, I was using a 128-byte transmit buffer on the socket.  Since that's much smaller than anyone's receive window, the result is that I'll send a packet with 128 bytes of data, then wait for the ACK before sending the next packet.  The TCP sliding-window thing doesn't help here, since I can't free up buffer space until the ACK comes in, just in case I need to re-send.

Well, Windows, running on its 2.08 GHz Athlon with 624M of RAM, is taking a hair under 200 freaking milliseconds to ACK my data packet.

So, when I'm sending a 5206-byte .js file, 128 bytes at a time, that's 41 packets, so I spend around 8 seconds waiting for Windows ACKs to come back.

Meanwhile, my not-terribly-efficient server, running on a 0.072 GHz ARM7 with 0.064M of RAM, turns the next data packet around in about 2 ms.

Anyway, I changed the transmit buffer size to 1024 (since I'm not really running short of memory), and performance picked right up.  Heck, I've still got about 24K of unused RAM; I could splurge on an even bigger buffer!

 

Maybe it is time for a new server

The idea of a new server has been floating around my head for a couple of years now, what with the software configuration on this one having gotten brittle, and replacement SATA150 hard drives having gotten scarce.

The need for a software update was driven home this morning when I found a Perl script (shellbot, as it turns out) eating the CPU.  Seems it had arrived via Exim (in the past, others have been infected via Apache) and was running as user "mailrun" and claiming to be "/usr/sbin/httpd (perl5.8.9)".

Updating Exim, or anything else, is a scary prospect, as I have a lot of software installed via the FreeBSD ports system, generally with custom settings, and some that's hand-installed, and any major update carries the prospect of a day in dependency hell trying to fix things that have gotten broken.

The current server has been running more or less continuously since June 2005, which is rather a long time for cheap hardware... and back in those days, a 160G hard drive was pretty darn big.  It does seem like time for one with a couple of terabytes of storage (or maybe a mirrored terabyte).

So, mayhap it's time to put together new hardware, with SATA300 drives and a fresh software install.  Possibly even move to the latest Debian, for easier software maintenance (which now means the opportunity to choose between a Linux kernel and a FreeBSD kernel).  The main annoyance would be translating my arcane firewall rules to whatever the new system uses.  (Well, that and coming up with a trio of Ethernet interfaces with consistent, distinct names.)

Oh, and an Intel processor this time.  AMD gives way better performance per CPU dollar, but Intel is better at performance per Watt, and for a machine that's left running continuously for years on end, and isn't meant to be a room heater, saving power is a bit of an issue... and even an Atom processor would have plenty of horsepower for my server needs.

 Update: Turns out AMD has a line of "energy efficient" Athlon II parts... 3 cores, 45W, about $100?  Interesting!  I'll probably, however, go with the nearly-complete set of spare parts I have lying around for a Core 2 Duo system (needing only a full-size case with good ventilation and a high-rel hard drive).  Less energy efficient in the long run, but less cash out of pocket right away.

A further factor driving new-server interest: it's past time for a bug-tracking system.  Must play nice with Subversion.  Open source strongly preferred.  Installing either Trac or MantisBT on the old server via the ports system turns out to be somewhere between impossible and impossible, so that leaves manual installation, which adds to the brittleness....

 

Wait, is there some spectator-sport thingy today?

Sasha Volokh doesn't keep track either.

I'm vaguely aware of when Superbowl Sunday comes around, as it's a reference point for a hike I've been known to lead: south from Gazos Creek, tripping over beach potatoes elephant seals all the way.  Never spotted any owls, Superb or otherwise, though.

Two reasons for doing that hike on this day: it's elephant-seal season, and the spectator-sports fans are all parked in front of their teevee sets.

...And I'm not out at Gazos Creek today.  Maybe in a couple of weeks, depending on schedule and weather.

Not watching the TV either, though.  I never watch that feetball stuff unless Wossamotta U is playing.  Or Trans Poly U.  I'd watch one of their games.

(And now, back to computer repair and other household chores.  Then there's a bunch of work that needs doing so's a new toaster can ship next week; the technicians came up with a bunch of last-minute tweaks and feature requests.)

 

Extinct tools

Slashdot links to an NPR story questioning (but failing to refute) the assertion that "...there is no species of technology that have ever gone globally extinct on this planet."

Naturally, people hearing this try to think of tools that have gone extinct... but, of course, the ones you think of are the ones that have been in use recently, and are probably still in use somewhere, in some form.

The ones that are likely to be extinct are going to be unfamiliar.

I suggest that no one's used an Antikythera in quite a while, though there may be a revival in the works now that the bits of one have been deciphered.

And what about some of the more specialized tools used by ancient Egyptian embalmers?  There's not much call for embalming Pharaohs in the traditional manner nowadays, so the tools may well be properly obsolete.

But, then, the term "species of technology" is broad enough that the assertion is almost certainly true; while, e.g., triremes have gone out of fashion, the species "rowboat" is alive and well.