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:
- the PDF manual accompanying some software, designed for the analysis of spectral energy distributions, recently downloaded
- the electronic handouts from a lecture on spectral energy distributions delivered by a friend whose brains one has been diligently picking for the past two weeks
- correspondence relating to one particular project, namely a guest lecture requested by Prof. Reddy Magenta in the Institute for Black-Body Emissions in the University of Whitechester on 2004 December 12 but not actually delivered on the Whitechester campus until 2005 October 11
- the stream of e-mail correspondence relating to all projects ever undertaken for the University of Whitechester (as it could be, guest lectures in 2005 and 2006 at the Institute for Black-Body Emissions on the Whitechester campus, and in addition a 2003 four-article series for the newsletter of the Green Studies Unit on that same campus)
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:
- the vendor-supplied digital authorization key for software running on the workstation
- our private notes on what had to be done to get the software running correctly
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):
- our maintenance area
- our area for the archiving of private copies of published digital materials
- our area for the keeping of private-study notes
- our area for working on the various projects of our various clients
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:
CNNN___e-mail_and_phone_list.html CPNN___courier_directions.html GNNN___our_history.html GPNN___our_philosophy_of_service.html MNNN___prepared_inks.html MPNN___custom_ink_formulation_services.html PNEN___portable_stamping_machines.html PNFN___nonportable_stamping_machines.html PSNN___stencil_machines.html RNNN___consulting_services_marking_machinery.html RPNN___consulting_services_marking_consumables.html XNNN___this_www_site_tech_notes.html
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:
CNNN___e-mail_and_phone_list.html CNNN___e-mail_and_phone_list____raw_from_client.doc CPNN___courier_directions.html GNNN___our_history___interview_notes.txt GNNN___our_history____draft01_from_writer.rtf GNNN___our_history____draft02_from_writer.rtf 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
GNNN___our_history___interview_notes.txt GNNN___our_history____draft20051010T150403Zfrom_writer.rtf GNNN___our_history____draft20051014T035205Zfrom_writer.rtf GNNN___our_history.html
or, if less precision is needed, as something like
GNNN___our_history___interview_notes.txt GNNN___our_history____draft20051010from_writer.rtf GNNN___our_history____draft20051013from_writer.rtf GNNN___our_history.html
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:
05086revision1pt3.pdf
…
ANNN____maintenance/
…
David_Jimson.letter.1
Desktop/
ENNN____library_of_public_docs_etc/
…
GNNN____studies_private/
HP-PhotoSmart_P1215-hpijs.ppd
…
NNNN____clients/
…
ZZNN____quasijunk_eg_informal_baks/
ZZZX____utter_junk/
…
mail/
…
t
…
t__lambda_central
tbh
…
tt
ttt
tttt
tttt_Prandtl
…
win2000Pro.cfg
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 foo.bar
is entered:
"Remove" foo.bar in what sense:
1. by moving it with /bin/mv into
~/ZZNN____quasijunk_eg_informal_baks?
2. by moving it with /bin/mv into
~/ZZZX____utter_junk?
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 *____* ANNN____maintenance/ CNNN____tools_apparatus_etc/ ENNN____library_of_public_docs_etc/ GNNN____studies_private/ NNNN____clients/ ZYNN____dotfile_baks/ ZZNN____quasijunk_eg_informal_baks/ ZZZX____utter_junk/ $
(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:
$ $pwd /home/verbum $cd *tools*apparat* $pwd /home/verbum/CNNN____tools_apparatus_etc $ls -1 CNNN____maths_and_drafting_and_drawing_inventory.txt CNNT____maths_and_drafting_and_drawing__CARTON/ NNNN____electromag_and_electronics_inventory.txt NNNT____electromag_and_electronics__CARTON/ PNNN____optics_inventory.txt PNNT____optics__CARTON/ RNNN____chemistry_inventory.txt RNNT____chemistry__CARTON/ $
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:
$ $pwd /home/verbum $cd *dotfile*bak* $pwd /home/verbum/ZYNN____dotfile_baks $ls -a .bashrc* … .bashrc____BAK20050604T033441Z .bashrc____BAK20050809T192847Z .bashrc____BAK20050817T223133Z .bashrc____BAK20050818T162243Z .bashrc____BAK20050910T183747Z
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:
$ $pwd /home/verbum $cd *maintenance* $pwd /home/verbum/ANNN____maintenance $ls -1 AANN____maintenance_policies_etc/ AENN____tool_development/ CNNN____headers_etc/ ENNN____bin/ NNNN____addresslists_etc/ RNNN____journals_etc/ SNNN____facilities_and_projects/ $
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,
with
+ hard-docs arm for reading and writing paper docs
(_in {t.karmo} actual practice includes 24 over-desk
pigeonholes)
__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
((SNIP))
__basic principles for hard files (folders, books, floppies, CDs):
* all hard files which happen to be collections of loose
papers
(_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
20011016T152707Z__rooing_the_har_with_green_paper
and that project so far generated paper files without
digital files, instead of creating the directory
20011016T152707Z__rooing_the_har_with_green_paper____HARDCOPY
we create the directory
20011016T152707Z__rooing_the_har_with_green_paper
and UNDER it put some such thing as
LNNN____useful_papers_including_coloured_stock____HARDCOPY
__justification:
+ 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,
((SNIP))
parent directory
20011016T152707Z__rooing_the_har_with_green_paper
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
downward
(_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
drawer)
(_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
files
(_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))
~/*public_docs*/Q/QB________astron*
QB51.3 I 72/Anderson IRAF scripts
((/__EXAMPLE))
__Library of Congress numbers
are used to track public documents
- ((__EXAMPLE))
~/*studies_private*/Q/QB________astron*
QB981 P424 Peebles Cosomology/comprehension
((/__EXAMPLE))
__Library of Congress numbers
are used to track private studies
- ((__EXAMPLE))
~/*clients*/n/nebular_visi
20000825T010203Z__train_((SNIP))
((/__EXAMPLE))
__ISO CCYYMMDDThhmmssZ timestamps are used
to track client projects
__"20000825T010203Z__train_((SNIP))"
is "Project Train the Staffer ((SNIP))",
started 2000-08-25 at 01:02:03 UTC
- ((__EXAMPLE))
~/*clients*/t/toronto_univ
19980901T120130Z__ast425h/presentation_199902
((/__EXAMPLE))
__"19980901T120130Z__ast425h/presentation_199902"
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,
((SNIP))
__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
__((SNIP))
* ~/GNNN____studies_private
__colloquially in paper filing "~/*studies_private*"
__Library of Congress numbers
subdivide this area
__((SNIP))
* ~/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
__justification:
a mirror is a quite special file
__we do not END the mirror name with the timestamp
__justification:
we wish to distinguish mirrors from mere timestamped
backups
* 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
PATH=$PATH":/home/verbum/ANNN____maintenance/ENNN____bin"
to make things like
foo work as command-line invocations.
5.3 The Maintenance Area:
Headers
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:
DOCUMENT-IN-A-NUTSHELL:
AUTHOR
__Toomas (Tom) Karmo = {t.karmo}
__416-971-6955
__253 College Street, Box 189, Toronto M5T 1R5
__((verbum@interlog.com))
__((http://www.metascientia.com))
__backup (mirroring) server = ((http://www.interlog.com/~verbum))
STORAGE
__definitive archived version
is in /home/verbum/NNNN____clients tree
of {t.karmo} Debian GNU/Linux workstation
veritas.((SNIP))
presently at ((SNIP)) Street, Toronto M5T ((SNIP))
REVISION HISTORY (LATEST FIRST)
* CCYYMMDDThhmmssZ/version0001.0000
DOCUMENT DESCRIPTION
......................................................................
......................................................................
......................................................................
......................................................................
......................................................................
= 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
slists_etc/NNNN____coordinates_etc.txt
(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
slists_etc/NNNN____coordinates_etc.txt
Here is a representative extract from the file, showing just two of its very roughly one thousand entries:
ACCESSIBILITY CHECKER (WEB)
__http://bobby.watchfire.com/bobby/html/en/index.jsp
__was http://www.cast.org/bobby/
----------------------------------------------------------------------
ADVANCE & UNIQUE TAXI PLUS LIMOUSINE
__for Richmond Hill (DDO gardening etc)
__van avail
__905-881-1212
__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):
----------------------------------------------------------------------
BEGIN PAPERMAIL XMAS
STOKOLSKA, Mrs JOANNA
23 Larkwhistle Road
Heaton Moor, Stockport
Cheshire SK4 4QF UK
END PAPERMAIL XMAS
__joannastokolska@aol.com
__current 2002-12
..............................
children Pattie, Abe
----------------------------------------------------------------------
I pull out details for these individuals with a short, crude
Perl script,
YNNN____generate_xmas_mailing_list.pl,
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:
$ $maint AANN____maintenance_policies_etc/ NNNN____addresslists_etc/ AENN____tool_development/ RNNN____journals_etc/ CNNN____headers_etc/ SNNN____facilities_and_projects/ ENNN____bin/ $cd *bin $ls *xmas* YNNN____generate_xmas_mailing_list.pl* $./*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
...................................................................... STOKOLSKA, Mrs JOANNA 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
jdoe@green-university.edu, 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:
DOE, Dr JANE
__jdoe@green-university.edu
__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
((SNIP))
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
----------------------------------------------------------------------
__{James.Martin}
__announced in 2004 to be founding institute in Oxford
__http://www.headstrong.com
__http://www.watchit.com
======================================================================
Gandhi
----------------------------------------------------------------------
__complete writings
at www.mahatma.org.in/index/jsp
======================================================================
peace analysts
__see also Gandhi
----------------------------------------------------------------------
* http://www.peacedirect.org/
__reported by BBC 2004-03-08
* http://www.oxfordresearchgroup.org.uk
__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
----------------------------------------------------------------------
__((QUOTE
SOURCE="http://www.debian.org/releases/stable/i386/ch03s06.html.en"
@="2005-07-27"))
How you access the BIOS (or ``CMOS'') configuration menu depends
on who
wrote your BIOS software:
AMI BIOS
Delete key during the POST (power on self test)
Award BIOS
((SNIP))
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
http://w3.uniroma1.it/vrd/mathematics/i-ranganathan.html;
faceted classification is demonstrated
in a computer-science setting at
http://facetmap.com/; 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
http://www.loc.gov/catdir/cpso/lcco/lcco.html),
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'):
$ $pwd /home/verbum/ANNN____maintenance/NNNN____addresslists_etc $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:
$
$pwd
/home/verbum/ANNN____maintenance/NNNN____addresslists_etc
$
$grep -i --after-context=30 "carrying capacity" *.txt
PNNN____facts_etc__S.txt:carrying capacity
PNNN____facts_etc__S.txt-----------------------------------------------------------------------
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-
__http://www.ishmael.com/Education/Science/tightening_conflict.shtml,
PNNN____facts_etc__S.txt- read @20040113T042449Z
PNNN____facts_etc__S.txt- __that's reprint of
http://www.npg.org 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
Pimentel
PNNN____facts_etc__S.txt-__((QUOTE))
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- http://www.darkage.fsnet.co.uk/
PNNN____facts_etc__S.txt- __read 20040328T015402Z
PNNN____facts_etc__S.txt-__book on organic gardening, read in
Chapters,
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
combination[?]:
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
ft
PNNN____facts_etc__S.txt- * irish potatoes 1.6 x 10^3 sq ft
PNNN____facts_etc__S.txt-__((QUOTE
PNNN____facts_etc__S.txt-
SOURCE="http://www.oilcrisis.com/whatToDo/decline.htm"
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
~/ANNN____maintenance/RNNN____jour
nals_etc/SNNN____financial_accounts
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:
$ $maint AANN____maintenance_policies_etc/ NNNN____addresslists_etc/ AENN____tool_development/ RNNN____journals_etc/ CNNN____headers_etc/ SNNN____facilities_and_projects/ ENNN____bin/ $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:
$pwd /home/verbum/ANNN____maintenance/SNNN____facilities_and_projects/c $ls -1F computing_prudentia/ computing_veritas/ $cd *ritas $ls -1F 19960601T010203Z__amdk6_or_earlier/ 20001201T010203Z__intel_celeron/ $cd *ron $ls -1F ANNN____manuals_etc/ LNNN____configfile_baks_etc/ LNON____system_restoration_howtos_etc/ NNNN____maintenance_logs_etc/ PNNN____special_installs_etc/ RNNN____antispam_project_etc/ SNNN____isp_selection_etc/ TNNN____special_hardware_etc/ ZNNN____informal_baks/ ((SNIP)) $
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
/home/maintainer/ANNN____mainte
nance/AENN____tool_development
rather than in a tree rooted at
/home/citizen_pat/ANNN____mainte
nance/AENN____tool_development
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:
$ $pwd /home/verbum/ANNN____maintenance/SNNN____facilities_and_projects/e $ls -1F electrical_equipment__not_signif_electronics/ electronic_equipment__communications/ electronic_equipment__not_communications/ $cd electron*not*comm* $ls -1F ENNN____wristwatch__casio_module_2184/ GNNN____microwave_oven__toastmaster_tmw3504can/ $cd *casio* $ls -1F UNNN____manual____HARDCOPY $
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:
$pwd /home/verbum/ANNN____maintenance/SNNN____facilities_and_projects/t $ls -1F travel/ $cd tra* $ls -1F 19980919T010101Z__nova_scotia_truro/ 19981113T010101Z__astron_observing__david_dunlap_observatory/ 20010101T010203Z__canada_rail/ 20010821T234120Z__nova_scotia_truro/ 20040416T133336Z__montreal/ 20050606T145344Z__bradford____SEE__clients__nurmis 20050613T144316Z__halifax_hospital_etc/ 20050618T210304Z__astron_speaking__david_dunlap_observatory/ 20050625T130000Z__radio__hart_house_farm/ $cd *radio* $ls baggage__hart_house_farm_20050625.txt $
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:
$ $pwd /home/verbum/ENNN____library_of_public_docs_etc $ls -1F A_______general_works/ B_______philosophy_psychology_religion/ C_______auxiliary_sciences_of_history/ D_______history_includes_travel/ E_______america/ F_______united_states_canada_latin_america/ G_______geography/ H_______social_sciences/ J_______political_science/ K_______law/ L_______education/ M_______music/ N_______fine_arts/ P_______language_and_lit/ Q_______science/ R_______medicine/ S_______agriculture/ T_______technology/ U_______military_science/ V_______naval_science/ Z_______books_in_general/ $cd Q* $ls -1F QA________maths/ QB________astronomy/ QC________physics/ $cd *astron* $ls -1F QB00000001____journals__etc/ QB00000051.3____imaging_systems/ QB00000065____atlases_and_charts/ QB00000088____telescopes/ QB00000465____spectroscopy/ QB00000830____nstars__ADHOC/ QB00000838____stars_pulsating/ $cd *telesco* $ls -1F QB88.M85____muirden__how_to_use/ $cd *muirden* $ls UNNN____partial_photocopy____HARDCOPY $
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:
$ $pwd /home/verbum $cd *stud* $ls -1F A_______general_works/ B_______philosophy_psychology_religion/ C_______auxiliary_sciences_of_history/ D_______history_includes_travel/ E_______america/ F_______united_states_canada_latin_america/ G_______geography/ H_______social_sciences/ J_______political_science/ K_______law/ L_______education/ M_______music/ N_______fine_arts/ P_______language_and_lit/ Q_______science/ R_______medicine/ S_______agriculture/ T_______technology/ U_______military_science/ V_______naval_science/ Z_______books_in_general/ $cd Q* $ls -1F QA____maths/ QB____astronomy/ QC____physics/ QC____physics____BAK20020530T163958Z/ QD____chemistry/ QH____biology/ TNNN____running_log_for_studying__QA_QB_QC_QD.txt $cd QH* $ls -1F QB00000308.2____intro/ $cd *intro* $ls -1F AANN____admin/ $cd *min $ls -1F NNNN____timelog_elementary_biol.txt $
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
======================================================================
@=20050903T194455Z____SEVERITY=70%__LC=QB461__DSCRP="u-substitution"
----------------------------------------------------------------------
__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
$\sin\theta\mathrm{d|\theta$
__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)
======================================================================
@=20050913T192347Z____SEVERITY=70%__LC=QA303__DSCRP="u-substitution"
----------------------------------------------------------------------
__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
~/GNNN____studies_private/Q_______sci ence/QC____physics/QC00000760____electromagnetics
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
20041209T1344Z
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
20050113T1455Z
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
20050715T0344Z
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:
20050808=00h53->062h01
20050816=00h40->062h41
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"
__hurrraa
20050825=01h01->080h00
20050826=01h00->081h00
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:
<!DOCTYPE BIBLIOG_TKARMO SYSTEM "xxxx.dtd">
<!--
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:
__<karmo@ungrad.astro.utoronto.ca> is deprecated e-mail address
__<verbum@interlog.com> 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
undefined
__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
-->
<BIBLIOG_TKARMO>
<!-- Here is a template for creating new records:
<RECORD>
<AUTHOR01>xxxx</AUTHOR01>
<AUTHOR02>xxxx</AUTHOR02>
<AUTHOR03>xxxx</AUTHOR03>
<YEAR>19xx</YEAR>
<DATEREC_AUDIENCE></DATEREC_AUDIENCE>
<JOURNAL>xxxxxx</JOURNAL>
<VOLUME>xxxx</VOLUME>
<COLLECTION>xxxx</COLLECTION>
<COLLECTION_EDITOR01>xxxx</COLLECTION_EDITOR01>
<COLLECTION_EDITOR02>xxxx</COLLECTION_EDITOR02>
<BOOK>xxxx</BOOK>
<EDITION>xxxx</EDITION>
<PUBLISHER_NAME>xxxx</PUBLISHER_NAME>
<PUBLISHER_CITY>xxxx</PUBLISHER_CITY>
<PAGE>xxxx</PAGE>
<URL>xxxx</URL>
<CONF SESSION=>xxxx</CONF>
<SEMINAR>xxxx</SEMINAR>
<COLLOQ>xxxx</COLLOQ>
<LECTURE>xxxx</LECTURE>
<SYMPOS>xxxx</SYMPOS>
<CNVRSATN>xxxx</CNVSATN>
<VENUE>xxxx</VENUE>
<TITLE>xxxx</TITLE>
<UNIV_ESSAY>xxxx</UNIV_ESSAY>
<UNIV_THESIS>xxxx</UNIV_THESIS>
<COMMENT01></COMMENT01>
<COMMENT02></COMMENT02>
<COMMENT03></COMMENT03>
<COMMENT04></COMMENT04>
<NOTES>
</NOTES>
<TOPIC></TOPIC>
<TOPIC></TOPIC>
<TOPIC></TOPIC>
<TOPIC></TOPIC>
<LIBRARY></LIBRARY>
<DATEREC_ARCHIVIST></DATEREC_ARCHIVIST>
</RECORD>
__revision history of this template:
* 20030428T204200Z/version 0000.5010
__replaced DATEREC with
DATEREC_AUDIENCE and DATEREC_ARCHIVIST
* 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
__examples:
* 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
information
__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:
<SEE>
<SEARCH>
xxxx
</SEARCH>
<RETRIEVE>
xxxx
</RETRIEVE>
</SEE>
<SEE_ALSO>
<SEARCH>
xxxx
</SEARCH>
<RETRIEVE>
xxxx
</RETRIEVE>
</SEE_ALSO>
-->
<!--
The document should have first all the records,
then all the "see" cross-refs,
then all the "see also" cross-refs.
-->
<RECORD>
<AUTHOR01>Struve, Otto</AUTHOR01>
<YEAR>1935</YEAR>
<JOURNAL>ApJ</JOURNAL>
<VOLUME>82</VOLUME>
<PAGE>252-260</PAGE>
<TITLE>
A Test of Thermodynamic Equilibrium in the Atmospheres
of Early-Type Stars
</TITLE>
<NOTES>
__following indicates two concepts of great importance
(the He anomaly, dilution) to {tk}'s overall study problem
<__QUOTE>
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.
<__QUOTE>
__{tk} did NOT understand 19991215T035200Z
</NOTES>
<TOPIC>dilution</TOPIC>
<TOPIC>He anomaly </TOPIC>
<DATEREC>19991215T035200Z</DATEREC>
</RECORD>
((SNIP))
<RECORD>
<AUTHOR01>Helfand, Prof. David</AUTHOR01>
<YEAR>2005</YEAR>
<DATEREC_AUDIENCE>20050930T2300Z</DATEREC_AUDIENCE>
<LECTURE>Cosmic Frontiers: Celebrating a Century
of Astronomy at the Univ of Toronto [2nd in series]
</LECTURE>
<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>
<NOTES>
__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
unconfined
__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
some
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
</NOTES>
<TOPIC>neutron stars</TOPIC>
<TOPIC>degenerate matter</TOPIC>
<TOPIC>quarks: unconfined, in neutron stars</TOPIC>
<TOPIC>X-ray astronomy: surveys</TOPIC>
((SNIP))
</RECORD>
<!-- here starts 2006 -->
<!-- here starts 2007 -->
<!-- here starts 2008 -->
<!-- "SEE" CROSS-REFS -->
<SEE>
<SEARCH>
speckle interferometry
</SEARCH>
<RETRIEVE>
interferometry, speckle
</RETRIEVE>
</SEE>
((SNIP))
<!-- "SEE ALSO" CROSS-REFS -->
<SEE_ALSO>
<SEARCH>
photometry, synthetic
</SEARCH>
<RETRIEVE>
spectrometry
</RETRIEVE>
</SEE_ALSO>
</BIBLIOG_TKARMO>
<! ----------------------------------------------------------------------->
<! --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:
$
$pwd
/home/verbum
$cd *client*
$pwd
/home/verbum/NNNN____clients
$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:
$ $pwd /home/verbum $cd *clien* $cd p $ls -1F pa((SNIP))h/ per((SNIP))_john/ pre((SNIP))l/ pro((SNIP))t/ public_welfare/ $cd *public* $ls -1F 20020813T143341Z__peace_campaign/ $cd *peace* $ls -1F ANNN____admin/ NNNN____workbench/ $cd *min $ls -1F NNNN____tasklist.txt ZZNN____bak/ $cd ../.. $ls -1F ANNN____admin/ NNNN____workbench/ $cd *nch $ls -1F ANNN___handout_20020813T1650Z.txt ZZNN____bak/ $
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
(_416-595-1700)
(_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)
__DONE@20020813T145634Z
__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
rights,
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
(_416-808-2222)
(_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
~/NNNN____clients/k/karmo_toomas/19960910T143250Z__bus
iness_www_site
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:
$ $pwd /home/verbum $cd *clien* $cd t $ls -1F ((SNIP)) td_bank_canada_trust/ toronto_univ/ truro_daily_news/ $cd *truro* $ls -1F 20020725T163339Z__world_youth_day/ 20020913T223149Z__railway/ 20030509T190000Z__tulips/ $cd *world* $ls -1F NNNN____admin/ PNNN____field_notes____HARDCOPY/ QNNN____workbench/ $cd *nch $ls -1F ANNN____outline.txt NNNN____wyd2002__version0000pt9000.txt NNNN____wyd2002__version0001pt0000.txt ZZNN____bak/ $cd *bak $ls *outli* ANNN____outline.txt____BAK20020728T204654Z $
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:
$ $pwd /home/verbum/NNNN____clients $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 20020121T225722Z____matter-neutral_notes/ ((SNIP)) 20021111T150233Z____do_prelim_prep_for_((SNIP))// 20030222T175356Z____edit_((SNIP))/ 20030413T221337Z____edit_((SNIP))/ 20030719T185514Z____edit_((SNIP))/ 20030727T000451Z____do_prelim_prep_for_((SNIP))/ 20030927T152011Z____edit_((SNIP))/ 20031016T150l43Z____edit_((SNIP))_and__((SNIP))_and_((SNIP))/ ((SNIP-MANY-LINES)) 20050719T170355Z____edit_((SNIP))/ 20050925T190431Z____edit__((SNIP))_and__((SNIP))/ $
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).