Devlabel 0.38.07 is available here.

* Added an ugly hack for weird hotpluggable hardware. Specifically, things like the "Pen Drive USB Flash Hard Drive" require an initial ioctl ping before Linux can do anything with them. Because of this, when the hotplug script called `devlabel restart`, devlabel was unable to yet see the device and would not create its symlink. Now, devlabel detects if it has been called by a hotplug agent, and if so, it issues a `devlabel status >/dev/null` right off the bat to act as this initial ping. Then, when the rest of the scripts get around to creating symlinks, everything works fine since the ping has occurred.

* Stopped using the readlink command since I didn't want a dependancy on tetex. Instead I wrote my own simple function which accomplishes the same thing.

DKMS 0.30.17 is available here.

* Added SuSE/United Linux kernel preparation support (Many Thanks to Fred Treasure - fwtreas () us ! ibm ! com). I have only tested this on SLES 8, but from what it looks like, this should prepare your UnitedLinux kernel for building a module regardless of which kernel you are currently running. SuSE has a different mkinitrd command so if it detects this, and REMAKE_INITRD is set in your dkms.conf, it tells you to manually fix your initrd. For Red Hat, it does all the mkinitrd work for you. If you have feedback on how to best accomplish this for SuSE/UL, please let me know.

* Added the --directive option. This allows you to specify dkms.conf directives on the command line. You can use the --directive option multiple times on the same command line to specify multiple additional cli directives. Also, if you plan to use to specify the make command during a build, you must use the MAKE= directive and not the MAKE_<kernel-regexp> directives.

* Added an internal readlink subroutine for determining the location of symlinks. I did not want to add a dependency on tetex so this seemed the better approach.

* Added a mkdir -p $LOCATION during dkms installs so that your built modules will get placed in the $LOCATION directory regardless if it existed beforehand or not.

Devlabel 0.38.05 is available here.

* Added the "reverseremap" action. This action is actually quite dangerous and should only be used when you know what you are doing. It wipes out the UUID values (column 3) from /etc/sysconfig/devlabel and using the last known device name (column 2), determines the UUID for that device and from then on devlabel will use that UUID to ensure consistent access. If a device renaming event has occurred on your system, using ReverseRemap will cause devlabel to ignore it and then think no renaming event ever happened.

This feature is especially useful for upgrading between devlabel versions where the UUID format has changed. Specifically, older versions of devlabel did not use the start sector of the partition as part of the UUID. If that older config file is then used on a newer devlabel, it will get confused. Using ReverseRemap is an easy way to get devlabel to repoll for the UUIDs based on the device names already in the config file.

You must specify --force in order for it to work. Without the --force, it prints a rather verbose warning explaining what ReverseRemap actually does. Thanks to Robert Hentosh for the idea (robert_hentosh@dell.com).

Jeremy Zawodny declares "PageRank is Dead". For the unititiated, PageRank is Google's method for determining website relavence. Jeremy writes that the days of PageRank are numbered because bloggers, among others, have learned how to game the system.

Though, I think Jeremy's got it wrong. Just because PageRank has been around a couple years and just because Google does not produce consistent results does not mean it is teatering on irrelavence. It simply means that it needs some tweaking, and I have a good feeling this is exactly what Google is currently working on. There has been a lot of chatter lately about blogging and its effects on Google, and its only natural that Google must and will adapt. Certainly there is more to Google than just the PageRank formula. I'm sure there are many different parameters and its just time to add and fiddle with them.

Jeremy and I agree that Google has a hard problem to solve, but in my estimation its just a small subset of the PageRank paradigm. I don't think it calls for something as new and revolutionary as PageRank was. Further, I just see the general sense of the blog entry as "Orlowskian"-- making a grand internet-related claim to generate traffic. And based on the responses he received, it seems most are merely preoccupied with their own modding down of their own name in Google's results. Thus, what's in a name? If PageRank gets a tweaking, is it not still to be called PageRank?

One responder to his blog definitely got it right. A google search for search engine doesn't even return Google first. Obviously, that just tells you its a work in progress.

Why are there always cops in Chipotle? Has anyone else ever noticed this?

DKMS 0.29.09 is available here.

* During a remove, not specifying the kernel-version now results in an error. If you want to remove a module for all kernels, you must now use the new --all option (eg. dkms remove -m module -v version --all).

* Added the file /etc/dkms_framework.conf which gets sourced in every time dkms runs. This allows you to specify alternate locations for $source_tree and $dkms_tree within this configuration file and allow dkms to use them.

* When looking for original modules to archive during an install, DKMS now uses the find command to search the /lib/modules/$kernel tree in the event that its not located in LOCATION. If multiple modules with the same name are located within the tree, it archives the one found in LOCATION. If multiple modules with the same name are located within the tree and none are in LOCATION, it archives nothing. If only one module is found with that name within the tree, it archives that one. Note that after uninstall, when it puts the module back into the /lib tree, regardless of where it came from initially, it will get put back into LOCATION.

* After builds complete, the kernel tree is now cleaned with a make mrproper. While doing a match, this cleaning only occurs after the last module is built.

* If an existing .config file is found in your source tree, DKMS now save it into memory and rewrites it after it does its thing.

* Added grep, cpio and gzip to the RPM Requires clause as they are needed.

I just saw the link to this NYTimes story from Slashdot. It's an interesting look towards the implications of commercially available pictures of the U.S. and the implications to the proliferation of its uses.

I just got back in from Cincinnati for the weekend. As with all airtrips, this is where I read books. Mostly, this is about the only time I ever sit down and read from paper. The choice of this trip was Skunk Works, by Ben Rich, father of the stealth bomber.

The book basically recounts the history of Lockheed Martin's skunk works devision (the people that invented the term skunk works) and Ben Rich's time there from work on the U2 spy plan, the SR71 black bird and then on to his tenure running the Skunk Works and developing stealth technology. Its a really great read and is really a recounting of the cold war through the technological development side-- one of its best features being the recounting of the same event through different "other voices" which include pilots, generals, CIA gmen, etc. In fact, some of the stuff would seem like it should still be classified.

I'm not done reading it yet, but just got through an interesting section on the black-bird and how the airplane was shelved prematurely (to put sole reliance on the use of spy satellites) by then secreatary of defense Dick Cheney. It even recounts how after it was decomissioned early and some situation occurred which called for its use, Cheney again refused as he felt that once it got operational again, there would be no way to decommision again. Rich doesn't really elaborate, but it does make you wonder why such a useful plane met such an early demise. I could throw in a consipiracy theory about control of information (spying controlled by the NSA as opposed to the air force), but really that all is groundless. I guess I just don't like the guy.

A very good read though. Tom Clancy says "Dynamite--The true story of America's crown jewels." I wonder if Clancy really said that, or if it was the novelist he hires to write books under his own name.

Influential South Korean Website Uses "Citizen Reporters" to cover news. It sounds like blogging taken a couple steps further. This whole internet thing, I think its gonna be big.

I just got my copy of June 2003's Linux Journal in the mail. On page 10, in the "diff -u: What's New in Kernel Development" section (by Zach Brown):

Dynamic kernel module support (DKMS) has come from a developer group at
Dell. A GPLed project, it aims to allow device driver source code to
reside anywhere on the filesystem, not only in the kernel source tree.
This makes it easier for vendors to release new versions of their
drivers and for users to recompile those drivers. As of March 2003,
DKMS is 2.4-specific, and it doesn't take account of some of the massive
reworkings appearing in 2.5, especially with the module code itself.

I'm not sure about the 2.5 comments as there were some threads about the module name it expects back in March, but DKMS should be ready to go regardless of kernel. But, who cares, its some good press.

DKMS 0.28.04 is available here.

* Fixed mktarball and ldtarball so that you are not forced to load your tar archive into /usr/src and /var/dkms. Instead, DKMS honors the variables $dkms_tree and $source_tree and should load everything where you now specify (thanks to Jordan Hargrave, jordan_hargrave at dell dot com).

* Added the mailing list info to the man page: dkms-devel@lists.us.dell.com

DKMS now has its own mailing list. If you'd like to discuss any issue regarding Dynamic Kernel Module Support, its features, its shortcomings, etc., go to Dell's mailing list webpage and join the DKMS-devel mailing list.

And while you're at it, you should also check out Dell's Linux-Poweredge list.

This article at NYTimes discusses some of the anti-piracy measures currently being explored by the recording industry. While nothing has formally been enacted due to concerns of legality, some of the proposed measures they are looking into include "freeze"-- a program designed to freeze your computer for some specified amount of time, and "silence"-- a program which roots out and deletes all illegal music on your system.

While reading the article, I couldn't help but draw some parallels to our war in Iraq and the war over piracy. With Iraq, you had a vicious regime lording over its people through fear and intimidation. Obviously, with the recording industry you have the same situation between the recording companies and the artists. Likewise, the recording artists are probably as skittish to losing all their rights and control over the music through music swapping as the Iraqi citizenry are to welcoming the American army to come in and "rebuild" their country.

This leaves the rather dubious parallel between the the similarities of the U.S. army and the peer to peer music swapping applications. However, this parallel is regime change. The technological prowess of U.S. forces is the equivalent to the unstoppable nature of peer to peer file sharing. If history does repeat itself, then the music industry should be very worried. P2P is destroying the recording industries ability to profit from the artists they control and at the same time the internet is the oil which might give the artists the resources they need to determine their own fate.

I guess ironically in both cases the American people are just the consumers-- consumers of oil and consumers of music. Rights? Tyranny? What's that all about? Fatten us up, lower our gas prices and drop the price of CDs and we'll be happy.

The Ottawa Linux Symposium has accepted my abstract for a Birds of Feather session on Dynamic Kernel Module Support (DKMS). The session will be led by Matt Domsch who is our lead Linux engineer. Here is the abstract. Unfortunately, I won't be there, but I should be in San Francisco a couple weeks later to do something similar for LinuxWorld.