GPT for FreeBSD!

A lot has changed since the PC was first introduced in the early 1980s. Unfortunately, a lot of legacy nonsense has remained behind that has to be hacked-around because of that history. In essence, a modern Intel based computer starts the boot process as an 8088 and, effectively, climbs up out of the primordial ooze stepwise, getting a little more advanced with each tweak.

One of those bits of legacy nonsense still with us is the old FDISK based partitioning scheme, which still has nonsense like cylinders, heads and sectors in it (which mean nothing at all to modern disks, which in essence are just single-dimensioned arrays of 512 byte blocks).

FreeBSD has existed within this framework by using the old BSD "slice" system to chop up a single FDISK partition. Linux, instead, has tended to use FDISK extended partitioning, but that has led, to some extent, to Linux systems living in a single filesystem. One of the benefits of the multi-partitioning that FreeBSD uses instead are that two of the typical partitions (/ and /usr) tend to be "read-mostly," while the other two (/var and /home) tend to have the majority of write activity. This is somewhat safer, since the volatility is kept away from important configuration data (in /etc) and system code (in /boot and /usr).

Macs have discarded a lot of the Intel legacy, since they don't have to boot 20 year old operating systems (instead, they boot Unix, which is a 30 year old operating system, but I digress). So the Intel macs have adopted GPT partitioning. GPT is great, since it can operate on disks with 2^64 blocks, which is ridiculously huge, and the number of partitions is unlimited (it's actually limited to the number of blocks allocated to the GPT itself, and by default it's 128 entries).

Well, with the advent of FreeBSD 7.1, support has been added to boot from a GPT partitioned disk. The way this works is that the legacy FDISK partition (which basically marks the entire disk as allocated to protect against FDISK based tools trying to do something to the disk) contains boot code that looks for a special GPT partition that contains the second stage boot loader. That partition and the FDISK boot sector is written with the 'gpt boot' command. That boot loader looks for the first UFS partition on the disk and loads the main FORTH-based loader, which in turn loads the kernel and so on.

Just to be on the safe side, I migrated my setup by buying a new disk (a 320GB disk for $55 - can't go wrong!), partitioning it and then copying all the stuff over. As a bonus, the new disk is faster than the old one, and we get to start the warranty over.

There is, however, a 'gpt migrate' command that purports to convert a disk from FDISK and BSD slice format to GPT, but that concept sounds a bit scary to me, at least for filesystems I really care about. :)

One interesting thing is that the gpt command opens the disk for writing, even if all you want to do is read information. But if there are mounted partitions, then this will fail. There is a -r option that will make the open read-only, which is useful for the 'show' command.

Now that the disk is GPT partitioned, converting to an EFI based machine would simply require replacing the special FreeBSD boot partition with an EFI system partition (it would need to be slightly larger, but space from the adjacent swap partition could be stolen), and EFI boot code for FreeBSD would need to be added to it (if it existed).

FreeBSD 7.1 hasn't yet has been released - it's at RC2 at the moment - but - on new year's day, in fact. I'm quite happy with it.

iPhone dartboard navigation

When I was waiting to turn left from San Tomas Expressway onto Saratoga Ave, I happened to glance down at my phone to see it tell me this:



Come on! That's not even the same zip code! Hell, it's not even the same city! It's the city two cities away! Oops.

Google hosed me

I took my car in for service last night, with the plan being to take CalTrain from work, as usual, but get off at the station close to the dealership and walk to go pick it up.

I settled on this plan because when I asked the iPhone's Google Maps app to give me directions from "Sunnyvale Caltrain" to Sunnyvale VW, it said that the route was about a mile.

Well, it appears that it decided that "Sunnyvale Caltrain" meant any CalTrain station in Sunnyvale... of which there are two. It's about 1 mile from the Lawrence station to Sunnyvale VW, but it's about 3 miles from the Sunnyvale CalTrain station. If it had said that it was a 3 mile walk and showed me a mostly southerly route, I probably would have known to try Lawrence instead.

So, thanks, Google. You clearly knew best when you thought I didn't mean the Sunnyvale CalTrain station when that's exactly what I typed in.

JBoss and custom LoginModules for data sources

This is rather a specialized topic, but precious little has been said about it, so I figure it's worth a mention.

A data source in JBoss is typically either a JMS or JDBC connection pool, more or less. It represents a resource within JBoss that you can turn to to obtain the thing you want, use it, then throw it away (typically the connections are wrapped with code that catches the "close()" call and rather than closing the connection returns it to the available pool).

If the resource represents a database or remote JMS server, you're going to need to authenticate - typically by providing a username and password. In most enterprise situations, you don't want those passwords to be in plaintext in the configuration files. Rather, you have either some sort of configurable password encryption system or a password fetching system. In every shop I've worked in so far where this has been an issue, there's been a pre-existing mechanism that is set in concrete and must be used more or less without modification to obtain passwords to connect to enterprise resources.

Well, if you're configuring a data source within JBoss, you give that data source an <application-and-security-domain>, which is a <application-policy> node within server/___/conf/login-config.xml, which contains a <authentication> section which provides the username and password. The question is, how can you provide the bridge between JBoss and your established mechanism for providing username and password? Naively, the answer is that you must write your own custom JAAS login module.

Fortunately, there is a much easier way.

JBoss provides a ConfiguredIdentityLoginModule, which is simply a wrapper for a plaintext username and password. The simplest way to wire in your own password fetching code is to extend this module. You simply need to replace this method in the class:

public void initialize(Subject subject, CallbackHandler handler, Map sharedState, Map options)

The "options" map is a map of the list of module-options from login-config.xml. You simply call super.initialize() with all of the same arguments, but with a different options map. The new options map will have in it the "username" and plaintext "password" options that are required by the ConfiguredIdentityLoginModule.

For example, if you have a CryptoWidget that can decrypt passwords, you'd write something like this:


public void initialize(Subject subject, CallbackHandler handler, Map sharedState, Map options) {
Map newOptions = new HashMap(options);
String pw = (String) newOptions.get("password");
pw = CryptoWidget.decrypt(pw);
newOptions.put("password", pw);
newOptions = Collections.unmodifiableMap(newOptions);
super.initialize(subject, handler, sharedState, options);
}


And that, more or less, is the entire class. You can do anything you need to modify the options map, so long as the options map you pass in to super.initialize() is what the superclass expects to get. It might be a good idea to remove any options that you require that the superclass does not require. For instance, if a "salt" option was required to pass some additional argument into the CryptoWidget, you'd fetch it, then remove it from newOptions.

Incidentally, it is necessary to make a copy of the options map because it is an unmodifiable map (note that we make newOptions unmodifiable before calling super.initialize() also).

Next ATSC test: 1/10, 33 cm

Well, despite the complete lack of success at 420 MHz, I'll be trying again on January 10th with the new 900 MHz amp. I'll be putting out around 75 watts or so of ATSC on 910-916 MHz into a KP-20, for a total of about 380 watts of ERP. I liked the Cañada college QTH when I was there last, so that's where I'll be this time.

Of course, in the meantime, I'll need to get ahold of a 28 VDC power supply and a small generator to run it.

Building a VHF TV dipole

After 2/17 of next year, there will be only two broadcasters below channel 14 here in the San Francisco market: KGO on channel 7 and KNTV on channel 11.

You could make do with a UHF corner Yagi... but what about those two channels?

Well, the ChannelMaster CM2016 is a good solution. It's a traditional UHF corner Yagi antenna combined with a VHF-hi dipole. But if you already have a UHF corner Yagi, there's no need to replace it. You can simply add your own VHF-hi dipole. Even better, you could make a relatively high quality folded dipole from copper plumbing pipe.

After February, the two channels that matter will be 7 and 12. 7 has a bottom of 174 MHz, 12's top is at 210 MHz. Halfway between those two is 192 MHz. A half wavelength at 192 MHz is 2.43 feet, or 29 1/4 inches, but we're going to put some fittings on each end, so subtract two inches, for 27 1/4". You'll need two pieces of 1/2" copper pipe that long, 2 90 degree 1/2" "street" elbows and two 90 degree 1/2" normal elbows. "Street" elbows are designed so that one side is the same diameter as the pipe itself, so that it can mate with one of the ordinary elbows to make a 180 degree turn.

Cut a half inch off one of the long pieces of copper and then cut that piece in half. Assemble the two ends out of one of each type of elbow. Put one of the combo elbows on each end of the long piece, and then stick a short piece in each remaining open elbow connection. The two short pieces should have a half inch gap between them. Once it is all dry-fit properly, use a plumber's torch and sweat the whole thing together. Use sheet metal screws to attach a standard TV balun on each side of the gap.

The only trick remaining is to mount the thing. You want the dipole to be at a right angles to the direction from your location to Mt. San Bruno and Sutro Tower. You need to use a piece of wood or plastic or something insulating to attach it to your mast. You also need to keep it at least a couple feet away from any other antenna on your mast, if you can.

Joel McHale at the Flint Center

Joel McHale has a message for all his fans:



Actually, no, Joel was very nice. As he was finishing his act, he told the entire assembled multitude (a sell-out crowd at the Flint Center) that he'd sign stuff for everyone afterwards, which I believe came as a shock to the house staff, since there were no preparations whatsoever for the resulting huge mob that gathered in the lobby around the merch booth. I waited an hour and a half to walk 5 feet.

If you go to the mall to visit Santa, the line is very orderly, but you don't get to have lots of chicks mashing their tits into your elbow.

Naturally, the ATM machine was broke, so I asked Joel if he'd let me slide on the T-shirt price by $5 (they were $25, but I only had $20). He signed my ticket, and let me take the picture you see above. When we got out, I told Scarlet the story and she said she had $5, but only had $4. We gave his bodyguard the $4 and had him pass it up to Joel and we left before he counted it. I'm sure that he made a snarky comment about it.

I'm actually going to put a dollar in the mail and send it to him (at E!). Just so he knows I'm not really cheap.

If you're a fan of The Soup (and don't you dare call it Talk Soup), you really should try and catch him if he comes near your town. It's great.