Date: Sat, 13 Apr 2002 03:36:12 -0700 From: Terry Lambert <tlambert2@mindspring.com> To: aw1@stade.co.uk Cc: chat@freebsd.org Subject: Re: setting up daily builds Message-ID: <3CB80A1C.7289702B@mindspring.com> References: <20020411214456.0E68B3F2D@bast.unixathome.org> <3CB63991.7B33851F@mindspring.com> <3CB707CF.D6DEAA19@attbi.com> <3CB7734B.DEE9ED94@mindspring.com> <p05101507b8dd3090f679@[10.0.1.25]> <20020413033208.C93690@titus.hanley.stade.co.uk>
next in thread | previous in thread | raw e-mail | index | archive | help
Adrian Wontroba wrote: > On Sat, Apr 13, 2002 at 02:48:00AM +0200, Brad Knowles wrote: > > > Or, to put it another way: "code does not rot: it takes an > > > intentional modification to break working code". > > Usually true, but not always. Y2k is a good example of an exception. > > If the mere passage of time within its design life stops code from > working, it is broken. > > Code which had to be changed for Y2K was broken, either when it was > produced, or when the decision was taken to prolong its life into the > danger period. In some cases the sins of one programming generation > were visited on the next. Y2K conversion of systems largely written in > the early 1980s was no fun (8-( Some code had a design lifetime of "until Y2K"; other code had a much shorter design lifetime, and blew up because it's operational lifetime exceeded the design lifetime by decades. While it's true that there was a lot of code that was written to use a two digit date field by people who didn't know any better, there was also a lot of code that was written to use a two byte date field because main memory was $1/byte (magnetic core memory) and "mass" storage was $0.10/byte (Winchester disks), and it was simply too uneconomical at the time to produce code with larger storage/processing requirements for the date fields. Actually, it's even more arguable that a 2 byte date field was an intentional limitation; it'd be fairly trivial to permit discontinous numeric spaces, since the storage of those bytes was as 8 bit or, minimally, 6 bit values. You could quickly modify the compiler to support two byte data vs. 5 digit numberic value, and/or to add a "redefines" to explicitly handle it, or a "dd" for "date" formatting string (in the case of COBOL). Conversion of stored data would not be necessary, even if you only counted up the 10's digit, there would be at least 20 times the increment capacity, or 6 times, for 6 bit storage. I believe that John Gilmore made a recent call for "expiration dates" in software. It probably would have been reasonable to "expire" software base on its design lifetime (I don't really agree with the idea of expiring software in the anticipation of a future upgrade, which is what I believe was suggested). Actually, the perversity of human nature was fairly well understood by programmers; the "Y2K" phenomenon was commented on in academic papers as early as 1956, with the knowledge that some systems would inevitably still be in use at the roll over of the millenium, due to the inherent perversity of human nature. 8-). -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-chat" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3CB80A1C.7289702B>