Year 2000 commentary

With the dates most closely associated with Y2K computer problems (January 1, 2000;February 29, 2000) fast approaching, I thought I would post some relevant commentary on the subject.

In June 1998 I wrote a small article entitled Year 2000 and secrets: New problem, or a symptom of an old problem?. The basic statement I made was:

Computer Software is like any other information used by humans or machines and needs to be:
  • periodically updated as conditions change
  • thoroughly tested (peer-reviewed, verified, tested in many environments, etc)
  • not be relied upon unless the last two conditions are met.

I also built a small links page pointing to a number of other sources of information, mostly of a political nature. Of a more practical nature I wrote a Y2K TODO document suggesting ways to determine how ready your organization is.

I am now being asked to draw up my own statement on Y2K to assure my customers that the services I provide are Y2K Compliant. My basic Y2K Compliance statement is:

YEAR 2000 (and beyond) STATEMENT:

As a consultant, I provide services and not products, and am just as Y2K compatible as any other human being would be. The recommendations I make are based on my 15+ years of experience and knowledge of the industry, and of my particular background in Open Systems/Free Software. I always try to make use of and recommend technology solutions that are as well tested and free of Y2K and other software defects as possible.

  • The online Internet services I offer are based on publicly peer reviewed software solutions. With the popularity of the most key applications, a large number of independent software reviews have been done, and the software is therefore less prone to software errors, including the type of errors associated with Y2K. For more information specifically on software associated with these core components (Examples: Linux Kernel, Apache, Sendmail, Samba), please see

  • My personal training included attending software testing courses at Carleton University. Any good software testing course includes testing for date-sensitive code, with Y2K and leap year testing being considered the most basic tests. This training was then applied to any software that I authored.

  • If you are using proprietary software, then this was either against my recommendation as a consultant or as a temporary compromise in a non-critical part of your business. In these cases you may be vulnerable. I believe that proprietary information cannot be adequately subjected to independent, open and scientific peer review, and thus is more likely to have Y2K or related errors in it.


I warranty the service that I provide in that if I charge for a day of work, I will have done that day of work to the best of my abilities. I can not personally warranty third party products and services that I normally make use of in the provision of my service.

My technologies worries for the Year 2000 are related to third party information that I do not have access to, such as the testing done on basic Internet infrastructure. I also have clients that are relying on proprietary information and software for their business, and the reliability of that information is unknown.

Year 2000/Software date Links

Note: A variety of opinions are expressed in the following links, and thus I am obviously not endorsing the opinions but instead have a desire to allow people to read this diversity.

As a further commentary, I chose to add a link to the WEB server software that the author chose in publishing their article. In my mind, any author that made use of secret-source software (EG: Microsoft servers) rather than the variety of publicly disclosed servers (Apache, NCSA, etc) has a bit of a credibility issue when it comes to the Y2K issue and it's need for full disclosure.

Y2K software problems: What you should be doing as a user of technologies to protect yourself.

Many of my customers have asked me to help them with Y2K plans over the 1998/1999 years. Designing a Y2K plan and assuring customers that they are ready is not easy as in many cases my fundamental recommendations are not being followed. As an example, many customers are relying on proprietary software, such as Microsoft Windows and associated proprietary office suites.

From my position piece on Y2K, my "common sense" recommendations are:

Computer Software is like any other information used by humans or machines and needs to be:
  • periodically updated as conditions change
  • thoroughly tested (peer-reviewed, verified, tested in many environments, etc)
  • not be relied upon unless the last two conditions are met.
The TODO list then becomes simple:
  1. Make a table of technologies that you use, sorted in the order of how dependent you are on those technologies. The technologies on the bottom of the list should then just be 'conveniences' and not things you are relying upon.

  2. I will be able to help, but most people can get started right away on some of the more obvious technologies such as listing versions of operating systems used and versions of the primary applications used. The determining of the sorted order will likely be the hardest part. As you build your table, include a column that indicates who in your organization is dependent on the technology and how.

  3. Starting at the top of the list, you will then need to verify the first two points above:
    1. Periodically updated doesn't mean latest version, but the latest bug fix release. For instance, running Window 95 Service pack 4 is better than running Windows 98 even though Win98 has a more recent release date. Service pack 4 is an update based on some testing Microsoft finally got around to doing and represents an update of information, while Windows 98 is a release of a number of new technologies that have not yet been adequately tested. (Nov 21, 1999 addition: Microsoft has now put some effort into cleaning up some of the bugs in Windows 98, including 2 series of bug fixes relating to Y2K. If you run Microsoft Windows, look at for more information)
    2. Technologies that cannot be adequately verified (EG: Secret-source software, technologies based on trade secrets, etc) should be minimized or put into areas that are non-critical. If your primary business is information publishing on the WEB, then having a bug in your Webserver is critical, while having a bug in your FAXmodem software is not.
    3. In the table we can indicate whether or not a backup exists for a given technology. This will then make a more critical technology able to slide down the list as you have a backup plan.

    4. For technologies that you know will fail, moving to the backup as soon as possible will be appropriate.

    5. You will need to check with each of your suppliers of the critical technologies and verify that they have done appropriate testing and made any required updates.

    6. For many companies who are just licensing you for the use of trade secrets you will just need to 'trust them' and won't be able to do your own independent verification. When just 'trusting someone', please remember that many insurance companies are not insuring against Y2K problems (As they are not accidents, but design flaws and bad purchasing decisions). Also remember that most software licenses protect the software companies against any liability in the use of their software (IE: If everything fails, you can't sue them for not doing adequate Y2K testing).

An example table might be as follows (Updated late 1999):
Software/Application Version 
Being Used
URL Ranking Software/System used By, Comments
BIOS Clock Various I use the following two test programs, which work on most BIOS.

AMI BIOS tester
Phoenix BIOS tester

TOP BIOS clock is in each microcomputer.
RedHat Linux 6.0 Y2K Statement
General Errata
 Top  All/Lan Server
SAMBA 2.0.5 Y2K Issues Top All/Print and File sharing with server.
Netscape Communicator  4.7 Y2K Statements  Medium Used for Email, Web browsing.
Ascend Pipeline 50 (Router) Unknown Product Specifications Low Used for Internet connectivity.  While it keeps a data, functionality not dependant on date.