Tinkering is, historically, the repair of tinware, usually by itinerant craftsmen.  Modern usage extends the term to any kind of more or less informal modification or adaptation of something.  If the object is intended to be useful or repurposed, we say it has been “tinkered with.”  If the purpose is to make an art statement, we resort to French, and call it “bricolage.”

A scrivener is traditionally a transcriptionist, someone who writes down what an illiterate person needs to have in print for legal or financial purposes.  Scriveners are still fairly common in Third-World countries, and in the First World, we use professionals to help us with legal and other formal paperwork.   In the modern age, reading and writing is more or less a universal skill, but computer coding is not, so we commonly also employ a scrivener to write down what we want a computer to do.   I think the term “scrivener” is more descriptive than “programmer.” As someone who revises more code than writing original code, we often use the combination, “Tinkers and Scriveners” as our informal motto.

In our last episode, we described a “just for fun” practice, describing (a word derived from “scribe”)  to our computers how to take pictures of our driveway, turn them into a timelapse video, and make them available on the Web.  To extend and refine this concept, we tinkered with the scripts this week, to automate the process and add an audio track, plus fix a few issues.

Try it out:  http://www.parkins.org/webcam

As part of the allure of having a video surveillance system, we had included a weather report along with the “real time” view.  The process is simple:  “Go get the weather report, take a picture, and display the picture, time, and current weather report in a web page.”   That worked fine when it was just me running it.  But, as soon as I posted the URL (Uniform Resource Locater, or web page name) to Facebook, that World-wide Eater of Time, I immediately got a “nastygram” from the weather service informing me that I had abused my (free) automated query privilege by asking for many weather reports all at once.   I don’t have all that many “fans” eagerly awaiting my next post, so I presume it was the WordPress.org  and Facebook robots burrowing into the link to see where it went–many, many times.  The search engines do this to score your site/post and the spammers also are looking for paths that lead to posts with open comment access.

So, the first order of business was to rethink the weather report.  The service only updates their reports a few times an hour, so there is no need to ask for a fresh report every time the page is accessed.  So, we told the computer, “Remember the weather report, and only get a new one if the one you have is more than 10 minutes old.”  We don’t expect a lot of traffic, but this ensures at least 10 minutes between weather updates, no matter how many visitors we get at once.

Here’s what that revision looks like, in patch form:

9a10
> import os.path
37,39c38,46
< 
< f = urllib2.urlopen('http://api.wunderground.com/api/...key.../geolookup/conditions/q/WA/Shelton.json')
< json_string = f.read()
---
> stale = time.time() - 600
> if ( os.path.getmtime('weather.dat') < stale ):
> f = urllib2.urlopen('http://api.wunderground.com/api/...key.../geolookup/conditions/q/WA/Shelton.json')
> json_string = f.read()
> w = open('weather.dat','w')
> w.write(json_string)
> w.close()
> w = open('weather.dat','r')
> json_string = w.read()

A minor change, but one that prevents breaking the application programming interface (API) agreement with the weather site. We can’t control how many hits we get on our web site, but we can control how often we hit theirs.

Since we are now taking a picture every 15 seconds, and the process runs all day, taking exclusive control over the camera hardware, we no longer can take snapshots in “real time” like we did originally. However, 15 seconds isn’t a long time, so we simply copy the picture into the “current” view every time we take one, and skip the “snap the shutter” part of the weather report page.  That part we had in the last post.  What we did this time, though, was add some code to update the time displayed on the screen and refresh the picture every 15 seconds.  This requires some browser code, in Javascript,  We also added some code to show when the weather report was last updated by the weather service.  The patch file looks something like this (we also cleaned up some other code that is no longer necessary):

28c30
< <h1>The view from Chaos Central %s</h1>
---
> <h1>The view from Chaos Central <span id="nowTime">%s</span></h1>

47a48
> updated = parsed_json['current_observation']['observation_time']
49,50c50,72
< print "<img src=\"/images/webcam.jpg\" />"
< print "<p>The current temperature in %s is: %s F / %s C<br />" % (location, temp_f, temp_c)
---
> print """
> <table><tr>
> <td>
> <img src="/images/current.png" id="currentImage"/>
> <script language="Javascript">
> setInterval(function() {
> var currentImageElement = document.getElementById('currentImage');
> currentImageElement.src = '/images/current.png?rand=' + Math.random();
> var now = new Date();
> var h = now.getHours();
> var m = now.getMinutes();
> var s = now.getSeconds();
> formatnum = function( num ) {
> if ( num < 10 ) { return '0' + num; }
> else { return '' + num; }
> }
> var time = formatnum(h) + ':' + formatnum(m) + ':' + formatnum(s);
> var nowTimeElement = document.getElementById("nowTime");
> nowTimeElement.innerHTML = time;
> }, 15000);
> </script>
> """
> print "<p>The temperature in %s is: %s F / %s C<br />" % (location, temp_f, temp_c)
52a75,76
> print "Weather Data %s<br />" % updated 
> print "Reload page to update weather: image updates automatically every 15 seconds<br />"
54a79,91
> print """
> </td><td>
> <ul>
> <li><a href="/timelapse0.html">Timelapse video of Monday</a></li>
> <li><a href="/timelapse1.html">Timelapse video of Tuesday</a></li>
> <li><a href="/timelapse2.html">Timelapse video of Wednesday</a></li>
> <li><a href="/timelapse3.html">Timelapse video of Thursday</a></li>
> <li><a href="/timelapse4.html">Timelapse video of Friday</a></li>
> <li><a href="/timelapse5.html">Timelapse video of Saturday</a></li>
> <li><a href="/timelapse6.html">Timelapse video of Sunday</a></li>
> </ul>
> </td></tr></table>
> """

Those of you familiar with HTML and web page layout will also notice that we converted the page into a table and added a column with a list of links to the timelapse videos, which weren’t really visible before, since we were testing them.

Now, to make all this useful and automated, we told the computers (plural, remember–the video production takes place in another, bigger machine) to make a new video every hour on the hour and add background music to the video.  For the first part, making a video of the images captured so far, we simply add the makevideo.sh script to a cron job.  “cron” is a daemon in the Unix/Linux system that runs programs at specified times, periodically. (A daemon is not to be confused with ‘demon.’  A demon is an evil force, a daemon is a helper or servant –the term comes from the Greek, adopted by the geek culture in the 1970s.)  Because our little Raspberry Pi runs on Universal Time (UTC, what used to be called Greenwich Mean Time), and daylight on the North American West Coast, eight time zones later, spans two days under UTC,  we have to put in two jobs for each time lapse image set, one for the morning and early afternoon, and one for late afternoon and evening:

0 16,17,18,19,20,21,22,23 * * 0 /home/larye/TIMELAPSE/makevideo.sh 6
0 0,1,2,3 * * 1 /home/larye/TIMELAPSE/makevideo.sh 6
0 16,17,18,19,20,21,22,23 * * 1 /home/larye/TIMELAPSE/makevideo.sh 0
0 0,1,2,3 * * 2 /home/larye/TIMELAPSE/makevideo.sh 0
0 16,17,18,19,20,21,22,23 * * 2 /home/larye/TIMELAPSE/makevideo.sh 1
0 0,1,2,3 * * 3 /home/larye/TIMELAPSE/makevideo.sh 1
0 16,17,18,19,20,21,22,23 * * 3 /home/larye/TIMELAPSE/makevideo.sh 2
0 0,1,2,3 * * 4 /home/larye/TIMELAPSE/makevideo.sh 2
0 16,17,18,19,20,21,22,23 * * 4 /home/larye/TIMELAPSE/makevideo.sh 3
0 0,1,2,3 * * 5 /home/larye/TIMELAPSE/makevideo.sh 3
0 16,17,18,19,20,21,22,23 * * 5 /home/larye/TIMELAPSE/makevideo.sh 4
0 0,1,2,3 * * 6 /home/larye/TIMELAPSE/makevideo.sh 4
0 16,17,18,19,20,21,22,23 * * 6 /home/larye/TIMELAPSE/makevideo.sh 5
0 0,1,2,3 * * 0 /home/larye/TIMELAPSE/makevideo.sh 5

Now, the web server owns the scripts that generate the web page and take the photos, but we share the folder on the external disk drive that holds the videos and I own the video building scripts on the CentOS server, so I run this set of  cron jobs under my own user account.  The timelapse show for the current day starts at 8:00am PST (1600 UTC), and runs until well after dark ( i.e., 0300 UTC, or 7:00pm PST).  As the days grow longer, if I am still running this experiment, I will need to extend the times, or use the astronomical data to control whether or not the video needs to be generated.  At the current display rate, the timelapse video covers an hour every 30 seconds.  In mid-winter, daylight lasts less than 8 hours at this latitude, but nearly 18 hours at the summer solstice, so the video will stretch out from the current 4-minute running time to nearly 10 minutes.  The camera program starts at 4:00am and waits for daylight to start recording, shutting off automatically at dark.  The programs are written so that it would be trivially easy to change the frame rate to keep the length of the video shorter by advancing the time scale faster later in the day, as the days get longer.

The last bit of code added was for an audio track.  For this, I told the computer, “Find a song in the music library that is about the same length as the video, and add a sound track using it.”  I have enough tunes of varying length in the library so that there is a different one every hour, and hopefully enough in between so we get different ones each week as the days get longer.

Part of this exercise was to get some practice writing in the Python language.  However, the song-picker, I wrote in my old standby, Perl, just to get it done quickly.

#!/usr/bin/perl -w

%list = (
 108 => "Sintel/Jan_Morgenstern_-_01_-_Snow_Fight.mp3",
.
.  # lots more songs here, deleted for clarity...
.
 225 => "Kai_Engel/Kai_Engel_-_09_-_Embracing_The_Sunrise.mp3");

$frames = $ARGV[0];
$rate = $ARGV[1];
$runtime = $frames / $rate;

foreach $key (sort { $a <=> $b } keys %list) {
 print STDERR "check: " . $key . " against " . $runtime . "\n";
 if ( $key >= $runtime ) {
 print $list{$key};
 exit();
 }
}
print $list{$key};

This program is called by the shell script that runs the video:

#!/bin/bash

cd ~/TIMELAPSE
rate=8
frames=`ls ./images/${1}/img*png | wc -l`
# find a music track that is about the same length as the video
song=`./songs.pl $frames $rate`
rm surveil${1}.mp4
~/bin/ffmpeg -framerate $rate -i ./images/${1}/img%04d.png -i ./music/${song}
-c:a aac -strict experimental -strict -2 -r 30 -pix_fmt yuv420p surveil${1}.mp4
echo $song > surveil${1}.txt

This also records the name of the artist and the song (for the credits) in a file, the contents of which are displayed by the Javascript code on the web page that plays the video clip.  This is still crude, using a frame.  The other part of this learning exercise is to hone my Javascript skills and learn to use AJAX (Asynchronous Javascript And XML–actually more often JSON rather than XML)  to pull data from the server and format it so the page is well-formatted and updates seamlessly.  The time updates on the “real-time” page also needs work to format it the same as the original time statement.  One oddity in that is that the initial timestamp is the server time, but the updates are for the timezone of the browser, so the hour will change if you are in a different timezone.  This violates the “least surprise” principle of good web and program design.

Finally, here is one of the video display pages, showing the mechanism to update the current video file and song title.  I should rewrite this as a Python script, so it accepts the index of the video and creates the proper page, instead of repeating the HTML code seven times and having to edit all of them for each code change, which leads to errors and inconsistency.  The random number function added on to the file URL in the Javascript code is a hack to make the browser reload the file–if the URL doesn’t change, the browser will use the cached (old) version of the file, so that the video and song title (and photo in the ‘real-time’ page)  wouldn’t update until the cache expired (usually a couple of weeks–not very effective for an hourly or 15-second update).  That’s always been an issue when fixing customer web sites–they don’t always see the change unless they clear their browser cache.  If they are working through a proxy server, they don’t have control over the proxy caching.  A cache is  a neat way to speed up the Internet for sites you visit a lot, but it can be annoying if the browser or proxy doesn’t check the file modification time against your cached copy.  Inaccurate time-keeping on the user end can also mess up cache coherence and browser cookie management.   Fortunately, most computers now get their time updates from the Internet automatically, so this is less of a problem than it was in the old modem/dial-up days when we couldn’t afford the overhead of a lot of background processing over the link.

<html>
<head><title>Webcam Timelapse</title></head>
<body>
<h2>Sunday</h2>
<table width="500px">
<tr><td align="left">
<a href="timelapse5.html">Saturday</a>
</td><td align="center">
<a href="/cgi-bin/webcam.cgi">Home</a>
</td><td align=right>
<a href="timelapse0.html">Monday</a>
</td></tr></table>
<video width="320" height="240" controls>
<source src="/TIMELAPSE/videos/surveil6.mp4" type="video/mp4" id="vidFile6">
</video>
<p>Music track: <iframe id="audFile6" src="/TIMELAPSE/videos/surveil6.txt" height="55px" width="300px" onload="upDate()"></iframe></p>
<script language="Javascript">
function upDate() {
 var currentVidFile6 = document.getElementById('vidFile6');
 currentVidFile6.src = '/TIMELAPSE/videos/surveil6.mp4?rand=' + Math.random();
}
</script>
</body>
</html>

So, there we have it: a project that is realized in a variety of programming languages and data formats: Python, Bash (Bourne-Again SHell), Perl (Practical Extraction and Report Language or Perniciously Eclectic Rubbish Lister or just short for ‘Pearl,’ depending who you ask), HTML5 (HyperText Markup Language version 5), and JSON (JavaScript Object Notation), MPEG 4 video and MPEG 3 audio, H264 video codec and AAC audio coding, and runs on several different Linux distributions, Raspian (Debian 7 on Atom CPU) and CentOS7 (Red Hat unlicensed version on 64-bit Intel CPU, as a virtual machine running on a CentOS6 host), using the Apache2 web server software configured to use CGI (Computer Gateway Interface, not Computer Generated Images, as used in the movies) and directories aliased on a shared disk drive. We use Secure Shell (SSH) with a password-caching agent to transfer files between the web server and the video processor, and a API (Application Programming Interface) to retrieve weather and astronomical data from a remote web server. We also use a script that queries an external “whats-my-address” server to track the variable IP address of the web server and link to it by a redirection statement on our public web server, routing the request through a firewall rule and port mapping to avoid a lot of hacker traffic on the public HTTP (HyperText Transport Protocol) port (80). All of the software used is freely available, shared for the benefit of all who use it and contribute to the software community: no proprietary, hidden code, no expensive training classes, just relatively inexpensive books or free on-line documentation and how-to-do-it forums. This is literacy in the 21st century–the ability to express yourself through ubiquitous and free technology, with the freedom to tinker–if you don’t like the way the software works, change it, or write something completely different. Expand your mind. Share your code and write about your experience.

Followers of the computing side of the Unix Curmudgeon blog will note that our 20-year dalliance with Linux has expanded from the server, workstation, and laptop incarnations to the appliance, namely Raspberry Pi, a tiny single-board card that runs Linux and uses an HDMI TV as a monitor. Of course, we’re familiar with the other fruity moniker, the Apple, and have even used Macs from time to time, since the advent of OS/X, the BSD-based operating environment introduced around the turn of the century:   use generally confined to command-line scripts in terminal windows, as opposed to the graphical desktop made popular with the original MacIntosh.

This summer, Judy–the Nice Person complement to the Unix Curmudgeon–who has patiently put up with the Linux-only network at Chaos Central until now–bought herself an iPad to replace the severely outclassed and underpowered Netbook road machine, which hadn’t fared well in the progressive upgrades over the years from Ubuntu 10.04 to Mint 17 (based on Ubuntu 14.04). Naturally, she has fallen in love with the tablet, the latest successor to “the computer for the rest of us.”

Meanwhile, the Curmudgeon has been making do between the Android phone and the Netbook during his limited-duty recovery from surgery earlier, akin to typing with boxing gloves while blindfolded.  So, the Nice Person, being a sentimental soul, designated a second iPad as a belated birthday present for the septuagenarian Curmudgeon.  OK, iOS, like Android, might have deep Unix roots, but, as “locked” appliances, aren’t multiuser and don’t have a command shell or root.  They also have “apps,” which aren’t “open,” though many of them are free (as in beer), and which, then aren’t customizable and it is less easy to roll your own custom apps.

So, the annoyances abound.  One of the first things of note is the way Apple deals with technologies they don’t like: they simply don’t support them.  Thus, none of the five dozen or so videos we’ve produced in the last couple of years will play on the iPad, with audio and/or video missing: we used the LAME MP3 coding for the audio track, and IOS only supports the newer Advanced Audio Coding format (OK, it’s been around for 17 years, but MP3 is still more common).  This in itself isn’t a huge problem, but it does mean re-generating all of the videos from project files, for which some of the source components have been moved, requiring hand-editing the text-based project files and searching for the missing component files.  Now, we do have some conversion utilities, but they inconveniently do not include the requisite audio coding.  The other issue is that we normally render videos at 25fps, even though the camera runs at 30, and Apple likes 30fps, period.  Fortunately, the video coding remains at H.264.  The real problem in all this was ferreting out the real cause of the problem, wading through the often less-than-helpful online help forums. The good news is that most other video software will accept the Apple set of protocols.

And so it goes: we have managed to find SSH apps that let us interact with the other *nix machines, with the exception of our bastion server, which requires host identification that we can’t generate or set on a rootless machine.  However, we can go through a third machine that is external to the network and registered with our server.

Some of the apps are just plain annoying or obtuse, with few clues as to how to get them to behave the way you expect ( no doubt some of the problem is unfamiliarity with the iOS gesture vocabulary that 4-year-olds seem to find intuitive).  As with all rapidly-changing technology today, the helpful hints found online only worked with the previous version of the system you just upgraded to.  But, yes, the slim tablet is much more portable, faster, brighter, and higher resolution than the old netbook, and the on-scene keyboard is much better than the tiny one on the phone… The apps put out by many of the sites we visit most make better use of the display than do the web browsers. I’d like to see some of the apps more generally available for Linux as well as the tablet OSes.

Oh, by the way, this post was composed, graphics and all, entirely on the iPad.  Who says old dogs can’t learn new tricks?

Once again, as winter draws to a close, it’s time to assess our systems, shovel out the office, and plan for the year ahead.  But, we seem to be a bit late, as everything catches up at once.  This has been one of those weeks/months where things fall apart when touched.

With tax time rapidly approaching, it’s that time of year to fire up the Windows XP virtual machine to run TurboTax.  Realizing that Microsoft is finally, in April of 2014, pulling the plug on the venerable platform first released in 2002, after three service packs, innumerable hotfixes, and an on-again, off-again sliding End-of-Life date, not to mention three successor (if not successful) systems.  Of course, many of us Unix professionals who don’t depend on Windows for our livelihood have nearly abandoned Microsoft altogether, but still are plagued with having to keep a working copy of Windows around “somewhere,” increasingly as a virtual desktop residing on a Linux or Apple workstation or server.

Vista was a complete failure: our copy–that come with “rover,” our 2007 Compaq laptop that has run Ubuntu Linux (and been updated at least every 2 years) since we unpacked it–spent its life unused but available as an alternate boot option until the hard drive failed and was replaced in 2012, with no hope (or desire) to revive the Windows installation. We had acquired a copy of Windows 7 with our HP Netbook ‘mini’ in 2010, which copy also lay dormant, minutes after unpacking it, taking up hard drive space until recently.  With the increasing dependence on Windows security (if there is such a thing) solutions for networking in the government, it looked like we might have to revive it, just to do business.  The first boot-up of Win7 in over three years took 3 days to complete, installing the updates, with multiple reboots.  Happily, in the meantime, the Unix/Linux support team, of which I am part, found a Linux solution to our immediate needs, so the NTFS partitions lapsed into dormancy once more–until the prospect of the demise of XP sent us shopping for an updated alternative for the Microsoft interoperability problem.  We do have some Windows applications that happily run under WINE, the Linux WINdows Emulator, but many others don’t.

Having migrated a friend’s home system from Apple (due to a serious case of narcolepsy in her Imac, a rare but aggravating problem that Apple seems to want to ignore) to a shiny new HP laptop, we had become painfully introduced to Windows 8, that ‘new idea’ from Microsoft that turns your desktop or laptop into a badly designed giant cell phone with no phone service.  A few minutes with that made me almost long for Vista.  But, realizing that Windows 7 seems to be Vista overlaid with the XP desktop, we decided the best option for the Chaos Central network would be to integrate Windows 7 into our stable of virtual machines, to be pulled up on demand, anywhere on the network it was needed.

Attempts to migrate the Windows 7 installation on the Netbook to a virtual appliance proved to be frustrating, as it appears to be difficult, if not impossible, to create a copy that doesn’t demand to see your genuine Microsoft license to boot up, which is difficult when you have a machine that doesn’t have an optical drive, and did not come with an install disk in the first place.  Thinking (wrongly, it turns out), that making a ‘recovery disk’ on a thumb drive would suffice, we proceeded to do so, which promptly destroyed the Ubuntu boot partition, rendering the machine totally useless, since that is also where the GRUB boot manager keeps the information on how to boot to all the systems, including Windows.  Erk.

So, time to reinstall Linux.  Having also been increasingly disenchanted with the Unity desktop (which turns your Linux desktop or laptop into a decently designed giant cell phone with no phone service), I decided to install Mint Linux (yet another Debian-based variant, similar to Ubuntu), with the XFCE desktop, a lightweight system that is annoyingly similar in appearance to the XP desktop, but nonetheless familiar and functional, as far as menu navigation goes, and with the ability to paste hot links all over your desktop instead of in a peek-a-boo toolbar with inscrutable icons instead of text labels.

Of course, once Grub was restored, we could boot to Windows, but, in process of trying to get around the Grub issue in order to export the Windows system, we ended up running the newly-created Windows Recovery disk, which restored the Windows 7 installation to Day 0 (no patches, no added software or files)–and promptly refused to boot again without the Genuine Microsoft Windows 7 installation disk, which we still don’t have, and for which the “Recovery Disk” is not a substitute, despite the fact that is the only thing we end users can create from the installed system we bought and paid for.  Have I mentioned lately how much I dislike Windows?

At this point, we are at the verge of simply continuing on with a static XP system, for as long as Quicken and Electric Quilt will support their applications on it.  Setting aside this issue for a while, having given up a chunk of our on-line and off-line storage to yet another unusable Microsoft product, we turned our focus back to the primary business of making and supporting Linux software, and the goal of organizing the accumulated piles of paperwork and other paraphernalia in the office.

Just then, my desktop workstation, ‘zara,’ which was recently converted to CentOS6 to be a bit more compatible with the customer development systems on the server, suddenly shut down in the middle of browsing the web.  That usually means overheating.  We had recently done a bit of mid-winter housecleaning on ‘strata,’ our big development laptop, which had been shutting down because of overheating, and also had thoroughly cleaned the interior of the virtualization server when we replaced the hard drives in it last month.  The laptop fan had stopped running, but a thorough cleaning and redressing the wire harness got it running again, solving that problem.

The desktop machine was another issue.  The CPU heat sink resembled the filter in the clothes dryer, and the fan was barely turning over.  After cleaning the heat sink fins of lint and giving a fan a few spins in an attempt to “loosen it up,” it still wouldn’t turn over more than a few turns.  So, we pulled it and peeled off the sticker over the shaft bearing. intending to re-lubricate the bearing.  Unfortunately, the bearing seal on this fan was plastic instead of rubber, and couldn’t be easily removed.

But, we had recently retired our Internet gateway server, ‘armonk,’ a 12-year-old IBM desktop machine running FreeBSD, replacing it with a Raspberry Pi, which is more than adequate for that use.  The IBM had been running smoothly, so I  went to the temporary holding area for dead computers (which has encroached on the studio area downstairs), popped the lid, and pulled the CPU fan.  It spun smoothly, so I bored out the mounting screw holes to countersink the shorter screws for the AMD CPU heat sink on zara, reassembled the system, and we’re back on the air again.

So, here we are, behind in our work, with the retired IBM now truly inoperative, no Windows 7 working copy, taxes undone, and the office and network still not completely reconfigured as we planned.  The fan fiasco occurred in the middle of replacing the printer table under the window with a storage cube system.  The old HP 1200 laser printer, which we haven’t used for several years, was finally taken off “standby” and retired along with the IBM server.  The storage cube now holds the ethernet switch, wireless router, Raspberry pi network servers and overflow books, in preparation for moving Judy’s desktop workstation, ‘giskard’ from her downstairs studio to the table formerly occupied by the IBM, and the old laptop, ‘rover,’ downstairs, to make space on the office table.

Oh, and the color laser printer suddenly decided it is out of cyan and yellow toner, printing everything with a magenta cast.  With receipts on the government contracts running behind (30-day due dates are simply ignored, by official policy) and a few months of lean billable hours behind us, the prospect of shelling out several hundred dollars for new toner cartridges just doesn’t fit the budget this month.  The ink-jet printer in Judy’s studio is out of black toner–we have a new cartridge, but waiting to move the workstation upstairs to service that one…

So it goes.  Spring cleaning continues: the goal here was to unclutter the office and upgrade the network services with fanless/solid-state low power devices that are reliable and recover automatically after power failures.  At the same time, it is hard to schedule a shutdown time to open the cases and blow out the accumulated dust that is the primary killer of computers, and to replenish supplies.  We don’t print a lot these days, and toner seems to have a finite shelf life that sometimes is longer than the useful life of the printer itself, so we tend not to order ahead.  A couple years of competitive bidding on contracts that trimmed upgrade/replacement budgets to the bone, plus the low ratio of billable to overhead time during contract turnover times means keeping vital systems running well past their reliable life, risking work disruption due to inevitable disk and fan failures.

On a final note, moving Judy’s old workstation upstairs seems to have killed the monitor, an old, early flat-panel model that had been cantankerous at best.  So, we’re up and running on our one remaining ancient and massive glass CRT monitor, until we can afford a new modern one to service both her workstation and the Dell virtualization server.  Right now, we have to switch the cable back and forth for the rare times we need a console on the big Dell server.  I did dig out an old KVM  switch (keyboard-video-mouse, not to be confused with Linux Kernel Virtual Machine, which is what we run on the server) to share one console between two machines, but the circuitry in that had failed either from lack of use or too much moving.   We’re due for another desktop machine, budget permitting, as ‘giskard,’ a Linux machine built from spare parts at least six years ago, isn’t modern enough or robust enough to run what we need, and the audio has never worked right, and we are way overdue for new monitors.