Lisandro Pardo
De acuerdo al reporte oficial, el Tiempo Universal Coordinado recibió un ajuste positivo de un segundo, haciendo que el día 30 de junio de 2012 fuera un segundo más largo de lo normal. Tanto para nuestras actividades cotidianas como para los sistemas más comunes de medición de tiempo, el segundo adicional quedó absorbido por el típico margen de error existente, y no causó mayores consecuencias. Sin embargo, en la Web se contó una historia diferente. Sitios y empresas de renombre experimentaron inconvenientes de software debido al “segundo intercalar”, y aunque los detalles fueron solucionados rápidamente, esto hace que nos preguntemos qué tan endeble puede ser el software.
Han pasado ya doce años desde aquella particular ocasión, pero nunca faltan quienes todavía se preguntan si todo lo que se mencionó, anticipó y realizó sobre el Y2K llevó a un resultado positivo que evitó el problema a gran escala, o si fue uno de los ejemplos de exageración más grandes jamás vistos. Lo cierto es que se gastaron más de 300 mil millones de dólares para combatir al Y2K, y que a pesar de eso hubo algunos incidentes. Probablemente el más serio fue el caso de Sheffield (Reino Unido), en donde un hospital envió diagnósticos erróneos de Síndrome de Down a más de 150 mujeres embarazadas, provocando dos abortos. El tiempo y el software mantienen una alianza mucho más delicada de lo que parece, y recientemente ha habido otra expresión de su fragilidad: El llamado “segundo intercalar” que se agregó el pasado 30 de junio.
Estamos hablando de un segundo, un valor que tranquilamente puede quedar atrapado en el margen de error de una enorme cantidad de relojes alrededor del globo, pero en algunos casos, fue un verdadero yunque. El reconocido portal Reddit experimentó problemas en Java-Cassandra debido al segundo intercalar. Por otro lado, Mozilla reportó inconvenientes en MySQL, y en los servidores que ejecutaban aplicaciones Java al estilo de ElasticSearch. Sistemas basados en Debian y Red Hat (y por extensión, en el kernel Linux) requirieron correcciones manuales o actualizaciones. El segundo intercalar provocó una condición “livelock” en el kernel, y la comunidad reaccionó de diferentes formas para solucionar el problema. Hasta la línea aérea Qantas vio afectado a su sistema de reservas debido al segundo adicional.
También encontramos ejemplos de empresas que han logrado evitar el problema del segundo intercalar. Una de ellas es nada menos que Google, quien ya había identificado un problema potencial en el año 2005. La solución a este error del segundo intercalar fue, desde cierto punto de vista, introducir otro error: Con cada actualización, los servidores NTP internos de Google agregaban unos pocos milisegundos. Con esto, los ingenieros evitaron incidentes relacionados al segundo intercalar en 2008 (el último año en recibir un segundo extra) y a esta reciente corrección. Al caos del segundo intercalar también se sumó una interrupción de energía en los servidores de Amazon, producto de una gran tormenta en la costa este de los Estados Unidos, afectando a servicios como Instagram y Netflix. Los errores provocados por el segundo intercalar han sido más preocupantes de lo esperado. Por suerte no sucedió nada grave, pero tal vez quieran vigilar a esos servidores un poco más de cerca en el futuro…
A ver, concretemos. No es que el software sea endeble, simplemente está mal hecho. Si señores, Linux tiene fallos, Java los tiene, los programas de IBM también… Particularmente porque esta gente, en lugar de pensar y solucionar los errores de su software con cabeza, se pasan la pelota de departamento en departamento mientras parchean el código lo justo para que su jefe no les atosigue.
Cuando programas tienes que tener en cuenta millones de posibilidades (si quedará memoria, si hay acceso a tal periférico, etc). A la mayoría de los programas no les afecta para sus cálculos cambiar un segundo, a otros sí. Los programadores de estos últimos son los que han supuesto que el tiempo no iba a variar, equivocándose estrepitósamente. Aunque esto suene a regreso al futuro pensad que el tiempo en un programa de ordenador no es algo físico, si no una "pregunta" a otro programa, que puede fallar en cualquier momento (como todos).
Conclusión: señores hagan software robusto y no parcheen. Un parche hoy te fockará mañana, recuerden.
#1 Me sorprende que no haya mencionado a Microsoft. Pantallas azules, problemas con drivers, consumo de recursos excesivo y en algunos casos, irracional. ¿Software perfecto? No lo hay amigo.
Trabajo desarrollando sobre la plataforma de Microsoft, y créame cuando le digo, parches usamos todos.
Concuerdo con lo que dice: "han supuesto que el tiempo no iba a variar, equivocándose estrepitósamente". Probablemente desde el día de hoy yo deje de suponerlo.
Saludos.
Desinformación, el problema no esta en el kernel linux o en java sino en el protocolo ntp, que estos hagan uso de ntp fue lo que ocasiono este problema, lo que mas sorprende es que es algo periódico por ende predecible y los desarrolladores no han hecho las correcciones.
http://n031.site90.net/xkcdclock.php
no entiendo como un problema que todos saben que va a pasar y tienen tiempo para arreglar simple mente lo dejan como si no importara(menos google que fue precabida)
y despues que pasa es que se ponen a arreglarlo
es el mismo problema de Y2K, todo el mundo sabia mas omenos que los sistemas se iban a caer pero nadie hiso nada hasta despues de ocurrido claro no fue la catastrofe que nos estaban pronosticando pero si saben que va a pasar para que esperan que ocurra para arreglarlo?