While we’re on an OpenWRT kick, let me mention that Amazon has the guaranteed flashable WRT-54GL for less than $50 again. I won’t even provide a non-referral link, so as not to raise eyebrows at wordpress.[non-]com[mercial]. I’m sure you could find it.

Possibly the best reason someone who’s not interested in getting to know their network or doing fun things with it is the possibility to use just one OpenWRT/DD-WRT/Tomato device (along with any standard wireless router) to extend internet connectivity to another part of the house without running wires or using shaky (and unencrypted) Power-Over-Ethernet.

On my list of future projects to waste my money on, though, is a set of cheap 802.11n devices, replacing the “G” bridges I’ve had for the last few years. Apparently, that day is near or already here. Of course “N” speeds only matter if you’re concerned with moving data between machines in the home. For a normal residence, any available residential networking technology is faster (in most cases orders of magnitude faster) than even the best of the universally crappy available residential internet connections, and so the bottleneck will always be at the WAN side (especially for upload.) Of course these days, most small businesses are actually paying more for even crappier Internet service. But I digress…

On a last OpenWRT note, if I had known about this contest in time, I definitely would have put together a team and devoted a few months. Maybe it really does pay to read Slashdot.

OpenWRT Kamikaze 8.09 processes /etc/config/dhcp and appends the settings specified there as command line options when running dnsmasq. To properly configure dnsmasq to point to your LTSP server you will both need to specify options in this file, and modify the dnsmasq init script for these new settings. (Note that you can also—right now—add an /etc/dnsmasq.conf with these options in standard syntax. But that’s not the way OpenWRT is heading, and there’s inconsistency across the various packages as to the use and naming of non-uci config files.)

The following worked for me with Debian Lenny running LTSP 5.1.10 installed fromt the repositories, other distros may require different paths:

In /etc/config/dhcp, add in the “config dnsmasq” section:

option dhcp_boot ltsp/i386/pxelinux.0,$LTSP_SERVER_HOSTNAME,$LTSP_SERVER_IP
option dhcp_option 17,'$LTSP_SERVER_IP:/opt/ltsp/i386/'

The first path is relative to /var/lib/tftpboot, the second is the ltsp chroot directory which should be in /etc/exports. The second option is equivalent to the root-path option offered by dhcpd (AFAIU) and solves the “need path” error. Apparently this is not necessary when the DHCP and LTSP servers are the same.

Etherboot clients may require different path information. And if you have a mixed set of clients, you can use the dhcp-vendorclass syntax demonstrated here (the paths in the dnsmasq section of this document are out of date, though they have been fixed in the rest of the page.)

In /etc/init.d/dnsmasq add in the “dnsmasq()” function:

append_parm "$cfg" "dhcp_boot" "--dhcp-boot"
append_parm "$cfg" "dhcp_option" "--dhcp-option"

Run:
# /etc/init.d/dnsmasq restart

Then boot one of your thin clients, hopefully to an LDM login screen.

(Credit where credit is due: This post on general PXE booting with Kamikaze got me halfway to getting this to work.)

Captioned Lists

May 22, 2009

I love this structure:

<dl> <dt>Animals</dt> <dd>
<ul>
<li>Cat</li>
<li>Dog</li>
<li>Horse</li>
<li>Cow</li>
</ul>
</dd> </dl>

– Kevin Marks on [whatwg] List captions

It seems more correct than the alternative he proposes (with each of the li’s here as dd’s) in that the list is an ostensive definition, whereas each of the items is a mere example. Practically, it saves me from having to deal with some lousy CSS on nested lists. And it does feel more semantic-ish than the nested list (for this case) anyway, and certainly better than the usual headings or paragraphs inside lists.

(Jump to the fix if you want to skip the introduction.)

Google Sites is the evolution of JotSpot. It allows individuals, teams, or organizations to create simple, revision-tracked web sites. Probably its strongest points are ease of setup and ease of embedding other objects, including Google documents, videos, slideshows, calendars, and any of the “gadgets” available to iGoogle home pages. The most obvious downside is frustratingly limited customizability, as is to be expected from a free hosted solution.

Another problem is that saves can be less than perfect. Configuring and adding gadgets can be particularly frustrating, as you may find yourself starting over several times. Read the rest of this entry »

Matthew Bass has written a nice introduction to the [dead simple] Google Charts API and to gchatrb, a Ruby interface to the API developed by Deepak Jois. (The article links to an older Google code repository. The latest version is at the github link provided here.)

Constructing the URLs for Google Charts is pretty simple, and gchartrb and its Python counterpart are almost as verbose, but it’s obviously easier to integrate the wrappers into a program’s flow.

I like Bass’ idea of using a Capistrano task to update the image, rather than rendering it from Google every time. He is a little harsh, though, on “the medieval monster which is ImageMagick.” I like ImageMagick. I’m awful with anything related to design, images, and the visual arts; but I often find myself lost in the (wrongly placed) ImageMagick docs trying out all sorts of esoteric combinations to do some stupid trick or the other. It may be one of the worst tools to have to get work out of, but in the end it does a pretty nifty (and usually not-quite-what-was-expected) job. If ImageMagick is a medieval monster, it’s Herbert the Timid Dragon:

Herbert the Timid Dragon

A few ongoing issues are building up my frustration level today. Note that these are not all strictly about usability, but if I allowed myself to title all posts “Frustration,” this blog would be worse than K-Menu (see #4): Read the rest of this entry »

Jeff Atwood this week offered the world an article on the fact that “PHP sucks [but it doesn’t matter.]” For a man who’s usually quite thoughtful, the critique presented in the article made it look like he’s been stuck on the LOST island with cached Slashdot discussions for a few years and he hit his head really hard and lost the ability to tell whether he’s actually saying anything of value or not. The substance of the apologia on the other hand – that in spite of sucking, PHP powers the web’s biggest and busiest – was put forth much more ably by Terry Chay in his thesis on the science fiction mythology behind the enterprise of the Enterprise.

However, I think Atwood has been redeemed by the fact that his piece provoked the following gem from Stanislav Malyshev: “I wish for every 50 ‘PHP sucks’ blogs people would write one good RFC.”
Read the rest of this entry »