refusal computing

I have to say that I fully endorse showing passwords in the clear as a user interface rule. This is a big break with traditional masking passwords of with dots or asterisks or without echoing anything, so it is obviously quite controversial for folks. However, clear passwords avoid usability problems with typing passwords. It requires people to actually make sure their neighbors are looking the other way when they are logging in or authenticating. It also could make long complex passwords -- passphrases -- more likely for people to use. Nobody should be looking in the direction of a keyboard while typing a password, clear passwords would require this as etiquette and induce a social norm.

The other day, security expert bruce_schneier wrote a follow-up article to his own on The Pros and Cons of Password Masking. He was back pedaling from his previous post The Problem with Password Masking that criticized masking of passwords. He was concurring with same opinion put forth on alertbox by Jakob Nielsen.

In the outrage that followed, there seemed to be a suggestion that this is bad, especially in the case where people are using a projector while logging in to a system. This is a weak argument. There are off-buttons for projectors others even have "black screen" buttons, so simply use them. False trust in password maskers can result in people typing their password in the clear during a presentation when the presenter was confused where their cursor's focus was. I've seen this happen.

This simple bit of PHP made some changes to a MediaWiki installation for me recently. Don't use it. My point here is in showing the satisfaction from changing a database with code that generates the SQL statements for you. The golden rule for database applications is to make sure there's an interface or programming layer to the actual database to preserve data integrity and keep changes limited in scope. One should use some of the scripts that come with MediaWiki--batchMove.php or namespaceDupes.php for example--to do this. Such scripts are better trusted, but also handle the schema should it change in a later release of the software.

Now that the disclaimer is out of the way, I was pleasantly surprised how consistent the schema for MediaWiki was for allowing me to rely on simple data structures and some for-loops to update 9 tables. Clearly, the schema isn't entirely normalized, but I predict there is a rationale for having some of the data denormalized. Given this scenario, it is a real compliment to a software package and its schema if one can write very concise code to generate a series of SQL statements for a task.

<?php
// Move 3 pages, and start 2 namespaces.  Don't use this code!

$table = array('page' => 'mw_page',
	       'rc' => 'mw_recentchanges',
	       'pl' => 'mw_pagelinks',
	       'pt' => 'mw_protected_titles',
	       'qc' => 'mw_querycache',
	       'qcc' => 'mw_querycachetwo',
	       'rd' => 'mw_redirect',
	       'tl' => 'mw_templatelinks',
	       'wl' => 'mw_watchlist');

$namespaces = array(100 => 'ThisWiki',
		    /* 101 => 'ThisWiki talk', */
		    110 => 'RPM',
		    /* 111 => 'RPM talk' */);

$rename = array('Changes_to_Wiki_database' => 'ThisWiki:Changes_to_database',
		'LocalSettings.php' => 'ThisWiki:LocalSettings.php',
		'Changes_to_Monobook_skin'
		  => 'ThisWiki:Changes_to_Monobook_skin');

foreach ($table as $short => $t) {
  // Move:
  foreach ($rename as $orig => $new) {
    foreach (array(0 => '', 1 => 'Talk') as $old_ns => $old_name) {
      printf("UPDATE %s\n"
	     . "SET %s_title = '%s'\n"
	     . "WHERE %s_title = '%s' AND %s_namespace = %d;\n",
	     $t, $short, $new, $short, $orig, $short, $old_ns);
    }
  }
  // Fix namespace:
  foreach ($namespaces as $num => $name) {
    foreach (array(0 => '', 1 => 'Talk') as $old_ns => $old_name) {
      printf("UPDATE %s\n"
	     . "SET %s_title = REPLACE(%s_title, '%s:', ''), "
	     . "%s_namespace = %d\n"
	     . "WHERE %s_title LIKE '%s:%%' AND %s_namespace = %d;\n",
	     $t, $short, $short, $name, $short, $num + $old_ns,
	     $short, $name, $short, $old_ns);
    }
  }
}
?>

It's dangerous to show this code, because someone may come to this page after a Web search and erroneously think this is the way to introduce namespaces in MediaWiki or something. I'll say it again: Don't use this!

Unfortunately, generating SQL statements by-hand is a dirty little secret of database maintenance. I've seen database maintenance done by evaluating SQL commands one-at-time more often than I'd like. Instead of being programmatic and more efficient, "easter egging" methods often introduce typos by either rousing "copy and paste" hell or a "search and replace" hell, and therefore risks typo errors and who knows what else. Writing database maintenance scripts programmaticaly enables you to work as a single transaction and study the results in each iteration. This quality forces one to use a test version of the data and avoid another database faux pas -- working on live databases.

There was a back and forth between Emacs bloggers Jared Dilettante and Ian Eure about whether Emacs users should write Emacs Lisp code for their own purposes or whether working in Emacs Lisp should primarily be in support of existing modes--and with the mode's documentation thoroughly read. At this point, the argument has fizzled out, but its worth pointing out that a manual for SQL mode doesn't seem to exist. SQL mode, like most Emacs modes, is self-documented well. However, this argument is evidence that it could probably use a manual.

As someone who's neither a trained writer nor a good one, I know that writing in one's own spoken language is difficult. However, writing concise documentation about Emacs can be just as important as writing Emacs Lisp code, if not maybe more so. Writing documentation will give you a deeper understanding of how something works and help you learn things you didn't already know. It's also important because the documentation you write will help someone else to learn how to use Emacs, too.

Documenting Emacs also improves your Emacs Lisp skills because you'll likely be reading other hacker's Emacs Lisp code. Most important of all you'll be working on existing code for Emacs rather than making more when it is not entirely necessary to reinvent the wheel.

Don't get me wrong. It's fine to twiddle code. Reinventing the wheel is the basis for higher education and university study and critical to life-long learning. However, writing code and championing your work as a solution only acts to avoid studying and maintaining existing code and risks distracting the Emacs community from progress. In a way, it's almost anti-social.

I know some Emacs hackers think multiple implementations are important, and "I wouldn't have learned as much if I didn't manage my own Emacs package". These arguments are spurious, though. One should be able to earn these same benefits--and more--by joining in on an existing project, rather than forking a new one. It may take more effort but its the right thing to do and is under my column of "best practices".

The GNU General Public License gives the Emacs hacker a lot of freedom, but we all could still use the occasional self-discipline.

Another subtle feature of Emacs that I hope doesn't go away any time soon is an easy way get to the Elisp manual. The key sequence is `C-h r TAB RET'.

Here's how it works. In Emacs 22, a new key binding appeared to access the Emacs manual, `C-h r'. Conveniently the first cross reference in the Emacs manual is "See Emacs Lisp(elisp)". Hitting `TAB' skips you to the first cross reference, then `RET' follows the cross reference.

Interesting discussion on how the REPL buffer of DrScheme is not like Emacs's. DrScheme is the GUI editor for PLT Scheme. PLT was how I learned Scheme in school a decade ago.

The argument pronounced by one of the academics who oversees the software's maintenance is essentially that having an inferior buffer to send and evaluate Scheme expressions is confusing for pedagogical reasons, and even to non-students. Years later, many of PLT followers and supporters want this feature. I recall seeing a PLT researcher who would argue that PLT was real-world, production-ready software.

My favorite is that the author starts it as a letter with the caustic greeting "Dear old Lisper". I've never seen the author speak but have heard of his self-sown reputation as an iconoclast.

One nice feature of Emacs, that is as old as Emacs itself, are buffers. Most Emacs users like them because you can have multiple buffers open at once and work on many things at once. And for the record, I'm actually a big fan of the Emacs buffer menu. It looks primitive compared to a tab bar or some such, but it gets things done. But the Emacs buffer list isn't the embarrassing way I use buffers.

I like buffers because they're inexpensive. "Cheap" as in they don't cost a lot to open. I often have arbitrary text with an ephemeral quality that I want to edit. I suppose the scratch buffer is the appropriate place to edit text with a short shelf-life. But I often run `C-x b b' to open a buffer called "b". If I need another I'll often type `C-x b b b' to open another named "bb". Obviously I name the buffers of varying lengths of "b" since "b" is also the last character that's part of the "switch to buffer" command. Since the buffer "b" doesn't exist for switching to, Emacs creates an empty one for you.

Opening a blank buffer opens in the blink of an eye -- faster than it takes to request it. It isn't associated with a file anywhere. Although, you can later, and you may want to if you the file grows to something worth saving. With a blank buffer, you can call an Emacs mode (or minor mode) that is appropriate for the text you're editing. Sometimes a mode like Mail mode or Shell mode are useful. More than likely I'm copying in text from another program to use Emacs's rectangle commands to transform text, or unconditional regular expression replacement or on occasion using keyboard macros.

Opening buffers with no file on disk associated means when you kill the buffer the data is gone -- unless its in the kill-ring. Emacs won't ask if you're sure and can be a bit dangerous, but as I said, use `C-x C-w' to save. This also has the added benefit of using Emacs's always reliable Auto-save feature.

Do folks have other small ways they use Emacs that definitely isn't described in the manual and doesn't necessarily seem correct, but helps them get things done and they wouldn't want to give up?

I'm in Utah on vacation, and happen to be using a friend's computer. It has Windows Vista Home edition. And it also has Intenet Explorer 7 (IE7). I've used IE7 once before when Windows Update snuck it by me. (I used to run Windows Update a lot as a computer tech in the public school system.) I vowed to avoid Internet Explorer 7 forever, but we meet again.

It's not too bad, except the tabbed browsing is extremely slow. I can take a sip of tea every time a new tab is opened.

I haven't done any thorough Web design work with IE 7, but I have spoken with people who work in those mines, and apparently Internet Explorer's following of Web standards is as weak as ever.

Suggesting free software alternatives has never been easier. Unfortunately, the Microsoft monopoly is probably worse than it was 10 years ago. I wonder what the Barack Obama Justice Department will do?

Making a QEMU image with kickstart would make it easier to build virtual Fedora systems. Consequently, this could help create a team of virtual RPM-building servers at my work.

Turn on, build everything, shut off.

The usual manner to build a package with the Redhat package manager (RPM) is running rpmbuild on the RPM spec file.

$ rpmbuild -bb package.spec

This presumes that all the source files for the RPM are already copied to the SOURCES directory accessible by RPM (%_topdir/SOURCES).

Its possible to build a source RPM (SRPM) from a spec file.

$ rpmbuild -bs package.spec

The benefit of an SRPM, is it contains all the source files necessary to rebuild the RPM.

$ rpmbuild --rebuild package-1.0-1.src.rpm

Using RPM to build an SRPM guarantees those files are included, and will put files in your SOURCES directory for you.

RPM has an additional feature where it can build an RPM from a tarball. Only a spec file needs to exist in the archive for it to work.

$ rpmbuild -tb package-1.0.tar.gz

This isn't a popular feature, nor is it very well documented. It is likely a relic of another time, when RPMs were not maintained by a distribution, but software maintainers would try and have their source packages install using RPM. This feature of RPM is made more and more obsolete with the success of large RPM-based distributions with a large and vibrant posse of packagers.

The rpmbuild in its tarball mode will find a spec file, even if its not in the top-directory of the package. For example, its not uncommon to put a spec file inside pkg/fedora.

The tarball mode of rpmbuild presumes you're in the SOURCES directory (More proof that RPM's tarball mode is probably a legacy feature). So copy the tarball to the SOURCES directory and run rpmbuild on it from there.

Most software packages simply need to be built from their source archive and don't need any additional files. However, it's not uncommon for packages to need to be specially configured by RPM on some systems by including particular files. On this chance, the included RPM spec file will name other source files or patch files besides the tarball (Source1, Source2, Patch0, Patch1 and so on). These files will need to be copied to the SOURCES directory as well. (Did I mention you need to run rpmbuild -tb in your SOURCES directory?)

I presumed there was some way to tell RPM where to find these SOURCE files in the tarball. For example, if you put these extra source files in the same place as the spec file, pkg/fedora then RPM would find them. Unfortunately, RPM's tarball mode doesn't know to copy anything to the SOURCES directory for you. However, it should be easy to modify the spec file to have it copy the source files in pkg/fedora to the SOURCES directory.

Adding the following tar command to the %prep section of the RPM spec file to copy the source files to the SOURCES directory.

tar -C %{name}-%{version}/pkg/fedora -cf - . | tar -C %{_sourcedir} -xf -

Alternatively, a single tar command on the actual tarball could extract the files into the SOURCES directory.

tar --strip=3 -C %{_sourcedir} -zxf %{SOURCE0} %{name}-%{version}/pkg/fedora/\*

The latter would only use a single execution of the tar command. The former may be more reliable should GNU tar not be available.

With that line inserted, a tar archive with such a SPEC file can bootstrap its own RPM.. The rpmbuild -ta will build both the binary and source RPMS.

Unfortunately, the rpmbuild -ts command will not work in this scenario, until the SOURCE files are present. You can copy the files yourself for it to work. Or run the the %prep stage of rpmbuild to get the task done.

$ rpmbuild -tp
$ rpmbuild -ts

And one other final word of warning, don't make changes to the tarball's source files in the SOURCES directory. Since the source files are extracted every time on each build, any changes to these files will be overwritten, unless you "short-circuit" the rpmbuild. Although short circuiting in RPM will not allow you to actually build the package.

Being able to build an RPM from the tarball source package is something for software maintainers to advertise to their users, but isn't a reliable way to develop RPM packages.

The way software bugs are reported is always changing.

In the beginning, I predict software bugs were reported in a notebook located near the switch panel of a mainframe computer. When software became distributed between sites, the bugs were probably reported on paper letterhead. (I was probably the last generation to be taught to touch-type a business memo in a secondary school keyboarding course. None of us would probably actually use the form for the rest of our lifetimes. I know I haven't done it to report a software bug.)

When electronic email appeared, many bugs would be reported using this more efficient technology. Emailing bug reports is how many bugs are still reported. They are often sent to a mailing list where a group of developers can receive and respond to each bug report.

In the late 1990s, bug databases would appear. Many of these would also sport fancy Web front-ends. Some software projects also use Web-based bulletin boards, or "forums".

Besides technology improving, the other dynamic is that more people are submitting bugs. It is a good thing to have more of the public able to report bugs -- or fix them in the case of free software. This has resulted in elaborate systems to manage them.

One of my favorite is the Debian bug tracking system. Like most bug databases, it's searchable, has an email gateway, and can quickly show you the status of a bug. It also sports a graphical version tracker. The little things it does are the big sellers. Every bug has an email address -- simply its bug number. Every bug has a short URL that makes it easy to find if you know the number -- and most people interacting with a bug system do know the number. This is the bug tracking software Emacs has begun to use.

The most historically consistent bug reporting method, are researchers in industry and academia who write journal articles. These articles analyze a piece of software for pages at a time and suggest an improvement. Obviously, computer-related journal articles are more often distributed electronically these days than paper. The authors may now formally submit bug a report to the software developers, but with a reference to their authored work. Regardless of submitting to electronic bug systems, the form, paper (electronic or otherwise), and quality have remained the same for this kind of thorough bug reporting

Most bug systems have good bug reports submitted. However, some systems do not inspire and instead receive terse or incomplete reports. To say the least, this is a subject of much controversy in some software communities. In a way, this is the consequence of bug reports being received from diverse segments of the general public. With the popularity of free software and the population of bug submitters increasing, the culture and expectations of bug reporting is relatively good.

A recently new idea is a kind of bug reporting for a document. Obviously, Wikipedia could be studied. A real radical idea was stet, a package used to receive comments on drafts for version 3 of the GPL, and for other FSF licenses under draft.

In 2008, as I make another release for PHP mode, I've discovered that a new method has been used to report bugs -- the Web log (blog) post. Some of these posts about bugs in PHP mode were directed to me by email or mentioned in PHP mode's official "bug tracker". Others, were posts that people just decided to write and I came across myself while browsing the Web.

Since blog posts avoid the method I'd like to receive bugs, I probably should ignore them. However, their quality is hard to ignore. I've found what's in a blog post is typically more inspired than anything in a bug reporting system. I predict this is because the nature of Web sites is for the author to feel confident writing long articles. With familiarity and confidence in your own blog, its worthwhile spending time adding material to your own Web site, than writing the bug report in some anonymous text box on a klunky Web application.

Is this increased quality from bug reporters wanting more recognition for their work? Traditional bug reports don't get enough glory -- they get filed away with the rest of the bug reports. Many blog posts often cite the error and offer a fix. There's no shame in bug reports where the person reports the problem lucidly, but doesn't propose the solution. The blog posts with bug reports I came across were more likely to have the fix.

Perhaps its the nature of the medium -- blogs -- that pre-select people who write good bug reports? I know anyone can easily have their own Web blog these days, but perhaps as a group bloggers are more likely to better research bugs in their software. Consider the authors of 5 page articles about deep problems in software. These people are called academics, so one *expects* they're well selected to do good work. Anybody can open a word processor and write 5 pages, too. The background as a computer science researcher is what predisposes good bug reports, not the medium.

So the other possibility is that this is just a new medium that is available to people, and how they prefer to communicate. There's no predisposition or quality about blogs or their bloggers, its just what people are familiar with.

However, blog posts can be a bit wordy and narrative format rather than just expository. Often this is to their benefit. The more information the better usually. Since bug reports are better when the user mentions what it is they were trying to do, and not just explain the problem in a theoretical vacuum.

The importance of a bug database is its motivation to act as an artifact for a software project. It builds a history and is a central store of information that influenced a software developer's work. A Web blog entry that is used to study a situation, may disappear from the Internet in 5 years or less, and any changes it inspired will seem arbitrary later. Obviously, blog posts won't scale well with large software projects, either, unless there was an easy way to syndicate and aggregate posts to a feed. Hmmm....

When you get stumped on how to handle a situation with your free software project, its always good to find advice. I found the Free Software Project Management HOWTO by Benjamin Mako Hill to be very useful. It has very sharp and leveled commentary, but it also does a good job of quoting other worthy sources on the topic.

It was updated as recently as August of 2008. However, the booklet covers topics that have lasting currency.

At my work, we use RPM to modify various system configuration files on Fedora GNU/Linux. We do a few tricks with RPM scripting in our RPM spec files to get this accomplished the way we'd like. Unfortunately, this results in a lot of SPEC files having the same block of 100 or more lines of shell script.

To our surprise, we've had to already fix a few bugs in the RPM script used across these files. The fixes can usually be propagated across the RPM spec files by applying a patch with the latest fix to the code. However, it was discovered you can create a macro file that contains the duplicated code and put it in /etc/rpm. My Fedora 9 system has the following macro files:

  $ ls -1 /etc/rpm/
  macros.dist
  macros.jpackage
  macros.pear
  macros.texlive
  platform

Fortunately, the macros are expanded and inserted in the spec file at compile-time (when the RPM is built), rather than run-time (when the RPM is installed or uninstalled). So we need to make sure that our custom RPMs files are on the build machine, but not any of the installed machines. If we find a bug, then the RPMs need to rebuilt and released as an update.

One could imagine it might be helpful to have the macro expanded at run-time, so you could fix bugs in the RPM scripts by just updating the macro file, and propagating the macro file through an update. However, this could have less than useful side-effects, ones that aren't confirmed by the original RPM-builder's intentions.

You know you have a poorly designed database when even the pluralization of table names is inconsistent.

In MySQL land, its not uncommon to create associations between two tables with an intermediate table rather than with foreign keys. So for example if you have a table called "person" and a table called "address", you'd associate them with a table called "person_address".

Where I'm sitting I'm seeing a table that is called "persons_address". Fortunately, table-name completion is available in some places, but its always a bit frustrating. Really, the database schema should have been reviewed -- by a different person, and perhaps with a style and guidelines document in mind.

Obviously, this is a pretty superfluous issue, but you can imagine that more critical components of database design are overlooked.

According to a few things I've read, the Windows operating system doesn't work well with SSDs -- even in newer versions, like Microsoft Vista. Hard drive companies have developed technologies like AHCI and NCQ to handle the fragmented nature of writes and reads by file systems that plagues a solid state drive (SSD).

The poor performance of SSD in Windows has resulted in companies not developing or producing as many SSD products had the computer market been using other operating systems. When tech companies can bring large quantities of a part to market, the price can be lower. When companies produce fewer, the price will stay high. You can't blame these companies for holding back. Nobody wants to sell a product -- an expensive one at that -- if they perform poorly in the dominant operating system. Unhappy customers could earn a technology enough of a bad reputation and backlash that could keep the technology from ever being adopted.

The result is that one large software company is slowing the development and adoption of a new product. Now, there are other technical issues beyond the price with SSD as a technology -- power consumption, storage capacity, server applications, and longevity. However, companies have the same reduced incentive to solve even these problem when the market is dominated by an SSD-unfriendly operating system.

One could blame the hardware manufacturers for not developing a controller card for SSDs that knows how to optimize its writes for Vista. However, Vista is a proprietary software operating system, with an undocumented file system -- if it was free software the source code could serve as documentation.

In university, we were taught that you should program software so that you could swap in and out underlying libraries and systems and replace them with different implementations. In other operating systems you can change the file system. The Linux kernel can use many different operating systems, and even the default works fine with flash memory. This is probably one of the many reasons why the Linux kernel is used in various systems using flash memory -- cell phones, GPS, routers, and bootable USB flash drives. There are even file systems that are optimized for flash.

Software is cheap to change, developing hardware that is Vista-specific is not only a silly expense to SSD makers and buyers, but a waste for the majority of people who don't use Vista.

Microsoft seems more and more like a lead weight around everyone's neck.

Sometimes there are files that are available from a Web server using Apache's auto index module (mod_autoindex), and you want to copy them to your machine. And you're satisfied retrieving them over HTTP this one time, rather than another file transfer method like SSH, FTP or rsync for that matter.

I usually feel confident retrieving things with GNU Wget things over HTTP, but its command-line arguments are hard to memorize. It took me a long time to put together, but the following will copy a directory on a Web server to your current directory.

  $ wget -r -N -nH -nd -np -R "index.html*" -P nyc-2008 \
         'http://localhost/~ashawley/photos/nyc-2008/

The command deletes all the file listings -- index.html* -- created by Apache's autoindex module. These files are used by Wget for retrieving your files recursively, but that's it. There should probably be an option for this in Wget.

The long option alternatives of Wget are easier to read, but don't help me much in remembering them.

  $ wget --recursive --timestamping --no-host-directories \
         --no-directories --no-parent --directory-prefix=nyc-2008 \
         http://localhost/~ashawley/photos/nyc-2008/

Now this post will help me remember them.

In an idealized microkernel environment -- like GNU/Hurd, you could have a translator that converts the HTTP protocol to a file system that can be accessed the same as the other files on your machine. For copying, you would just use the command you're used to using for copying files.

  $ cp -pr /http/localhost/~ashawley/photos/nyc-2008/ .

Or use your favorite more complex unix commands to get only the things you want.

  $ find /http/localhost/~ashawley/photos/nyc-2008/ \
         -type f -name '*.jpg' -size -1M -print0 \
      | cpio -0 -pd nyc-2008 

Someday I'll have my pie in the sky.

After making a few upgrades with Yum in Fedora, you learn to quickly uninstall packages that seem superfluous at the time. I mean, why download and upgrade the video player and its associated plug-ins and codecs if you don't really use it. Uninstalling is also a good survival tactic if Yum is having no success finding some dependencies or doing a poor of job getting the newer version of every package.

Today, I wanted to see the GNU Birthday wish from Stephen Fry. Of course, I don't have a video player since the last upgrade. And I don't remember what the package name is called.

I'm sure there are individuals with Fedora credentials or otherwise who can quickly tell you the name of popular free software multimedia packages. I don't follow free software distributions as closely as I used to, however. The user interface of Fedora doesn't help you here, either. The menu item for the movie player is called "Movie Player". Of course, that has its benefits for beginners, but is less than informative. Running yum install movie-player doesn't do anything. The group information of Yum does have what you need, though:

See if there is a group with the word "video" in it.

  $ yum grouplist | grep -i video
     Sound and Video

Yes. See what the default packages are for the group are.

  $ yum groupinfo "Sound and Video" \
      | sed -ne '/^ Default/,/^ Optional/p' \
      | sed -e '$d'
   Default Packages:
     alsa-plugins-pulseaudio
     bluez-utils-alsa
     cdparanoia
     codeina
     genisoimage
     gstreamer-plugins-good
     gstreamer-plugins-pulse
     icedax
     pavucontrol
     pulseaudio
     pulseaudio-utils
     rhythmbox
     sound-juicer
     sox
     totem
     totem-mozplugin
     totem-nautilus
     wodim

I guess totem is what I wanted.

In a previous post, I mentioned we are putting together an RPM build server at work. The RPMs that are built are signed by an encryption key and uploaded to the Yum server. The GnuPG (GPG) signing will give us confidence that the RPMs were from the build server and weren't tampered with since they were built and copied to the Yum repository.

At this point, the security of the signing key is not important. I say this confidently even after the recent package signing compromise at Fedora and Red Hat. We want to have automated package signing and we're only building packages for distribution inside the office.

One nice feature of GnuPG is its automatic key generation. The RPM build server is generating its own key, and preferably as non-interactive as possible. Unfortunately, this requires entropy to work consistently.

For information about automatically generating keys with GPG see the section "Unattended key generation" in the DETAILS file that comes with GnuPG. That documentation can be found on a GNU/Linux system with the following command.

  $ less -p "^Unattended" /usr/share/doc/gnupg-*/DETAILS

As the summary says:

This feature allows unattended generation of keys controlled by a parameter file. To use this feature, you use --gen-key together with --batch and feed the parameters either from stdin or from a file given on the command line [sic].

Here's an example of automatically generating a secret GPG key.

  $ cat gpg-key.conf
  %echo Generating a package signing key
  Key-Type: DSA
  Key-Length: 1024
  Subkey-Type: ELG-E
  Subkey-Length: 2048
  Name-Real: Build Server
  Name-Email: builds@site.org
  Expire-Date: 0
  Passphrase: Does not ex1st!
  %commit
  %echo Done
  $ gpg --batch --gen-key gpg-key.conf \
        > gpg-keygen.log \
        2> gpg-keygen_error.log

Those familliar with generating keys know that it is an extremely interactive process. Not just for entering the details about the key, but because you need to inject entropy into the computer to ensure the newly generated key is random. (Debian had erroneously weakened the random number generation in a security-related package necessitating a significant response to those systems affected by the vulnerability.) Usually, GnuPG receives entropy by jiggling the mouse or banging on the keyboard. As the GnuPG README says:

If you see no progress during key generation you should start some other activities such as moving the mouse or hitting the CTRL and SHIFT keys. Generate a key only on a machine where you have direct physical access - don't do it over the network or on a machine also used by others, especially if you have no access to the root account. (original emphasis)

This becomes a problem on servers that don't have mice or keyboards attached. One would typically see the following message from GnuPG complaining about not having enough entropy.

  $ gpg --batch --gen-key gpg-key.conf
  gpg: Generating a package signing key
  .++++++++++++++++++++...+++++..++++++++++++++++++++++++++++++++++++++++++++++++
  +++++++.+++++++++++++++++++++++++++++++++++++++++++++++++++++++..>+++++...+++++

  Not enough random bytes available.  Please do some other work to give
  the OS a chance to collect more entropy! (Need 123 more bytes)

  gpg: Interrupt caught ... exiting

As a sidebar, the "Key generation" section of the DETAILS file explains all those special characters spit to the screen when the key is generated.

    Key generation shows progress by printing different characters to
    stderr:
	     "."  Last 10 Miller-Rabin tests failed
	     "+"  Miller-Rabin test succeeded
	     "!"  Reloading the pool with fresh prime numbers
	     "^"  Checking a new value for the generator
	     "<"  Size of one factor decreased
	     ">"  Size of one factor increased

I tried various complicated strategies of creating entropy on a headless system to no success. One of them was piping the output of /dev/random into /dev/urandom and visa verse. Let's see if I can rehash it here.

  $ b=2048; \
    future=$(date -d'+6 seconds' +'%s' ); \
    while [ ${future} -gt $(date +'%s') ]; do \
      head -c b /dev/random > /dev/urandom; \
      head -c ${b} /dev/urandom > /dev/random; \
    done &
  $ gpg --batch --gen-key gpg-key.conf

Anyway, it didn't work.

Running this does, though.

  # rngd -r /dev/urandom

The rngd service provides "true random number generation" (RNG). It comes as part of the rng-tools package.

According to the documentation in the Linux kernel:

The hw_random framework is software that makes use of a special hardware feature on your CPU or motherboard, a Random Number Generator (RNG). The software has two parts: a core providing the /dev/hw_random character device and its sysfs support, plus a hardware-specific driver that plugs into that core.

In Fedora, this package can be installed with Yum.

  # yum install rng-utils

I've arrived on Planet Fedora. Planet Fedora is an aggregation of article feeds from members of the Fedora Project -- a community project affiliated with Red Hat that distributes the GNU/Linux operating system.

Joshua Gay wrote a good article about the GNU/Linux naming controversy on Wikipedia. I read the article in the FSF Bulletin that I receive twice a year as a member of the Free Software Foundation.

The naming controversy about whether to call the popular free software operating system "Linux", "GNU/Linux" and even "GNU Linux" has often been a discussion between elements of various community projects working on free software operating systems -- "in fighting" if you will. Gay's article responds to the latest venue -- Wikipedia.

However, Gay's article brings up another environ: proprietary software companies. In particular those companies that use GNU software in their commercial activity -- legally and in compliance with the relevant free software licenses -- but don't mention "GNU".

"Those companies that suppress the GNU name from their distributions are some of the worst offenders in not only distributing proprietary software, but also openly developing, promoting, and encouraging its proliferation. In many ways, these companies are hijacking the free software movement for their own gain, and their suppression of GNU is just one way of distracting people from the fact that they are unwilling to make an outright commitment to free software."

Adapting the GNU userland tools (and Debian package management) to the core system of a free software version of Solaris is called Nexenta. I used Solaris in university and learned a lot of unix and X window things while using it. I don't have any particular use for it, as I've only worked in situations where people could only afford GNU/Linux, and never had an legacy Solaris systems. Clearly, keeping GNU software highly portable has reaped many rewards for the day other kernels besides Linux became free software.

A posting from earlier this year by Karl Fogel called Thread Theory explains how electronic conversation -- email, newsgroups, forums -- are all the same thing, threads.

This reminds me of something an old roommate had discovered 2 or 3 years ago when he was loving electronic fora -- Gmane, mailing lists, Usenet, blogs. He was also developing Web course software as a project for a software assignment for school. I think his quote was, "'You want a mailing list? That's a newsgroup. You want a Web forum? That's a newsgroup. You want a blog. Yeah, that's just a newsgroup.'" Needless to say, his group's Web course software design dropped the usual boring SQL database in favor of interacting with a Usenet server on the backend.