[comp.unix.questions] 21st Century UN*X - Bugs??

stevedc@syma.sussex.ac.uk (Stephen D Carter) (02/15/90)

In the (predictable) flurry of fuss surrounding the change of the year
from 1989 to 1990, the following appeared in an *editorial* column of
'Computer Weekly' a major weekly computer trade paper in the UK (ie not
a fringe thing).

In the context of a note about the (usual) shambles that seems to
surround such calendar events it said.....

   As currently programmed not a single system using Unix
   will be able to come to grips with the 21st Century.

(I have the paper in front of me, so this is verbatim and first hand).

This is one heck of an assertion, and if true needs to be resolved, and
if untrue needs to be firmly refuted.

What do you think/know about this.  I'd be especially interested to hear
from some grey haired Un*x originators :-), some current developers
(Posix folks?), manufacturers?  or even journalists who see the Net.

Frankly, if it is true, I'll not mail my order for a Un*x system, but
will go back to a sensible Operating System.


Stephen D Carter, Systems Manager, The Administration, 
The University of Sussex, Sussex House, Falmer, BRIGHTON, BN1 9RH.  UK
Tel: +44 273 678203 (Direct line). Tel: +44 273 606755 (Switchboard).
JANET : stevedc@uk.ac.sussex.syma   
ARPA  : stevedc%sussex.syma@nsfnet-relay.ac.uk
USENET: stevedc@syma.sussex.ac.uk
UUCP  : ...!mcvax!ukc!syma!stevedc
BITNET: ukacrl!sussex.syma!stevedc or stevedc%sussex.syma@ukacrl

jsloan@ncar.ucar.edu (John Sloan,8292,X1243,ML44E) (02/17/90)

From article <2198@syma.sussex.ac.uk>, by stevedc@syma.sussex.ac.uk (Stephen D Carter):
	:
> the following appeared in an *editorial* column of 'Computer Weekly'
	:
>    As currently programmed not a single system using Unix
>    will be able to come to grips with the 21st Century.
	:

So, what else is new? This is one of those statements that is both
completely true and patently false.

UNIX is like George Washington's Ax (you know the old story: "We
replaced the handle back in 19xx when it rotted away... and we replaced
the head in 19yy when it rusted to pieces"). UNIX will survive, albeit
perhaps under other names, because it is not an operating system but
rather an approach, a philosophy. The kernel can be replaced, the file
system can be replaced, shells can be replaced, and still be
recognizable as UNIX. UNIX has been around since 1969, yet hasn't much
or even most of its code has been replaced or at least heavily modified
at one time or another?

Heck, look at OS/360... I was a systems programmer on IBM mainframes
in a previous reincarnation, and worked on OS/MFT, OS/MVT, OS/SVS and
OS/MVS, and despite the fact that most of the subsystems in OS/360 have
been replaced, it's still recognizable.

I assert that the statement above is true for ANY current production
operating system, particular those that have been in use since the
1960's, like OS/360 and UNIX (1969?).

The question is not whether UNIX will survive _in its current form_,
but whether it's placed to evolve more easily into something that
_does_ survive, more so than other current operating systems.

"As currently programmed" is the key phrase. Since I can go to
Radio Shack and buy for under a grand a computer that will
outperform the first IBM 360/65 I ever worked on, I don't find
this statement that radical.

	The ability to advance the leading edge of technology is
	constrained by the ability to prune the trailing edge.
	-- Charles Dickens (Stanford)

	Throughout the centuries there were men who took first steps
	down new roads armed with nothing but their own vision.
	-- Ayn Rand

--
John Sloan          NCAR/SCD               NSFnet: jsloan@ncar.ucar.edu
AMA #515306         P.O. Box 3000          UUCP:        ...!ncar!jsloan
DoD #000011         Boulder CO 80307       Voice:       +1 303 497 1243
Logical Disclaimer: belong(opinions,jsloan).belong(opinions,_):-!,fail.

rhealey@umn-d-ub.D.UMN.EDU (Rob Healey) (02/17/90)

In article <2198@syma.sussex.ac.uk> stevedc@syma.sussex.ac.uk (Stephen D Carter) writes:
>In the (predictable) flurry of fuss surrounding the change of the year
>from 1989 to 1990, the following appeared in an *editorial* column of
>'Computer Weekly' a major weekly computer trade paper in the UK (ie not
>a fringe thing).
>
>   As currently programmed not a single system using Unix
>   will be able to come to grips with the 21st Century.
>(I have the paper in front of me, so this is verbatim and first hand).
>This is one heck of an assertion, and if true needs to be resolved, and
>if untrue needs to be firmly refuted.

	Have the person add 2 billion seconds to Jan 1st, 1970 and see
	where they end up, should be around 2038. I'd say 2038 is a
	fair way through the 21st century and certainly longer than
	most other OS's allow for. 

	I think the CORRECT statement should have been:

	Due to the lazyness and lack of foresite of certain programmers alot of
	PROGRAMS under ALL forms of computers and OS's will not make it
	into the 21st century. i.e. don't have any of your money in a bank
	on new years eve 2000 or the negative intrest rate might zero
	it as 1999 becomes, effectively, 1900...

			-Rob

jsloan@ncar.ucar.edu (John Sloan,8292,X1243,ML44E) (02/17/90)

From article <3222@umn-d-ub.D.UMN.EDU>, by rhealey@umn-d-ub.D.UMN.EDU (Rob Healey):
> In article <2198@syma.sussex.ac.uk> stevedc@syma.sussex.ac.uk (Stephen D Carter) writes:
		:
	[quoting from a newspaper article]
		:
>>   As currently programmed not a single system using Unix
>>   will be able to come to grips with the 21st Century.
		:
> 	Due to the lazyness and lack of foresite of certain programmers alot of
> 	PROGRAMS under ALL forms of computers and OS's will not make it

If this article is really discussing problems with handling 21st
century dates, then [A] I grossly misunderstood the intent (which now
seems obvious), and [B] the author of the original newspaper article
apparently doesn't have anything better to write about. C'mon, there
was an entire _book_ published a few years ago predicting doom and the
ultimate collapse of society as the clock ticked past 23:59:59 on
December 31, 1999. Sheesh... as Rob Healey pointed out, that's hardly
a problem... less of a problem for UNIX users than when the Congress
changed the date that daylight savings time changed by a week.

But since I rather stupidly bought the topic up, anyone want to take
a guess as to what _will_ be the 21st century UNIX equivalent?

	Mach?
	Plan 9?
	5.9BSD?
	POSIX?
	System VI?
	OSFix?

--
John Sloan            NCAR/SCD             NSFnet: jsloan@ncar.ucar.edu
+1 303 497 1243       P.O. Box 3000        UUCP:        ...!ncar!jsloan
AMA #515306           Boulder CO 80307     BITNET:   jsloan%ncar@ncario       
Logical Disclaimer: belong(opinions,jsloan).belong(opinions,_):-!,fail.

gwyn@smoke.BRL.MIL (Doug Gwyn) (02/17/90)

In article <2198@syma.sussex.ac.uk> stevedc@syma.sussex.ac.uk (Stephen D Carter) writes:
>Frankly, if it is true, I'll not mail my order for a Un*x system, but
>will go back to a sensible Operating System.

Feel free.  Anyone who believes everything he reads in a newspaper
deserves to be saddled with a "sensible" operating system.

The factual basis for the silly concern is that 32 bits is used in
many current UNIX implementations to hold a count of the number of
seconds since the beginning of 1970 (UT).  By the time we have to
worry about running out of bits, 64-bit implementations will
probably be the norm.

By the way, your "sensible" operating systems have had similar problems
in the past..

cpcahil@virtech.uucp (Conor P. Cahill) (02/17/90)

In article <2198@syma.sussex.ac.uk> stevedc@syma.sussex.ac.uk (Stephen D Carter) writes:
>   As currently programmed not a single system using Unix
>   will be able to come to grips with the 21st Century.
>
>(I have the paper in front of me, so this is verbatim and first hand).

The first part of the problem is that in unix, time is kept as a count of
the number of seconds since Jan 1 1970 (GMT).  This value is kept in a long
integer, which for most systems is a 32 bit entity and therefore has
a maximum value of 4 billion or so.  Since there are 31 million or so
seconds per year, 4 billion seconds can handle approx 136 or so years.

Obviously someone will have to fix this by then.  I doubt you or anyone 
else will still be running any current machine or any current OS at that
time.

BTW- the change to using time_t as the type of the data element that 
keeps track of time is part of an effort to make it easier to change 
the underlying type without adversly effecting software.

>Frankly, if it is true, I'll not mail my order for a Un*x system, but
>will go back to a sensible Operating System.

If you look hard enough you will find that most systems have some built
in limit as to the end of time.  It just isn't necessary to build a OS
that will last for hundreds of years when they will be replaced in 20 or
30.

A second part of the issue is that lots of software has been written
assuming that the year is allways 19xx.  This kind of software is not
limited to UNIX.  When 2000 comes around lots of software will break.

NOTE: If you have any brains, you will already be scheduling your vacation time
to take the months of Dec 1999 and Jan 2000 off. :-)


-- 
+-----------------------------------------------------------------------+
| Conor P. Cahill     uunet!virtech!cpcahil      	703-430-9247	!
| Virtual Technologies Inc.,    P. O. Box 876,   Sterling, VA 22170     |
+-----------------------------------------------------------------------+

john@newave.UUCP (John A. Weeks III) (02/19/90)

In article <5393@buengc.BU.EDU> bph@buengc.bu.edu (Blair P. Houghton) writes:
> In article <3222@umn-d-ub.D.UMN.EDU> rhealey@ub.d.umn.edu (Rob Healey) writes:
> 
> >	I think the CORRECT statement should have been:
> >
> >	Due to the lazyness and lack of foresite of certain programmers alot of
> >	PROGRAMS under ALL forms of computers and OS's will not make it
> >	into the 21st century. i.e. don't have any of your money in a bank
> >	on new years eve 2000 or the negative intrest rate might zero
> >	it as 1999 becomes, effectively, 1900...
>
> Don't bet on it.  First of all, big bucks await
> crufty-systems programmers in the 90's as every bank in the
> world converts to bigger date-fields.

Don't bet on it...as a person who works for a real company (i.e., staying
open on a day-by-day basis) that supports hundreds of systems at other real
companies (i.e, some of which pay their bills on time), all too often I
see systems where "up and running" means the system analyst claims that
it is working, and s/he things they have a good shot at getting to the
airport before the customer figures out what is happening.

> Second, any of these bugs that are missed will be nonfatal, as
> the banks will be sure to make full backups of their asset data
> before the clock rolls over.

Have you ever asked someone who has just experieced a disk crash
about back-ups?  Often times you get a rather neat blank stare when
you ask this question.  People usually do not care about preventing
a computer disaster until after they get burned once.

> Any funds suddenly zeroed-out will be reinstatable,

Right.  At my bank, the "computer" is never wrong.  Us mere mortal
humans are not even allowed to question the actions of their 
electronic gods...even if it did credit one of my paychecks to 
some other Mr. Weeks, and then proceede to charge me $18 a shot
for 12 bounced checks.

> and the anomaly will in fact become just another
> debugging tool, pointing like a trillion-dollar neon lint(1)
> to the erroneous code.

...which will be used all of three college students trying to make
brownie points with a T/A.  In the real world, I have yet to see
lint being used 'cause everyone has way too much work and impossible
deadlines.  I don't hope for miracles, I rely upon them... and I'm
still going to miss my next deadline.

>				--Blair
>				  "Third, I'll have busted into your
>				   account and stolen all your money
>				   LONG before then... Moo-ha-ha."

				  Remember when I was 9 years old and
				  I ran you over with my bicycle?  Well,
				  I drive a computer now...

The only saving grace that us UNIX hackers have is that nobody in
banking uses UNIX.  Then again, UNIX is probably the only current
O/S that has a chance of still being around in 10 years.

-john-

-- 
===============================================================================
John A. Weeks III               (612) 942-6969               john@newave.mn.org
NeWave Communications                ...uunet!rosevax!bungia!wd0gol!newave!john
===============================================================================

john@newave.UUCP (John A. Weeks III) (02/19/90)

In article <1990Feb17.151104.10132@virtech.uucp> cpcahil@virtech.UUCP (Conor P. Cahill) writes:
>
>A second part of the issue is that lots of software has been written
>assuming that the year is allways 19xx.  This kind of software is not
>limited to UNIX.  When 2000 comes around lots of software will break.

I heard a story like this last year when the Emperor of Japan died.  It
seems that Japan names its years after the current Emperor.  When Herohito
passed away, a great deal of money was spent converting programs to the
new date system named after the new emperor.

For example, if emperor Foo dies after ruling for 23 years, and he is
followed by emperor Bar, the date changes from Foo 23 to Bar 1.

The big problem in Japan's case is that you really cannot predict when the
emperor is going to die.  Would it be sensible to spend a lot of time to
allow for the case of changing dates after the emperor dies if the 
emperor was rather young.  There is a good chance that your program would
be long obsolete before the date system changes.

If anyone on the net has any more hard details on this, please feel
free to post.

-john-

[In general, anything dealing with dates in computer programs is a
big pain in the butt.]

-- 
===============================================================================
John A. Weeks III               (612) 942-6969               john@newave.mn.org
NeWave Communications                ...uunet!rosevax!bungia!wd0gol!newave!john
===============================================================================

hollombe@ttidca.TTI.COM (The Polymath) (02/27/90)

In article <47@newave.UUCP> john@newave.mn.org (John A. Weeks III) writes:
}The only saving grace that us UNIX hackers have is that nobody in
}banking uses UNIX.  ...

Want to bet?

If so, take a look at the signature below.

Still want to bet? (-:

-- 
The Polymath (aka: Jerry Hollombe, hollombe@ttidca.tti.com)  Illegitimis non
Citicorp(+)TTI                                                 Carborundum
3100 Ocean Park Blvd.   (213) 450-9111, x2483
Santa Monica, CA  90405 {csun | philabs | psivax}!ttidca!hollombe

ps@fps.com (Patricia Shanahan) (02/27/90)

In article <1990Feb17.151104.10132@virtech.uucp> cpcahil@virtech.UUCP (Conor P. Cahill) writes:
...
>NOTE: If you have any brains, you will already be scheduling your vacation time
>to take the months of Dec 1999 and Jan 2000 off. :-)

I am planning to take February 2000 off as well, regardless of whether it
turns out to have 28 days or 29. Things should be safe again by about
mid-March 2000.
--
	Patricia Shanahan
	ps@fps.com
        uucp : {decvax!ucbvax || ihnp4 || philabs}!ucsd!celerity!ps
	phone: (619) 271-9940

art@pilikia.pegasus.com (Art Neilson) (02/28/90)

Roger that 8^).
-- 
Arthur W. Neilson III		| ARPA: art@pilikia.pegasus.com
Bank of Hawaii Tech Support	| UUCP: uunet!ucsd!nosc!pegasus!pilikia!art