Copyright (c) 2004 Toomas Karmo. Revision history: 20051113T055029Z/version_0001.2003 (made minor corrections); 20051112T235216Z/version_0001.2000 (added several further paragraphs, in part by creating Sections 9 and 10); 20051108T052252Z/version_0001.0000 (finished base version); 20051106T060513Z/version_0000.9000 (added still more material and started polishing); 20051105T200949Z/version_0000.0450 (hastily replaced bare logic blueprint with some unchecked first-draft prose); 20051105T060616Z/version_0000.0400 (hastily added still more material); 20051103T051922Z/version_0000.0100 (hastily added lots of material to the base version, in the realization that the essay was already getting readers on the Web); 20051011T210021Z/version_0000.0010 (started the base version). Permission is granted to copy, distribute, and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2, or any later version published by the Free Software Foundation. In the terminology of the License, this document has no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. The definitive machine-readable copy of this document is in the 'Literary' section of A copy of the License is included in a hyperlinked section, entitled GNU Free Documentation License, of the machine-readable copy.

No-Frills GNU/Linux:
Imposing Order
on Filenames
and Directory Hierarchies

For the reader in a hurry, here's an overview with hyperlinks to the relevant sections, further down the single ultra-long page (you're reading its initial paragraph now) that displays this twenty-thousand-word essay.

The first section, 'About This Essay' and the second, 'Basic Workflow Concepts', lay foundations. The third, 'Filenames: Case, Sort Order, and Related Issues', is likewise foundational, talking about conventions governing a fundamental chore, the naming of directories (in Microsoft and Macintosh terminology, "folders") and their contents. The fourth, 'Allowing a Degree of Untidiness in the Home Directory', argues that there is no need to keep one's home directory tidy, provided an appropriate "Big Four" of subdirectories is present to impose order on what lies below home in one's filesystem hierarchy. The following four sections, namely the exceptionally long 'Organizing the Maintenance Area' and the shorter 'Organizing the Public-Documents Archive' and 'Organizing the Private-Studies Area' and 'Organizing the Client Area', explore this Big Foursome of handy directories. I finish with short sections entitled 'Further Reading' and 'Acknowledgements'.

1. About This Essay

How can we keep files on our GNU/Linux workstation in good order, so that we can easily find what we are looking for? Nowadays, with GNU/Linux coming into more and more widespread use, the question touches the full range of professionals: not only the natural scientists on faculty at the universities, but also such people as freelance nonfiction book writers; journalists; lawyers; public servants; and of course, now even more than at the 1990s dawn of GNU/Linux, software developers. Further, the question is of interest to the student embarking on university studies and to the information-technology manager counselling end users (as when such a manager, having been engaged by a government deploying many tens or hundreds of lean-and-mean GNU/Linux machines for its administrative cadre, is asked to specify an end-user training curriculum). Finally, the question is of some interest to the architect of the large, customized XML-driven "Document Management Systems" and "Content Management Systems" now being rolled out within large organizations, notably within today's international business corporations.

Although I write in the first instance for Unix-, notably GNU/Linux-, aware readers, much of my analysis proceeds at a level of abstraction high enough to make it neutral among operating environments. The contemporary Macintosh OS X environment combines a user-friendly GUI facade with a BSD Unix interior. It it therefore possible in OS X to invoke a command-line prompt and handle files, including directories, very much in the way sketched here for GNU/Linux. In Microsoft, one has the option of pulling up a window with a "DOS prompt", communicating with the machine in a language developed in the 1980s as a sort of reworked Unix subset. In any kind of Mac or Microsoft work, moreover, and also in today's sophisticated corporate XML-driven browser-interfaced intranets, one can apply many of the concepts in this essay at a GUI level (remaining mindful in such an application that the GUI end user tends to say 'folder' where the traditional Unix-trained workstation owner says 'directory').

To make issues concrete, we take a possible real-life scenario. A GNU/Linux workstation owner in natural science may be wondering how to file all the following items:

We will not address this specific scenario in what follows. But a few readers may later, having finished and digested this essay, wish to revisit the scenario, taking it as a simple comprehension exercise and working out how the listed items are to be filed. Any readers who are unsure of the correctness of their answers or for any other reason wish to talk about electronic filing are welcome to contact me by e-mail. An appropriate subject line is any string containing both no-frills GNU/Linux and filenames.

In much of what follows, I will be displaying examples from my own workstation. I have for the most part resisted the temptation to tinker with the examples, beyond making a few ((SNIP)) edits and in one rather sensitive case forging or hacking (as I there warn readers) the displayed timestamps. One temptation to maintain the bella figura I have, all the same, indulged to the hilt. I normally type in haste, at a speed in English of, to one significant figure, 70 words per minute. In consequence, I make some error, some philosphy for philosophy, some reductoin for reduction, in easily every fifth line. Most of those errors I have corrected, applying the spell-checker not only to my words in this essay but even to the examples displayed from my real-life workstation environment.

2. Basic Workflow Concepts

2.1 Basic Workflow Concepts:
The Fourfold Division

We start by considering a single governing concept, designed to impose a degree of order on the looming chaos of workstation activity. If we engage with the exact natural sciences, with the life sciences, with humanities, with technology, with law, or with some similar intellectual field, our activity tends to oscillate between study and service. We study a subject, whether broad or narrow; on the strength of that study, we contribute some service to a "matter" or "project", whether big or small, for what may in a loose sense be called a "client"; we study again, whether in that same subject or in some other; and we again contribute some service, whether to the same client and project, or to a different project of the same client, or to a different client altogether.

The workstation is kept in order by mirroring this natural oscillation. We therefore set up two separate working areas, or collections of files. On the one hand we have an area for preparatory studies. On the other we have an area for client service.

The preparatory-studies area is for its part best set up as a pair of domains, with on the one hand an area in which we simply archive our private copies of published digital documents, on the other hand an area in which we actively work on our private-study notes. Into the former sub-area we put such things as the Richard Gray digital spectral-classification atlas (duly downloaded from a North Carolina astronomy server) in PDF or PostScript, or the Credit Lyonnais Securities Asia 2005 'Sun Screen II: Investment Opportunities in Solar Power' small-book PDF (duly downloaded by clicking on a hyperlink in the Web site for photovoltaics trade journal Photon), or conceivably some ArXiV physics preprint from the ArXiV server. Into the latter sub-area we put such things as our notes on 'Sun Screen', perhaps accompanied by our copy-and-paste notes from some Web pages mentioned in 'Sun Screen'.

Although the distinction between published documents and private-study materials is often unimportant, it comes in handy just often enough to be justified. Quite apart from legal issues surrounding the disposal of a deceased workstation-owner's estate (we are going to encounter those recondite issues below), there are practicalities of quick-and-dirty archiving. For instance, we may be leaving town temporarily, in haste, and may need to take along from the workstation some modest, 900-kilobyte, notes on environmentalism. (Here "take along" might mean copying the notes via FTP to some public, universally accessible, space-limited server, or sending them somewhere in an e-mail attachment of manageable size, or putting them onto a ZIP drive or a floppy.) Bad luck may have it that whereas our private study notes are terse, we have downloaded some megabytes' worth of PDF publications from a source such as Greenpeace. What we want is a small, quick-and-dirty *.tar file, constituting a complete archive of all and only our private-study environmentalism notes. In our rush to catch the train, we do not wish to fuss with an explicit exclusion of the PDF material when we invoke tar. It is the clear separation between published and private-study materials that lets us get away with a simple invocation in the style tar -cf quick_and_dirty.tar the_overall_enviro_studies_directory, bypassing the intricacies of tar --exclude=.

One further area is necessary. We need a place on our workstation in which we store maintenance materials - that is, materials needed to keep our workstation running properly whether we happen to be undertaking private study today or, on the contrary, happen to be serving a client today. Here are two examples of such maintenance materials:

We think of this further area as foundational, i.e., as logically prior both to studies and to client service.

We thus have a fourfold scheme (appropriately implemented on the workstation with four directories right below the home directory):

2.2 Basic Workflow Concepts:
Some Demarcation Issues

We now examine three tricky demarcation issues arising from this fourfold scheme.

(A) Here is a problem case involving material that could go into either the first or the second of the four main areas. (Admittedly, it is a made-up case rather than one I have encountered in running my own workstation.) Most of the software on our workstation comes (let us suppose) from the international Debian GNU/Linux project and consequently has its documentation meticulously archived at install tine by the Debian package-installation scripts in /usr/share/doc, under conventions ultimately documented in a published piece of project legislation, the Debian Policy Manual. There is no point in fussing further about the filing of such documentation. We may, however, some day find ourselves forced to install some commercial GNU/Linux software outside Debian, with documentation separately packaged. Where, now, should such documentation go? Does it belong in the maintenance area, along with, say, the vendor's digital authorization key and our own notes on what had to be done at install time to get the software working properly? Or does the documentation belong by contrast in the public-documents area, like an ordinary downloaded book on computers?

This tricky case is resolved by looking not at the contents of the documentation but at our intention in storing it. If the documentation will be discarded when we stop using the software, then it belongs in the maintenance area. Some software documentation, however, we keep because it takes on a life of its own, as a reference work. For instance, the documentation on a symbolic-computation package may contain some background information on Fourier transforms or matrix inversion, helpful in our general mathematical reading, and therefore worth keeping even if that specific software tool outlives its usefulness and gets replaced with a symbolic-computation package from some competing vendor. In such a case, there are various ways to proceed. (a) We may file the problematic manual within the maintenance area but with a symbolic link inserted in the public-documents area as a reminder. Alternatively, we may, as a not-interestingly-different variant on this tactic, file the problematic manual within the maintenance area but with a zero-byte descriptively titled reminder file, a "human pointer", say FOR_matrix_inversion_SEE_ALSO_matlynx_docs, created at the command-line prompt with the incantation touch FOR_matrix_inversion_SEE_ALSO_matlynx_docs. These two approaches are appropriate if our main interest in the manual is as a resource for our software, with its work-of-mathematical-reference aspect a strictly subordinate consideration. We then take it that if the software is uninstalled, we may delete the manual with a clean conscience. That deletion will simply leave behind a broken symbolic link, or a no-longer-quite-apposite zero-byte human-pointer file, as a reminder from uninstall time onward of the mathematical textbook we have lost. (b) In the less likely event that the manual is useful first and foremost as a mathematical textbook, we will file it in the public-documents area, but with either a symbolic link or a human-pointer zero-byte file in the maintenance area. In that case, we will retain possession of the manual at software uninstall time. We will take it, further, that if the manual proves inaccurate as a mathematical reference, requiring to be thrown out, then we may delete it with a clean conscience. That deletion will simply leave behind in the maintenance area a broken symbolic link, or a no-longer-quite-apposite zero-byte human-pointer file, as a reminder from purge time onward of the software-maintenance resource we have lost. (c) If we really cannot decide which aspect of the problematic manual is the important one, we will file a copy of the manual in both places, soothing our uneasiness over the ensuing redundancy with the reflection that document engineering sometimes pays the price of redundancy to achieve an overarching goal of safety.

(B) Next, we consider a problem case involving material that could go into either the second or the third of our four main areas. (This, unlike the case just disposed of, does come up, over and over again, in my own work.) Let us suppose that we are surfing the Web for information on wind turbines and that we compose a lot of notes on what we read. There is no demarcation problem with these notes themselves, since they clearly belong in the private-studies area. But let us now imagine that we also copy and paste, as plain ASCII text, many slabs of prose from many different Web pages (as it might be, the sites of these wind-turbine vendors and those wind-energy public-policy advocates), putting everything into one big ASCII foo.txt file. Is foo.txt a public document? Or is it, on the contrary, a set of private-study notes?

To this I answer: Not really a public document. My reasoning is that in compiling the scrapbook, the workstation owner has added value, extracting interesting parts of Web pages out of longer pages and putting the selected texts into some more or less deliberate order within foo.txt. A conceivable lawyer's test makes the issue clear. Upon the workstation owner's death, is foo.txt a simple chattel, to be disposed of in a manner analogous to the disposal of a published book sitting on a wall shelf? Or does foo.txt form, on the contrary, part of a literary estate, to be archived and guarded and treated with due respect for information security, its disposal becoming a delicate task analogous to the disposal of a drawerful of private handwritten papers? The latter interpretation is clearly favoured. Admittedly, there are grey areas. If scant thought had been put into the selecting and organizing of the foo.txt materials, one might be tempted to dismiss the file as a mere public document. But on the whole, the temptation is to be resisted. The case is a little like the messy candy-box of magazine clippings, brochure fragments, and even ripped-out book pages in the drawer of a deceased professional. The contents of that candy box should be presumed to form part of a literary estate, and should therefore not be disposed of casually: the guiding presumption must be that it is not, so to speak, the used book dealer down town but rather the archivist of the University of Bluechapel, under the guidance of a formal confidentiality review, who deserves to get the potentially-ever-so-revealing box.

(C) Finally, we consider a problem case (one arising in a minor way in my own work) involving material that could go into either the third or the fourth of our main areas. Let us suppose the workstation owner to be enrolled as a student in the course CHEM105, in the summer of 2006, in the University of Brownfields. Many electronic files get created as work in that course proceeds. Lecture notes, for instance, are downloaded from the lecturer's Web site. Past exam papers are downloaded both from the lecturer's own Web site and from other sites, including sites outside Brownfields. Problem sets are worked not only with pencil and paper but in some instances also with electronic "notebook" files written by symbolic-computation software. Various administrative notices, about such things as the tutorial timetable, are received as ASCII e-mails or as PDF files from various sources, including the lecturer's Web site and the teaching assistant's e-mail account. Matters are made still more complex by the fact that the workstation owner has already studied the intellectual content of CHEM105 to some extent in the summers of both 2004 and 2005, using textbooks including, and yet not confined to, the official CHEM105 textbook. Moreover, the same intellectual content is liable to be revisited, with private note-taking, even in 2020 or 2025. Does this entire heterogeneous assemblage of materials get filed in essentially one place?

I give a two-part answer to this question. (a) The files that relate to the administration of CHEM105, with CHEM105 conceived of as a chore undertaken for the university rather than as a building up of one's private intellectual capital, are files for the "CHEM105 project", with the University of Brownfields as client. (b) The files that relate to the actual learning of chemistry, whether in the coursework summer of 2006, or in the preliminary-reading summers of 2004 and 2005, or in the refresher-reading years after the course is over, all belong together, in a basic-chemistry section of the private-studies area.

So much, then, for the basic philosophy of filing. In my own practice, I have not found more than a tiny handful of tricky cases, even though I have now spent perhaps six years evolving my present system. Still, various issues concerning the details of filing may, depending on the workstation owner's exact circumstances, call for supplementary private documentation. I for my part do have a philosophy-of-filing rulebook, called NNNN____guiding_policies.txt and stored in the uniquely appropriate place, namely the maintenance area, although I have so far not had to put into it any hard-cases law. We will take a closer look at NNNN____guiding_policies.txt in Section 5 below.

3. Filenames: Case, Sort Order, and Related Issues

The Second Extended filesystem traditional in Linux makes pathnames case-sensitive and in addition allows them to be long (running to as many as 256 characters). We can put both features to work, encoding a significant amount of information within the names themselves.

Upper case, in particular, deserves to be handled as a powerful, rather special tool. It makes sense to reserve upper case for encoding information about the place the given item occupies in some larger set of directories or ordinary files on the workstation and to reserve lower case for encoding information about the contents of the item (the files under it, if the item is a directory; the significance of the text, numbers, executable instructions, images, or sounds it contains, if the item is a regular file). So, for example, it makes sense to prefer correspondence_unesco over correspondence_UNESCO as a directory name and to prefer correspondence_unesco_2006.txt over correspondence_UNESCO_2006.txt as a name for a file containing plain-text e-mail transcripts.

What, on the other hand, about a file whose purpose is to back up a file of plain-text e-mail transcripts? (Such backups are a precaution against accidents in which a text-editing utility ends up corrupting the original file. Some command-mode typos, in particular, can lead to disaster with the otherwise very helpful text editors in the vi family.) In this case we consider a first step to an acceptable naming style to be correspondence_unesco_2006.txt_BAK rather than correspondence_unesco_2006.txt_bak. Admittedly, we should in strict logic prefer a timestamped style such as correspondence_unesco_2006.txt_BAK200510112T152200Z. I will say a little more about timestamps later in this essay, and I discuss that topic in depth in my companion essay 'No-Frills GNU/Linux: Timekeeping, Timestamping, Timelogging'.

Upper case is particularly useful in a string of letters placed at the beginning of each of a number of items in a single directory, to ensure that the GNU/Linux directory-listing commands ls and dir generate rationally structured screen displays. Here is an example. Imagine that, as part of our effort to learn about renewable energy sources, we are studying wind power. Then our private-studies area may well contain a plain-text, *.txt, file on turbines; another such file on the lead-acid batteries typically used in the small off-grid installation to store charge from the turbine-driven generators; and a third such file on the "inverters" typically used to produce alternating current for home appliances from the battery bank. If we name these files turbines.txt, batteries.txt, and inverters.txt, we get an illogical sequence in the directory listing:

-rw-------   1 verbum   verbum    1920 Sep  4 21:20 batteries.txt
-rw-------   1 verbum   verbum    3141 Sep  1 21:33 inverters.txt
-rw-------   1 verbum   verbum    2718 Sep  4 23:25 turbines.txt

The problem here is that the investigation of wind-power hardware logically starts with upstream components, notably turbines, continues through intermediate technologies such as batteries, and finishes with such downstream components as inverters. Somewhat more satisfactory is the use of sort-ordering prefixes A, B, and C (with a suitably large number of underscores; it is convenient to think in powers of two, and so to say to oneself 'two, four, eight, …' in deciding on such numbers):

-rw-------   1 verbum   verbum    2718 Sep  4 23:25 A____turbines.txt
-rw-------   1 verbum   verbum    1920 Sep  4 21:20 B____batteries.txt
-rw-------   1 verbum   verbum    3141 Sep  1 21:33 C____inverters.txt

However, this does not allow for the possibility of interpolations. It could be that as our studies progress, we find an unexpected need to interpolate a file of notes on generators between the notes on turbines and the notes on batteries and to add notes on preliminary wind-survey methods before the notes on turbines. Several years of experience have shown me that problems are kept safely at bay, no matter how complex the work in hand may be, if the sort-ordering prefix is written with four letters, rather than with one, and if a generous use is made of letters towards the middle of the alphabet (so that files can be added easily to the beginning or the end of a directory-listing sequence should the need suddenly arise). Working along these lines, we can name our files in the style

-rw-------   1 verbum   verbum    2718 Sep  4 23:25 DNNN____turbines.txt
-rw-------   1 verbum   verbum    1920 Sep  4 21:20 INNN____batteries.txt
-rw-------   1 verbum   verbum    3141 Sep  1 21:33 NNNN____inverters.txt

It is now easy to update our notes later, say to

-rw-------   1 verbum   verbum     963 Oct 14 12:01 CNNN____surveys.txt
-rw-------   1 verbum   verbum    2718 Sep  4 23:25 DNNN____turbines.txt
-rw-------   1 verbum   verbum    8302 Dec 10 01:13 FNNN____generators.txt
-rw-------   1 verbum   verbum    1920 Sep  4 21:20 INNN____batteries.txt
-rw-------   1 verbum   verbum    3141 Sep  1 21:33 NNNN____inverters.txt

The exact choice of letters is arbitrary. The only point that matters is the final ordering we see when we generate a display by, for instance, issuing the command ls -l at the command-line prompt. With the sort-ordering prefixes fully four letters long, and stuffed for the most part with letters from the middle of the alphabet, we rest assured that emergency interpolations will remain possible for quite a long time:

-rw-------   1 verbum   verbum     963 Oct 14 12:01 CNNN____surveys.txt
-rw-------   1 verbum   verbum    2718 Sep  4 23:25 DNNN____turbines.txt
-rw-------   1 verbum   verbum    2718 Dec 30 13:25 ENNN____drive_shafts.txt
-rw-------   1 verbum   verbum    2718 Dec 30 13:40 EPNN____gears.txt
-rw-------   1 verbum   verbum    8302 Dec 10 01:13 FNNN____generators.txt
-rw-------   1 verbum   verbum    1920 Sep  4 21:20 INNN____batteries.txt
-rw-------   1 verbum   verbum    3141 Sep  1 21:33 NNNN____inverters.txt

In many real-life situations, it is pedantic to try to make directory listings clean. It probably does not matter too much in what order our workstation lists the files in a directory that contains, as in this example, only seven files, where the content of those files is nothing more elaborate than flat-ASCII study notes. However, there are situations in which the rational ordering of directory listings does become important. As an imaginary example, take a contract job for a commercial client, in which we build a small Web site for a firm selling stencilling and stamping equipment to industrial customers. (Hypothetical though this example is, it closely mirrors a situation in my own work at the end of the 1990s, as I was directing a two-country team in the assembly of a Web site for an overseas government agency.) Imagine that the site is small enough to allow all XHTML files to be kept in one directory. The site is built from the usual index.html, plus twelve other XHTML files:


This hypothetical client has imposed the requirement that all the XHTML content outside the index.html homepage be reachable in a single homepage click. People who study the cognitive psychology of software interface design warn developers to avoid presenting the end user with more than a relatively small number, roughly half a dozen, of simultaneous choices, unless those choices have somehow been segregated into groups. (The cognitive psychologists then remind the software or Web developers that the requisite grouping can be achieved in various ways: for example, by varying the vertical spacing, or again by presenting each group of buttons in its own distinctive colour. In a real-life multi-person Web construction project, the abstract demarcational ideas would be worked out by the editor-cum-content-manager, with implementation at the level of whitespacing and colouring left to the graphic artist.)

We accordingly select our sort-ordering prefixes to mirror the groupings which we shall be instructing our graphic artist to achieve in laying out the page. First come two files for contact information, which we have here coded with sort-ordering prefixes CNNN and CPNN. Prefixes such as CMMM and CPMM would do just as well. But we avoid a pair of prefixes such as AAAA and AAAB, in case the commercial client suddenly requires us, later in the life of the project, to add content somehow logically prior to the two files embodying contact information. Next come two files talking about the human side of the firm, isolated in our coding with prefixes whose initial character is G. The next three groups (M, P, R) present the client's core advertising message. Two of the three files in the P group are named rather subtly, to indicate to the business-writing team on the project that they contain tightly linked stories, for two contrasting types of industrial machinery. The filenaming leaves the possibility of interpolation open (since between PNEN and PNFN one can fit some such sort-ordering prefix as PNER or PNFD), yet not invitingly open. At the very end comes a file named with the prefix XNNN discussing such issues as support for CSS-blind browsers. In the name for that file, we prudently use the prefix XNNN rather than ZNNN, so as to allow for the possibility of the client's suddenly adding material that has to come still later in the underlying business-writing logic (perhaps, for instance, some legal boilerplate that covers the entire page, including even the at-the-moment-supposedly-final remarks on browser support).

Top-down planning is useful in a complex task such as a Web development project. By first deciding on the filenames, including the groupings inherent in their names, we start at the appropriate place, with the forest rather than the trees. It is once we have decided on a proper scheme of filenames that we fill in details. In particular, in a Web development project, the sort-ordering prefixes make it possible to keep *.txt and other subsidiary files, needed as the project takes shape, cleanly associated with their *.html counterparts. Chaos is thereby avoided when, for instance, a business writer hands a story in *.txt or *.doc or *.rtf format over to an XHTML specialist for formatting, or when the XHTML itself is created in a couple of varieties for appraisal and critique within the team:


GNNN___our_history.html …

In actual filenaming practice, strings like draft01 and draft02 are not always sufficiently informative. If there are five drafts, it can be useful to have the filename remind us which draft it was that emerged from Monday's brainstorming session with the commercial client over morning coffee, and which reflected, rather, some late-night Internet research, towards the end of the week, into the client's competitors. The need to keep the filenames informative is best met by using numerical timestamps. For details, the reader is referred to the second section of my companion essay, 'No-Frills GNU/Linux: Timekeeping, Timestamping, Timelogging'. Here it suffices to make the very quick remark that a time such as 23:52:05, in the normal civil time of Toronto, on 2005 October 13, is in the careful notation of the International Organization for Standardization (ISO) written 20051014T035205Z, and that an acceptable low-precision, date-only, variant on this timestamp is 20051014 or (depending on how pedantic we want to be on the difference between the closing hours or 2005 October 13 and the opening hours of 2005 October 14) 20051013. We can thus write our filenames as


or, if less precision is needed, as something like


4. Allowing a Degree of Untidiness in the Home Directory

We are all tempted to accumulate junk in our home directories. I will argue here, taking my own setup as a case study, that this temptation is not worth resisting.

At the present instant, that is to say the instant referred to by ISO timestamping conventions as 20051103T000730Z, the simple ls -1F command reveals an embarrassing 123 items in my home directory. (Here ls means 'List the files, including those files that are directories, beneath the current working directory, provided these files are not "hidden" in the sense of having names that start with a dot.' There are many "hidden" files of a utility character, such as the shell-configuration file .bashrc and the text-editor-configuration file .exrc. The incantation ls -1, with its numeral 1 rather than the more often used letter l, means all of what was just said, but with the further proviso '…and put that listing into a single column on the screen, not into two columns.' Finally, the incantation ls -1F means all of what was just said, including the proviso, but with the second proviso '…and display a slash after the name of any file that happens to be a directory.') Here are extracts from the 123-item list:


Inspection of those extracts reveals how home-directory jetsam tends to accumulate.

The file 05086revision1pt3.pdf is from a client project that saw me copyedit a little physics. In the course of the project, I received this file from the client as a workflow input. (In strict fact, I have changed the filename slightly to preserve client confidentiality, while keeping the overall filenaming style unaltered.) Does the presence of this item in the home directory mean that something has gone wrong? Not really. I actually keep 05086revision1pt3.pdf as an appropriately situated leaf on a tree rooted in my master clients-and-projects directory. Evidently, however, I found it useful to put a temporary copy of that file into my home directory for ease in viewing it with some such tool as (GNU/Linux) Adobe Acrobat or xpdf and then forgot to clean up.

The directory ANNN____maintenance is one of the Big Four already discussed. It is the repository for all aspects of maintenance, of course organized into a big tree of sub-directories, sub-sub-directories, sub-sub-sub-directories, and so on. So it, unlike 05086revision1pt3.pdf, is unreservedly welcome under the home directory.

The file David_Jimsson.letter.1 came from Heaven-knows-where. (Here again, I have altered the filename a little, to preserve someone's privacy, while keeping the essence of the filenaming style.) Coming from a trivial stream of correspondence, it lacks archival value. If David Jimson were someone I am helping with some grave problem, for instance if this David were someone I am counselling or in some other way supporting, he would count as a (perhaps non-paying) client, and his file would be in my client area, filed under the appropriate David Jimson project. As things actually stand, though, I must have obtained the file as an attachment to a trivial chit-chat e-mail, must have parked it in my home directory because I was processing the day's e-mail in a rush, must have taken some such simple action as sending a reply e-mail, and then must have forgotten to clean up.

The directory Desktop was not created by me at all but by some piece of GNU/Linux software. Consequently, I cannot safely delete it, and cannot even - at any rate, cannot without a troublesome investigation of the software configuration possibilities, by looking into the software manual - rename it. The directory is intended for a window manager or session manager that I do not normally invoke, but that I keep available as a standby resource. (Normally, I use the lean-and-mean FVWM window manager, which has its own configuration files, quite separate from this mildly unexpected Desktop area.)

The directories ENNN____library_of_public_docs_etc and GNNN____studies_private are the second and third of the Big Four, and so again are unreservedly welcome.

The printer-description file HP-PhotoSmart_P1215-hpijs.ppd is a further embarrassment. It belongs elsewhere, altogether outside the /home directory hierarchy, wherever a Debian GNU/Linux collection of printer-describing *.ppd files is supposed to reside. Since I got my HP PhotoSmart 1215 inkjet printer working with stable-branch Debian GNU/Linux 3.1 (the "Sarge" branch), and since the printer does not look for a *.ppd file in an end-user home directory, this item can be deleted without causing printing to fail. And yet I forgot to delete it.

The directory NNNN____clients, being the fourth of the Big Four, is again unreservedly welcome.

Although ZZNN____quasijunk_eg_informal_baks and ZZZX____utter_junk are not among the Big Four, they do have a certain importance and legitimacy. The former is supposed to sweep up stuff that might prove mildly useful some day and yet has through poor housekeeping accumulated in the home directory or in some other not-quite-appropriate place. The directory ZZZX____utter_junk is what its name says.

A moment ago, I remarked that David_Jimson.letter.1 and HP-PhotoSmart_P1215-hpijs.ppd should have been deleted. In fact, however, it might have been better to have moved then into one or the other of the two directories just mentioned. Deletion in GNU/Linux does not make it straightforwardly possible to get a file back again, and I might, just possibly, be wrong in my present assessment that there is never going to be any use for those Jimson and PhotoSmart materials.

The availability of ZZNN____quasijunk_eg_informal_baks and ZZZX____utter_junk suggests a reply to the critic of GNU/Linux who objects that here, in contrast with the Macintosh and Microsoft interfaces, a trashcan is lacking. The reply is that we can if we wish implement the rm, or "remove", command not as the dangerous ELF 32-bit executable /bin/rm but as a special user-crafted bash script or bash function, specifically as a wrapper for /bin/rm and /bin/mv, generating a user-friendly dialogue at the command-line prompt when the command rm is entered:

    "Remove" in what sense: 
    1. by moving it with /bin/mv into 
    2. by moving it with /bin/mv into 
    3. by deleting it irrevocably with /bin/rm?
    Please make your choice 
    by typing the appropriate numeral. 

Next, we have the files t*. I write 't' for 'temporary': these are all junk files, strictly needed only for a few seconds as I work on some bigger file. I do almost all my writing with a text editor rather than with one of those file-bloating "word processors" that keep appearing in GNU/Linux in imitation of the proprietary operating environments. I find the best text editor to be some member or other of the venerable vi family, since that family is lean and mean, and in addition is well documented. (I have the Hewlett-Packard vi book on my shelf and may some day add the O'Reilly offering, which I now find available in, dramatically enough, a sixth edition.) Working in such an editor, I often issue commands like :12-15w! ~/t for 'Please overwrite the current material in home-directory file t with the contents of lines 12 through 15' and :578r ~/t for 'Please read the current contents of home-directory file t into the file herewith being edited, making the insertion just after line 578.' This gives the effect of a Microsoft or Mac scratchpad. It then proves, of course, useful enough to have multiple scratchpads, in a workflow in which one sometimes says not :12-15w! ~/t but :12-15w! ~/tt or even (for a delicate situation which I guess involves the copying-and-pasting of some lines of text referring specifically to choice of "central lambda", in other words of mid-spectrogram wavelength) :12-15w! ~/t__lambda_central.

Finally, we have win2000Pro.cfg, as a trace of my work performed with Microsoft tools. The mission requirements of a certain paying client induced me some years ago to create a Microsoft area within my GNU/Linux desktop, as a a VMWare virtual machine, and in that area to boot up Win2000 Professional in tandem with Microsoft Word for one project, and in other projects to use the Microsoft-based book-indexing package CINDEX. The various Microsoft-formatted client inputs and client deliverables I archived not in the VMWare virtual-disk file but in the canonically prescribed clients-and-projects area within Debian GNU/Linux.

How worked worked up should we get by such an accumulation of junk? I answer: Not very. If we wish to list our Big Four directories, so as to recall their exact names, and in the same process to list other useful directories such as the Two-Graveyards-from-the-Land-of-ZZ, we can use appropriate wildcarding. Secure in the knowledge that we have put ____ into the filenames of the Big Four and the ZZ Two, and that few or no junk files have such names, we throw the -1 and -d switches on a wildcarded ls invocation, as follows:

  $ls -1d *____*

(The second of these two switches means 'Please list only directory names of the form *____*, i.e., please refrain from listing the contents of such directories.')

What is happening with directories CNNN____tools_apparatus_etc and ZYNN____dotfile_baks on my workstation? We have not pondered these so far, and yet they look rather important!

Important they are, in the former case for me personally, in the latter case probably for anyone. The directory CNNN____tools_apparatus_etc mirrors my own particular physical circumstances, reflecting the fact that in my cramped living quarters, I have not only clothes and books but even boxes, containing such things as electronic measuring equipment and lenses. Not too many readers of this essay will be in my precise poverty-stricken situation. Nevertheless, I explain, since the explanation provides an opportunity to make, or rather to recapitulate, a big point, of interest to most readers. The point is that to keep track not only of computer files but of storage boxes and (what is for most people, including me, mission-critical) cardboard filing folders, one can integrate pointers to real physical objects with the ordinary files on the workstation. I do this in a manner I have sketched in what is logically a predecessor of this essay, namely in the final section, 'No-Frills GNU/Linux in the Noosphere: Details from a Debian Implementation', of my long 'No-Frills GNU/Linux: Philosophical Foundations'. But for emphasis, I now recapitulate the points made there with the fresh example of CNNN____tools_apparatus_etc.

Inspection of this directory reveals the following:

  $cd *tools*apparat*
  $ls -1

The *.txt files are presently zero-byte files, created with commands such as touch CNNN____maths_and_drafting_and_drawing_inventory.txt and serving as reminders of the places into which it may some day be desirable to put a detailed inventory of my physical possessions, in plain ASCII.

The four zero-byte files CNNT____maths_and_drafting_and_drawing__CARTON, NNNT____electromag_and_electronics__CARTON, PNNT____optics__CARTON, and RNNT____chemistry__CARTON, on the other hand, correspond to four big cardboard boxes, known in the stationery trade as 'Banker's Boxes', in which I keep such things as my graduated chemistry-lab cylinder, my digital multimeter, and a couple of cheap lenses with associated optical-bench mounts. The boxes (or three of them, at any rate; I keep goofing up in small ways) are correspondingly labelled in black ink, with wildcard asterisks to reduce the burden of label-writing and label-reading. In particular, the lowest of the labelled boxes, and therefore the one hardest to retrieve from the metre-high stack, is labelled RNNT____*chemistry*.

By keeping track of physical things in this way, I have only to look at my workstation to find a canonical name for the physical item I seek to retrieve for the day's task, and on the strength of that canonical name to figure out where in the hopelessly overstuffed room to reach for the item. Since the chemistry materials come at the end of the filename listing, I can see that the box with the graduated glass cylinder is at or near the bottom of my stack of boxes. Consequently, in the unlikely event that upcoming Observatory gardening, say, obliges me to pack my transport bag with a vessel for measuring five millilitres of fluid, I can put my hands rather quickly on the specific box that has the desired glassware, scanning the workstation and reading just one paper label rather than straining, from an awkward position, to read many such labels.

Why, it may be asked, put chemistry last, by selecting the filename prefix RNNN in place of, say, BNNN? In my particular technical-scientific-intellectual circumstances, chemistry is of marginal importance, in contrast with the rather central topics of optics and electronics. Given my circumstances (other people will be in a different position), it is therefore rational for me (a) to make its directory name come at the very bottom of the ls -1 column and (b) to minimize physical-manipulation time by having its corresponding cardboard box sit below the more-likely-to-be-opened optics and electronics boxes.

My method of keeping track of physical items is only a mild convenience in the case of a one-metre stack of Banker's Boxes. However, the method comes in very handy indeed for keeping track of a continually proliferating stock of cardboard filing folders. The latter point I develop at length in the 'No-Frills GNU/Linux in the Noosphere: Details from a Debian Implementation' section of my companion essay 'No-Frills GNU/Linux: Philosophical Foundations'.

So much, then, for CNNN____tools_apparatus_etc. The directory ZYNN____dotfile_baks is more quickly disposed of. Here I keep, and in some rather similar place many readers may want to keep, timestamped backup copies of such "hidden" files as .bashrc. It is useful, for instance, to take a timestamped backup of .bashrc before editing (such edits happen often, as one keeps adding or retiring aliases or functions, to reflect the changing dictates of one's workflow), and from time to time to sweep up the backups into ZYNN____dotfile_baks:

  $cd *dotfile*bak*
  $ls -a .bashrc*

5. Organizing the Maintenance Area

5.0 The Maintenance Area:
Snapshot of the Top Level

Here is a quick, in fact an eleven-second, tour of the top level in my maintenance area:

  $cd *maintenance*
  $ls -1

5.1 The Maintenance Area:
Policy Document on Filing Rules

The directory AANN____maintenance_policies_etc is the right place to put a policy document on filing rules, such as was as mentioned at the end of Section 2 above. The time has now come to reproduce most of my own version of this document.

My particular document-of-rules (filenamed, for no profound reason, NNNN____guiding_policies.txt) is rather ancient, dating from 2001. That was the year I sat down and analyzed the problem of filing. I put enough effort into composing NNNN____guiding_policies.txt to make it more or less unnecessary to refer to that file over the next four years. The act of writing, in other words, forced me to think, and indeed forced me to think hard enough to be ram the resulting concepts into longer-term memory.

I would urge my readers not to take this NNNN____guiding_policies.txt as a set of rules to be followed mechanically in their own workstation operations. Rather, it is to be taken as illustrative material, as an example of the general kind of private rule-making that private circumstances may conceivably dictate.

I present my document here directly in its raw point-and-subpoint-and-subsubpoint plain-ASCII formatting, but with a very small number of deletions marked ((SNIP)):

  __basic principles of office layout:
    * L-shaped desk, 
      + hard-docs arm for reading and writing paper docs 
        (_in {t.karmo} actual practice includes 24 over-desk 
        __hard-docs arm includes areas 
          - for both papermail-as-yet-unopened, 
            and papers-as-yet-unfiled
            (_in {t.karmo} actual practice, 
              these are 2 of the 24 over-desk pigeonholes) 
          - for folders pulled-and-not-refiled
            (_in {t.karmo} actual practice, 
              these are some of the remaining over-desk pigeonholes) 
      + soft-docs arm with PC workstation 
        for reading and writing digital docs
  __basic principles for soft files: 
    * soft files are kept under some type of Unix
  __basic principles for hard files (folders, books, floppies, CDs): 
    * all hard files which happen to be collections of loose
      (_folders of paper, boxes of papers...; but not books 
        or binders)
      are entered in the workstation, 
      with a directory name ending in the string ____HARDCOPY 
      __this directory is never the TOP directory for a single matter
        __so, for instance, if client foo has project
          and that project so far generated paper files without
          digital files, instead of creating the directory
          we create the directory
          and UNDER it put some such thing as
        + this helps 
          make it clear at filing time whether to start a new folder
          (box, ... ) or, on the contrary, use an existing folder or box 
          __it is not necessary to go pawing through the shelves
            before taking the decision
        + the workstation can be programmed to list
          all the *HARDCOPY directories, 
          thus generating a full shelflist
        + it becomes easy to see to where        
          the digital files are supplemented with hardcopy files 
        + if a matter starts out being paper-only, and later 
          in its evolution  
          generates some digital files,
          a clear audit trail is kept of what is paper, 
          what is digital, 
          with everything bundled tidily into a directory
          that is neutral as between paper and digital
          __in terms of the example above, 
            parent directory              
            is neutral, being capable of having under it
            directories which refer to hardcopy materials AND directories
            which refer to digital materials
    * no attempt is made 
      (_yikes: we live dangerously)
      to allow for possible transfer
      of files from North America to other continents, 
      even though 
      + outside North America A4 supplants 8.5"-by-11"
      + Library of Congress classifications 
        (_used heavily in this formalization: see below) 
        may be exotic on continents other than North America
    * no legal-length filing folders are tolerated
      (_all folders are for 8.5"x11" papers)
      (_recall that record-management professionals in North America
        now deprecate USA legal-length folders)  
    * hard files 
      (_even books, floppies, CDs) are kept as far as possible
      in ((SNIP)) stackable filing crates
      (_available in Toronto from ((SNIP))  ) 
      (_stackable in principle from floor to ceiling) 
      stacked with bottom to wall, 
      with long side horizontal, 
      (_i.e., with short side vertical, 
        i.e., with box in landscape-not-portrait orientation, 
        i.e., with filing folders vertical) 
      with male connectors on crate pointing to floor
      and female connectors on crate pointing to ceiling
      (_mnemonic: "Use missionary position") 
      with each filing-folder tab 
      meant to be read by a person standing to the left
      of the tab, and with the reader's eye moving
      (_that ensures that if filing folder were to be placed with bottom
        parallel to floor and long side parallel to line of sight 
        (_i.e., with the plane of each filing folder perpendicular
          to the line of sight) 
        then file tabs would appear as in a standard file-cabinet
      (_mnemonic: "Stand on the left of the tab and read down") 
      with the sort-order-early files to the left of the sort-order-late
      (_that ensures that if filing folder were to be placed with bottom
        against floor 
        then file tabs would be
        as in a standard file-cabinet drawer) 
      (_mnemonic: "As you stand on the left, 
        you see the sort-order-early files earliest") 
    * those hard files which consist of filing folders
      are marked thus: 
      + on tab official markings, 
        and no official markings anywhere else,
        the tab containing 
        exactly two lines, as per following examples: 
        - ((__EXAMPLE))
          QB51.3 I 72/Anderson IRAF scripts
          __Library of Congress numbers
            are used to track public documents 
        - ((__EXAMPLE))
          QB981 P424 Peebles Cosomology/comprehension
          __Library of Congress numbers
            are used to track private studies 
        - ((__EXAMPLE))
          __ISO CCYYMMDDThhmmssZ timestamps are used
            to track client projects
              is "Project Train the Staffer ((SNIP))", 
              started 2000-08-25 at 01:02:03 UTC
        - ((__EXAMPLE))
            is one big task in the ast425h coursework, 
            started 1998-09-01 at 20:13:07 UTC--namely, that task which
            is the 1999 February seminar presentation 
      + elsewhere any convenient markings, 
        to have mere unofficial standing
        (_for example: pencil annotation at bottom of folder, 
          to facilitate putting the folder into pigeonholes
          over hard-copy desk when folder has been taken
          out of official filing and has thereby
          become  a folder-in-use) 
    * shelf organization of hard files imitates as far as possible
      the hard-drive-directory organization of soft files
    * ((SNIP))
  __basic conceptual organization 
    for both hard and soft files
    reflects workflow from basic maintenance to 
    assembling a library of public docs to studying the library
    to using the acquired knowledge to service a set of clients 
    (_the four-letter identifiers "ANNN", "ENNN", etc in what follows
      are useful for imposing a clear sort order in Unix directory
      listings, but have no deeper conceptual significance): 
    * ~/ANNN____maintenance
      __hard files include equipment manuals, 
      __soft files include software-tool development files  
        (_for instance, files needed to create
          small Unix sysadmin scripts in bash or perl) 
      __soft files include timelogs, appointments diaries, 
        private financial bookkeeping
        (_but not, e.g., wordprocessing of income-tax letters
          __income tax is a matter for a client, 
            in Canada the Canada Customs and Revenue Agency
            __concept of a client is discussed below) 
      __colloquially in paper filing "~/*maintenance*"
    * ~/ENNN____library_of_public_docs_etc
      __colloquially in paper filing "~/*public_docs*"
      __Library of Congress numbers subdivide this area
    * ~/GNNN____studies_private
      __colloquially in paper filing "~/*studies_private*"
      __Library of Congress numbers
        subdivide this area 
    * ~/NNNN____clients
      __formal studies, 
        e.g., at Toronto University of
        would go here, 
        Toronto University of being a client
      __Canada Govt of Canada Customs and Revenue Agency 
        filings would go here, 
        the government agency being a client
      __colloquially in paper filing "~/*clients*"
      __this area is subdivided alphabetically 
        __so that 
          + Toronto University of is in the t subarea
          + Canada Govt of Canada Customs and Revenue Agency
            is in the c subarea
  __whatever other languages may be used in filing, 
    English is always visible and governing
    (_even when work is being done for, e.g., 
      some Estonian client) 
    (_since English is universally read, 
      this ensures that file ordering will be universally intelligible) 
  __basic organization of mirroring on other hosts
    __where foo is the original version of
      some directory or ordinary file
      on some host, 
      * roo_20010822T013422ZMIRROR 
        is its mirror at 20010822T013422Z
        __we do not require that foo and roo be the same name
          __we normally name mirrors in the style
            UNNN____veritas_MIRROR, i.e., by using the U????____
            portion of canonical namespace
        __we always end a mirror name with MIRROR
            a mirror is a quite special file
          __we do not END the mirror name with the timestamp  
              we wish to distinguish mirrors from mere timestamped
      * roo_MIRROR is its mirror if we elect not to make a formal
        record of the time of the mirroring
    __if in the original dir foo contains file bar, har, 
      then it is permissible on a mirroring host
      to create foo_20010822T013422ZMIRROR or foo_MIRROR
      and then to put under foo files bar and har, 
      or even bar without har

5.2 The Maintenance Area:
Tool Development

Our tour of the top level of ANNN____maintenance continues with the directory AENN____tool_development. Here are kept the working files for the development of "tools", essentially just Perl and bash scripts for the workstation. Once a tool foo, typically an executable, is ready to go into production, it might well be filed as ~/bin/foo. However, I for my part file it as ~/ANNN____maintenance/ENNN____bin/foo, having some years ago added to my ~/.bashrc the line


to make things like foo work as command-line invocations.

5.3 The Maintenance Area:

The directory CNNN____headers_etc, that is to say ~/ANNN____maintenance/CNNN____headers_etc, has skeletons for various types of files. The three most important subdirectories of CNNN____headers_etc are ANNN____general_ascii and ANNN____general_html and AZNN____general_tex. Of these three, the two coded html (for Web work) and tex (for the TeX typesetting system) are not interesting enough to be examined here. Of the approximately half-dozen files in ANNN____general_ascii, just one, namely AANN____allpurpose_doc.txt, is worth examining. This file furnishes a time-saving template for an elaborate plain-ASCII essay, such as the occasional analytical report prepared for some pro-bono or commercial client.

Here is that file in its entirety, with the exception of a couple of excisions, marked ((SNIP)), made for reasons of security:

  __Toomas (Tom) Karmo = {t.karmo} 
  __253 College Street, Box 189, Toronto M5T 1R5
    __backup (mirroring) server = ((
  __definitive archived version 
    is in /home/verbum/NNNN____clients tree    
    of {t.karmo} Debian GNU/Linux workstation 
    presently at ((SNIP)) Street, Toronto M5T ((SNIP))
  * CCYYMMDDThhmmssZ/version0001.0000
                        = END OF DOCUMENT = 

The heading DOCUMENT-IN-A-NUTSHELL: is (as the colon suggests) intended to start a single line of text, describing the file in the tersest possible terms. Here is a hypothetical example: operating manual for 0.6 m scope. The no-colon heading DOCUMENT DESCRIPTION, on the other hand, introduces a description extending over several lines, in a typical case formatted in point-and-subpoint-and-subsubpoint style. Here is a hypothetical example:

  __general manual for end user of 0.6 m scope
    (_the one in the central dome, main building, ((SNIP)) Obs)
    (_not an engineering manual 
      __there IS apparently some ancient engineering documentation
        on the shelves in ((SNIP))'s room) 
    __to be kept in hardcopy in warmroom 
    __to be uploaded to Departmental server, ((SNIP)) pages
    __incorporates what material from the 1980s manual is still relevant

Concerning the other files in ~/ANNN____maintenance/CNNN____headers_etc, I will here make only the remark that I have such a dull thing as PNNN____baggage_label_etc.txt. That file does not prove useful now, but is perhaps destined to be revisited in some currently unimaginable future contingency calling for repeated intercity flights.

5.4 The Maintenance Area:
Addresses, Commitments, Bibliographies, and Factoids

In the directory ~/ANNN____maintenance/NNNN____addresslists_etc resides my supremely important NNNN____coordinates_etc.txt. That is a general address book, or more accurately a repository not only for postal addresses and courier particulars but also for e-mail addresses, phone numbers, and similar bits of communications-support information, relevant to every aspect of daily work and recreation.

It goes almost, but not quite, without saying that I abstain from viewing the contents of the general address book with such a clumsy command-line incantation as

  less ~/ANNN____maintenance/NNNN____addres

(For convenient Web display, I break that incantation, and similar incantations later in this essay, into separate lines here, placing the artificial line break in such a way as to cleave a token.) I instead have a pair of aliases, defined in ~/.bashrc. When, as happens several times during a normal working day, I find it necessary to view the address file, I issue the command coo, as shorthand for the one-line command just displayed in line-broken formatting. When, as happens several times during a normal working week, I find it necessary to edit the address file, I issue the command coow (the w is for 'write'), as shorthand for

  vi ~/ANNN____maintenance/NNNN____addres

Here is a representative extract from the file, showing just two of its very roughly one thousand entries:

  __for Richmond Hill (DDO gardening etc)
  __van avail
    __also 905-415-9191
    __also 905-472-1010
    __all thee nrs were current 2004-05-16

This example helps in two ways to bring out the merits of a plain-ASCII, no-frills approach to the maintenance of an address book. First, it shows how one can insert any kind of information in just about any convenient order, without worrying about logical structures. In some cases, as in the first of the two entries shown here, one finds oneself recording not one URL but two, with the second serving as a comment or footnote on the first. In other cases, as in the second of the two entries shown here, one finds oneself recording not one phone number but a whole string of numbers, with a comment, and in addition putting in a comment (separate from the comment on phone numbers) on what the organization in question is useful for. (In the particular case shown, the comment serves as a reminder that Advance & Unique offers van transport in addition to conventional taxi and that this particular business is therefore worth considering when transporting some awkward load, such as bedding plants from a nursery vendor, to the David Dunlap Observatory.) In still other cases (not illustrated here) one may, having made an entry for the name of an organization, then find it necessary to append a long list of all the people known by name in that organization, adding for some entries in the list point-and-subpoint comments with such things as birthday dates.

A second merit of the plain-ASCII approach is that plain ASCII allows one to perform retrievals in the address book through simple text searches, with powerful and well-documented Unix tools. In practice, I hardly ever end up performing more than a simple text-string search within the less display that is launched by the command-line invocation coo. Still, the doors remain open for Perl scripts or for command-line incantations along the lines of grep foo *barfile*.txt | grep roo.

I write here 'hardly ever' rather than 'never'. The one point in my personal annual round of duties at which I do find a fancy retrieval appropriate comes in November or December, when NNNN____coordinates_etc.txt has to be mined for a list of Christmas-card recipients. At this point, my tactic is to use a little Perl. Individuals getting cards have NNNN____coordinates_etc.txt entries resembling the following (here I change many details to preserve privacy):

  23 Larkwhistle Road 
  Heaton Moor, Stockport
  Cheshire SK4 4QF UK  
    __current 2002-12 
  children Pattie, Abe 

I pull out details for these individuals with a short, crude Perl script,, in ~/ANNN____maintenance/ENNN___bin:

  #!/usr/bin/perl -w
  $we_are_on_a_relevant_line = 0; 
  while (defined($line=<STDIN>)) {
    if ($line =~ "BEGIN PAPERMAIL XMAS") {
        $we_are_on_a_relevant_line = 1;
    if ($line =~ "END PAPERMAIL XMAS") {
        $we_are_on_a_relevant_line = 0;
    if ($we_are_on_a_relevant_line > 0) {
       if($line =~ "BEGIN PAPERMAIL XMAS") {
           print "....................................\n";
       } else {
           print "$line";

Here is a recipe for using the script: (1) Invoke a vi editor on NNNN____coordinates_etc.txt, from any working directory, by issuing the command coow. (2) Within that vi session, take a temporary copy of NNNN____coordinates_etc.txt by issuing the editor command :w! ~/t. (3) Go to the directory housing the script, run the script, and print out the address list, as follows:

  AANN____maintenance_policies_etc/  NNNN____addresslists_etc/
  AENN____tool_development/          RNNN____journals_etc/
  $cd *bin
  $ls *xmas**
  $./*xmas* < ~/t > ~/tt
  $lpr ~/tt

(Here, I should add, I have used another ~/.bashrc alias, created by putting into ~/.bashrc the line alias maint='cd /home/verbum/ANNN____maintenance; ls -F'.) The result of this minute's work is a not-too-elegant pile of printed paper, with entries such as

  23 Larkwhistle Road
  Heaton Moor, Stockport
  Cheshire SK4 4QF UK

I then cut with scissors along the dotted lines and apply my crude mailing labels to envelopes with sticky tape.

This setup I have used since at least Christmas of 2003, and none of my approximately sixty Christmas-card recipients has complained so far. It's probably not worth the trouble of refining it, but of course refinements, for instance to yield printout on fully professional adhesive labels, are feasible.

Some people resort to relational databases, with a cosmetic front-end to a query language such as SQL, for keeping their private address lists. I have already argued against such an approach in my companion essay 'No-Frills GNU/Linux: Philosophical Foundations'.

Some might contend, even while embracing plain ASCII as a format, that address lists are best kept in a personal digital assistant (PDA). To this contention I reply that PDAs are really useful only to those people who are constantly travelling, most notably to those people who are often absent overnight from the workstation. It is true that one is liable to acquire names, phone numbers, e-mail addresses, and URLs throughout the working day, including those parts of it that are spent away from the workstation, for instance in meetings. But since I, like many or most people, am often present at my workstation during the day, and am only infrequently away from it for more than 24 hours, I have developed a system, which I now explain, involving fewer risks than are created by a PDA.

My system involves keeping on hand a generous supply of blank business-card stock. This material is readily procured even in a very small city, let alone in a megalopolis like Toronto, from jobbing printers who make up business cards. At the start of each new day, I take two fresh cards, writing a timestamped identifier with ballpoint ink in a squashed circle in the upper left-hand corners of each of the four markable surfaces, in the style '20051103 (THU) a', '20051103 (THU) b', '20051103 (THU) c', '20051103 (THU) *'. The first surface becomes the place to keep running notes, for instance from conversations and newspaper reading, from the morning of the day. The second and third surfaces ('b' and 'c') are used for the same purpose, but for the afternoon and evening, respectively. The fourth surface ('*') serves as an overflow area, for the rare occasions on which the three surfaces just mentioned prove too cramped. As a variant, for occasions on which the day is prolonged with a midnight-to-daybreak working shift, I write '20051103 (THU) d' in place of '20051103 (THU) *'. The two cards go into a dedicated breast-pocket cardholder, in flexible plastic, bought as a "pocket protector" at a small-city stationer's.

As the day unfolds, I accumulate minor scraps of information, in each case making a concise and semi-cryptic notation in black mechanical pencil on the card. That notation is itself demarcated in black mechanical pencil with some convenient closed curve, typically a squashed circle. So (to take a purely hypothetical example) if in the afternoon of 2005 November 3 I meet a Dr Jane Doe with e-mail address, I write this information in black pencil, in some cryptically terse way, onto the '20051103 (THU) b' surface and circle it.

Later, typically at the start of the next working day, I review my black-pencil annotations, sitting at my workstation with an erasable blue pencil in my hand. (When I last went shopping for coloured pencils, I found a good Toronto art supply dealer stocking the very item already recommended by a good book on the editing of books, namely the 'Col-Erase' wooden pencil. I have found a set comprising the three colours marketed by the Col-Erase people as 'Indigo Blue', 'Tuscan Red', and 'Grass Green' to be adequate for all my various branches of technical work, including time-logging, book editing, and mathematics study. If I were shopping today, though, I would start by considering not wooden pencils but mechanical pencil leads, initially searching with the quotation-marked Google string "erasable color refill leads".) My aim is now to "discharge" or "dispose of" each circled black-pencil item, either (this rarely happens) deciding to forget about the item or (this usually happens) deciding to make some kind of entry somewhere in the workstation. Thus, for instance, on the morning of 2005 November 4, I see from my cryptically terse note that I met Dr Jane Doe the previous afternoon, and recollect (even though the note may not say this) why the meeting was important, and accordingly I create a new coordinate-file entry with my ~/.bashrc-defined coow command:

     __address current 2005-11-03
  __met 2005-11-03 in rG office
    __said she has colleague in amateur radio astron
      __said she can introduce us in 2006

Upon discharging the circled item, I fill its circle in with blue pencil, applying strokes heavy enough to colour the area in and yet light enough to leave the black-pencil markings readable. When the entire '20051103 (THU) b' surface has all its circled black-pencil entries coloured blue, I apply blue pencil also to the circled ballpoint-ink annotation '20051103 (THU) b', thereby marking the entire surface as "discharged". When all four surfaces are in this sense "discharged", I put the cards into a chronologically ordered depository of fully discharged cards, going back many years, for retrieval if necessary. (In practice, retrieval from that depository only seems to happen when I find I have made some recent mistake in card management, and so have to inspect the not-quite-properly-discharged card from, as it were, last Friday.)

Now it is time to make a first remark about the harvesting of information from one's environment. Although much can no doubt be said about the harvesting of information from such complex natural surroundings as a forest, I will confine myself here to the common case in which we are moving around in a print-rich, voice-rich, image-rich townscape. This time, in contrast with my fictitious "Jane Doe" scenario, I will give a real-life example.

In walking through a nursery on 2004 April 24, I observed some interesting plant labels. Extracting the appropriate card and the appropriate black mechanical pencil from my breast pocket, I first made some telegraphically condensed notes, then put a circle around what I had written. Later, quite possibly on the morning of the following day, I transferred that information, with appropriate clarifications and amplifications, to the workstation (into a special file that we have not yet examined, but will examine), again using blue pencil to colour in, or "discharge", the circled material:

  __perennials observed at South Hill Shopping Centre 2004-04-24:
    __at Loblaws:
      * Coreopsis grandiflora
        __June-October, 18 inches, yellow
      * Dianthus deltoides[sp?], colloq maiden pinks
        __June-September, 8 inches

The cry will again be raised: 'But surely a PDA would be more pleasant, more effective, less Luddite!' To this I reply that PDA time overheads have to be taken into account. The act of writing information into a PDA takes longer than the act of scribbling with black mechanical pencil onto a simple card, and is therefore likely to prove a little too troublesome in an intellectual emergency, as when one unexpectedly notices something important on a vendor's labels in a market.

The discharging of the four surfaces on a pair of cards is, admittedly, itself troublesome. Particularly is this the case in my own setup, since I use my four cards even for timelogging, in a system - I nowadays refer to it as the 'Comprehensive Time Allocation Formalism', or 'CTAF', and speak to myself of such things as 'CTAF cards' - described briefly in the companion essay 'No-Frills GNU/Linux: Timekeeping, Timestamping, Timelogging'. A PDA, however, is troublesome in different ways. Information has to be transferred even from it into the workstation, ideally in a daily docking operation, if the information-harvesting and information-processing systems are to remain effective. In particular, frequent docking is needed to keep the PDA safely backed up.

The essential point here is one that calls to mind the obvious, and yet all too seldom articulated, argument against city motoring. When all the overheads are taken into account, owning a motorcar in Toronto is unlikely to save much time or trouble over a system of frequent three-kilometre walks, frequent five-kilometre Toronto Transit Commission rides, and a roughly monthly short-or-long urgent taxi ride. With both PDA and motorcar, the accounting has to be done systematically: there are the many hours spent in shopping for the vehicle; there are the many hours spent in discussions with vehicle mechanics, insurance brokers, and other maintenance or regulatory personnel; there is the time spent in earning the money to pay on the one hand for the vehicle, on the other hand for its fuel, lubricants, antifreeze, accessory hardware, insurance, and parking; and finally there are the many hours spent in selling the vehicle when its inevitable decommissioning commences. Moreover, even the kind of ruthless accounting just proposed is incomplete, because it externalizes major burdens both on the social environment (consumer electronics, whether in a PDA or in a motorcar, get assembled these days in virtual slave-labour conditions) and on the biosphere (even a PDA, although small, consumes fossil fuels, for instance - first in its fabrication, then in its ten-thousand-kilometre journey from the poor-country sweatshop to the rich-country retailer).

Also implemented as leaves in the tree rooted at ~/ANNN____maintenance/NNNN____addresslists_etc are plain-ASCII files for bibliographies ("resource lists") and small, self-contained factoids. To speed up the storage and retrieval of this information, I use ~/.bahsrc to set up a big set of aliases, corresponding to Library of Congress subject-classification codes. I'll render ideas concrete here by focusing on politics (for which the Library of Congress uses the code 'J'), with the background comment that I keep bibliography and factoid files on just about everything, covering the whole gamut from philosophy-psychology-religion (Library of Congress code 'B') to military affairs ('U') and librarianship ('Z').

For politics, then, I created a year or two ago, as a leaf on the tree rooted at ~/ANNN____maintenance/NNNN____addresslists_etc, a file ENNN____resources_etc__J.txt. This file I bring up on the screen instantly when necessary, in a vi-family editor, through the ~/.bashrc alias resJ. Here is an excerpt:

  computing and society, analysts of
    __announced in 2004 to be founding institute in Oxford
  __complete writings
  peace analysts
  __see also Gandhi
    __reported by BBC 2004-03-08
    __reported by BBC 2004-03-08

A look at what goes above and what goes below the single (____), as opposed to the less interesting double (====), lines reveals the governing idea. I track URLs, books, mass-media articles, and the like in a formalism based on back-of-the-book indexing. That formalism is expounded reliably in several places, of which it is here appropriate to mention firstly two items from the Chicago University Press, namely Nancy C. Mulvany's Indexing Books (1994) and the how-to-index-a-book chapter in the current (fifteenth, i.e., 2003) edition of The Chicago Manual of Style, and secondly the classic, if dated, Indexing, The Art of, by the dean of twentieth-century British indexing, erstwhile barrister G. Norman Knight. Book-indexing formalism uses a main subject heading and if necessary a subheading or even a sub-subheading. Much of the art of indexing consists in pulling material together in fruitful ways, synthesizing concepts. (The materials being read and indexed perhaps nowhere refer to 'computing and society, analysts of', in those exact words, and yet that is what they are, in all their diverse terminologies, discussing.) In an effort to establish fruitful conceptual connections, cross-references are made rather liberally to main headings with 'See' and 'See also', and on rare occasions obliquely even to subheadings or sub-subheadings with 'See under' and 'See also under'.

Also present as a leaf on the tree rooted at ~/ANNN____maintenance/NNNN____addresslists_etc is a second 'J', or 'politics', file, PNNN____facts_etc__J.txt housing factoids as opposed to resource pointers, and brought up on the screen in a vi-family editor through the ~/.bashrc alias faJ. Here is an excerpt:

  Blair, Tony
  __relationship with Bush, George W.
  __{Richard.Heinberg} _The Party's Over: Oil, War, and the Fate
    of Industrial Societies_ 
    (_Gabriola Island, BC: New Society Publishers, 2003)
    writes on p. 197 that he allegedly, reputedly
    ((QUOTE))regards George W. Bush personally as little
    more than a buffoon ((/QUOTE)) 
    __supporting evidence offered: Blair's telling the
      anecdote in which Mr Bush says the French have no word in
      their language for "entrepreneur"
  copyright, intellectual property, and related issues
  __embroiled in court work re patent on breast-cancer gene: 
    corporation called Myriad
    (_source: Watson book on DNA
      __noted 2005-08-04) 
  Egypt repressions
  __speaker Newman Centre (Jesuit) 2003-10-26: 
    * ((SNIP)) Decree of ((SNIP)) 

As for politics, so too for all the other subjects in the general map of knowledge. Thus, for instance, because the Library of Congress code for agriculture is 'S', the factoid about Coreopsis grandiflora mentioned above gets entered through the vi-invoking command faS.

Everyone is a generalist over much of the map of knowledge and a specialist in a few parts. In my own case, I do not find it useful to subdivide 'S' into such subdomains as agriculture, horticulture, and silviculture. I do, on the other hand, find it advisable to subdivide 'Q', or 'science'. Instead of setting up a simple pair of ~/.bashrc aliases faQ and resQ, I have such things as faQA (since it is 'QA' that is the general Library of Congress code for mathematics) and resQC (since it is 'QC' that is the general Library of Congress code for physics). A worker who is more ruthlessly specialized in mathematics than I am might descend still further into Library of Congress minutiae, going just as far as is needed to minimize the file bloat that puts a brake on storage and retrieval efforts. Such a worker might, for instance, recall that QA403 and QA551 are what get used in the Library of Congress, and therefore in most major North American academic libraries, as the codes for Fourier methods and analytical geometry, respectively, and might therefore go so far as to use faQA403 and faQA551. This hypothetical worker could then reserve faQA for pesky mathematical factoids in, say, topology, that do not belong in either of the two specialized repositories invoked by faQA403 and faQA551.

Admittedly, the Library of Congress system is tedious for classifying computer materials. The system was devised generations ago, in a decades-long process of introduction at the Library from at least 1898 onward. (Details on its history, and on library formalisms generally, can be had from Lois Mai Chan's Cataloguing and Classification, available in at least a second, 1994, edition from McGraw-Hill.) With the advent of computers after World War II, the maintaining authorities at the Library put computer science essentially under QA. I say 'essentially' because, distressingly enough, dull engineering topics such as the mechanics of an ink-jet printer are required to go instead under the technology heading 'T'. We thus now have intricate Library of Congress codes like QA76, for the general topic of programming languages, and more specifically codes of the form QA76.Jmm and QA76.Smm and QA76.Snn (where 'mm' and 'nn' are numerals) for languages such as Java, Scheme, and SQL, and in addition some 'T' codes. Fed up with these intricacies, I myself cut the Gordian knot, giving my workstation a special ~/.bashrc alias faQx. Upon typing faQx at the command-line prompt, one launches a vi-family edit of a file from which the following is a representative extract:

  attributes of files, how to change in Linux
  __man chattr
  backup strategies
  __rsync is helpful
    __for remote updating
    __man rsync
    __said at TLUG 20040713 to be useful with rdiff
  __rcs gives discipline in maintaining config files
    __formal checkin, checkout, revision history
  __useful to take tar file of /etc
  BIOS, how to access
  How you access the BIOS (or ``CMOS'') configuration menu depends
  on who
  wrote your BIOS software:
  Delete key during the POST (power on self test)
  Award BIOS

One might well imagine pure-mathematics specialists likewise cutting certain Gordian knots by creating more or less ingenious Congress-classification-straddlers as supplements to their generally Congress-kosher schemes. The following is a conceivable example: faQAcounter might be dedicated to counterexamples refuting overhasty generalizations, be they in vector analysis, in linear algebra, in topology, or indeed in any subdiscipline of mathematics. It would be in that spot that one would record, for example, the failure, for the case of a punctured disk, of the usual equality-of-partial-derivatives test for 'Am I, as a vector field, somebody's gradient?'

It might well be asked whether there is something better than the 1898-vintage Library of Congress formalism, something more in accord with modern conceptions in computer science. Shiyali Ramamrita Ranganathan (1892-1972) promulgated his "colon classification" scheme, a form of "faceted classification", from 1933 onward, as a radical alternative to the reigning orthodoxies, including the Library of Congress headings and the more modest Dewey Decimal System. Ranganathan is discussed as man and theoretician at; faceted classification is demonstrated in a computer-science setting at; and the practical importance of Ranganathan's ideas is underscored by their emerging use within the Debian Project (the Google string debtags yields up-to-the-minute references) for the "tagging" of software packages, in a technology that seeks to expedite the ordinary GNU/Linux end-user's ever-so-important task of software discovery. However, my suspicion is that as far as the filing of bibliographies and factoids goes, filing really meticulously, in the spirit of faceted classification, is more trouble than it is worth, since one then ceases to talk the current language of the very literature, namely the big-campus reference-library classification manuals and their various Web mirrorings (for instance, perhaps, at, that one needs to be prepared to consult if a hard classification question arises.

It might also be asked whether there is an overarching conceptual blemish in the proposed scheme, amounting to an unwarranted stretching of the notion of maintenance. Is it really so clear that bibliography and factoid files need to be leaves in the tree rooted at ~/ANNN____maintenance? Some people might instead expect them to be leaves in the tree rooted at ~/GNNN____studies_private. Some might even expect them to be leaves rooted in a tree having no leaves in common with either of the trees just mentioned, perhaps asking us to increase the Big Four to a Big Five by creating something like ~/DNNN____resources_and_factoids.

In response to these lines of criticism, it is necessary to show, in a three-part argument, that the keeping of bibliography and factoid lists is indeed a maintenance task.

(a) We are liable, even if infrequently, to accumulate resource pointers and factoids when we are preparing to augment our set of public documents. The examples already given contain, in particular, a pointer to some downloadable writings by Gandhi, which might come in handy later in putting Gandhi's selected works into the tree rooted at ~/ENNN____library_of_public_docs_etc.

(b) We very frequently accumulate resource pointers and factoids when preparing for formal study. Factoids, as they are thought of here, are mere tidbits, not long slabs, of information. It is therefore not too much of a strain to say that they serve merely to orient us as we prepare for the deeper processes of reading and reflection recorded in leaves of the tree rooted at ~/GNNN____studies_private. In the extract from PNNN____facts_etc__J.txt presented above, there appears an amusing gossip-factoid relating to Mr Tony Blair. It is not too much of a strain to call this a mere casual note, and to insist on a division of labour: this note is mere preparation for studying the politics of the north Atlantic alliance, a mere clearing of the desk and sharpening of the pencil; if, on the other hand, one's accumulated information about Mr Blair amounts to more than a casual twenty or so words, one has moved from getting-ready-to-study mode into actual study mode and should no longer be using the simple, lightweight faJ.

(c) The resource pointers and factoids we accumulate when serving clients fall into three different categories. First there are the pointers and factoids that may be useful for many purposes, not restricted to the particular client whose matter is now in hand. Perhaps Client X's current matter leads us to take a few hasty notes on the Foucault knife-edge test in mirror optics, without studying the topic properly. That information is liable to be useful outside the domain of Client X, say for Client Y, or for one's eventual careful private study of mirror-grinding, or even for one's own system-maintenance purposes. In such a situation, we reach for something like the simple, lightweight, faQC (assuming that we are using Library of Congress code 'QC' for physics, and that we have not found it necessary to confer a special status on optics as a subdiscipline of physics). Second come the pointers and factoids arising from genuine private study, as when one realizes that one is out of one's intellectual depth in working with Client X, and accordingly puts Client X aside for some hours (in my case, this would involve stopping the Client X time-tracking in my CTAF) to engage in emergency private study. Notes from this work are properly kept not with the lightweight faQC, and not in the Client X files, but in the tree rooted at ~/GNNN____studies_private. Third come the pointers and factoids that relate indisputably and uniquely to Client X, with little real possibility of ever being useful for another client. (There may be, for instance, scraps of information proprietary to the client, perhaps even protected by a formal non-disclosure agreement.) Such items are properly deposited in the Client-X portion of tree rooted at ~/NNNN____clients. That choice of depository is in part a matter of safeguarding Client X: we must ensure that if some other person is granted access to the workstation contents, the proprietary Client X matters are safely segregated in one tightly defined ~/NNNN____clients subtree, ready for deletion (or encryption) through rm -Rf (or whatever) performed on a single directory, where that directory is readily located and client-specific.

A final point remains to be made about bibliographies and factoids. Since the filing of information is fraught both with inherent uncertainties and with adventitious human error, it makes sense, as I will explain at some length now, to keep all bibliography and factoid files in one (rather big) directory.

A few months ago, I was asked to help judge a high-school science competition. The students were designing a space station, required by competition rules to house a largely self-sufficient population of (if I remember correctly) ten thousand people. A good part of my work, I decided, must consist in looking with a skeptical eye at the students' proffered cardboard or plastic models, asking the exhibiting team in each case whether there was sufficient solar-panel area to give each inhabitant a reasonable kilowatt of electric power. Another part of my work, I decided, must consist in analyzing nutrition. It was in the course of that latter analysis necessary to refer to the "carrying capacity" of land.

I already had at contest time some notion of the amount of land needed to "carry", i.e., to prevent from starving, a human being, but I see now in retrospect that my notions were a little vague and indeed that I was a little too harsh with some of the poor contestants. (For the most part - there was one impressive exception - the competing teams, being citified, of course underestimated the amount of agricultural acreage needed to feed a human. When you think about the requirements carefully, you begin to wonder if a self-sustaining space station could be created at all. But what I'm saying here is that I was a bit too harsh, probably intimating in my judge's comments, contrary to actual agronomical fact, that a single human being needs something on the order of a half hectare.)

Now, I stress, the Ontario high-school culture being as conservative as it is, this is the type of scenario that may well play itself out again in, say, 2015 or 2025. Our planet will be still more deeply in the grip of climate change than it is now (with warmed cropsoils and warmed tundras by then releasing their own hefty quotas of greenhouse gases, even apart from the smokestacks of an industrial sector by then increasingly tempted to substitute coal for hard-to-procure petroleum), North America and Europe will teeter still more precariously on the cusp of grid collapse, and yet Ontario pupils will be be no less eager then than their parents proved in 2005 - nay, than their great-grandparents must have proved in 1965 - -to build cardboard models of big hypothetical space stations. So, I confidently predict, in some way or other, perhaps in 2015 or 2025, I will again have to think, quite possibly on my feet in public, by now grey-haired and prone to fatigue, and quite possibly in front of lots of pupils, about carrying capacity, and the next time it happens I will have to be better prepared. Since that contest, I've been taking my carrying-capacity notes rather seriously.

The point of all this? Although I can certainly remember now, in 2005, that my carrying-capacity factoids are to be retrieved with Library-of-Congress 'S'-for-agriculture faS rather than with 'QH'-for-biology faQH, I may not recall the requisite retrieval tactic so easily in 2025. But, happily, with all my factoid files, for whatever branch of knowledge, shepherded into one single directory, I can cd to that directory and grep everything in one fell swoop.

Here is a simple grep swoop (with no switch thrown except for -i, 'ignore case'):

$grep -i "carrying capacity" *txt
PNNN____facts_etc__S.txt:carrying capacity

Here is a more elaborate swoop, with a grep"windowing" or "context-sizing" switch thrown also, so as to reveal an initial segment of my carrying-capacity notes:

$grep -i --after-context=30 "carrying capacity" *.txt
PNNN____facts_etc__S.txt:carrying capacity
PNNN____facts_etc__S.txt-__with world population at 5.5 bn,
there were 0.28 ha of arable
PNNN____facts_etc__S.txt-  land per capita
PNNN____facts_etc__S.txt-  __but 0.5 ha per capita is needed for
a varied diet
PNNN____facts_etc__S.txt-    read @20040113T042449Z
PNNN____facts_etc__S.txt-    __that's reprint of article 
PNNN____facts_etc__S.txt-      "The Tightening Conflict:
Population, Energy Use,
PNNN____facts_etc__S.txt-      and the Ecology of Agriculture"
PNNN____facts_etc__S.txt-      by Mario Giampietro and David
PNNN____facts_etc__S.txt-  Five acres can only support one
person for a year
PNNN____facts_etc__S.txt-  if it is used as beef pasture, but it
can support a dozen
PNNN____facts_etc__S.txt-  people if it is
PNNN____facts_etc__S.txt-  used for wheat, and thirty five if it
is used for soya
PNNN____facts_etc__S.txt-  beans.[cxciii]
PNNN____facts_etc__S.txt-  ((/QUOTE)) 
PNNN____facts_etc__S.txt-  __from {Marc.Widdowson} book
available at 
PNNN____facts_etc__S.txt-    __read 20040328T015402Z
PNNN____facts_etc__S.txt-__book on organic gardening, read in
PNNN____facts_etc__S.txt-  says 2400 calories/day 
PNNN____facts_etc__S.txt-  (_sufficient for 1 person)
PNNN____facts_etc__S.txt-  can be had from following
PNNN____facts_etc__S.txt-  * pinto beans 5.5 x 10^3 sq ft
PNNN____facts_etc__S.txt-  * hard red spring wheat 5.8 x 10^3 sq
PNNN____facts_etc__S.txt-  * irish potatoes 1.6 x 10^3 sq ft
PNNN____facts_etc__S.txt-  @="20050730T031807Z"))

Yes, I know, I know: since I am now keeping so much information on carrying capacity, it is starting to look as though I ought to create some dedicated carrying_capacity__statistics.txt leaf on the tree rooted at ~/GNNN____studies_private/S_______agriculture. If and when I perform that necessary housekeeping, bringing practice into strict conformity with preaching on, hypothetically, 2007 February 1, say around the time of Ontario midwinter sunset, I'll have a simple pointer under resS, roughly in the style

  carrying capacity
  __of farmland, for largely vegan humans
  __workstation veritas, 
    one or more private-notes files as leaves in tree rooted
    at /home/verbum/GNNN____studies_private/S_______agriculture
    __this arrangement in effect from 20070201T223000Zapprox
      __veritas used to have just a factoid-file entry under 'S'
        __but then the notes became so bulky
          that I decided I was in reality embarking
          on a programme of substantive study  
          (_was no longer doing mere study-prep factoid-recording 
            __study-prep is deemed mere maint) 

Next in our tour of the top level of ANNN____maintenance comes the directory RNNN____journals_etc. This is the place in which are kept such things as the appointments diary, the daily tasklists, the financial journals (including business ledgers), and such light-hearted things as one's discursive kewl-stuff-on-this-day diary.

I have kept my own appointments diary in its present digital form since 2000 December 11, and I retain it all on line. At the moment, early in 2005 November, there are 1207 entries for the past and 13 entries for the future. Retention of long-past entries is useful, since one then has an answer ready when associates pose such questions as this: 'Was it you who was on the telescope on the problematic 2002 December 22 second-half-night, or were you at that point already in the train for your normal December journey from Toronto to Nova Scotia?'

As it is a mistake to use a relational-database solution for keeping one's address book, so also is it a mistake to use special software for keeping an appointments diary. Plain ASCII minimizes corruption risk and maintenance time. In my own setup, the relevant file is brought up in the xterm session with a pair of ~/.bashrc aliases, namely com ('Please invoke the less pager on the list-of-commitments file') and comw ('Please write, with a vi-family text editor, into the list-of-commitments file').

Here is an illustrative extract from my particular appointments file, showing a medical appointment, two telescope nights, a daytime meeting with a faculty member, and some activity with local theologians. In this extract, 'TO' is standard local jargon for 'Telescope Operator'; 'Regis Coll' is private shorthand for 'Regis College'; and 'rG', 'Kmo', and 'Tn' are standard personnel identifiers at the David Dunlap Observatory. To maintain confidentiality, I have applied ((SNIP)) edits to the actual file in a couple of places:

  2004-01-14 (WED) 09:00 ((SNIP)) consultation NB!!  
  2004-01-16 (FRI) DDO Kmo 1st half night, Kmo 2nd half (TO=Tn) 
  2004-01-17 (SAT) DDO Kmo 1st half night, Kmo 2nd half (TO=Tn) 
  2004-01-26 (MON) 14:00 rG NB!!!!
  2004-01-28 (WED) 13:30 ((SNIP)), Regis Coll NB!!!

Those dull day-by-day documents which are my daily tasklists I pull up in a vi-family editor, from any working directory, with the ~/.bashrc-defined alias ta. In addition, I take a timestamped backup, using a ~/.bashrc-defined alias bta, just before starting a new tasklist, and keep the old tasklists on disk. It has been said that whereas ordinary people have memoranda such as 'Pick up the dry cleaning and don't forget that Marcie's piano lesson is early tonight,' people from New York have glamorous, mysterious memoranda, for instance 'Gucci and Armani sign jointly at 11:00 latte.' Since I, for my part, do not presently live in New York, there is little point in my reproducing a daily tasklist here. I will, however, remark that my own (dull) tasklists contain not only notes about the dry cleaning but also miscellaneous ephemeral scraps and jottings, of the kind one sometimes makes upon hearing a complicated voice message on the answering machine. Of these jottings, some serve as seeds for more serious note-taking elsewhere in the workstation, and it is prudent to preserve them all in the bowels of a cumulative tasklist archive.

Concerning financial journals, I will here say only that I keep ledgers in plain ASCII, and that if (as is unlikely) I were to move to a higher level of commercial engagement, I would first consider automating the bookkeeping with Perl scripts. If the bookkeeping were to become very intricate, it might prove necessary to run Microsoft-based accounting software in a VMWare virtual machine within the Linux desktop, creating the Microsoft-readable accounting files inside a Microsoft window-of-Windows but archiving them as leaves in the tree rooted at


Concerning the kewl-stuff-of-the-day diary, I make two remarks. (1) Being no Pepys, and seldom living through anything as dramatic as the Great Fire of London, I write at most a few paragraphs a month. (2) Pepys could use the formalism presented here. Possible filenames for his operation might be ye_totally_kewle_diary__16670101_to_16670131.txt, ye_totally_kewle_diary__16670201_to_16670228.txt, ye_totally_kewle_diary__16670301_to_16670331.txt, and the like. Being, for good or ill, one of the more formidable efficiency experts ever to roam British Civil Service corridors, he would favour plain ASCII over more elaborate data formats and would use a combination of Perl and grep for easy information retrievals.

5.5 The Maintenance Area:
Facilities and Projects

We end this long tour of the top level of ANNN____maintenance with the directory SNNN____facilities_and_projects, for which subdirectories are arranged as in a dictionary or phone book:

  AANN____maintenance_policies_etc/  NNNN____addresslists_etc/
  AENN____tool_development/          RNNN____journals_etc/
  $cd *fac*
  $ls -F
  a/  c/  e/  g/  i/  k/  m/  o/  q/  s/  u/  w/  y/
  b/  d/  f/  h/  j/  l/  n/  p/  r/  t/  v/  x/  z/

It suffices to examine just three of those twenty-six subdirectories. First, we look at c:

  $ls -1F
  $cd *ritas
  $ls -1F
  $cd *ron
  $ls -1F

It can be seen from this terminal session that my particular computing-maintenance area contains materials relating to the maintenance of two machines, prudentia and veritas. It is veritas that is my main workstation. Drilling further down in the "computing, specifically veritas" area, we find firstly files relating to a period from 1996 June 1 onward, in which the RedHat Linux or Mandrake Linux veritas was physically realized on such hardware as the AMD-K6 CPU, and secondly files relating to the period from 2000 December 1 onward, in which veritas (first as Mandrake Linux, then as Debian GNU/Linux) was put onto an ASUS motherboard housing an Intel Celeron CPU. Drilling still further down in the "computing, specifically veritas, more specifically Celeron" area, we see still further directories. These include the all-important NNNN____maintenance_logs_etc/, used for storing the running log of veritas Celeron-era problems, veritas Celeron-era conundrums, and veritas Celeron-era fixes.

It can happen that we share a machine foo with some other person. In this case, it makes sense to set up a special user account, say maintainer, for maintaining foo qua foo. It is in the facilities-and-projects area of that account, rather than of any end user, that will be kept (somewhere under c-for-computing) the foo machine-incident log. Into the facilities-and-projects of one's personal foo account, somewhere under c, will go, rather, computing issues relating to one's personal foo operations (as when one installs some executable privately, in a private bin area rather than in /bin, /sbin, /usr/bin, /usr/sbin, /usr/local/bin, or /usr/local/sbin). Similarly for other parts of the maintainer maintenance area, outside the facilities-and-projects domain: the end-user Pat B. Citizen who has to look after foo will develop tools intended for all foo end users in some tree rooted at something like

rather than in a tree rooted at

It goes almost, but not quite, without saying that the superuser (root) account should not itself be used for developing a tool or composing a machine-incident writeup, being reserved instead for such solemn tasks as our daily security-patrolling chkrootkit and our daily (Debian) package-updating aptitude upgrade.

Taking as a second example ~/ANNN____maintenance/SNNN____facilities_and_projects/e, I simulate a search for the manual accompanying my present solar-powered wristwatch:

  $ls -1F
  $cd electron*not*comm*
  $ls -1F
  $cd *casio*
  $ls -1F

The simulation reveals that there are three directories under my particular e directory and that it is the third of these that is relevant in the search. (Had we been looking instead for documentation accompanying a certain electric space heater in my room, we would have gone to the first of the three. Had we been looking for documentation on equipment broadly relevant to ham radio, we would have gone to the second.) Within that relevant directory, we find no digital manual, but do eventually find a human-friendly pointer (a zero-byte file with an informative title) to a cardboard filing folder on the shelves of the workstation room. Since the folders are arranged in a way parallel to the arrangement of files in the workstation, we know that that cardboard folder is housed in the 'maintenance' stretch of shelving (as distinct from the 'public documents', 'private studies', and 'client' stretches), and we moreover see that cardboard folder to be somewhere in the 'e' part of the 'facilities and projects' stretch.

Taking as a third example ~/ANNN____maintenance/SNNN____facilities_and_projects/t, I simulate a search for a baggage-list archive, thereby anticipating a situation that is likely to come up next June (in 2006), half a year from now. I predict that in that June I shall be recalling my 2005 June journey to the University of Toronto ("Hart House") ham-radio Field Day events and shall be wondering how to pack baggage, seeking to negotiate in haste the intricacies of mosquito repellent, clipboard, lab book, duffel bag, army boots, and the like pretty much as I (successfully) negotiated them in 2005. The search, then, is likely to go something like this:

  $ls -1F
  $cd tra*
  $ls -1F
  $cd *radio*

My suspicion now, in the waning weeks of 2005, is that I shall be creating some such file as baggage__hart_house_farm_20060624.txt, cloning much of baggage__hart_house_farm_20050625.txt and keeping both files in the already-existing directory 20050625T130000Z__radio__hart_house_farm. That directory is to be thought of as the storage bin for travel plans, baggage lists, and the like, for a whole sequence of similar journeys, the first of which started on a Saturday, namely on 2005 June 25 at 09:00 EDT, i.e., at 13:00 Universal Coordinated Time; the second of which is anticipated for the corresponding Saturday in 2006, namely 2006 June 24; and the third of which might conceivably be anticipated for the corresponding Saturday in 2007, namely 2007 June 23.

6. Organizing the Public-Documents Archive

Public documents (for instance, downloadable PDFs of books and essays) are rather easy to organize. At the higher levels, it is easy to imitate the shelf arrangement at the Library of Congress. At the lower levels, one uses whatever method of organization is most convenient (for instance, a simple imposition of sort-order-enforcing four-letter prefixes). Here is a tour of the relevant part of my main workstation:

  $ls -1F
  $cd Q*
  $ls -1F
  $cd *astron*
  $ls -1F
  $cd *telesco*
  $ls -1F
  $cd *muirden*

We see from the tour that because on this particular machine there is a lot of material under the Library of Congress 'Q', or 'science', heading, it makes sense to proceed downward for quite some time in the Library of Congress formalism before making filenames less disciplined, in other words before relaxing into ad-hoc filenames in the style UNNN____.

It must be admitted that the Library of Congress system does display its unhappily pre-computer, indeed vintage-1898, origins in the use of codes without a fixed number of characters: the Library has 'Q1' for astronomy journals, but 'Q51.3' for imaging systems such as the National Optical Astronomy Observatories "IRAF" software and QB88 for telescopes. To overcome the resulting awkwardness in directory listings, I tend to violate strict Library rules by adding zeroes for padding.

In the simulated search shown here, it turns out that the workstation room does have some kind of published document on telescopes, from an amateur-level book by Muirden. Further digging in the course of the terminal session shows that Muirden is present not as a digital file on the workstation but merely as some photocopied sheets in a cardboard folder within the "private studies, Q, QB, QB88" stretch of shelving.

7. Organizing the Private-Studies Area

The private-studies area is similar in its arrangement to the repository of published documents, as the following terminal session shows:

  $cd *stud*
  $ls -1F
  $cd Q*
  $ls -1F
  $cd QH*
  $ls -1F
  $cd *intro*
  $ls -1F
  $cd *min
  $ls -1F

Here we find pretty much the same directory layout as for the public documents. I do notice, however, a special backup directory for private-study notes on physics. (I notice it to my mild surprise, on composing this present essay: normally I fly in and out via a ~/.bashrc-defined alias without bothering to inspect filenames.) Evidently I found it prudent around lunch time on 2002 May 30 to take a copy of old physics notes, as a preliminary to making some more or less sweeping revisions of the physics-notes directory. Further, we see that the private-studies directory Q_______science contains a biology subdirectory, in contrast with the public-documents Q_______science. I read only a little biology, and evidently I have not yet come across such a thing as an absolutely-must-retain biology-PDF publication.

Finally, we find in this private-studies Q_______science the rather important TNNN____running_log_for_studying__QA_QB_QC_QD.txt, a general incident log for intermittent studies in maths, astronomy, physics, and chemistry, from which the following is an excerpt:

  @=20050520T195400Z____SEVERITY=85%__LC=QC518__DSCRP="leaky capacit"
  __found to my surprise 
    that leaky capacitor
    (_this is a Sears example) 
    cannot be represented as C, R in series
    and also cannot be represented as C, R in parallel
  Papers filed canonically: studies in Sears electr-and-magn book  
  __instructive difficulty in working thru 
    Carroll-Ostlie proof that radially symmetric
    mass distribution produces the gravitational field
    of a point mass 
    (_~/*studies*/*QB461.C35.1996*compr*chap02* p. 036@0.6)
    __had to evaluate
      $\Int -(R^2 + r^2 - 2Rr \cos\theta)^{-3/2} 
              \cos\theta \sin\theta \mathrm{d}\theta$
      __despaired of getting antiderivative, 
        and then found that Ca-Os used substitution
        $u = R^2 + r^2 - 2Rr\cos\theta$
        __the idea is that we then get 
          a tidy expression for $\cos\theta$
          and thereby get a tidy expression for 
        __for the first time that I can recall,
          I encounter a situation in which 
          the "u-substitution" is really USEFUL
          (_normally, I think of the "u-substitution"
            as a formally dressing-up of work that
            could be done by directly invoking the Chain Rule 
            and writing the requisite antiderivative immediately) 
  __on examining SaHi discussion of reparametrization of
    line integral path (SaHi p. 1018), 
    once again worked out, and found that I had in at least
    two previous years worked out, a rationale for u-substitution
    which does not oblige us to((SNIP))

In this log of (elementary) struggles and joys, I assign a timestamp by running an appropriate bash script within the vi editing session, then assign a severity level ('99%' would correspond to something apocalyptic, say a result so deep as to call for a reworking of my longer-term plans), then classify the event according to its approximate place in the Library of Congress formalism. It can be seen that where mathematics is needed, I tend to write it up with $\foo \bar \roo \har$-style LaTeX typesetting codes. The reference to 'canonical filing' of papers from the incident of 20050520T195400Z indicates that the papers are in a cardboard folder, assigned a spot in the hard-copy shelving corresponding to the location in the workstation of a descriptively named zero-byte file, with that file itself duly realized as a leaf on the tree rooted at


Paper notes from private studies, incidentally, I tend to categorize either as "comprehension" (as when I am simply reading some textbook) or as "exercises" (as when I am working some of a textbook author's end-of-chapter numerical problems with pencil and calculator). A reading of the old-but-insightful sophomore electromagnetism text by Sears, page 12, at a point 70% of the way down the page, in an attack on some nasty little obscurity that I commenced at 20041209T1344Z, is liable to generate black-pencil mathematics - here I imagine the fourth sheet in a hypothetical stack - headed in ink as

  *QC760*sears*chap01*compr*                p. 012@0.7::04

A working of Exercise 13 in Sears's Chapter 9, where the working started at 20050113T1455Z, is liable to generate black-pencil mathematics - here I imagine the second sheet in a hypothetical stack - headed in ink as

  *QC760*seas*chapter09*exerc*               #09.13::02

The advantage of this formalism that one can easily keep straight on the one hand a comprehension worry encountered 70% of the way through page 12, on the other hand a comprehension worry encountered elsewhere on that same page, say 40% of the way through. Further, one can easily keep straight on the one hand the second sheet from one's 20050113T1455Z efforts on a tricky exercise and the second sheet from one's (more successful?) efforts six months later:

  *QC760*seas*chapter09*exerc*               #09.13::02

Any of these careful pencil notes could in principle get a precise cross-reference, right down to the level of the individual cardboard-filing-folder sheet, in the workstation. However, I for my part seem to find it sufficient when typing up a workstation reference to say, in very nonspecific language, that my relevant sheets are "canonically filed".

A necessary part of studying is timelogging. In general, a good question to ask oneself is: What multiple or fraction of 200 hours have I now invested? If one spends 200 desk hours on a topic, one has done the equivalent of a thorough one-semester university course. Here, then, is a part of a timelog, specifically a leaf from the tree rooted at /GNNN____studies_private/Q_______science, for a review of second- or first-year electromagnetism:

  20050817=02h14->072h55__pondered ammeter-as-voltmeter, etc
  20050818=04h03->076h58__pondered motor-generator-emf, etc
  20050823=01h01->077h59__had trouble with justifcn 
                          of Kirchhoff's loop rule
  20050824=01h00->078h59__Kirchhoff now okay
                          __devised new language for branches:
                            "electrical power imported-exported", 
                            "electrical power consumed", 
                            "electrical power produced" 

In the previous section, I argued the case for putting casual notes, that is to say mere twenty-word factoids, into files in the maintenance area and then invoking such files in a rough-and-ready way with ~/.bashrc-defined aliases in the style faQC. What, by contrast, do serious study notes look like? My present formalism goes back several years and now needs an overhaul: although I constructed it on the strength of some studies in SGML, it really should be redone in the machine-streamlined idiom of the SGML turn-of-the-millennium progeny XML. Nevertheless, it is useful to present an extract here, complete with that part of the file that documents the formalism:

  consolidated personal reading list 
  of Tom Karmo = {tkarmo} 
  __rather experimental 
  __readers are encouraged to use this reading list
    as a basis for their OWN experiments in 
    workstation bibliography management, 
    and to communicate their suggestions to {tkarmo} 
    __{tkarmo} communications particulars: 
      __<> is deprecated e-mail address
      __<> is preferred e-mail address 
  __format is SGML (hand-coded) 
    __it may later be possible to develop an SGML 
      DTD (Document Type Definition) 
      on the strength of this hand-coding experiment 
      __the DTD will define various points so far left
        __most notably, for each tag "FOO", whether
          a record has to have 
          * exactly one FOO, or 
          * zero-or-one FOO,  or 
          * zero-or-more FOOs 
      __with a DTD developed, Linux sgmls can be run 
        to check that this SGML document is DTD-compliant
        __we thereby have formal machinery for detecting 
          certain kinds of data-entry errors
      __but it would be better to find someone 
        in the astronomical community who has already developed
        an SGML DTD for a consolidated personal reading list 
    __it may later be possible to develop Perl scripts 
      which will do some automatic processing of this SGML document
      __example_a: retrieve from the document all and only the entries 
        which relate to the topic HD21699, and display 
        just the author names, titles, journals, and years 
        for those entries, suppressing other information 
      __example_b: convert this whole bloody document into some
        quite different flat-ASCII format, 
        if a really good flat-ASCII format for
        personal reading lists turns out to exist 
        __it is possible that some astronomy student, on some
          campus somewhere, has gone through this exercise already, 
          and has invented a much superior flat-ASCII format, 
          perhaps even coded in some formalism other than SGML 
  __reading list was started 19990709
  __reading list initially related to {rgarrison}{tkarmo}
    collaboration on HD21699
    __but it was intended 
      to have reading list grow to include many other topics
  __reading list is sorted in forward order by year of publication, 
    and is sorted in forward alphabetical order by author surname
    within any one given year  
  __{tkarmo} has consulted briefly on this reading-list format
    with librarian Marlene Cummmins = {mcummins} at Dept of Astron,
    University of Toronto 
  <!-- Here is a template for creating new records: 
    <CONF SESSION=>xxxx</CONF>
  __revision history of this template: 
    * 20030428T204200Z/version 0000.5010 
      __replaced DATEREC with
    * 199?????T??????Z/version 0000.5000 prelim version
  __in this template, "AUDIENCE_DATEREC" is used 
    to indicate 
    * the time at which a colloquium or lecture or broadcast 
      was scheduled to start
      (_even if the start was delayed or the notetaker arrived late) 
    * the time at which the notetaker downloaded Web content  
    __had a lecture been scheduled for 2003 March 02 at 13:10:00 
      Eastern Standard Time, 
      then its time would be entered as 20030302T181000Z
      __note timestamping convention, with all times stated to 
        the second, and referred to "Z" (UTC = Universal Coordinated
        Time): CCYYMMDDThhmmssZ 
        __this convention is prescribed by ISO in Geneva 
        __Linux boxes can be readily configured to generate 
          timestamps which conform to this convention 
  __in this template, "URL" is used only for very special situations
    __for example, for a publication which is available 
      by anonymous ftp from some server, and is NOT in print
  __in this template, "VENUE" is used only for very special situations
      * colloquia
      * conference presentations
  __in this template, A
  __in this template, the role of "COMMENT01", . . . , "COMMENT04"
    is not yet very sharply defined 
    __{tkarmo} has to think about 
      comments over the coming months and years, 
      not developing fully sharp comment concepts too quickly 
  __in this template, "NOTES" is intended for free-form comments 
    __"NOTES" is the place for storing substantive scientific
      __for instance, the information that HD21699 is 
        not radio-bright at 6 cm 
      __with a good author, "NOTES" might store a great deal 
        of information 
      __"NOTES" is useful for guiding one's overall study programme 
      __"NOTES" may be expected to evolve rather radically as one
        makes the transition from BSc to MSc to PhD, etc, etc, etc
        __ :-)  
  __in this template, <TOPIC> means, essentially, "keyword"
    __the following use of "SUBTOPIC" is legal: 
      <TOPIC>HD21699<SUBTOPIC>Zeeman effect</SUBTOPIC></TOPIC>
  __in this template, "LIBRARY" is intended as a place to store
    library call numbers
    __keeping that kind of information on line can save time
      in certain special cases 
      __it is not ALWAYS obvious where in the library system 
        an ink-and-paper artifact resides 
    __"LIBRARY" is only supposed to be used in unusual situations
      __common sense and street smarts are ENTIRELY sufficient
        to let one locate items like ApJ and PASP 
  __in this template, "DATEREC" stores the timestamp of the last
    major modification to the given record 
    __a record started @19991223T235900Z, modified in a major way
      @20010430T131345Z, and trivially modified 
      @20010501T123004Z, should be timestamped 20010430T131345Z
  <!-- Here are templates for creating new cross-refs:
  The document should have first all the records, 
  then all the "see" cross-refs,
  then all the "see also" cross-refs.
    <AUTHOR01>Struve, Otto</AUTHOR01>
      A Test of Thermodynamic Equilibrium in the Atmospheres
      of Early-Type Stars
    __following indicates two concepts of great importance
      (the He anomaly, dilution) to {tk}'s overall study problem 
      The intensities of He I lines show variations which are
      contrary to Boltzmann's formula [fn of tempr], and Rudnick
      has shown that this effect cannot be explained by turbulence.
      It is suggested that the He anomaly results from an accumulation
      of atoms in the triplet system, the lowest term of which is
      metastable. Such an accumulation is possible if there are
      departures from thermodynamic equilibrium, e.g., if the 
      photospheric radiation is appreciably diluted in the 
      absorbing atmosphere. Departures of this nature are not
      improbable in the giants of early type. 
      __{tk} did NOT understand 19991215T035200Z
    <TOPIC>He anomaly </TOPIC>
    <AUTHOR01>Helfand, Prof. David</AUTHOR01>
    <LECTURE>Cosmic Frontiers: Celebrating a Century
      of Astronomy at the Univ of Toronto [2nd in series]
    <VENUE>U of Toronto, Convocation Hall</VENUE> 
    <TITLE>Way too cool: tales of
     stellar corpses</TITLE>
    <COMMENT01>I must remember that lecturer is the
    greying portly ex-actor from Columbia Univ</COMMENT01>
    __central point was as follows:
      __there is no deep reason for thinking that quarks
        are fundamental particles 
      __to study quarks further, we seek to find them
      __theories of neutron-star composition 
        are confronted with observation by 
        observations that indicate the TEMPERATURE
        of neutron stars
      __there is so far one successful such confrontation, 
        and it has deep theoretical implications, 
        precisely in yielding UNCONFINED quarks
        (_contrary to orthodox theoretical expectation) 
      __the confrontation is via the one neutron star in our galaxy  
        known to be still younger than the M1 object, 
        namely a neutron star from a supernova observed 
        in Japan, China, Korea in 1181 A.D. August 
        __temperature is inferred from fact that at min light
          (_rotation rate is 17 rev per second) 
          we do NOT see the stellar spot
        __if neutron star is merely macroscopic atomic nucleus, 
          with quarks fully confined, we expect tempr 1.8 x 10e6 K
        __but our observation means that tempr is 
          less than 1x10e6 K 
          (_and so, since luminosity goes as 4th power of tempr, 
            is only 1/15 as luminous as expected) 
        __explanation: here we do NOT have a macroscopic nucleus, 
          with quarks fully confined, but have an object in which
          quarks were LIBERATED, with consequent radiating away
          of more energy than a macroscopic nucleus could
          radiate away 
          [_lecturer's phrase: "started to melt neutrons into quarks"]
       [_lecturer showed plots, one of which he called the
         "standard model", and stressed that his data point
         does not lie on that plot, and remarked further that
         a survey is now seeking to find OTHER such neutron stars, 
         so that more than ONE observed data plot can be used to 
         confront theory with observation 
         (_the survey uses radio to find new supernova remnants, 
           and on THAT basis to aim the X-ray scopes) 
    __peripheral factoids useful to me are as follows: 
      __whereas nature has 50 octaves of e.m. radiation, 
        our eyes see 1 octave
        (_our ears hear 10 octaves of sound) 
      __98% of stars avoid supernova deaths 
      __lowest-luminos stars have 1e10-4 solar luminos
      __lifetime of 100 solar-mass star is 3x10e6 y 
      __think of solar nucleosynthesis as having THREE steps:
        *a____H + H -> He of mass 2 
        *b____He of mass 2  + H -> He of mass 3
        *c____He of mass 3 + He of mass 3 -> 
                     He of mass 4 + H + H 
      __He ignition will occur when solar core reaches
        tmpr of 100x10e6 K   
      __star with supernova death collapses in 0.5 s
        (_from size of Earth to size of Toronto) 
        (_typical spin-up: from 1 rev/day to 100 rev/s) 
      __at Palomar 5 m eyepiece, one can waggle one's finger
        at central M1 star and SEE strobe effect
        [_lecturer said to me after that this is ((SNIP))   
          though ((SNIP))] 
      __when stars form in a metal-enriched cloud, 
        the heavier elements do NOT preferentially seek
        the centre of the aggregate, as they did when Earth formed
        __reason [I don't understand this] is that 
          in star we have plasma, not liquid or conventional gas
      __the scoop on solar neutrino deficit is this: 
        observed flux was 1/3 of expected, but theory survived
        the observation when the profs showed
        that neutrinos come in three
        interconverting sorts, of which only ONE sort was observed
        __neutrino flux is in fact a very GOOD test of our 
          theories of solar core tempr, 
          now confirming those theories
    <TOPIC>neutron stars</TOPIC>
    <TOPIC>degenerate matter</TOPIC>
    <TOPIC>quarks: unconfined, in neutron stars</TOPIC>
    <TOPIC>X-ray astronomy: surveys</TOPIC>
  <!-- here starts 2006 -->
  <!-- here starts 2007 -->
  <!-- here starts 2008 -->
  <!-- "SEE" CROSS-REFS --> 
    speckle interferometry
    interferometry, speckle
  <!-- "SEE ALSO" CROSS-REFS --> 
    photometry, synthetic
  <! ----------------------------------------------------------------------->
  <!                            --END--                                     > 
  <! ----------------------------------------------------------------------->

The file from which this extract comes is in fact housed not on my own workstation but on a workstation-cum-server under my administration on campus. However, directories on that workstation are laid out in the same way as directories on my main workstation. The reason for my pairing a workstation with a workstation-cum-server is not of particular interest in the present context.

One further remark must be made about private-study notes. The formalism offered here is the formalism I refer to in my 2002 essay 'Indexing Tomorrow's Web-Delivered World Wide Library'. I should now repeat my twofold plea for help, in connection with an vision for so-called 'IndiciaScientia' software, from that essay. (1) It would be good for some open-source programmers to craft an XML-based tool, say the "IndiciaScientia client", for end users. The tool would prompt users for the content that gets enclosed by <AUTHOR01>, <TITLE>, <TOPIC>, and the various other markup tags, so that users do not themselves have to waste time in tagging. (We may note here that Debian GNU/Linux, perhaps especially since the 2005 June rollout of version 3.1, "Sarge", is emerging as a robust XML development platform.) (2) It would be good for some open-source programmers to work with international authorities, for instance with the International Astronomical Union or the Council of Biology Editors, to set up a system of XML-aware "IndiciaScientia servers", as a first step toward the amassing of a controlled vocabulary for the indexing of tomorrow's Web-delivered World Wide Library. The client software, deployed in hundreds or thousands of individual faculty offices around the world for each academic discipline, would periodically transmit <TOPIC>-tagged information from the individual workstations to the central servers, in a workflow I describe at greater length in my 2002 essay.

From this examination of serious-study-notes concepts one draws the moral that on some (rare) occasions, formatting more elaborate than plain ASCII actually does have a role to play. Why not just use free-form ASCII, here as for the address list and appointments book? We would then lose out on the possible communal benefits of IndiciaScientia.

8. Organizing the Client Area

Here is a tour of the top level of my client-service area:

    $cd *client*
    $ls -F
    a/  c/  e/  g/  i/  k/  m/  o/  q/  s/  u/   virz/  w/  y/
    b/  d/  f/  h/  j/  l/  n/  p/  r/  t/  va/  visa/  x/  z/

Clients are organized alphabetically. Since client files are numerous and bulky (those very occasional clients who are commercial, for instance, are liable to send me bulky project-specific PDFs), some attention has to be given to archiving. My method is to keep each of the child directories of ~/NNNN____clients rather small. I start out with one directory for each letter of the English alphabet but am ready to make splits (as has actually happened here with v) when the output from an archiving command such as tar -cf v.tar v would be an uncomfortably inflated tarball.

I cannot take a random illustration of the organization of client files on my main workstation since so much here is confidential. Choosing judiciously, I start by displaying a terminal session involving a client and a "project" (one could also say, as lawyers, do, a "matter") of a quite straightforward kind, free of confidentiality restrictions even in its most minute details:

  $cd *clien*
  $cd p
  $ls -1F
  $cd *public*
  $ls -1F
  $cd *peace*
  $ls -1F
  $cd *min
  $ls -1F
  $cd ../..
  $ls -1F
  $cd *nch
  $ls -1F

Here we see that among the 'p' clients are a certain John P. and three businesses or organizations with one-word names. We see also that 'public_welfare' has been set up as a client, for actions that seek to serve the public welfare. (Admittedly, in this particular case, united_states__government_federal would have been a more logical choice. Whereas a client normally solicits services, some very odd clients, such as Uncle Sam, might conceivably require for their own greater good to have some small services thrust upon them. Other public-welfare projects I have filed more rationally, naming the clients tightly.) Associated with this particular perhaps-misnamed 'p' client is just one "project" or "matter", launched at 20020813T143341Z.

Here as for most clients, I set up an administrative area (in which, as can be seen from the terminal session, I keep a tasklist) and a workbench. It is in the workbench that I keep "deliverables", which are a feature of quite a few projects. One kind of deliverable is the newspaper article, sold to an editor; another is the analytical memorandum, for an enterprise or individual receiving, whether for payment or for free, some kind of advice.

We may now view a representative extract from the administrative-area tasklist for the project:

  !_phone USA consulate
    (_need to say, approx: 
      * Dr Tom Karmo 416-971-6955
      * phoning in the matter of public protest against 
        envisaged invasion of Iraq 
      * wish to stand outside consulate today at lunch time, 
        12:50 approx, 
        on the public thoroughfare, 
        with candle and my own antiwar handout, singing 
        "Where Have All the Flowers Gone"
      * will also be advising 52nd Division of my proposed action
      * wish after finishing to hand letter to Consulate
      * need to know whether there are any legal rules
        that I must follow) 
       __security officer 
         (_name was Stu something?)
         said I had picked very bad time, since construction
         in progress, but said that I would be within my legal
         and that there is no need to phone police beforehand
         __when he asked how long I would be protesting, 
           I said maybe 00h10, maybe 00h20, not 00h30)  
  !_phone police
    (_need to say, approx: 
      * Dr Tom Karmo 416-971-6955
        12:50 approx, 
        on the public thoroughfare, 
        with candle((SNIP))

The deliverable, in this project the street-protest handout ANNN___handout_20020813T1650Z.txt, later took on a second life, in a different project, becoming material published (no doubt with a few small changes) on my Web site as 'Open Letter to American Secretary of Defense Donald Rumsfeld'. In that second life, the client was simply me, and the project was one that long antedated the Second Gulf War, namely the creation, from 1996 onward, of a business Web site. (It is on a few occasions logical to call oneself a client: sometimes we serve the interests of others, whether for free or for pay, and sometimes we just work for ourselves, not really in a system-maintenance capacity, doing for ourselves a job very similar to what we might some day do for another.) The ultimate Web deliverable, a file that happens to be named DSNN____rumsfeld.html, is consequently a leaf on a tree rooted at


Of all the various tasks performed at the workstation, it is client service that most notably calls for revisions in action plans, in literary-composition outlines, and in literary drafts, with old versions typically kept on hand as a precaution. It can be gathered from the terminal session relating to ANNN___handout_20020813T1650Z.txt that I tend to use ZZNN____ directories for this purpose in my administrative and workbench client-service areas. I will illustrate this point further with a fresh client-service example. My fresh example has to do with journalistic writing for a client (having, as can be seen, three projects or "matters" so far) in Truro, Nova Scotia:

  $cd *clien*
  $cd t
  $ls -1F
  $cd *truro*
  $ls -1F
  $cd *world*
  $ls -1F
  $cd *nch
  $ls -1F
  $cd *bak
  $ls *outli*

In my own version-control efforts, I have not found it necessary to implement the industrial-strength GNU/Linux Revision Control System and Source Code Control System. Still, I do keep handy on my shelves one of the standard reference works for these tools, Don Bolinger's and Tan Bronson's Applying RCS and SCCS (O'Reilly, 1995).

Sometimes we can have not one matter for a client, as with my initial example, or three, as with the client just presented, but twenty or more. I'll now cite an instance from my ~/NNNN____clients, while altering the display first by making heavy ((SNIP))-style edits, and second by forging all timestamps by at least a few days, so as to preserve confidentiality:

$ls -F
a/  c/  e/  g/  i/  k/  m/  o/  q/  s/  u/   virz/  w/  y/
b/  d/  f/  h/  j/  l/  n/  p/  r/  t/  va/  visa/  x/  z/
$cd ((SNIP))
$cd ((SNIP)) 
$ls -1F

Sometimes, as here, client work can become intricate, with a mix of financially compensated projects and projects that, being in a sense preparatory, cannot be compensated. For this particular client, financially compensated work, specifically the editing of certain English-language texts, predominates. In some cases, for instance with the matter here represented as having been launched by the client at 20030222T175356Z, there is one piece to be edited. In other cases, as with the matter here represented as having been launched by the client at 20031016T150l43Z, there is more than one. My essential point in this example is that we sometimes need in the directory of a client not just subdirectories for that client's various matters but also a directory that is "matter-neutral". In the matter-neutral area here represented as bearing the timestamp 20020121T225722Z, I keep client instructions that are liable to govern more than one matter: for instance, the client's in-house rulebooks, promulgated by the client's various officers as long-term standing instructions.

9. Further Reading

The topic of personal-office organization is discussed in two magical books by Vladimir Stibic: Personal Documentation for Professionals: Means and Methods (North-Holland Publishing Company, 1980) and Tools of the Mind : Techniques and Methods for Intellectual Work (North-Holland Publishing Company, 1982). Stibic, being an electronics engineer with Philips in the Netherlands, foresaw the advent of today's adequately powerful workstations even while addressing himself to a 1980s readership deploying such weak personal hardware as the Apple II and the Osborne 1.

The deeper implications of intellectual activity are discussed by Antonin Gilbert Sertillanges (1863-1948) in an equally magical French-language theological work, available from large North American academic libraries at least in its English translation: The Intellectual Life: Its Spirit, Conditions, Methods (Newman Press, 1948).

10. Acknowledgements

I'd like to thank the following individuals (listed here in alphabetical order) for conversations: Marlene Cummins (Library of Department of Astronomy and Astrophysics, University of Toronto), Darlene Davidovic (Price Waterhouse, Toronto), Emeritus Prof. Robert Garrison (Department of Astronomy and Astrophysics, University of Toronto), and Drew Sullivan (Greater Toronto Area Linux User Group).