In the course of trying to track down other system lockups, I upgraded to the 2.6.18 kernel, and wish-2.1.3 stopped building for me. A devfs header file that it used was finally deprecated out of the module-building header directory. Luckily, in the mean time, wish-2.1.5 was released without this dependence on devfs. I re-generated the patches, and updated the bug to be an ebuild for wish-2.1.5, a.k.a. x10dev.

I’ve read in the last couple of months, however, that Org-Mode is already in emacs-cvs, and will be part of the standard distribution of emacs-22. I decided to try it out, was quickly impressed, and transitioned over.

Both support the same basic data model: files of mixed notes and todo-items, where the items are simply specially-formatted lines in the file. Items have an optional due date and an optional priority (ABC). For example, in planner-mode, they appear:

A _ Write up planner-/org-mode post (2006.11.24)

B X Make faux-chicken dinner for Thanksgiving (2006.11.23)

For Org-mode:

** TODO [#A] Write up planner-/org-mode post SCHEDULED: <2006-11-24> ** DONE Make faux-chicken dinner for Thanksgiving SCHEDULED: <2006-11-23> CLOSED: [2006-11-23 Thu]

Both support the same basic execution flow: when requested, the package looks through the special files to find lines that fit the pattern, and constructs another file (planner) or a transient view (Org) over past-due and presently-due items. There are operations for creating items, scheduling them on a particular date, transitioning them closed, jumping from the item to associated notes, &c. As well, both support some form of unidirectional publishing of the content to HTML, ostensibly to serve as some public project-planning status.

Org-mode, I’ve discovered, goes far beyond planner-mode in terms of features.

• Core
• It is based on outliner-mode, and its documents are inherently foldable, hierarchical documents.

• It uses file extension (”.org”) for mode-selection, so planning document can live next-to or within projects.

• Todo

• There’s a bit more latitude where items can be placed in the notes documents.
• It supports — separately from the scheduled to-do time for a task — a deadline, which is brought up differently in the “now” view.
• Overdue items are indicated more clearly.
• Items can be scheduled for a range of time.
• Items can be tagged arbitrarily and searched/viewed by tags (”WORK”, “STORE”, “@LAPTOP”, …)
• Supports progress logging

• Supports hierarchical sub-tasks (yay!)

• Linking

• Explicit linking rather than CamelCase (though CamelCase is an option), which was the major problem I was having with planner-mode (it starts to become really slow for large documents).

• Patterned links (”bugs:1234″, “http://bugs/show_bug.cgi?id=%s” → “[...]?id=1234″) are supported.

• Other

• Has a table/spreadsheet editor. The table-editing part appears similar to table.el, but the spreadsheet functionality is just pure awesome.

Update Mon 2006-11-27: after being contacted by Carten Dominik, the author of org-mode, I’ve revised the comment at the end about the table/spreadsheet editor.

In the scenario it was created for, data is (externally) collected into a (directory) tree of RRD files. While there are only a handful of unique RRD file and graph types, there are a large number of instances of those templates. Good examples of this are:

• cpu load
• 1,5,15 minute averages
• 1 per machine
• disk util
• avail, used, free
• ~5 per machine
• cache stats
• (hit, miss, size) stats
• 2 .. 20 caches/”node”, depending type.

This collected data might exist in the following tree of RRD files:

/servers/hostA/cpu.rrd /servers/hostA/disk/root.rrd /servers/hostA/disk/usr.rrd /servers/hostA/disk/data/logs.rrd /node/nodeA/cache/foo.rrd /node/nodeA/cache/bar.rrd [...15 more caches...]

Cacti has the following templates manually configured:

/servers//cpu /servers//disk /node/*/_cache

The script, then, knows how to relate RRD files of the regex pattern r'''/servers/([^/]+)/cpu''' to the template(s) “/servers/*/cpu”, using the regexp group 1 as the name of the host; edit the ‘rrd_types‘ global to suit your scenario.

Instances are named as their RRD file name (yes, skipping Cacti’s own |template_formatting|).

The script will delete instances with the same name, allowing you to re-run it pretty liberally to pick up new rrd files, changes in templates, &c.

The process of cloning is as follows; see ‘execute_plan_alpha(...)‘ in the script for the gory details.

• find the host in table ‘host‘.
• data template instantiation
• find the data template id (by name) in ‘data_template‘.
• if an instance with the name already exists: delete it.
• insert into data_local, get new (autoinc) id for the instance.
• get the list of rrd DSes from the template (from ‘data_template_rrd‘)
• copy each, maintaining the instance -> template id map.
• instantiate the data_template itself (’data_template_data‘)
• copy the RRAs as well (’data_template_data_rra‘)
• graph instantiation
• get the graph_template_id (by name) from ‘graph_templates‘
• insert into ‘graph_local‘, get autoinc id.
• instantiate graph (’graph_template‘).
• copy ‘graph_instance_item’s, as this is where the graph-ds/rrd-ds mapping is stored, run the relevant ids through the map retained earlier.

For details on Cacti 0.8’s rather atrocious database schema, see Cacti Forums: Database schema… WTF? and Cacti Forums: Cacti data relationship diagram.

-- shell-script --

Copyright 2006 Joshua Sled

Distributed under the terms of the GNU General Public License v2

inherit eutils java-pkg

MY_PV=${PV}final

DESCRIPTION=”SQL client” HOMEPAGE=”http://squirrel-sql.sourceforge.net/” SRCURI=”mirror://sourceforge/${PN}/${PN}-${MYPV}-src.zip”

@fixme: log4j, commons-cli, nano-xml

DEPEND=”>=virtual/jdk-1.4 dev-java/ant-core” LICENSE=”LGPL-2″ SLOT=”0″ KEYWORDS=”x86″ IUSE=”"

S=”${WORKDIR}/sql12″

src_unpack() { unpack ${A} cd ${S} }

srccompile() { cd ${S}/build ant jarsource compile_plugins }

src_install() { dodir /opt/${P} dodir /opt/${P}/doc

cp -R ${WORKDIR}/squirrel-sql-dist/squirrel-sql/core/dist/* ${D}/opt/${P}/ cp ${D}/opt/${P}/squirrel-sql.sh ${T} echo ${T} sed -e “s#%INSTALLPATH#/opt/${P}#” < ${T}/squirrel-sql.sh > ${D}/opt/${P}/squirrel-sql.sh makedesktop_entry squirrel-sql.sh “SQuirreL SQL ${PV}” /opt/${P}/icons/acorn.png “Utility” /opt/${P}/ }

-- shell-script --

Copyright 2005 Joshua Sled

Distributed under the terms of the GNU General Public License v2

inherit eutils java-pkg

MY_PV=${PV}final

DESCRIPTION=”SQL client” HOMEPAGE=”http://squirrel-sql.sourceforge.net/” SRCURI=”mirror://sourceforge/${PN}/${PN}-${MYPV}-standard.tar.gz” DEPEND=”>=virtual/jdk-1.4″ LICENSE=”LGPL-2″ SLOT=”0″ KEYWORDS=”x86″ IUSE=”"

S=”${WORKDIR}/SQuirreL SQL Client”

src_unpack() { unpack ${A} cd “${S}” }

src_compile() { echo “no compilation” }

src_install() { dodir /opt/${PN} cp -r “${S}”/* ${D}opt/${PN} }

After most of the presentation, we had pizza and Chris finished a more open-ended section of the presentation, where we were able to trigger some alerts in real-time from another machine in the lab by doing nessus and nmap scans, which is always fun. After that we talked around for a while about the group’s recent history and directions forward. I wanted to emphasize the importance of regular meetings, and we talked about having a mid-November meeting focused on mini-presentations: short (10-minute) mini-coverage of a narrow area or topic.

We also talked about the notion of doing more install-fests, and generally decided that we should play down the install piece, and play up the and how do you want to use it? piece, which is more engaging.

It’s really nice to see the same faces coming back to the meetings, and to meet the new people (3!) who showed up to this one. Hopefully that’ll increase even more over the next year.

If you’re a Vermont Linux/Unix geek, or just generally a tech-head, you might want to subscribe to the moderate-traffic mailing list, or at least the VAGUE RSS event-announcement feed.