Yesterday, the nice person and the Unix Curmudgeon were prowling our favorite thrift store (the one we donate our unwanted stuff to), and we came across a shelf of old Unix books, mostly O’Reilly titles.  Some were a bit dated, like “High Performance Computing,” which, today, means huge Linux Clusters on multi-core AMD and Intel CPUs, but in 1993 meant RISC processors like Sun’s SuperSPARC and HP’s PA-RISC.  But, the book works on core principles, so many of the chapters are still valid advice and technique for tweaking programs on any computer, so it goes on the shelf as a reference and memory jogger.

The real prize in this blast from the past is a Hayden Books tome dated 1987, UNIX Text Processing, with Tim O’Reilly’s name on the by-line, as co-author with Dale Dougherty and acknowledgement to “the staff of O’Reilly & Associates.”  Much of this thick book is a crusty introduction to Unix and basic utilities, as the target audience are word smiths and other folks who may not have heard of Unix,  rather than programmers and administrators.  But, at the chewy core is a review of the Typesetting RunOFF system (troff), with all the popular macro packages, plus the pre-processors tbl, pic, and eqn.  As a bonus, the authors show us how to use those venerable command-line tools like awk to slice, dice, and embroider the raw markup.

“Big Deal,” you say.  OpenOffice Writer does all that stuff automatically.  Markup languages are out, WYSIWYG is in–in fact, so ubiquitous that nobody calls it that anymore.  Well, markup still exists, though many of us, myself included, often use OpenOffice and content management systems (like WordPress, with which this blog is written) to create and edit documents, though I find myself flipping over to the “source” view and tweaking the HTML manually in nearly every post.

But, wait–there was that word: manually.  What if we have a document format in which we want to generate documents automatically?  Oh, right–we can generate XML and write a parser for it, or write PHP code that converts database tables into HTML tables, and we can even use PDF libraries to write output directly to PDF.  Still, for a lot of documents, writing complex scripts is overkill, and needs a lot of debugging.

For a lot of ad hoc documents–prototypes or one-time reports, it may be much simpler to write a template for a troff macro, populate the template with our data using a simple filter script, and pipe it all to the Unix text formatting utilities.   With pic, you can even automatically generate graphs from your data, and embed them in the output.  The advantage of using the text formatting utilities is that you are in the realm of the core Unix philosophy–piping data from one utility that does one thing well to another, so you can easily add filters on the front end or backend to adapt to different data sources or different output formats, or quickly change the layout.

Since starting this blog almost two months ago, the posts have been all over the map, literally.  The underlying thread is our continuing relationship with computers and Unix in particular, but, since we work primarily from “home,”  and often from “the road,” who we are and what we do is all-inclusive.  Computers and the craft of keeping software, hardware, and networks running are infused with how we approach everything, from home repair to textile and fiber arts, metalwork, health and fitness, and travel.

Take our recent trip to Canada.  This was, in the traditional sense, a “vacation,”  but the first thing we did on arrival was to hook up our computer to the Internet.  Sure, we used it to find restaurants and map out our daily excursions, but we also used it to keep in touch with clients and work on web sites, as well as update friends and family on what we were up to.  We had an agenda for our trip, but also some contingency plans to take into account the variable spring weather in the Pacific Northwest.  So, our “vacation” wasn’t the travel agencies’ vision of being pampered and indulged, but a reflection of our ability to make plans and execute those plans.  And, have a bit of fun doing it.

I remember the ads from the early 1990s, when the Internet was just getting notice among the general public and non-computer businesses.  The tagline went, “FAX from the beach?  You will.”  At the time, it looked like it might be another one of those “flying car” or “smart house” ads from the 1950s that never quite happened.  But, the computer is one of those machines that isn’t bound by moving tons of earth and concrete, legislation, and public funding, so anything one can imagine doing with it can actually be tried.  And easily copied.  In the 1990s, I did actually “FAX from the beach,”  but it involved dragging a thermal-paper FAX machine to the resort, a computer with dial-up modem, and patching through to my servers at home through the resort switchboard.  Today, FAX is one of those old-fashioned technologies, like telegrams, and even the most rustic of B&Bs have wireless networking.

So, you can take your business with you, and most of us have, connected to the office or our clients through smart phones or wi-fi, 24×7.  Inevitably, our daily life becomes part of our business, and vice versa.  We’re not going to hide the fact that we’re out on the trail, or remodeling the laundry room when you call for a project update.  When video phones were first proposed, people wrote about having to have fake backdrops so your caller would think you were in your office cubicle instead of on your patio or at a beach resort.  The reality is, people have found that business and pleasure do mix–it’s healthy to be active and social, and, thanks to modern computer and communications technology, you can still be in touch with business projects, and even bring a fresh approach to solving problems, because you are more refreshed and relaxed, and open to new things if you are in a dynamic setting.

We look at these travelogues and non-computer project articles as a reflection of our approach to getting things done, that directly relates to how we approach solving business problems, without going into case studies.  OK, maybe we’re not “on the job” eight hours a day–sometimes it is more than that.  I can’t count the number of times over the past 30 years of bike commuting that I’ve come in from a long bike ride with a fresh insight on solving a problem or tackling a project design.  The kind of “head work” that is necessary in a problem-solving and creative profession doesn’t turn on and off when you sit down at the keyboard, but is the total sum of life experience.

Preston Gralla, at ITworld.com wrote a blog about Microsoft Turns 35.  About the subject, we’d quote the Vice President [speaking “off the record” on the health care bill] here, but this is a family blog, so I won’t. Anyway, Preston’s article about the successes and failures of what the Unix Curmudgeon fondly calls “The Redmond Menace” skimmed over a few milestones and features, being mostly non-technical in nature.

Of course, it is fairly well known that Unix predates Microsoft by five years: the Unix Epoch, which is also the time system used on the Internet, starts on January 1, 1970 (GMT, so that zero-time in the United States is always sometime in afternoon or evening of December 31, 1969, thus explaining those SPAMS you get dated 1969–the forged emails have no timestamp, so your mail system puts in “zero” for the “sent time.”)  What isn’t so well known and wasn’t pointed out in the article was that, for a time, Microsoft licensed a version of Unix called Xenix, written for the Intel 80286 microprocessor, which could access more than 1MB of memory and had a protected mode to provide kernel security. Microsoft didn’t directly market Xenix, but sublicensed it to the Santa Cruz Operation. What Microsoft did do was to “borrow” some of the concepts [but not the code–that would be “software piracy,” something that Microsoft has vowed to eliminate by making sure every computer on the planet has a paid-up Windows license] from Unix to incorporate in MS-DOS 2.0.

MS-DOS 1.0, as mentioned in the referenced article, was essentially a 16-bit reverse-engineered clone of CP/M and wasn’t very extensible, especially in handling file systems on large disks, since CP/M was originally an 8-bit floppy-disk program loader, and IBM wanted to add a 5-MB Winchester hard disk to the PC. Subdirectories came from Unix, but Microsoft retained the drive letter designation from CP/M, and reversed the directory level separator, using a back-slash because CP/M (and DOS 1.0) used the forward slash for command-line options and, then as now, backward compatibility was a primary goal, even if it perpetuated bad ideas and awkward constructions. Since the Internet was developed out of Unix networking, the Web uses the Unix conventions, which causes confusion between Windows native file paths and web paths to this day.

Of course, CP/M came along about 15 years into my IT career, and was the system on the first microcomputer I used at work in 1981. In the prior age, when we wrote computer programs, each program was self-contained, and the computer only knew how to read the first file on the tape.  The idea of CP/M, a universal front-end for loading and interfacing with microprocessors, that would load other programs and handle input and output, had a lot of promise, and made it easy for companies to write programs that would work on any computer that had a compatible processor and CP/M: I even attended the big CP/M ’83 conference in San Francisco where the latest database, spreadsheet, and word processing programs were rolled out, still doing rather remarkable things on 8-bit microprocessors. But, by the end of the year, MS-DOS and IBM had cornered the big business market what was essentially a 16-bit reverse-engineered port of CP/M, and CP/M itself was relegated to the dustbin of history. My first MS-DOS machine at home, in late 1985, ran MS-DOS 4.0, which was, as stated, buggy and was missing a lot of the capability added by MS-DOS 5. A couple years later, I installed Windows 2.0/286, which was terrible, compared with the Digital Research GEM (Graphical Environment Manager) that was used as the front-end, under MS-DOS, for a lot of graphics programs in the mid-1980s, and no match whatsoever for the Apple Macintosh, which, like Unix, was a true multi-tasking operating system under the similar graphics. Both GEM and Macintosh were inspired by the Xerox Star graphical user interface developed at the Palo Alto Research Center, and Windows was inspired by the need to kill Apple at all cost (GEM was killable by virtue of being an MS-DOS application that simply wouldn’t run with Windows). Windows was little more than a slow, low-resolution, limited-color task switcher, and few programs were written for it because the programming API was a mess that took months for an experienced programmer to master.

But, since I had an 80286 computer, I could run a real operating system on it, instead of the Microsoft abomination. Xenix, since royalties flowed through the Santa Cruz Operation to Microsoft to AT&T, was extremely expensive, but a decent Unix clone based on System 7–the last in-house version before the deregulation of the telephone monopoly Bell created AT&T and allowed them to market Unix commercially–was available for $99. So, I ran Coherent–for years. It not only ran multiple programs concurrently, but we bought a few text terminals at a swap meet for a few dollars each and the whole family could use it at the same time–it was multi-user.

With the introduction of the 32-bit Intel 80386 microprocessor, which could run standard Unix, SCO broke out from under the thumb of Microsoft and released SCO Unix, letting Xenix die the death it deserved (the 16-bit computers had a 64K data segment size limitation, something that we also had to deal with in Coherent). At home, we finally retired the 80286 and jumped directly to an 80486 when Coherent was ported to 32-bit. By then, Microsoft had released Windows 3.1, which actually had some usable capability, though it was, like GEM, little more than a graphics manager that loaded on top of MS-DOS, and was still 16-bit. But, IBM and Microsoft were building a real[tm] 32-bit operating system, OS/2. Although Unix (Coherent) was the workhorse system at home, I needed to develop MS-DOS and Windows applications, so I bought another computer and immediately installed OS/2 on it. OS/2 was rock-solid and performed well, running Windows programs as well as native code. But, because of the split between IBM and Microsoft, when Microsoft released their own 32-bit operating system, Windows 95, OS/2 could no longer run programs written for Windows 95, and it simply died.

Even mighty IBM was not immune to the wrath of the Redmond Menace–a company that, time and again, exhibited a ruthless policy to either absorb or destroy any possible competition. The easy targets were, of course, companies that depended on Windows and MS-DOS as an operating platform. Apple and Unix continued to survive and even flourish, though their market share percentages shrank as Microsoft swallowed the world with their draconian licensing policies that made it impossible to build a computer capable of running Windows without paying for and installing Windows on it. All of us running Coherent, OS/2, and, later, Linux, not only paid Mark Williams Company, IBM, or one of the Linux distributors–Slackware, Debian, SusE, Red Hat, or others–for a usable system and support, but also paid Microsoft for a useless system to throw away. This means, of course, that, though Microsoft claims more than 90% market share, based on PCs sold versus Macintosh sold, a substantial percentage of those computers shipped with factory-installed Windows are actually now Linux computers. We try not to contribute to the Microsoft market share (or their already-bulging coffers) by building our own Linux computers from spare parts, but, of course, these don’t even show up in the numbers because they weren’t sold as complete systems.

Time will tell whether Microsoft will survive to see 50.  Their flagship system, Windows, has evolved slowly, through blunders and misguided attempts to layer new concepts on top of dead-end designs, layers that have added complexity to the programming and management of the systems, so that turning the juggernaut onto a new track may be nearly impossible.  Apple solved their transition into the 21st century and second quarter century of existence by porting their trademark user interface onto a solid, standard, and open operating system–a version of BSD Unix named Darwin, though it results in one of the stranger flavors of Unix to administer.  I can’t see that happening with Windows–it is just too alien and too convoluted to fix by running it on top of Unix.  Rewriting the NT kernel one more time to fix the security issues from the bottom up instead of the top-down weekly and monthly and emergency band-aids Windows users are subjected to would be a massive undertaking, and we’ve seen 10 years of effort since Windows 2000 to get what seem to be minor refinements and even some major setbacks, with the Vista fiasco as a prime example.  And, with the improvements in automated installation of Linux and the renewed visibility of Apple in the music and phone marketplace, users know they have a choice, and don’t have to endure years of frustration in hopes of getting a system that works to replace the one they have.