tech help

A quick tutorial on writing a program that accepts plugins

On the CWE-LUG mailing list, someone asked a question about creating a program that can be extended with plugins. I thought the answer was so useful that I wanted to save it and make it available to others.

On 2/17/07, Mark wrote:

I’m a young programmer (just finishing high school) who has done a fair amount of programming with PHP, MySQL, and other web technologies. … How does one go about designing a program so it can be extended later with plugins, apis, and modules?

Ed Howland, veteran programmer, replied:

Mark, if i understand you correctly, you are seeking how to design a general purpose program that can be extended by others. It would help us to know what your target environment is. Especially if it is a dynamic language like Perl, Ruby or Python.Or a compiled language like Java or C/C++. The difference lies in linking others source code with yours, interpreted languages are easier in this respect.

That said, the general techniques are well-established. For purposes of illustration, I’ll call the code you are wanting to write the host (application) and the external modules, the guest (module.) The basic idea is to use various callbacks into the guest module from the host application. But first the guest application must register itself with the host (see it is like a hotel checkin…) This registration process can take many forms and is usually dictated by the programming environment. Anyway, the host maintains a list of registered guests. Each time a new guest registers, he is appended to said list.

Next, the host will then use the handle that represents the main object of the guest, and call an initialize routine in the guest. That routine sets stuff and gets a handle to the host so it can call things in the framework API to open windows, etc.

So the basic steps are:

  1. Devise a registration process
  2. Maintain a list of registered guest modules
  3. When starting, loop over your registered guests and call their initialize routines
    1. When a guest’s initialize routine is called, it calls pre-defined host API calls to open windows, or other things.
    2. These might cause the framework (in the host) to callback to the guest to display the window, and paint the contents of the windows.

You want to make your plugin callback interface as narrow as possible. And you want your host API to be simple to create widgets, windows, whatever in a few easy steps. If using a O-O language like Java or C#, use interfaces for both the IPlugin (guest) and IPluginHost (host) and guest module writes will inherit from or implement those interfaces. Ideally, the minimal IPlugin interface could be as small as init() and destroy() (if destroy is needed.)

Finally, if starting fresh, you might think about designing your entire application to nothing but the framework and your own pieces will simply be plugins.

The hard part is the registration process. Do you allow files to be uploaded to a web server? Does it write and re-read a config file listing plugins? I haven’t looked at DotNuke or PHPNuke or Typo, WordPress or any of the other ones. But the answer is in there.

Ruby on Rails has a built-in plugin architecture, but not one that you can upload files to, at least not w/o restarting the RoR app iteself, IIRC. It looks in a subdirectory for plugin subdirs for a file called init.rb. It just executes whatever is in that tile.

HTH, somewhat.


Find out a hard drive’s UUID

If you want to add a device like an external hard drive to your /etc/fstab file, it helps if you know the hard drive’s UUID. If you use K/Ubuntu, the following command will display the UUID, along with other useful information.

$ sudo vol_id /dev/sdo1

Retrieve CD Key from Windows 95 or NT

Start | Settings | Control Panel | System

Under Registered to, you’ll see user name & a 20-digit number. Digits 6 through 15 make up the CD key.

If you’re using an OEM version, the entire number is the CD key.

Ubuntu Edgy changes to fstab

I upgraded my Ubuntu Linux desktop today from Dapper to Edgy. It appears that in /etc/fstab, LABEL= no longer works, and you must now use UUID=.

So my fstab now looks like this, for instance (these are all external drives):

UUID=a3d8a126-a7fc-4994-9675-748ed62c3109 /media/music           xfs      rw,user,noauto  0  0
UUID=e6e83a83-7487-4f22-a7ac-42cb100dfe24 /media/music-copy      reiserfs rw,user,noauto  0  0
UUID=99198c52-3f9e-4255-9326-7891a90223ac /media/temp            reiserfs rw,user,noauto  0  0
UUID=e0e73b81-f432-4b9e-918c-595fbfb1ac93 /media/data            ext3     rw,user,noauto  0  0
UUID=2296551a-1d7d-4aff-9aea-873121464c9a /media/data-copy       ext3     rw,user,noauto  0  0
UUID=e04e7b7a-b429-4a0f-a458-6af0c120bb9b /media/music-rock      xfs      rw,user,noauto  0  0
UUID=af39f5e1-1554-4dac-be5c-1f5028ee9503 /media/music-rock-copy xfs      rw,user,noauto  0  0

Edgy also converts any old fstab entries for /dev/hda1 and so on to the new UUID method as well.

For more on labels & uuid in fstab, see:

The politics & basics of Unicode

From Tim Bray’s “On the Goodness of Unicode” (6 April 2003):

Unicode proper is a consortium of technology vendors that, many years ago in a flash of intelligence and public-spiritedness, decided to unify their work with that going on at the ISO. Thus, while there are officially two standards you should care about, Unicode and ISO 10646, through some political/organizational magic they are exactly the same, and if you’re using one you’re also using the other. …

The basics of Unicode are actually pretty simple. It defines a large (and steadily growing) number of characters – just under 100,000 last time I checked. Each character gets a name and a number, for example LATIN CAPITAL LETTER A is 65 and TIBETAN SYLLABLE OM is 3840. Unicode includes a table of useful character properties such as “this is lower case” or “this is a number” or “this is a punctuation mark”.

My new book – Linux Phrasebook – is out!

I’m really proud to announce that my 3rd book is now out & available for purchase: Linux Phrasebook. My first book – Don’t Click on the Blue E!: Switching to Firefox – was for general readers (really!) who wanted to learn how to move to and use the fantastic Firefox web browser. I included a lot of great information for more technical users as well, but the focus was your average Joe. My second book – Hacking Knoppix – was for the more advanced user who wanted to take advantage of Knoppix, a version of Linux that runs entirely off of a CD. You don’t need to be super-technical to use and enjoy Hacking Knoppix, but the more technical you are, the more you’ll enjoy the book. Linux Phrasebook is all about the Linux command line, and it’s perfect for both Linux newbies and experienced users. In fact, when I was asked to write the book, I responded, “Write it? I can’t wait to buy it!”

The idea behind Linux Phrasebook is to give practical examples of Linux commands and their myriad options, with examples for everything. Too often a Linux user will look up a command in order to discover how it works, and while the command and its many options will be detailed, something vitally important will be left out: examples. That’s where Linux Phrasebook comes in. I cover a huge number of different commands and their options, and for every single one, I give an example of usage and results that makes it clear how to use it.

Here’s the table of contents; in parentheses I’ve included some (just some) of the commands I cover in each chapter:

  1. Things to Know About Your Command Line
  2. The Basics (ls, cd, mkdir, cp, mv, rm)
  3. Learning About Commands (man, info, whereis, apropos)
  4. Building Blocks (;, &&, |, >, >>)
  5. Viewing Files (cat, less, head, tail)
  6. Printing and Managing Print Jobs (lpr, lpq, lprm)
  7. Ownerships and Permissions (chgrp, chown, chmod)
  8. Archiving and Compression (zip, gzip, bzip2, tar)
  9. Finding Stuff: Easy (grep, locate)
  10. The find command (find)
  11. Your Shell (history, alias, set)
  12. Monitoring System Resources (ps, lsof, free, df, du)
  13. Installing software (rpm, dkpg, apt-get, yum)
  14. Connectivity (ping, traceroute, route, ifconfig, iwconfig)
  15. Working on the Network (ssh, sftp, scp, rsync, wget)
  16. Windows Networking (nmblookup, smbclient, smbmount)

I’m really proud of the whole book, but the chapter on the super-powerful and useful find command is a standout, along with the material on ssh and its descendants sftp and scp. But really, the whole book is great, and I will definitely be keeping a copy on my desk as a reference. If you want to know more about the Linux command line and how to use it, then I know you’ll enjoy and learn from Linux Phrasebook.

You can read about and buy the book at Amazon ( for $10.19. If you have any questions or comments, don’t hesitate to contact me at scott at granneman dot com.

1st 2 questions AOL tech support asks

From Spare me the details (The Economist: 28 October 2004):

LISA HOOK, an executive at AOL, one of the biggest providers of traditional (“dial-up”) internet access, has learned amazing things by listening in on the calls to AOL’s help desk. Usually, the problem is that users cannot get online. The help desk’s first question is: “Do you have a computer?” Surprisingly often the answer is no, and the customer was trying to shove the installation CD into the stereo or TV set. The help desk’s next question is: “Do you have a second telephone line?” Again, surprisingly often the answer is no, which means that the customer cannot get on to the internet because he is on the line to the help desk. And so it goes on. …

Unix specs vs. Windows specs

From Peter Seebach’s Standards and specs: Not by UNIX alone (IBM developerWorks: 8 March 2006):

In the past 20 years, developers for “the same” desktop platform (“whatever Microsoft ships”) have been told that the API to target is (in this order):

* Win16
* OS/2
* Win32
* WinNT
* WinXP
* and most recently .NET.

Of course, that list is from last year, and now the “stable” target that you should be developing for, if you have an eye for the future, is Vista.

It hasn’t been quite as bad in the Macintosh world, where the number of major API changes has been limited: classic single-tasking Mac OS, classic multitasking Mac OS (System 7), Carbon (System 8/9 and preview of OS X), and Cocoa (OS X), but even there, the cost of migration has been significant. At least OS X finally offers a stable UNIX API for the back-end part of programs, allowing developers to ignore the API creep except in GUI code.

By contrast, twenty-year-old UNIX utilities still compile and run. A new desktop computing API will come and everyone will have to rewrite for it, but mountains will erode away before read() and write() stop working. This is the reason that all the hassle of formal UNIX standards has had so little effect on practical UNIX software development; the core API is simple, clean, and well-designed, and there is no need to change it significantly.

… UNIX users have been switching hardware platforms since the 1970s; it’s no big deal. …

Just as there are many varieties of UNIX, there are many UNIX standards:

* Probably the oldest standard that people still refer to is AT&T’s 1985 System V Interface Definition (SVID). This standard shows up, for instance, in man pages describing the standards compliance of functions that have been in the C library “forever.”
* Meanwhile, X/Open (now the Open Group) was developing “portability guides” with names like XPG2, XPG3, and so on. XPG1 was actually released in 1995. The XPG guides are largely subsumed into newer specs, but once again, are still referred to sometimes in documentation.
* The IEEE’s POSIX standard showed up in 1990 with updates in 1992 and 1993 and a second edition in 1996. It’s still a viable standard, although it has suffered from poor accessibility. POSIX specs have names like 1003.x; for instance, 1003.1 and 1003.2, which refer to different parts of the standard, or 1003.1-1988 and 1003.1-1990, which refer to two versions of the standard.
* The fairly ominous sounding “Spec 1170” (also known as “UNIX 98” or “Single Unix Specification”) is probably the most complete specification; it is produced by the Open Group, and is effectively a descendant of the XPG series. In practice, this is “the” UNIX standard these days, although it’s a little large; this has had an impact on conformance testing.
* The Linux Standards Base is not strictly a UNIX standard, but it’s a standardization effort relevant to a very large number of developers working with code designed to run “on UNIX.” …

You can look at OS specifications in two very different ways: one is from the point of view of a developer trying to port an application, and the other is from the point of view of the user trying to interact with the system.

UNIX conveniently blurs this distinction. The primary user interface is also one of the primary development environments; therefore, UNIX specifications often cover not only the C language API, but also the shell environment and many of the core utilities shell programmers rely on. …

From the perspective of a developer who’s seen many Unix-like systems, Linux is probably mostly sort of similar to System V. The heavy focus on GNU utilities gives a sort of surreal combination of Berkeley and System V features, but if you have to guess whether Linux does something the Berkeley way or the System V way, go with System V. This is especially true of system startup; nearly all Linux systems use the System V /etc/inittab and /etc/rc.d structure, or something very close to it. …

Windows directory services

From David HM Spector’s Unfinished Business Part 2: Closing the Circle (LinuxDevCenter: 7 July 2003):

… an integrated enterprise directory service does give network managers a much greater ability to manage large-scale networks and resources from almost every perspective.

Unlike most UNIX systems, Windows environments are homogeneous. There are three modes of operation in terms of user and resource management in the Windows universe:

1. Stand-alone.
2. Domain membership through a domain controller.
3. Organizational-unit membership in an LDAP-based directory such as Active Directory (or via a third-party directory such as NDS, but those are declining as more organizations switch to AD). …

Three major pieces of software make up the bulk of what Active Directory does:

* LDAP, the Lightweight Directory Access Protocol.
* Kerberos, the authorization system originally developed as part of MIT Athena (later, the basis for the security components in OSF’s DME).
* A SQL database.

These components interact with the Windows APIs to deliver a one-stop repository for any attribute that can be used to describe a system, a service, a device, users, groups, a relationship, a policy, an authorization, or another relationship in a computing environment. …

LDAP in AD is used to manage:

* DNS addresses
* Workstation and server descriptions
* Printers
* Print queues
* Volume mappings
* Certificates
* Licenses
* Policies (such as ACLs, security policies, etc.)
* Groups
* Users
* Contacts

All of these data are stored in one unified system, which can be broken down relatively easily (with some major caveats) by physical location (site), division, organization unit, or department and workgroup, and managed in a distributed fashion. These data can be replicated for redundancy and performance purposes. All Windows APIs must operate within this system if they are to participate in the network and have access to its resources. Repository data is wrapped up by and authenticated through the use of Kerberos Tickets, which makes the system (again, general Windows caveats applied) secure. …

The most interesting part of this story is that 95% of the hard work has already been done! Microsoft didn’t invent totally new LDAP schemas to make Active Directory as comprehensive as it is — as usual, they embraced and extended the work of others. LDAP schemas already exist, and are publicly available to cover:

* Contact management: The InetOrgPerson schema
* IP Addresses, Users, Server/Workstation Info: The NIS schema
* Kerberos tickets: IETF Kerberos KDC schema

Of course, Microsoft’s own schemas are available for perusal on any Active Directory server (or, if you happen to have a Macintosh OS X box, look in /etc/openldap, for all of Microsoft’s schemas are there). …

When to use XML

From W3C’s “Architecture of the World Wide Web, Volume One“:

XML defines textual data formats that are naturally suited to describing data objects which are hierarchical and processed in a chosen sequence. It is widely, but not universally, applicable for data formats; an audio or video format, for example, is unlikely to be well suited to expression in XML. Design constraints that would suggest the use of XML include:

1. Requirement for a hierarchical structure.
2. Need for a wide range of tools on a variety of platforms.
3. Need for data that can outlive the applications that currently process it.
4. Ability to support internationalization in a self-describing way that makes confusion over coding options unlikely.
5. Early detection of encoding errors with no requirement to “work around” such errors.
6. A high proportion of human-readable textual content.
7. Potential composition of the data format with other XML-encoded formats.
8. Desire for data easily parsed by both humans and machines.
9. Desire for vocabularies that can be invented in a distributed manner and combined flexibly.

Articles read on 25 November 2003

Crypto-Gram Newsletter of 15 November 2003

"I don’t believe that airplane hijacking is a thing of the past, but when the next plane gets taken over it will be because a group of hijackers figured out a clever new weapon that we haven’t thought of, and not because they snuck some small pointy objects through security."

The Big Here and Long Now, by Brian Eno

"The Long Now is the recognition that the precise moment you’re in grows out of the past and is a seed for the future. The longer your sense of Now, the more past and future it includes. It’s ironic that, at a time when humankind is at a peak of its technical powers, able to create huge global changes that will echo down the centuries, most of our social systems seem geared to increasingly short nows."

The End of the Modern Era, by Vaclav Havel

"The end of Communism is, first and foremost, a message to the human race. It is a message we have not yet fully deciphered and comprehended. In its deepest sense, the end of Communism has brought a major era in human history to an end. It has brought an end not just to the 19th and 20th centuries, but to the modern age as a whole." : Using it with Style

"We will examine how the styles work within and how they can be used to make your job easier when it comes to word processing."

KDE, Mac Os X, Windows: What can we learn (copy or improve) from them? (PDF)

Howard Rheingold: Smart Mobs

"Smart mobs use mobile media and computer networks to organize collective actions, from swarms of techo-savvy youth in urban Asia and Scandinavia to citizen revolts on the streets of Seattle, Manila, and Caracas. Wireless community networks, webloggers, buyers and sellers on eBay are early indicators of smart mobs that will emerge in the coming decade. Communication and computing technologies capable of amplifying human cooperation already appear to be both beneficial and destructive, used by some to support democracy and by others to coordinate terrorist attacks."

Problems with the Book of Mormon

"Written by a former believer in the book of Mormon, this article reveals serious objective weaknesses in any truth claims concerning the Book of Mormon."

Articles read on 20 November 2003

The CUPS printing system

The Linux Process Scheduler

"Learn all of your favorite Linux scheduling ins and outs: policy, the scheduling algorithm, preemption and context switching, real-time scheduling, and Scheduler-Related System Calls."

The final irony,3605,985375,00.html

"’Isn’t it ironic?’ You hear it all the time – and, most of the time, actually no, it isn’t. Hypocritical, cynical, lazy, coincidental, more likely. But what is irony and why did pundits think it would die two years ago, after September 11? Zoe Williams meticulously, sincerely, unironically, hunts it down."

Patch and Pray

"It’s the dirtiest little secret in the software industry: Patching no longer works. And there’s nothing you can do about it. Except maybe patch less. Or possibly patch more."

Open-Source King of Data Backup

"But is Rsync an industrial-strength tool that enterprises can substitute for commercial back-up wares? That depends on the size and scale of a network. It is, however, an indispensable utility, useful for many online file-transfer applications."

How to add menus to Radio Userland

I don’t use Radio Userland any longer, but I found these instructions incredibly helpful, so here they are:

go to

add a name: kitNews
value: /system/kit/news

now go to

scroll down to addCommand list

add the following: addCommand (“Kit News”,


SSL in depth

I host Web sites, but we’ve only recently [2004] had to start implementing SSL, the Secure Sockets Layer, which turns http into https. I’ve been on the lookout for a good overview of SSL that explains why it is implemented as it is, and I think I’ve finally found one: Chris Shiflett: HTTP Developer’s Handbook: 18. Secure Sockets Layer is a chapter from Shiflett’s book posted on his web site, and boy it is good.

SSL has dramatically changed the way people use the Web, and it provides a very good solution to many of the Web’s shortcomings, most importantly:

  • Data integrity – SSL can help ensure that data (HTTP messages) cannot be changed while in transit.
  • Data confidentiality – SSL provides strong cryptographic techniques used to encrypt HTTP messages.
  • Identification – SSL can offer reasonable assurance as to the identity of a Web server. It can also be used to validate the identity of a client, but this is less common.

Shiflett is a clear technical writer, and if this chapter is any indication, the rest of his book may be worth buying.