Upper Kananaskis Lake

No seasonal affective disorders here, just a brief return to winter.  On this last day of April, a quiet Monday, when most of the skiers have gone home and the golfers, mountain bikers, hikers, and fly fishers have not yet arrived, we took advantage of the solitude to venture up into the Kananaskis Country, south of Canmore, climbing to an elevation of 1724 meters (5600 ft), where winter was in full force yet at the Kananaskis Lakes, which won’t begin to fill with snow melt for many weeks yet.

Lower Kananaskis Lake

We chose not to bring our bicycle on this trip, figuring the bike trails would not yet be open. Well, we were partly right. Although there is an extensive trail system throughout Kananaskis Country, some trails are closed to bicycles, as seen here, and some are just closed, anyway, along with many roads, services, and all the campgrounds.

No Bikes Allowed on this trail, even if you can find it...

We had set out for the day up Alberta Highway 40, which was still closed for the winter about 50Km up the valley. After a short hike for views of the lakes, we headed back, following the GPS, which pointed out the shortest route back was via the Spray Lakes, most of which was unpaved, but, for the first 50 Km or so, was very wide and relatively smooth and empty of traffic.

Spray Trail, along the Spray Lakes Reservoir

The scenery was great, even though visibility was low.

Spray Lakes Reservoir

Despite having dropped quite a bit in altitude, the lakes were still frozen, and we were getting quite close to town. At the dam at the head of the main reservoir, the road narrowed and deteriorated, and, more ominously, quit descending, until we came to Whitemans Pond, perched on the edge of a cliff, 400 meters (1300 ft) directly above our resort. The narrow gravel road turned sharply left across the face of the cliff and descended at a double-digit grade. Suffice it to say that, had we chosen this route outbound to the high country, we would not have attempted the journey. As it was, we were within 5Km of town and no turn-arounds, so we plummeted down the slope, transmission screaming in low gear (but, to her credit, the Nice Person, white-knuckled in the infelicitous downward-view seat, was not–screaming, that is).

Spray Trail (diagonal cut above the trees in the forground)

Meanwhile, between adventures in the wilderness, work goes on for the Unix Curmudgeon. Email correspondence tended, files uploaded, advice rendered, and life goes on. Hmmm, wonder where to go tomorrow on coffee break?

So, we found ourselves, after several days of leisurely travel, in Canmore Alberta, having retraced some of our celebrated bike tour before heading east from Banff.  Of course, not being exactly ready for vacation–again–we have brought work with us.  Such is the magic and curse of the Internet…

Columbia Lake, looking south to the headwaters of the Columbia River

It’s always a treat to journey to the headwaters of the mighty Columbia River, which is only a few kilometers from its eventual tributary, the Kootenay, already a mighty river as it passes through Canal Flats, near the head of Lake Columbia.  Canal Flats is called thus because David Thompson, for whom Thompson Falls, Montana is named, built a canal between Lake Columbia and the Kootenay to create a water trade route through eastern British Columbia, Montana, and Idaho.

Kootenay National Park, Canada, looking north from Sinclair Pass

Moving on north along the Columbia (which flows north before turning south toward Washington), we climb through Sinclair Canyon into the Kootenay National Park, following our bike tour path of so long ago.  This view up the Kootenay from Sinclair Pass is near where we cracked a rim riding over a slip in the road surface.  We rode on it, with minor adjustments at Banff, another 400 kilometers to Jasper, getting a new rim on our return.

Bow Falls, in Banff, Alberta

On this trip, we traversed what was a three-day bike ride from Radium Hot Springs into Banff in about 90 minutes in the car.  After lunch, we did a bit of site-seeing around Banff before moving on to our destination in Canmore.

Looking east at the confluence of the Bow and Spray rivers, Banff

Mt. Rundle, from the Tunnel Mountain Road, Banff

Worldmark Canmore

So, here we are, an extension of Chaos Central in the far north. It is not quite spring here. This morning in Cranbrook, there was frost on the car, and snow in sheltered areas, and we experienced a few flurries while taking pictures on Tunnel Mountain, though the temps reached the teens (C) in the valleys. We have a week to explore the area, and try to get some work done, before returning to the normal hectic pace.

So, when we were in Seattle, the ancestral home and headquarters of Starbucks, for an IT conference, we had a need for “one for the road” when heading home.  There was a Starbucks just around the corner, but, being in a hurry, we elected to drive (us, the intrepid bike tourists?  What were we thinking?), with the excuse that it’s “on the way.”  Of course, urban shops don’t have drive-up windows (which we almost never use, anyway–half the enjoyment is ogling the pastry case and the coffee accessory displays arrayed to direct and slow traffic flow), and there is no parking on the street except a slot about two feet shorter than our not-so-big Jeep.  No problem, there’s another Starbucks just a few short blocks away, walkable in less time that it takes to chug a Venti caramel latte.  Such is life in big cities on the west coast: if you can see a Starbucks, odds are very good that you are in one already.

So, off we go, straight ahead.  And, lo, there is a parking spot directly in front of the store.  It’s about 5:30pm on a Saturday; the parking permit machine is halfway down the block.  It’s gotta be after hours, right?  So, we dash in, order coffee and a pastry, depleting our gold card balance by about $6.  But, by the time the pastry comes out of the microwave and we dash back to our car, there’s a $44 ticket stuck in the wiper blade, with the ink still drying, and a date stamp of 5:27, about 20 seconds ago.

Of course, the $50 coffee pales in comparison to staying at the conference hotel.  Oh, it was a very nice hotel, to be sure, but city real estate is at a premium, so everything is compact.  Double bed, up against the wall, and bathroom so small that you had to step into the tub to close the door.  But, big closet, complete with complementary (with $20 deposit) umbrella (this is the Emerald City, after all), and corresponding big price tag, at nearly $200 a night, bring your own iPod if you want to wake to music.  But, for this, we got a spectacular view of the sunset over the Olympic Mountains (they’re to the north from our windows at home).

And, the conference was terrific: so much talent in the Silicon Rain Forest: most of the  instructors were fairly local, and absolutely tops in their fields.  I took classes in network troubleshooting and server configuration management from local folks (Portland, OR being fairly local) and VM cluster management from one of Google’s top New York sysadmins, whose books line my office shelves.  Will we back? You bet, but next time, we take the ferry and the bus, like we used to when we worked here, back in the 90s.  Parking in the city is a non-starter.

And, so it went.  After weaving a couple inches of weft and examining the results, the pattern had some glitches in it.  I discovered I had skipped a step in the threading pattern, about 1/3 of the way across the warp. Correcting this problem required unthreading about 100 threads and moving them to the next harness.  About 3/4 of the way through this process, real work crept in, and the time budget ran out.

The project sat idle for about nine months.  Finally, when a similar fate befell an actual programming project, the Unix Curmudgeon (under some prodding from the Nice Person, who wanted to use the loom the stalled project was tying up) reopened the project and finished threading those last couple dozen warp threads, retied the warp, and started weaving.  Again, the testing cycle, a couple of inches of weft later, showed a break in the pattern.  This time, it was only a couple threads in the wrong harnesses.  Clipping the heddle and tying a new one on the proper harness fixed the problem, and the project proceeded.

The project is a stitched doubleweave, with 8/2 wool on top at 12epi, and 20/2 Tencel at 24epi on the bottom. A short video of the weaving process is here.

The weaving process, once “debugged,” proceeded swiftly.  Other than a few issues with maintaining uniform tension between the two different fibers (wool grabs everything, and I broke a warp thread that got doubled over when I advanced the warp), and a couple of weft floats caused by not having enough warp tension (helped by sticky wool warp), the project turned out well.  Documentation of projects is also helpful: the first hem end is tabby, while the second hem end is pattern weave, the weaver having forgotten what he did several weeks ago…

The finished product was “fulled’ (rinsed in hot water to let the fiber tension even out and the fabric shrink a bit), and laid out flat to dry.  It turned out just a bit wider than planned (the weft tension was not as high as estimated), but exactly the planned length, which was measured while weaving, with a 10% shrinkage allowance.

Finished wool-tencel scarf

The completed scarf is a “re-imagining” of a World War I aviators scarf. Modern aviator scarves are silk, but in the original open-cockpit planes of the 1914-1918 era, wool was needed for warmth, and silk for wiping engine oil from goggles and instruments. Most of the early combat planes on both sides used rotary engines (not to be confused with the Wankel rotor engine). These engines used a lot of oil, which was usually castor oil, which does not dissolve in gasoline. Without a model to work from, I decided to try to create a two-sided scarf using stitched double-weave. The weave structure does not separate the fibers, but the wool is dominant on one side and the tencel, a modern silk substitute, is dominant on the other. The result is interesting, if not quite what I expected.

Unlike computer software, where the bugs can be removed by patching and performance improved by refactoring, a woven cloth is what it is, unless the errors are caught and corrected while weaving. The knot where the warp thread broke shows as a woolly spot on the tencel side and the inadvertent weft floats show as well in the pattern. The two misthreading errors were corrected, but the item was not rewoven, so they show in the first couple of inches. But, the discipline required to weave well should also improve my coding skills, as coding errors are easier to correct if caught early, and refactoring during development (like reweaving to remove mistakes) results in a better product.

At first, the solution to the problem seemed to be to modify the source code to add the required functionality, which involved getting the source code from the author and permission to modify it, something we had done before to change a static list page to read from a tab delimited file.  But, the types of changes didn’t always fit with the format of the administration forms and still required sending files to the server administrator, as we didn’t have FTP or SSH access to the site.  Then, we noticed that the web hosting service had recently added WordPress to the stable of offerings.  The solution was obvious: convert the entire site to WordPress.  Of course, the convenience of fill-in-the-blank forms would be gone, but we would have the ability to create new pages, add member accounts, create limited-access content, and upload both documents and photos.

The process was fairly simple:  using the stock, standard WordPress template, the content of the current site was simply copied and pasted into new pages, and the site configured as a web site with a blog rather than the default blog with pages format.  Some editing of the content to fit with the standard WordPress theme style models, and juggling the background and header to fit with the color scheme and appearance of the old site, and incorporate the organization’s logo in the header, and it was done: the system administrator replaced the old site with the new, with appropriate redirection mapping from the old PHP URLs to the corresponding WordPress pages. This migration represented yet another step in the evolution of the web, or, more properly, in our experience with on-line content.

In the beginning, there was the concept of markup languages.  My first encounter with such was in the mid 1980s with the formatting tags in Ventura Publisher, which was the first desktop publishing tool, introduced in GEM (Graphical Environment Manager), a user interface orginally developed for CP/M, the first microcomputer operating system, preceding MS-DOS by a few years (MS-DOS evolved from a 16-bit port of the 8-bit CP/M).  Markup tags grew from the penciled editing marks used in the typewriter age, by which editors indicated changes to retype copy:  Capitalize this, underline (bold) this, start a new paragraph, etc.  In typesetting, markups indicated the composition element, i.e., chapter heading, subparagraph heading, bullet list, etc, rather than specific indent, typeface and size, etc.  In electronic documents, tags were inserted as part of the text, like <tag>this</tag>.  Where the tag delimiters needed to be installed in the text, they were described as special characters, like &gt;tag&lt; to print “<tag>” (which, if you look at the page source for this document, you will see nested several layers deep, since printing “&” requires yet another “escape,” &amp;).

One of the reasons for the rise of markup languages as plain-text tags in documents was the proliferation of software systems, all of which were incompatible, and for which the markup tags were generally binary, i.e., not human readable.  Gradually, the tags became standardized.  When the World Wide Web was conceived, an augmented subset of the newly-minted Standardized Generalized Markup Language (SGML) was christened  HyperText Markup Language (HTML).  HTML used markup tags primarily to facilitate linking different parts of text out of order, or even enable jumping to different documents.  Later, the anchor (<A>) tag  and its variants were expanded to allow insertion of images and other elements.

Of course, these early web documents were static, and editors and authors had to memorized and type dozens of different markup tags.  To make matters worse, the primary advantage of markup tags, the identification of composition elements independent of style, became subverted as browser software proliferated.  In the beginning, the interpretation of tags was controlled by the Document Type Definition (DTD), the “back end” part of the markup language concept.  The DTD is a fairly standard description of how to render the tags in a particular typesetting or display system.  Each HTML document is supposed to include a tag that identifies the DTD for the set of tags used in the rest of the document.  But, since different browsers might display a particular tag with different fonts–size, typeface, color, etc.–the HTML tags allowed style modifiers to specify how the particular element enclosed by that one tag would be displayed.  This not only invites chaos, i.e., allows every instance of the same tag to be displayed differently, but most word processors, when converting from internal format to HTML, surround every text element with the precise style that applies to that text element, making it virtually impossible to edit for style in HTML form.  To combat this proclivity toward creative styling, the Cascading Style Sheet (CSS) was invented, allowing authors and editors to globally define a specific style for a tag, or locally define styles within a cascade, by using the <DIV> and <SPAN> tags to define a block of text or subsection within a tag.

It quickly became obvious that HTML, as a static markup, was not adequate for the dynamic growth of information on the Web.  Web pages could interact with users, by transmitting snippets of programming script code (between <SCRIPT></SCRIPT> tags) bound to markup tags by modifiers to create effects like changing text color when the mouse is over the enclosed text, or preprocess form input to validate data entry before transmitting it to the server.  The most popular scripting language for this is Javascript.  Of course, in the beginning, competing browsers interpreted the code differently or even supported different dialects of the language, which caused no end of grief for web programmers.  Fortunately, the popularity and proliferation of non-Microsoft browsers in recent years has caused Microsoft to tone down that aspect of their quest for world domination, so Javascript is now more or less standardized.

In order to use the Web as an interactive tool, and an interface for applications running on the server, it was necessary to augment the HyperText Transmission Protocol (HTTP), the language that the server uses to process requests from the browser, to pass requests to internal programs on the server.  This was implemented through the Computer Gateway Interface (CGI — not to be confused with Computer Generated Imagery used in movie-making animation and special effects).  Originally, it was necessary to write all of the code to generate HTML documents from the CGI code and to parse the input from the browser. But, thanks to a Perl module, CGI.pm, written by renowned scientist Dr. Lincoln Stein, this became a lot easier and established the Perl scripting language as the de facto web programming language.

But, as the Web became ubiquitous, most content on the web was still static HTML, created by individuals using simple HTML tags in a text editor or saving their word processing documents as HTML, or using PC-based HTML editors like Homesite or Dreamweaver.  Adding interactive elements to these pages required them to be rewritten as CGI programs that emitted (programmer-eze for “printed”) the now-dynamic content.  By now, however, web servers had incorporated internal modules that could run CGI programs directly without calling the external interpreter software and incurring extra memory overhead.  By adding special HTML tags interpreted by the server, snippets of script code could be added in-line with the page content, making it much easier to convert static pages to dynamic ones.  Since the primary need was to add the ability to process form input, this led to the development of specialized server-side scripting languages, such as Rasmus Lerdorf’s PHP.

But, now that creating web pages was becoming a programming task more than a word-smithing task, there was a need for better authoring tools.  The proliferation of PHP and the spread of high-speed Internet access made it more feasible to actually put interactive user applications on web servers.  Web editing moved from the personal computer to the Web itself, as the concept of content management systems took hold.  Early forms were Wikis, where users could enter data with Yet Another Markup Standard, that would be stored on the server and displayed as HTML.  More free-form text form processors followed, making possible forums of dialogue and whole web formats for group interaction, using engines like PHP-Nuke and others, that used a database back-end to store input and PHP to render the stored content and collect new content. The expansion of the forums into tools for diarists and essayists in the form of blogs (from weB LOG) led to development of even more powerful content management systems, like Joomla and WordPress, capable of developing powerful web sites without programming.

So, we have progressed in evolution from desktop publishing to the Web, to interactive applications, to converting static sites to dynamic ones, and finally, to converting custom programs to templates for generalized site-building engines.  The Web, through new web forums for social interaction between friends and relatives who have never seen raw HTML code, allows ordinary folks to converse with friends and relatives across the world, to post photos, videos, and links to other sites of interest, just as the original hypertext designers intended.  What seemed arcane and innovative thinking 30 years ago is now just another form of natural human interaction.

But, for those of us who make our living interpreting dreams in current technology, the bar moves up again.  As we no longer think about the double newline needed at the beginning of every HTML document after the “Content-type” line and before the <HTML> tag, which is the first code emitted from a CGI program or from the server itself, we no longer need to write CSS files from scratch or PHP functions to perform common actions.  But, we need to learn the new tools and still remember how to tweak the code for those distinctive touches that separate the ordinary from the special.  And, there are still lots of sites to upgrade…

Here at Chaos Central, we have the usual UPS units lurking under the desks, which we largely ignore until the power goes out and they start beeping.  The home office/small office versions of these small units that more or less promise Uninteruptible Power to your computers are best for those momentary power glitches that plague any power grid during uncertain weather or simply human error at the control center: the lights blink, the power supplies beep, and computing goes on.   During winter ice storms and summer heat waves, when everything goes dark for minutes or hours, one of two things happens:

Ideally, you have a flashlight nearby so you can see the keyboards of the servers and workstations well enough to save your current work and run through shutdown cycles (for those machines that don’t have software wired to the power supply that automatically do this) before the batteries run down.  If you have done your system design correctly, you have purchased enough capacity to run the systems for five to fifteen minutes on battery, long enough to shut down the systems gracefully.

On the other hand, if you haven’t provisioned properly, or if you have not paid attention to the age of that black or beige box under your desk, the systems will shut down ungracefully, sometimes in mid keystroke.  Batteries need to be replaced every 3-5 years: the units themselves continue to improve, and the electronics also have been known to fail, so replacing the entire unit is sometimes easier and not that much more expensive.  A good rule of thumb is to get a new UPS when you buy a new computer.  Laptops have a built-in UPS, the battery, so all you need is a surge protector.

In either case–orderly or disorderly shutdown–in an extended outage, the UPS units need to be turned off and everything gets quiet.  When the power is restored, it all needs to be turned back on manually.  (Tip:  if you work from a home office and travel often during “the season,” it is a good idea to have a “network sitter,” someone you trust who can go to your house and turn the critical systems back on after an outage, if you need remote access to your network: we’ve been left “out in the cold” several times over the years, and, yes, have had a network sitter from time to time and it has paid off).

At Chaos Central, some systems come on with the line power, but some need to be manually started as well.  Our main server is a Citrix XenServer, which hosts a variety of systems, some of which are used for network services and some for experiments and development projects, so we leave those to be manually started from the XenServer console.  But, the NFS shares and system image shares need to be connected from the XenCenter GUI, which only runs on Windows.  We keep a Microsoft Windows XP image (converted to VM from an old PC that now runs Linux) in the virtual machine stack for that, but, in order to use it, we have to attach to it from a Linux system that runs XVP.  Finally, after all the network shares, DNS server, and DHCP server are started, we can boot up the rest of the VMs and physical machines.

The next step in the process is to prime the backup system.  Here at Chaos Central, we use rsnapshot to do backups, with SSH agents to permit the backup server to access the clients.  The agent needs to be primed and passphrases entered into it.  The agent environment is kept in a file, accessed by the cron jobs that run the backup process.

ssh-agent > my_agent_env; source my_agent_env; ssh-add

starts the agent and puts the socket id in a file, then sets the environment from the file and adds credentials to it.  Previously, each backup client has had the public key installed in the .ssh/authorized_keys file.  And, of course, since we use inexpensive USB drives instead of expensive tape drives, we need to manually mount the drives: those things never seem to come up fast enough to be mounted from /etc/fstab.   There is a setting in /etc/rsnapshot.conf to prevent writing to the root drive in  case you forget this step…

We also permit remote logins to our bastion server so we can access our files while on travel.  After the system has been off-line for a while, we can’t count on getting the same IP address for our network from our provider, so we have a cron job in the system that queries the router periodically for the current IP address, then posts changes to a file on our external web server shell account.  This also requires setting up an SSH agent.

Now, we are all up and running, usually just in time for the next power outage: here in the Pacific Northwest, winter ice storms usually result in several days of rolling blackouts.  Yesterday was up and down, today has been stable, except for a few blinks that don’t take down the network, so the backups are running and all the services are up.  Our son and grandsons have arrived with a pile of dead computers, cell phones, and rechargeable lighting, having endured two days of continuous blackout in their larger city.  The network is abuzz as everyone jacks in  to catch up on work, news, mail, etc.

It’s a lot of work to run a multi-platform network in a home office, but worth it, when you consider that we didn’t have to scrape snow and ice off the car, shovel the driveway, or brave icy streets and snarled traffic to get to “the office.”

The benefits of telecommuting outweigh the chore of keeping up the network.

The folks who live on the Great Plains and along the Great Lakes snicker a bit at news reports on the mass closures in Seattle when snow comes to the the Puget Sound region. Of course, the standard excuse is, “It doesn’t snow that much here, so we don’t have enough snow removal equipment.” But, wait, there’s more…

Most of us live in the Pacific Northwest because of the geography and the climate. The climate is temperate, with few days below freezing in the winter and few days in the 90s in the summer. Most of us live within 20 miles of either salt water or a fresh-water lake. If you want snow, you can find it in the nearby Olympic or Cascade mountain ranges, 12 months out of the year. The rest of the year, the lush green mountains invite backpackers, the flat river valleys attract bicyclists, lakes and estuaries fill with kayakers and canoeists, rivers with rafters, and the larger lakes and the Salish Sea (the accepted name for the inland sea that stretches from Olympia, Washington to Prince Rupert, BC, bounded by the Olympic Peninsula and Vancouver Island) fills with sailboats and motor craft of all sizes.

For all of this, we are willing to put up with the moisture that is a natural consequence of air warmed by the Pacific ocean currents flowing up the coast from the south. Rainwear is a fashion statement, and umbrellas are considered a mostly ineffective and cumbersome nuisance in a land where the average day ranges between swirling mist that clings to everything and fire-hose-like sideways blasts with downpours so heavy that motorists have to brake for migrating salmon. And, for a few days every odd year or so, cold and wet coincide in a heavy snowfall like those that come in waves winter-long in places like Minneapolis and Chicago. But, this is not the midwest.

Double-digit grades and ice do not mix: the street in front of Chaos Central

First, because of the geography: the region is characterized by foothills of the mountain ranges that frame the inland sea. The foothills give way to steep bluffs of glacial till that fall off sharply into the river valleys and sea, up which rise city grids on double-digit grades more suited to Olympic ski jump ramps than walking, driving, or pedaling. And second, because of the climate: the temperate nature of the climate dictates that, when the temperature does dip to the low end of the range, it hovers back and forth across the freezing line. The mass of the inland sea also helps moderate the temperature: when the wind is calm, the snow level is measured in not less than a couple hundred feet above sea level. But, the wind is never that calm, which means the rain that falls on the lower elevations, itself barely melted snow, falls on frozen snow, and therein lies the root of the problem.

Our camellia bends over under the weight of clear ice on top of snow

Steep slopes plus ice plus a preponderance of evergreen foilage combine for interesting times. The foilage includes firs, pine, and cedar, which are better-adapted to snowy conditions but less so to strong winds, since the wet climate promotes shallow root structures. Other temperate evergreens include broad-leaf plants like the native rhododendron, holly, and other ornamental shrubs found in cities. Deciduous trees in cities tend to become infested with English ivy and other climbing evergreen vines, which make them vulnerable to wind and snowload as well.

So, in the aftermath of one of these snow episodes, the snow plowing efforts, inadequate to begin with, leave many streets unplowed and packed down by adventuresome traffic. Trees are heavy with snow. And then, it rains. At first, since snow is an insulator, the rain simply combines with the snow to form a heavy crust of ice on top of a fluffy layer of loosely-packed flakes. This results in two different effects: first, the leaves and needles of the trees hold the snowballs in place until they become ice balls, at which point the tree either breaks apart or falls over, usually on a power line. Buildings designed for “normal” snow loads may collapse as well as the ice builds up. Second, on steep slopes where there are no trees (because this happens often enough to discourage their growth), the weight of the ice overcomes the integrity of the fluff beneath, and the whole mass heads downhill, picking up speed and mass as it goes, sweeping everything and everyone before it, often ending up in a solid mass of lumpy ice and boulders across a major highway.

While major power transmission lines have usually been built well clear of historic avalanche zones, the metropolitan and rural power grids are not so fortunate, being in the midst of so many snow and ice-laden trees: power outages soon follow, lasting anywhere from several hours to several days, depending on the distance from the substation to the consumer. Getting to the site of the outage to repair the damage or getting to a location where there is power is also problematic. Where the roads have been plowed and walkways shoveled, the rain freezes directly on the surface, creating a virtually frictionless surface not suitable for either walking or driving. New power outages crop up where cars skid off icy roads into power poles or trees.

Meanwhile, the temperature continues to rise, and the snow level moves higher, leaving behind a slushy mixture that begins to be more water than ice. The water moves downhill: the ice holds it back. Water backs up into basements and garages and fills dips in streets and roadways. Then, it all ends up suddenly in streams and rivers, which quickly overflow onto low-lying areas that may have been spared the heavy snow and ice loads but now find themselves underwater.

If the snow load was large enough and the rains continue, the clay bluffs continue to absorb water until they, too, become too heavy and slippery, and the hillsides collapse into the bays, taking trees, houses, and roads with them. Fortunately, the combination of wet and cold winters happen only once a decade or two in this area, so people rebuild and forget the troubles by the next sunny day when the “mountains are out” and they head for the beaches, marinas, backroads, or trails.

In the beginning, Unix was a toolbox for scientists and engineers to build things quickly and cheaply: initially, document processors, and utility software, and, later, the Internet itself.  The growing popularity of Linux, and particularly the Ubuntu distribution, has driven the need to make it useful for the things “ordinary” people–i.e., those who don’t make a living from tweaking the innards of Big Iron computing–like to do, like surf the net and manage their music, video, and image collections.  And, since Linux is still what to do with your old PC when it gets too bloated with malware and  spyware, the popular distributions still need to fit on a CD.

Most industrial-strength distros now come on DVDS, sometimes more than one, containing the entire Linux collection of free software. but, for the masses, armed with CD-only PCs, something has to give, which often are the venerable, legacy Unix features that most home users will never need.  But, many of those are what we’ve been lugging around on our hard drives for 20 years or more:  venerable editors like emacs and vi, superceded by menu-driven simple editors or integrated graphical development environments but still more powerful and with more features than anyone will ever use, and for which the ones I’ve learned, are extremely useful and well-practiced enough to be second nature, so I keep using them, even if they don’t come with the system anymore.  And, more recently, enterprise-level tools for building massive compute clusters, like GridEngine and MPICH2, along with software development libraries and specialized utility libraries for science and engineering.  We also need a lot more development tools than come with a standard desktop, since we develop software for the web and for high-performance computing clusters.

Fortunately, the Ubuntu software repositories have a lot of those tools packaged up and loadable from the Software Center application, so we don’t need to go through the ritual of downloading, unpacking, configuring, compling, and installing nested sets of dependent programs like the old days.  But, our old computers have accumulated a unique set of software over the four or five years of their busy lives, so the new ones have a lot to learn:  we first had to load the no-longer-included Synaptic Package Manager to grab some of the software libraries and utilities not available in the Software Center catalog.  And, of course, get rid of that silly Unity desktop that only works well for folks who only do one thing at a time with their computers.  We have to have lots of toolbars visible and lots of  workspaces to which we can jump with a single click, which Gnome gives us.

Not surprisingly, some of the more esoteric and least-used packaged software still have a few surprise unresolved dependency issues.  To my delight, GridEngine, a distributed job control system for compute clusters created by Sun Microsystems a dozen or more years ago, was available in the Software Center.  Since Oracle bought Sun a couple years ago, a lot of these tools have disappeared off the free download list at Oracle, folded back into the supported product lines, and the old packages are sometmes hard to find.

GridEngine is one of those transitional systems that, unlike the new applications designed to run under Gnome or KDE desktop management systems, was born and developed during the days of OpenWindows (contemporary with Microsoft Windows 2) and the Common Desktop Environment (CDE, which predates Windows 95), both high-end X-Window System desktop managers in their day.  X11 programs used to be a lot harder to write, and designed for networking more than having the client and server on the same workstation, so they tended to leverage the Unix philosophy of lots of little programs, each doing one thing well, working together, much more than the more integrated and abstracted desktop applications of today.

GridEngine is more likely to be installed on an Ubuntu machine as a client or, at most, an execution node in an ad hoc cluster, rather than a master host, so would not usually run the graphical grid manager, qmon.  But, Open Source being what it is, the whole package is available.  However, the “just works” philosophy of Ubuntu breaks down here, as the dependencies of the archaic and arcane OpenWindows flavor of the graphical component aren’t checked very thoroughly, and there is a bit of a problem.  The application depends on the X11 font server, a client-server application designed to facilitate running X11 clients on a server and displaying them on a different X11 server that might not have all of the requisite fonts loaded.  Also, because CDE relied heavily on licensed Adobe Truetype fonts, the chain of dependency gets broken when it comes to fitting old non-GPL’d software into a Linux distribution.

When you get a GNU/Linux system distribution, everything in it is licensed under the GNU Public License.  You can install anything you want in addition to that, but you can’t package the extras and redistribute it  This also extends to the packaging system.  The Ubuntu Software Center has provisions for adding non-free (i.e., non-GPL) software repositories, but they aren’t going to intereact with each other, so complex packages like GridEngine, that depend on non-free components, come with “some assembly required.”  In my case, someone had already solved the problem for Ubuntu, so a Google search turned up a list of the missing packages and how to install them.  I’ve used GridEngine for years, but on Solaris and RedHat Linux systems.  Solaris, of course, was licensed from Sun (now Oracle) and had full support.  The old Sun GridEngine for Linux packages came with the non-free fonts and dependent packages integrated, because you got them from Sun–they weren’t on any of the five or six CDs (now two DVDs) that comprise the full Red Hat Enterprise Linux (or, as many of us who don’t need any hand-holding support from Red Hat use–CentOS).

So, at Chaos Central, the new dogs are gradually getting housebroken and have largely quit chewing on the furniture, i.e, have learned enough so they–to use another analogy, don’t respond–like HAL9000 from “2001: A Space Odyssey,” “I’m afraid I can’t do that…” when asked to perform tasks the other computers have been doing for years.  They’ve even learned, with larger memory and faster processors, to do new things.

Here at Chaos Central, we observe the Christmas tradition in a more subdued manner: a small celebration with close family who are practicing Christians, with small gifts, some hand-made, and exchanging end-of-the-year greetings with friends.  And, since, by coincidence, the holiday does happen at the end of the calendar (and tax) year, we do evaluate our balance sheet and make a few last-minute gifts to charities, as well as gifting ourselves with any tax deductible business purchases that were on the near-term planning cycle.  A truly secular side to the “shopping season.”

In this topsy-turvy economy, where millions are unemployed but there is no shortage of merchandise made “off-shore,” and the number two and three brands sell well only because the number one brand sold out during the enforced shopping frenzy, it makes sense to consider making small changes to how we buy things, to reverse the economic trends that have brought us to the brink.  Competition is healthy: the existence of near-monopolies stifles innovation, despite the fact that innovation may have created the monopoly in the first place.  That’s one reason we put off buying computers: There are simply too few alternate choices.  It is much too late to “Buy American,” because very little manufacturing is done in this country anymore.  Almost all computers, whether running Microsoft Windows or Apple OS/X, are manufactured offshore.  And, those are the only choices of operating systems in the big-box stores. But, we can at least buy things assembled in America, and with a choice of open operating systems, if we look for them.

In our case, it is time to upgrade our aging stable of computers, reassigning an 8-year-old workstation now suitable only as a graphics terminal for virtual machines (and not very good at that), and a 4-year-old laptop with limited memory and disk size.  We need a laptop suitable for hosting multiple virtual machines and a full multi-media desktop to adequately support our business projects. These are overdue, postponed while we weathered the deepest and most personal effects of the Recession.  Things fall apart.  Not literally, but the thread of progress gets unraveled when there is no growth due to lack of capital.  [Lest we get confused, capital is not profit--what is wrong with much of America is the failure to invest in capital, in an attempt to keep up the appearance of profit during downturns.]  Computers last upwards of ten years or more if properly maintained (we have one, a Sun workstation, still running after ten years, and 15 and 20-year-old “retired” computers that will still boot up), but they are not cost-effective after four or five years, as they simply cannot do the work to remain competitive against newer systems, and are often not able to run newer software efficiently, if at all.

For some years now, adding a new computer running Unix or Linux to the network at Chaos Central has usually involved buying an off-the-shelf machine and stripping off the unwanted default operating software–i.e., the currently shipping version of Microsoft Windows–or ordering piece parts and building a bare machine from scratch, which is possible for desktop machines but difficult in the case of laptops.  In both strategies, the machine is not ready for use until a suitable replacement environment has been installed. Server-class machines can be (and have been) ordered with no installed operating environment, but the choice of portable systems and compatible desktop workstations has been limited to systems manufactured by Apple, running the OS/X operating system, or a wide variety of other Intel and AMD-based machines–all running Microsoft.  While OS/X is a variant of Unix (the Darwin microkernel port of BSD),  GNU/Linux, Oracle Solaris, and FreeBSD are more commonly compatible with the server systems that we administer and program for clients, so those are what we want on our desk and in our luggage.

Fortunately, there is a large enough market, 20 years into the GNU/Linux revolution, so a number of enterprises have sprung up to build and sell systems that run Linux “out of the box.”  A few major manufacturers, like Dell, did offer Linux choices at one time, but for various reasons–too small a segment of the commodity desktop/laptop business at that time to diversify software choices; and/or problems with Microsoft OEM licensing agreements that applied to product lines rather than individual machines–they dropped the offerings, except for the much smaller and more customized server product lines, in which case they only sell licenses and media: installation and configuration is left up to the buyer.

Small-footprint desktop, preloaded with Ubuntu

However, near west coast port cities, like Seattle, San Francisco, and Long Beach, the ready availability of computer piece parts in economical small lots from tier 1 importers makes it possible for small businesses to build custom non-Microsoft computer systems at nearly-competitive prices.  As it turns out, the market for Linux workstations overlaps with the market for high-end video game machines–with powerful graphics, multi-core processors, and lots of memory–so there is a plentiful supply of components, most of which aren’t found in commodity desktop machines anyway, so the price difference is well within reason.

We like a bargain as well as anyone else, but, as a small home-based business ourselves, we prefer paying a little more, knowing that that extra is providing a living wage to fellow entrepreneurs and folks who love what they do, not boosting the portfolio of an executive as a bonus for outsourcing the entire product and support pipeline to southeast Asia.  We bought our new machines, a high-end laptop and a workstation powerful enough to serve multimedia applications, from Zareason, a small company whose owners we met at Linuxfest Northwest last spring, where we got to check out their offerings.

Buying locally-assembled products isn’t bringing back “Made in America” factories, but it’s a start toward turning a nation of consumers into a nation of producers who take pride in what they make with their own hands and minds.    We’ve written here a lot, recently, about our adventures on our “Made in Oregon” tandem bicycle, and we’re now configuring the next generation of Linux computers, “Made in California.”

Faced with a longer, more difficult bike trip, we augmented our bicycle camping equipment and actually managed to work in an overnight bicycle camping trip to test our gear and our fitness, after having not ridden for a month. A week or so before leaving, we had hosted a succession of late-season bicycle tourists headed south on the Pacific Coast bike trail, and had ridden with the last group on a final 30-mile “training ride,” not exactly a proper training and conditioning regimen for a planned 400-mile fully-loaded tour.

One of the factors affecting our pre-tour training was the need to catch up on work projects largely shelved for our September excursion. The other was the onset of cool, wet weather in the Pacific Northwest. When we finally left on the final stage of Tour 2011, headed east through Montana before angling southwest toward Florida, morning frost followed us as far as St. Louis. Finding ourselves riding 60 miles a day in 80-degree heat and searing sun was, quite frankly, a shock. That, combined with road conditions unsuitable to our equipment, led to modifying our tour to suit our capabilities, in mid-tour, well documented in earlier posts, as was the long trip home across I-10, I-8, and I-5.

When we at last arrived back at Chaos Central, we found our network down, from a power outage incurred several days earlier during the first winter storm of the season. Getting the services back on line was necessary before resuming work projects. While we were gone, our landscape contractor had been busy, with most of the major digging, rock work, and large plantings done. But, much detail remained, taking a couple of weeks of distraction. A scheduled servicing of our now-not-so-new Jeep Patriot showed that the 35,000 miles we had driven since January, mostly at freeway speeds, had worn out the factory tires. Indeed, the noise level in the car had grown steadily on the trip home, as the wear bands moved closer to the road.

In the midst of the emergent work, which included some software issues on one customer’s server, email issues with another, and web updates and issues for several others, we began to unpack, finding places to stow our newly-revised camping gear complement, and performing cleanup, tuning, and reassembly of the Bike Friday “Q.” The rain fly on the tent was a bit musty, having been packed since that last dew-soaked morning on the shores of Lake Okeechobee nearly two weeks before, but aired out fine and was repacked. The bike did not seem to suffer as much as we feared, after its dowsing with brackish water on the ill-maintained bike trails in South Florida. Application of an aircraft anti-corrosion treatment (ACF-50) on the trailer parts and some of the lower frame parts seemed to take care of visible effects. But, the real shock was the discovery of a broken spoke on the rear wheel: this had undoubtedly occurred during our mad dash down the Overseas Highway which had resulted in three flat tires, and loosened the headset and the trailer hitch. I had probably ridden the 76-mile day on it, but hadn’t noticed any handling problems, since the wheel is built for tandem loads.

Another casualty of the Marathon Gauntlet: a broken spoke on the rear wheel.

Fortunately, the broken spoke was on the left side, so could be replaced without removing the freewheel cassette. Bike Friday does include two spare spokes of each of the three sizes needed. But, we did not have the freewheel removal tool in our kit, an omission we quickly remedied with a stop at REI on our next trip into the Big City, along with other supplies to finish the post-tour grooming of the bike, something that is progressing slowly.

Work still hasn’t caught up: a couple of projects have yet to be restarted; planned end-of-the-year computer upgrades have not yet been ordered. When the bike is finally assembled, we need to construct indoor window inserts for the winter, an alternative to simply taping plastic to the old single-pane windows at Chaos Central. The lumber and plastic film awaits. All we need is time…

End of a hard season: salt-crusted bike cap