]>
&header;
A medida que se va entendiendo el problema del año 2000,
más y más compañías están
demandando informes oficiales de los proveedores de hardware y
software, de como sus productos responderán frente al cambio
de milenio.
Las organizaciones que usan sistemas operativos unix como FreeBSD
están un paso por delante del problema. FreeBSD mantendrá
sin problemas las fechas posteriores al año 2000.
Más información
(Esta sección está basada en el texto de Linux Y2K compliance
)
Como en todos los sistemas operativos Unix, la hora y fecha se
representa internamente como el número de segundos transcurridos
desde el 1 de Enero de 1970 (la "época" Unix). Actualmente,
esta figura se almacena en un entero de 32 bits, desbordandose sobre
el año 2038. Para entonces esperamos (seguro) usar un contador
de 64 bits (o mayor) el cual no daría problemas hasta el fin
del universo.
Ten en cuenta que un sistema operativo sin el problema Y2K no
solucionará las aplicaciones que no sean Y2k.
De la misma manera, el sistema operativo espera leer la fecha y hora
actual del reloj CMOS de tu computador. No todos estos dispositivos
manejan correctamente el año 2000. Recomendamos que testees cada
plataforma independientemente para asegurar que el reloj de tu hardware
soporta sin problemas el paso del año 1999 al 2000, y que
éste es interpretado correctamente.
Qué puedes hacer.
FreeBSD continuaráa manteniendo correctamente tanto la
fecha como la hora durante el próximo siglo. Aplicaciones
de terceras partes, quizás no lo hagan. Tu mejor defensa
frente a los problemas del 2000 es un buen ataque. Escuchar las
historias clamando el final del mundo pensamos que no
es la mejor manera de hacer frente al problema. El proyecto FreeBSD
te recomienda realizar comprobaciones de tus sistemas antes de
la llegada del 2000.
Hay tests que puedes usar para comprobar la respuesta de tu
sistema. Pon el reloj de tu computador a unos minutos antes de la
media noche del nuevo año y comprueba la fecha. Tu sistema
debería mostrar el año 2000 y no el 1900. Si el
año mostrado es incorrecto, tendrás bastante tiempo
por delante para actualizar el hardware. Operar los sistemas de
información de tu organización durante unos
días con la fecha adelantada, puede darte una idea real de
lo que ocurrirá en el cambio del año.
Importante: No hagas esto en
sistemas en producción. Puedes confundir y tener muchos
problemas en aplicaciones que utilizan las fechas (sistemas de
facturación, regímenes de copias, etc). Utiliza siempre
para este tipo de pruebas máquinas de desarrollo las cuales no
puedan afectar datos importantes.
Estado del Y2K en FreeBSD
"Después de extensos análisis y tests, creemos que FreeBSD
es 100% compatible con el Y2K. En caso de que algo se nos haya pasado
por alto, haremos todo lo posible para fijar el problema lo antes
posible."
David Greenman
Arquitecto Principal, The
FreeBSD project
Problemas solucionados
Los siguientes problemas Y2K han sido identificados y solucionados
en FreeBSD.
- misc/1380
- Muchos programas tenían incluido de manera fija el formato
19%d para el año. Los programas afectados incluyen: yacc, ftpd,
y make.
[Solucionado: yacc v1.2 1999/01/18; ftpd v1.7 1996/08/05;
make v1.4 1996/10/06]
- conf/1382
- El script sed de /etc/rc.local que crea la línea del
host/kernel ID para el mensaje del día depende de que el
año no sobrepase el 1999. [Solucionado: v1.21 1996/10/24]
- misc/3465
- El comando etc/namedb/make-localhost genera el número
serial del DNS como YYMMDD. En el año 2000, éste
será generado como 1YYMMDD.[Solucionado v1.2 1997/08/11]
- gnu/4930 y
gnu/8321
- Las macros groff tenían integrado 19 para generar algunas
fechas.
[Solucionado: tmac.e v1.3 1998/12/06; doc-common v1.10 1999/01/19]
- bin/9323
- El comando touch no trata correctamente los dos digitos del
año. Los años en el rango 00-68 son tratados como
1900-1968 en lugar de 2000-2068. [Solucionado: v1.7 1999/01/05]
- xntpd/parse/util/dcfd.c
- El cálculo de años bisiestos para el número de
días en un año, y la conversión del tiempo DFC77
a segundos desde el Epoch era incorrecta. Estos errores afectaban a
todos los años. [Solucionado: v1.6 1999/01/12]
- tar/getdate.y
- La función convert() tenía fijado el uso de dos
dígitos en el año para el rango 70-99. Ha sido ajustada
para permitir años de dos dígitos para for 1970-2069.
La función no permite usar años bisiestos -
alerta y2k1!. [Solucionado: v1.4 1999/01/12]
- fetch/http.c
- El protocolo HTTP incluye un formato de fecha obsoleto que usa un
año de dos dígitos. Las versiones anteriores de fetch
interpretaban todas las fechas en 1900s; con esta revisión, se
usa la recomendación de la
RFC
2068. [Solucionado: v1.24 1999/01/15]
- misc/9500
- El script `edithook' en el directorio CVSROOT usa tm_year y
mostraría 01/01/100 en el 2000-JAN-01.
[Solucionado: v1.2 1999/01/17]
- bin/9501
- Muchos de los ficheros "cvs contrib" tienen el problema del
año 2000. Los scripts log.pl y sccs2rcs.csh añaden 19
al año, resultando en mostrar 19100 para el 2000. El script
log_accum.pl usa un año de 2 dígitos en un lugar y en
otro asume que tm_year es el año dentro del siglo en lugar
de año desde 1900.
[Solucionado: log.pl v1.2 1999/01/15; sccs2rcs.csh v1.3 1999/01/15]
- bin/9502
- El registro numérico de groff `yr' es asignado desde
(struct tm).tm_year representando el número de años desde
1900, no el año dentro del siglo (mirar la definición en
troff/input.cc).
[Solucionado: ahora usa mod 100, input.cc V1.2 1999/06/03]
- bin/9503
- El programa simple_httpd de PicoBSD usa tm_year y mostrará
01/01/100 para 2000-JAN-01.
[Solucionado: v1.2 1999/01/16]
- bin/9505
- Adduser usa tm_year y mostrará 01/01/100 para 2000-JAN-01.
[Solucionado: v1.42 1999/01/15]
- bin/9506
- Cron usa tm_year y mostrará 01/01/100 para 2000-JAN-01.
[Solucionado: v1.7 1999/01/16]
- bin/9507
- tcpslice(8) usa tm_year y mostraráa 100y01m01d... para
2000-JAN-01. Por compatibilidad, usa un año de dos
dígitos hasta el 2000. [Solucionado: v1.8 1999/01/20]
Aplicaciones Problemáticas
- ports/7681
- TkDesk 1.0 tiene integrado un 19 en el fichero de lista de
ventanas. Un fichero con fecha > 2000 se muestra como
"191xx" donde xx son los dos últimos núros de la
fecha real. Este error ha sido fijado en la versión 1.1.
- ports/9295
- INN 1.7.2 tiene varios problemas relacionados con Y2K. Uno ocurre
cuando purgamos las news (option -f del nntpget) y otro está
relacionado con la cabecera Expire con fechas relativas pasado el
año 2000.
[Ports INN actualizados a INN 2.2 1999/05/02]
- ports/9298
- Knews tiene varios problemas relacionados con Y2K. Uno ocurre
durante la generación del comando NNTP NEWGROUPS. El otro ocurre
por que knews no piensa que el 2000 es una año bisiesto. Ambos
están solucionados en knews-1.0b.1. [Port actualizado 1999/01/07]
- ports/9300
- Nntp-t5 tiene un problema de Y2K durante la generación del
comando NEWNEWS. [Port parcheado 1999/01/05]
- ports/11144
- El port tiff tiene fijado 19xx. Aunque esté en la
sección contrib (para convertir el formato de SUN a TIFF), y
no es instalado por defecto, debería ser solucionado.
[Solucionado: 1999/04/18]
- ports/11145
- El port dgs tiene el mismo problema que el port tiff.
[Solucionado: 1999/04/18]
Más información
Si tienes alguna pregunta sobre la compatibilidad de FreeBSD con el
año 2000, o has descubierto alguna aplicación ejecutada
bajo FreeBSD que no cumple con Y2K, por favor, ponte en contacto con
nosotros en la dirección freebsd-bugs@FreeBSD.ORG.
&footer;