What To Do With Old Carpet

Carpet is not used up once it is no longer good for use in the parlor. There are lots of uses (reuses) for old carpet.

• Unless it smells like cat:
• Insulate the dog house
• Make a cat scratch post
• Cut into strips and put it on the garden (especially if it smells like cat)
• Use it as a drop cloth for painting
• Cover or separate furniture when moving
• With bicycle hanger hooks, attach it to the eaves of a garage or shed, paint a target such as a baseball strike zone on it, and allow your aspiring young pitcher, golfer, or place kicker to practice in style. (Note: color choice may impact effectiveness.)
  
• Pad or protect a pickup truck bed, sides, or rails, tailgate
  
• Another site adds:
  

  • Cut up carpets for use in cars as floor mats or to line the trunk.
  • Cut into small circles and place under the feet of heavy furniture.
  • Take camping for a doormat, or to put under sleeping bags
    
  • Insulate your compost pile over the winter
• A commenter at yet another site suggests using it in a greenhouse (which would go as well for any other indoor/outdoor area where function outweighs beauty, such as a garage or barn)
  

How To Do Anything

As the title suggests, what follows is a strategy for accomplishing any goal, no matter how easy or how hard. Some of the rules may not seem to apply to your goal. Some of it is age-old wisdom, while some is just stuff I've noticed. Which is which will almost certainly be obvious.

I use the terms 'task' and 'project' interchangeably in what follows, except for the connotation that projects are more complex than tasks. A simple task, however, can reveal or become a huge project. A project can also serve as a metaphor for a lifelong dream. The process is recursive: treat each task in a project as a project.

• Think First, Do Second
  Planning is only necessary if you want to succeed. Before you start work on some project, learn about it. While a novel approach sometimes strikes out of the blue, most of the time your 'novel' approach will be the first one that everyone else who ever tried to do what you're about to do thought of the first time, too. When you are learning about a subject area, don't be too quick to come up with a plan, but let the new information percolate. Time spent thinking, drawing pictures, or asking around will save many multiples in wasted effort, or will avoid the same amount in the paralysis of procrastination. It may also mean the difference between success and failure, or falling prey to threats for which you should have accounted. Periodically on the way to your goal, revisit your plan to make sure external events haven't changed your requirements, and to be sure you haven't gotten away from the plan.
  
  
• Read The Fine Manual
  A lot of things seem impossible until you know how to do them, but are easy once you do. If you don't know how to do something, perhaps someone else does. Few things are really new. In the modern era of search engines and instant communication, getting instructions has never been easier. No matter what the task, by the Green Tennis Shoes Principle, someone probably has a web page describing how to do it — with a printable checklist and a flash movie of the tricky parts, and a forum of users with answers to questions you didn't even know enough to ask. The instructions will generally also tell you how to mitigate any risks.
  
  
• Ask For Help
  People don't know you need help. Ask. Sometimes just asking even someone who has no apparent skills at all to help you will be enough to make you realize what you have to do. There's nothing like teaching a thing to make you learn it. But you most often will be surprised at how a fresh perspective will confront a problem, making what seemed hard before much less so.
  
  
• Divide and Conquer
  Almost by definition, any task worthy of a plan will have component parts which can be handled separately. Take on the largest or most difficult portion you can reasonably achieve while leaving the rest for later.
  
  
• Know What You Have
  Every project has finite resources. Most often this is time, but there may be some other key finite resource such as a raw material, money, distance to be covered, or pounds to be lost, for which you need to account more closely than time. You also need to consider the helpers and groups who will be available to you, and any who may oppose you. The opposition (even if that is only entropy) gets a vote, and so every part of every plan must account for as many kinds of failure as practical.
  
  
• Consider Dependencies Carefully
  One reason a project seems complicated is that one part may depend on other parts being done, or simply started, first.
  
  
• Set Deadlines
  Even if your project has no external deadlines, set them for yourself. Think carefully about these dependencies, and set your deadlines accordingly. Set milestones or benchmarks for each phase or portion of the project, in terms of the key finite resource.
  
  
• Do the Hard Part First
  If there are several independent parts to some project, you have the option to pick off some of the easier portions before tackling what you think will be the hard parts. Other things being equal, it's best to get the hard parts out of the way. This is especially true when "easy" and "hard" are actually euphemisms for "fun" and "not fun", or "rewarding" and "unrewarding". The hard part typically will have the biggest uncertainty in terms of time and resource requirements; doing it first allows you the greatest control over your own deadlines.
  
  
• Measure Twice, Cut Once
  After your plans are made, and you think you know what to do, go over those plans again. Start from what you are sure you know, such as a factory edge, a bank balance, or a spot on a map, and measure your key resource in a different way than you did before. Repeat this process until all measurements match.
  
  
• Do Something Next
  If you don't know what to do next, it usually means you haven't thought or planned enough. But in the middle of a project, it may be inopportune to go back to the drawing board. To avoid indecision paralysis, just pick something. Sometimes it will be a suboptimal choice, but most of the time will be as good as any other, and only rarely will you choose a task order that is harmful.
  Sometimes, just do what you can do. But beware of avoiding things you don't want to do.
  
  
• Don't Bang Your Head
  If you find yourself trying to do the same task repeatedly and having it not work, stop. If you are banging your head on a wall, it either means you need to look for a window, a door, a way around the wall, or you're working on the wrong wall. Perhaps you're just doing it wrong, and need to ask for help. Take a step back and look at the overall project. Is this wall even part of the plan? Is there something else you can do first? Sometimes nibbling at the edge of some other part of a project will make the whole thing easier in ways you didn't understand during initial planning. But most of all, doing something else will allow you to come back at the head-banging problem fresh, perhaps after your subconscious has had a chance to solve the problem.
  
  
• Serialize Parallel Steps
  Some jobs require, or appear to require, doing several things at once. Typically, however, it's possible to take those things one after another, repeatedly switching among them. For people who find it difficult to juggle many tasks at once, taking this serial approach to parallel tasks may make all the difference.
  
  
• Parallelize Serial Steps
  In Divide and Conquer, we saw that sometimes it's possible to accomplish parts of a task independently of one another. If resources permit, taking up several of these independent tasks at the same time, rather than one after another, may make doing them all easier. This is particularly true if there are helpers who can be working on the different pieces.
  
  
• Delegate the Repetitive
  Computers, robots, employees, and tools are helpers. They give you the ability to parallelize, but require time for setup and maintenance, as well as for coordination and inspection of the finished work. Many times a skilled or well-designed helper can perform a task better than you can. Sometimes one of them, especially in the case of humans, really ought to be your boss. Confront (or ignore) such concerns and focus on the project. Delegate, and apply your own ability where it is best used.
  
  
• Invent A Tool
  If you are having difficulty with a particular task, and no one seems to know how to do it, and you've followed all of the other points here, it may be time to step back from the process of doing, and become a toolmaker. Even if you lack the skill to make the actual tool, sometimes you can envision a tool that someone more skilled never thought of making, or never thought to apply to your use. Don't be afraid to invent a tool you will discard after the job. Toolmaking helps especially if you are banging the wall, or if you know you need to delegate a parallel task but don't have any helpers. The hard part will seem easy when you have the right tool.
  
  
• Completeness
  Finish all of the parts, even the ones that don't show. Dependencies lurk everywhere. An incomplete or sloppy job at a minor task here, a corner cut there, and pretty soon you are wasting key resources on reworking tasks that you thought were done, introducing new dependencies and foiling all your plans. Do things right the first time, and do them completely.
  

Each of the above points could get an entire blog entry, and someday they may. Each of them deserves examples and other justification. Many deserve some scientific at least philosophical underpinning. For all of that, brevity won out.

More sed Tricks

Sometimes I think sed(1) is the reason I like Unix. Well, it's one of the quintessentially Unix tools, anyway.

One of my favorite uses for sed is to rename a whole bunch of files all at once. Whether the problem is a spaces or other special characters in filenames, capitalization problems, or whatever, as long as you can see a pattern sed can probably fix it for you.

For instance, I just had to make a whole bunch of symbolic links to some files

audit_user.dir
auto_data.pag
auto_master.dir
exec_attr.pag
....

so that the links had the names:

audit.user.dir
auto.data.pag
auto.master.dir
exec.attr.pag

and so on. Sed to the rescue:

for f in *_* ; do
ln -s $f `echo $f | sed -e 's,_,.,'`
done

(If you try something like that, put an "echo" before the "ln" to test it out)

That's a fairly simple example, and in fact the Unix C-shell has that kind of search-replace built in. I don't use C-shell, because the standard Bourne shell /bin/sh and derivatives (such as the Bourne Again SHell /bin/bash) are better for scripting.

But consider the problem of turning off some, but not all, of the "init scripts" under a particular runlevel in a typical SystemV-style system, such as Solaris or Linux. Red Hat Linux solves this with the chkconfig command, and Red Hat admins may like to use that handy facility.

But for those of us who have heterogenous collections of systems to worry about, and even on Red Hat systems when digging under the hood, it would be nice to have a way to turn off (or on) several services at once.

A "runlevel" is sort of like a system mode, and the levels are not standardized but generally follow a pattern of sorts. The chkconfig link above gives a nice description of runlevels for Linux, but note that while under Linux runlevel 5 means X Window operation, under Solaris it means shut down.

In a System V-style system, the init scripts themselves are stored in /etc/init.d, with some reasonable name like 'apache' for the Apache web server or 'autofs' for the file system automounter.

Each runlevel has its own directory, /etc/rcN.d, which contains symbolic links to the init scripts in /etc/init.d. To control how a particular runlevel uses a given init script, the symbolic link is prepended with an "S" for Start, "K" for Kill, or sometimes another letter, which means to ignore. After the S or K is a number, like 01 or 25, used to sort the names. The init(1) processing runs each S script in alphanumerical order, so that services should get higher numbers than the more basic services on which they depend.

Renaming the files is a bit of a hassle, either from the command line or with a GUI, because each one must be done. From the command line in particular, changing just the first letter requires typing the whole file name, with the numbers.

So what has all of this to do with sed?

This little script renames all the files matching a list of patterns you supply, either from S##name to K##name or the other way. It preserves the numbers, without you having to type the whole name.

#!/bin/sh
#------------------------------
# Script : s2k Copyright 2000,Loren Heal
# Author : lheal
# Created: 20010305
# Known Bugs:
# TODO: only operates on current directory.
#(------------------------------
FROM=S
TO=K
FORCE=""
TEST=""

usage()
   {
   echo "$1 [-on|-off|-force|-test] expression [...]"
   echo ... where "expression" matches one or more of:
   ls -F ${FROM}*
   exit
   }

[ -z ''"${@}" ] &&  usage "${0}"

while [ -n "$1" ] ; do
   # echo "$1"
   case ${1} in
   "-on" )    FROM="K"; TO="S" ;;
   "-off" )   FROM="S"; TO="K" ;;
   "-force" ) FORCE="-f" ;;
   "-test" )  TEST="echo" ;;
   * ) for fname in `ls ${FROM}*${1}*` ; do
           tname=`echo ${fname} | sed "s/^${FROM}/${TO}/"`
           if [ -n "${tname}" -a -n "${fname}" -f ${fname} ] ; then
  && ${TEST} mv ${FORCE} ${fname} ${tname}
     fi
       done
       ;;
   esac
   shift
done

Tying Shoelaces So They Stay Tied

The bow knot we use to tie our shoes has some good things going for it. It's easy enough to learn, it's as quick as anything else to tie, and as importantly, it's very quick to untie. The trouble is, it comes undone too easily. I use a slight variation on the bow knot, which looks like a nicely tied bow knot but never comes untied until you untie it.

Athletes, children, even business people find it important to keep their shoes tied. Whenever I see some collegiate or professional athlete calling time out so that millions of people can watch him tie his shoes, I think "There's a guy who doesn't know how to tie this shoes!" And there are few things sillier than a man in a $1000 suit walking around with laces dangling from one $200 shoe.

The usual solution, retying the loop ends, looks ugly, doesn't stay as well as it should, and worst of all makes the knot difficult to untie.

Parents and coaches everywhere need to teach their kids the following simple little method. Once it becomes a habit, it's one less worry in life, and one less thing to nag about.

The problem is the ordinary bow knot we traditionally use to tie shoes. I use a slight variation on the bow knot, which looks the same (but neater), and never comes untied. I've used this knot with leather boots, dress shoes, and shoes used in running hundreds of miles.

1. Cross the strings over to make the usual base, cinching it as tight as desired.
2. Make a loop with one string.
3. Wrap the other string around that one TWICE, instead of just once.
4. Push the remainder of the wrapping string through two wrappings.
5. Tighten fully.

This works with any shoe lace, whether cotton, synthetic, or leather.

As I typed all of this in, I did a web search to find a picture of shoelaces. It turns out that a guy has a whole site just about shoelaces. The Green Tennis Shoes Principle striketh. His site has pictures of this method, called the Better Bow Knot.



Why does this work?

As the two loops are pulled apart during the final tightening, notice that the two center wrappings cross over one another. That forms a little sub-knot, so that in order for one wrap to slip, the other has to slip first. As a result, neither one does.

Untying is the same as with a standard bow knot. Make sure the ends aren't pulled through the loops, and pull on the loose ends.

I suspect, without any data whatsoever, that this method may even be easier to learn for first-timers. The only hard part about tying a bow knot is in the wrap-and-tuck step. Wrapping twice should make it more clear to young learner how it should be done.

Or maybe knot.

Robust Systems

Information systems should be robust. A robust system is one which operates correctly and efficiently under a wide range of conditions, even under conditions for which it was not specifically designed. In particular, a robust system resists attempts to make it operate incorrectly. In other words, it is secure.

While the above sounds simple enough, "correct", "efficient", and "secure" as used above are actually terms of art. An information system is a collection of devices or programs organized to change, transmit, or store data. A system can be said to be correct when its output is provable for all given inputs, and efficient when it completes its job with an acceptable and predictable use of resources.

Systems more complicated than shoelaces should be designed in two or more stages. At each stage there is the potential for debugging. The optimal breakdown for the stages of the overall development process can be thought of as finding the maximum amount of progress toward completion that can be effectively debugged, while also maximizing the likelihood of catching a mistake before the next stage.

Along with basic engineering practices, the principles that lead to robust operation are the same ones recognized by security experts:

1. Economy of Mechanism - this means to keep things simple. Simpler processes are easier to understand and are generally more robust.
   
2. Fail Safe Design - Erroneous input should result in the least harmful action.
   
3. Open Design - The reliability of the system should not depend on keeping its workings hidden.
   
4. Complete Access Control - All access to assets should be allowed only to those authorized.
   
5. Least Privilege - Access to assets should be given only as required.
   
6. Separation of Privilege - Access to assets should be based on multiple independent criteria.
   
7. Least Common Mechanism - Shared means of operations should be minimized.
   
8. Psychological Acceptability - If the perceived inconvenience associated with system safeguards is higher than the perceived value they allow, users will tend either to circumvent the safeguards or not to use the system. Therefore, measures should be implemented only if:
1. They can be built in to the system such that following them will be no harder than avoiding them
2. They are more likely to mitigate a threat than to cause user frustration
   

Here are some principles to bear in mind when creating correct, robust systems.

1. Garbage In, Garbage Out: Input should be validated before it is used
2. Efficiency: when possible, the resources used by a process should not grow faster than the size of the input. Typically the resource use should be bounded by a function of the size of the input, and for robustness, resource use should not depend on the particular input given.
   
3. Correctness: a process cannot be known to be efficient unless it is known to be correct. If some inputs yield spurious results, that is not robust.
   
4. Special Cases: the allowance for special cases signals that a design can be improved
5. Hope is the Enemy of Know: The result doesn't care what you hoped it would be
6. Expect Failure: Component failure should be an expected part of operation.
7. Capacity: rooted in efficiency, capacity is a vital part of robustness.
   

So enough of these generalities. What are some examples of robust system?

• Handicapped stalls
  Whenever possible, if I have to use a public restroom I use the handicapped stall. These stalls are roomier, and generally better lit.
  
  
• Automatic doors
  Grocery stores have long used automatic doors, which sense the presence of a customer and open without anyone touching them. That works for anyone from small children to the elderly. It also works equally well for anyone, one of the hallmarks of a robust design.
  
  
• 36-inch doors and accessible homes
  Similarly, while 36-inch doors make rooms accessible to those in wheelchairs, they also facilitate moving furniture.

Robustness is not just a matter of handling lots of volume. It's a question of design. A robust system is designed to handle all cases equally well, because it doesn't play favorites. The same algorithm, method, or formula used to handle the most common case handles the unusual ones. That gives the best chance for handling cases we don't even expect to encounter with the same aplomb that we handle the ones we do expect.

Google Books and the Big Ten

Google Books and the Committee on Institutional Cooperation (CIC), comprising the Big Ten and the University of Chicago, have announced an agreement with Google to digitize works from its member libraries as part of the Google Book Search project.

In the CIC are 6 of the nation's largest 20 libraries.

In a multi-year project, Google will scan for search millions of public domain and copyrighted items, under Fair Use or by agreement with copyright holders. According to a CIC release,

Public domain materials can be viewed, searched and downloaded in their entirety. For books under copyright protection, a search will result in basic information (such as the book's title and the author's name), and a snippet of text surrounding the search term. Users seeking further information from the text will be directed to avenues for purchase or library access.

The CIC plans to implement a digital archive of research and other content, both for preservation and to enable academic study and collaboration.

This partnership with Google will enable the CIC universities to digitize library content at a scale and scope not possible with the limited means available to individual institutions. And now, with the future promise of a shared digital repository, our universities will enter into an ambitious, groundbreaking collaboration to collectively archive digital public domain materials previously housed within the bricks and mortar of individual libraries.

See the CIC site more information on the CIC and the Google partnership.

Google / CIC Release

Email release from University of Illinois Provost Linda Katehi:

Today the Committee on Institutional Cooperation (CIC), a consortium of 12 world-class research universities, advancing their missions by sharing expertise, leveraging campus resources and collaborating on innovative programs, is announcing an agreement with Google to digitize distinctive collections across all its libraries as part of the Google Book Search project.  As a member of the consortium, our university is part of this important initiative.

Over the next several years, Google will scan and make searchable up to 10 million public domain and in-copyright volumes in a way that is consistent with copyright law.  Public domain materials can be viewed, searched and downloaded in their entirety.  For books under copyright protection, a search will result in basic information (such as the book's title and the author's name), and a snippet of text surrounding the search term.  Users seeking further information from the text will be directed to avenues for purchase or library access.

Also, this agreement anticipates the CIC's intention to create a shared digital repository, so that each university can "deposit" its digitized public domain files into a commonly funded and managed data storage system.  Over time, the shared digital repository will enable our librarians to archive and organize content collectively for scholarly activity, as well as design services such as customized searches for the academic community. When implemented, students and faculty will have convenient, desktop access to a vast array of public domain materials from across our 12 institutions.

The role of archiving and preserving the vast spectrum of written materials is a critical one for university libraries. Many works become out of print, or deteriorate with age, or are threatened by natural disasters or societal upheavals through the centuries. And as we move to a completely technological and digital environment, materials not available in a digital format will become less and less discoverable.  Digitization enables us to preserve our historical collections for all time.

This partnership with Google will enable the CIC universities to digitize library content at a scale and scope not possible with the limited means available to individual institutions.  And now, with the future promise of a shared digital repository, our universities will enter into an
ambitious, groundbreaking collaboration to collectively archive digital public domain materials previously housed within the bricks and mortar of individual libraries.

For more information on the CIC and today's announcement, visit:
http://www.cic.uiuc.edu/digitalbooks.

How About Employing an Editor?

If you can't see anything wrong, click here for an explanation.

ht: Daily Telegraph