Testing Linux and Open Source for Y2K 12
Stephen Hurrell asks: "I'm interested in getting feedback about how people and/or sites running Linux with all the usual applications like apache, samba, perl, php, jdk's, postgresql, oracle, X, etc. are handling the Y2K problem. Particularly how they are Y2K testing and communicating results in order to ease management's open source concerns. What do you do and what did you find? There may be a silver lining in Linux that in fact most applications may be using UNIX time structures and that the open source community may be able to respond quicker than Brand M for patches and fixes. Hopefully this may result in increased trust and usage of open source products. What do you think?"
Interesting question... (Score:2)
A little late? (Score:1)
Too late for Y2K worries (Score:1)
Re:Too late for Y2K worries (Score:1)
Red Hat paid for independent testing (Score:3)
In it, they say:
We are pleased to disclose that the core system components of Red Hat Linux, versions 5.2 and 6.0, on Intel architecture have been independently certified as Year 2000 compliant.
and they define "core" as:
1.Commands
after
at
hwclock
convdate
crontab
date
ftpshut
ls
rdate
sleep
touch
usradd
hwclock
telnet
ftp
2.Daemons
httpd
ftpd
telnetd
inted
atd
crond
3.libc
strptime
asctime
gmtime
mktime
int time_t
struct tm
Not exactly the entire distribution... but at least most of the time-related functions...
----
Re:Too late for Y2K worries (Score:1)
-Chris
Heh (Score:2)
Me: Is Linux Y2k?
Random l-n Person: Linux is based on UNIX which uses time_t and is good for 40 more years.
Me: Yes, I know that, but what about the apps?
RLNP: Apps should use time_t.
Me: Yes, "should". Do they? Furthermore, what about stored dates?
RLNP: If a programmer has not used time_t or has stored a date incorrectly, they are stupid.
Me: Yes, I know that. That's what we want to test. AAAAAAaaagghghghghghghghghhhhhhh
---
Unix Time? (Score:1)
A Little Late, Aren't You? (Score:1)
Note: This will be an off-topic rant about Y2K insanity. Please ignore the contents of this post.
To be asking the question 'uh, what about that Y2K thing?' just 13 or so days from The Day, seems silly. If you haven't testing and retested by now, your best bet is to bend over and kiss your buttocks goodbye.
At my company, we have been doing testing and fixes for years. Since November, every change must be approved through the corporate headquarters. (The changes must be approved by the C*Os and their lawyers, not actually by people who know anything about computers.)
I had a perl CGI script that I needed to update. We have put a new system online and it used to be called "TEST" on the daily reports. Now that it was in production it was to be called "R5" for Release Five...
Original code snippit...$R5Name="TEST" ;
Updated code snippit...
$R5Name="R5" ;
To make that change required three pages of paperwork describing the change, a test plan to make sure this change worked and a backout plan should this fail. It took a week and a half to get the change approved.
Somewhere between your 'uh, Y2K?' at T-minus 13 and counting and my piles of paperwork, there's probably a Happy Place.
To somewhat answer your question, you should test your Open Source systems in the same fashion you should have tested your closed source systems. Just because something is GPL doesn't mean that it somehow magically will work on January 1, 2000.
Further, just because someone else says that an application or operating system is Y2K compliant doesn't mean it has been checked or that it will work. If you haven't tested the system yourself, assume that it won't work. Heck, I have systems that I have checked myself extensively and I wouldn't bet my job on it let alone my life.
Conclusion: Stop wasting your time asking Slashdot if your systems are compliant and start doing some testing.
InitZero
"It doesn't matter... (Score:2)
A quote from the Perl Y2K Statement [perlmongers.org].