Acerca del momento en que se anuncian los cambios en los husos horarios

Matt Johnson escribió en abril de 2016 On the Timing of Time Zone Changes en su blog y me autorizó a traducirlo y publicarlo.

¿Qué tienen en común Turquía, Chile, Rusia, Venezuela, Azerbaiyán, Corea del Norte y Haití? ¡Caos con el cambio de hora!

No, no es el remate de un chiste. Es un problema grave en realidad. El mayor problema con los husos horarios no es que existan, ni que haya horas de ahorro de energía en verano. Si no que estas cambien en forma completamente desorganizada. Déjenme explicar.

Primero hay que comprender que desde una perspectiva global, uno podría pensar que los husos horarios del mundo deberían ser manejados por una entidad internacional relativamente neutra, como la división UIT de Naciones Unidas, o quizás la UAI. Sin embargo, cada uno de los husos horarios del mundo se controlan, en realidad, desde una perspectiva local. Cada nación tiene el derecho soberano para decidir acerca de la hora local en las tierras bajo su jurisdicción. Esto incluye tanto la diferencia con la Hora Universal (UT), como las reglas que definen los cambios durante el año para el ahorro de energía, si deciden hacerlos.

Esto no es un problema en sí mismo y estoy absolutamente de acuerdo con que los países deberían poder hacer lo que quieran con los relojes adentro de sus fronteras. Sin embargo, una y otra vez, nos topamos con el mismo problema, que es que estos cambios se hacen sin una antelación suficientemente amplia. Todos los países mencionados más arriba han hecho esto recientemente, junto con muchos otros.

Es crucial que cuando los gobiernos hacen cambios a sus husos horarios o las reglas para cambiar la hora durante un período, permitan un tiempo suficiente para que la tecnología se adecue, haga pruebas a los cambios y publique y distribuya las actualizaciones. Luego hay que tener en cuenta que los individuos no siempre actualizan sus sistemas instantáneamente. Es muy común que una actualización de husos horarios esté disponible por semanas o meses antes de que el usuario final la instale efectivamente.

Caso de estudio – Turquía:

Tomemos a Turquía como ejemplo. En 2015 el gobierno decidió que sería una buena idea retrasar dos semanas la finalización del cambio de hora para ahorro de energía para permitir más horas de luz diurna durante las elecciones. Movieron la fecha de finalización de DST (cambio de hora para ahorro de energía) del 25 de octubre al 8 de noviembre.

  • Lo primero que se supo acerca de esto fue a través de una nota periodística no oficial publicada el 8 de septiembre, alrededor de 6 semanas antes de que se debieran cambiar los relojes. Sin embargo, el artículo recién fue registrado por la comunidad TZ alrededor del 19 de septiembre. Es difícil basarse solamente en notas periodísticas, ya que muchas veces son confusos o contienen errores. Unas pocas palabras de un político a un periodista simplemente no son suficiente.
  • El 29 de septiembre, una agencia del gobierno también reportó el cambio. Todavía no era completamente oficial, ya que no hacía referencia a ningún tipo de decreto o legislación. Pero era suficiente para convencer a algunos en la comunidad TZ de que era real y por lo tanto se comenzó a configurar un cambio en la IANA TZ database y se publicó unos días después, el 1° de octubre.
  • El anuncio definitivo del gobierno finalmente salió el 4 de octubre cuando se publicó en la Gaceta Oficial. Esto es alrededor de tres semanas de antelación oficial de la propuesta de cambio.
  • Muchos proveedores de tecnología, incluyendo a los grandes como Apple, Google y Oracle, tomaron los datos de IANA y los publicaron a través de sus propios canales. Por ejemplo, Apple lo lanzó para dispositivos iPhone y iPad con la actualización iOS 9.1 el 21 de octubre, dejando sólo 3 días para que los usuarios instalen la actualización para evitar que sus relojes cambien la hora el día incorrecto.
  • Para Microsoft Windows que sigue un procedimiento levemente diferente y requiere de un mayor grado de confirmación, se hizo un anuncio el 9 de octubre y se publicó la actualización el 20 de octubre.
  • En algunos casos, la fecha se pasó por completo, como en el caso de pytz – la popular biblioteca de manejo de husos horarios para el lenguaje Python, que publicó su versión 2015.7 el 26 de octubre.

Entonces ¿cuál fue el resultado? Bueno, citando a la BBC:

Turcos confundidos se preguntan “¿qué hora es?” luego de que los relojes automáticos desafiaran una decisión del gobierno para posponer el cambio de hora estacional.

O como reportó el IBT:

Millones de turcos se despertaron en una mañana confusa el domingo … ya que teléfonos inteligentes, tabletas, y computadoras habían cambiado la hora automáticamente del mismo modo que otros países en el huso horario de Europa Occidental (Eastern European Time zone), aun cuando Turquía retrasó el cambio de hora para dos semanas más adelante.

Como se podrán imaginar, esto tuvo en la votación exactamente el efecto opuesto a lo que el gobierno había intentado lograr. Sin embargo, podrían haberlo previsto ya que ¡pasó exactamente lo mismo el año anterior! como lo reportó la Agencia de Noticias Independientes de los Balcanes en 2014:

Una increíble confusión para 52,9 millones de votantes turcos fue causada por la decisión del gobierno turco de posponer por un día el cambio de hora que se aplica en todo el mundo, cuando los relojes se adelantan una hora. La razón para posponer la aplicación de la hora de verano según el gobierno de Erdogan, fue para facilitar la administración de las elecciones, pero nadie predijo el factor de la “nueva tecnología”. Todos los teléfonos inteligentes de los ciudadanos turcos cambiaron la hora automáticamente, resultando en miles de votantes que fueron a a votar más temprano y tuvieron que esperar hasta una hora para poder hacerlo.

Problemas similares ocurrieron en computadoras que no habían bajado una nueva versión del software. También hubo problemas en el sistema de despacho de equipajes en el aeropuerto de Estambul ya que el sistema cambió la hora automáticamente, ignorando los planes del gobierno y, como resultado, el equipaje fue enviado a los pasajeros con grandes demoras. También hubo problemas con muchos vuelos ya que los pasajeros confundían el horario de partida.

¿Qué hay con el resto del mundo?

No sólo Turquía no aprendió de sus propios errores, otros países alrededor del mundo tampoco aprendieron de la experiencia y continúan teniendo este problema. ¿Recuerdan la lista que enumeré antes? Veámosla más de cerca:

  • Chile estuvo en “DST permanente” durante 2015, pero el 13 de marzo de 2016, el gobierno anunció que volverían a la hora estándar a partir del 15 de mayo de 2016 (2 meses de antelación).
  • Rusia tenía 11 husos horarios diferentes, desde UTC+02 hasta UTC+12, con una historia compleja de cambios en los límites entre ellas.

    Para 2016, seis regiones cambiaron sus husos horarios el 27 de marzo de 2016. Cada una de estas regiones tuvo su propia ley para hacer efectivo el cambio. Una fue firmada el 30 de diciembre (12 semanas de antelación), lo cual es razonable. Sin embrgo, las otras fueron firmadas o bien el 15 de febrero (6 semanas de antelación) o bien el 9 de marzo (2 semanas de antelación).

    Otras dos regiones tenían la legislación pendiente durante este período, una de las cuales recién la aprobó el 5 de abril, de la cual la fecha de vigencia se extendió hasta el 24 de abril (3 semanas de antelación). La otra todavía está esperando la firma final del Presidente, lo que se espera que ocurra en los próximos días, tiene fecha de vigencia al 29 de mayo (4 semanas de antelación). (Actualización: La ley se firmó el 26 de abril).

  • Venezuela estuvo en UTC-04:30 desde 2007, pero el gobierno decidió hace poco que retornaría a UTC-04 el 1° de mayo. El cambio se anunció el 15 de abril, el anuncio se convirtió en oficial el 18 de abril al ser publicado en la Gaceta Oficial del país (2 semanas de antelación).
  • Azerbaiyán canceló el cambio de hora permanentemente en 2016. La cancelación se haría el 27 de marzo pero recién se anunció el 17 de marzo (10 días de antelación).
  • Corea del Norte cambió de UTC-09 a UTC-08:30 el 15 de agosto de 2015. El cambio fue anunciado el 7 de agosto (8 días de antelación).
  • Haití canceló el cambio de hora al menos durante el año calendario 2016. Estaba programado para el 13 de marzo, pero el 12 de marzo (¡sólo 1 día de antelación!) el gobierno publicó un comunicado de prensa cancelándolo.

Otros problemas con los tiempos

Mientras todos los cambios descritos conllevan un cierto grado de sorpresa, hay algunas partes del mundo que simplemente no hacen ninguna programación anticipada para el cambio de hora.

Fiyi es una de esas zonas. Tuvo DST todos los años desde 2009. Sin embargo, cada año, el gobierno hace un anuncio indicando en qué fecha comienza y termina. Es levemente diferente cada año y no queda claro exactamente cuándo el gobierno tomará la decisión, o qué hacer ante la ausencia de un anuncio. Sería mucho más simple si decidieran hacerlo con una programación regular y sólo hacer anuncios cuando haya desvíos respecto de dicha programación.

Otro lugar así es Marruecos, donde la programación del primer inicio y el último fin del DST están definidos adecuadamente, pero cada año, desde 2012 hay un “período de suspensión del DST”, de modo que DST termine antes del comienzo de ramadán y se restaure en algún momento luego de la finalización. Esto no sólo significa que los relojes deben cambiarse cuatro veces por año calendario, si no también que nadie sabe bien cuándo son las dos transiciones del medio hasta que el gobierno hace un anuncio. Parte de la razón de esto es que las fechas de ramadán están basadas en las fases observadas de la luna. Sin embargo, mi opinión personal es que aún así deberían fijar las transiciones de DST a un calendario prefijado, aun si comienza antes de ramadán y termina algún tiempo después. La imprevisibilidad de las fechas hace que sea demasiado difícil saber qué hora es en Marruecos a menos que estés realmente allí. (De hecho, Egipto también hizo lo mismo, pero sólo en 2010 y 2014).

Recomendaciones a los gobiernos del mundo

Primero, debo enfatizar que estas son mis recomendaciones personales. No hablo en nombre mi gobierno, de mi empleador, o de la comunidad TZ. Estas recomendaciones están basadas en años de experiencia trabajando con husos horarios en computación, y en la observación de hechos reales.

Si vas a hacer cambios en tu(s) huso(s) horario(s), ya sea para la distancia de tu hora estándar desde UTC, o la puesta en funcionamiento o desactivación del cambio de hora para el ahorro de energía, o para las fechas en que los cambios de hora ocurren, entonces, por favor, hacé todo lo siguiente:

  1. Da un aviso con una antelación importante, preferiblemente no menos de 6 meses. Un año o más sería aún mejor.
  2. Proveé ese aviso a través de un decreto oficial de gobierno o una ley. Publicá la ley y disponibilizala a través de un sitio web oficial del gobierno.
  3. Asegurate de incluir los detalles precisos del cambio, incluyendo la fecha y la hora del día en que el mismo debe hacerse efectivo. Por ejemplo, decí “los relojes avanzarán 30 minutos el 1° de abril a la 01:00 hora local”. No digas simplemente “la hora va a cambiar en abril”. Además, si el cambio sólo afecta una región particular de tu país, por favor, especificá las áreas exactas que son afectadas.
  4. Notificá a tus ciudadanos a través de comunicados de prensa y los medios de noticias, pero no cuentes sólo con esto para comunicar el cambio. El decreto o ley oficial debería estar por encima de cualquier declaración hecha a la prensa.
  5. Enviá notificaciones a la comunidad TZ. Para hacer esto, sólo tenés que mandar un mail a tz@iana.org que es la dirección de la lista de discusión tz. El mail debería contener un URL para el anuncio publicado en un sitio web oficial del gobierno.
  6. Si se aborta la decisión de realizar el cambio, por favor da aviso de esto también con mucha anticipación.

Seguir estos lineamientos te asegura que tu cambio sea observado por la tecnología, incluyendo computadoras, teléfonos celulares y otros dispositivos.

Recomendaciones para desarrolladores de software

  1. No trates de inventar tu propio sistema de husos horarios ni pongas una configuración de zonas manualmente en tu aplicación.
  2. Utilizá los recursos de tu plataforma o biblioteca de desarrollo para hacer conversiones de husos horarios. No intentes codificar las reglas vos mismo.
  3. No te bases únicamente en diferencias fijas desde UTC, ni hagas ninguna suposición sobre el cambio de hora para el ahorro de energía de día (daylight saving time) para un huso horario en particular.
  4. Estate al tanto de las actualizaciones de los husos horarios. Asegurate de saber como mantenerlos actualizados utilizando los mecanismos de tu plataforma o biblioteca.
  5. Suscribite a la lista de correo de anuncios de TZ, así sabés cuando está disponible cada actulización de los datos.
  6. Si sabés de un cambio que está por ocurrir en un huso horario en un área en particular que difiere de la información conocida actualmente, o si tenés otras preguntas acerca del husos horarios en computación, unite a la lista de correo electrónico de discusión de TZ.
  7. Usá timeanddate.com para validar cualquier suposición que tengas acerca de los husos horarios para una región en particular. La precisión de este sitio en particular ha sido bien establecida y sus propietarios participan en la comunidad TZ.
  8. Para Windows, .NET y otros productos de Microsoft, seguí el canal de noticias de este sitio para saber cuándo están disponibles las actualizaciones de la plataforma. (Aunque deberías preferir los husos horarios de IANA cuando sea posible, aun si implica que tenés que utilizar una biblioteca para hacerlo).

Addendum personal

Esto lo escribo yo, Mariano Absatz y no Matt Johnson, con lo cual, las críticas y quejas a esta sección deberán dirigirse directamente a mí.

Pienso que si Matt hubiese escrito esta nota a fines de 2008 el mayor ejemplo de torpezas cometidas, habría sido la Argentina en lugar de Turquía, ya que los cambios que se hicieron tanto en el verano 2007/2008 como los que no se hicieron en octubre de 2008 son un muestrario de todos los errores posibles de ser cometidos.

Para información al respecto ver las notas que escribí en ese entonces:

DreamHost migra de Debian a Ubuntu

La semana pasada recibí un mail de DreamHost (donde tengo alojada esta página y algunas otras) avisándome que el servidor donde está alojada mi cuenta se iba a actualizar a Ubuntu 12.04.

DreamHost es un proveedor de hosting compartido muy barato (cuanto más lo usás, más barato es ya que tiene un precio fijo de alrededor de US$9 por mes y no tiene límites en cuanto a cantidad de dominios, cuentas de mail, bases de datos, espacio en disco, etc). Una de las cosas que siempre me gustó es que tienen una política bastante abierta en cuanto a problemas generalizados en su sitio DreamHost Status y que los servidores tenían instalado Debian (que era la distribución que yo usaba) y te daban acceso a un shell y no sólo a través de FTP.

Dada la cantidad de servers que tiene DreamHost (entiendo que son decenas de miles), los upgrades de los sistemas operativos de cada uno de estos servidores (que, a su vez, tienen varios cientos de usuarios cada uno) es algo que encaran con bastante cuidado.

Yo recuerdo el upgrade de Debian 3.1 (sarge) a Debian 4.0 (etch) que fue el primero que me tocó vivir y que se hizo bastante tiempo después del release original de etch. Luego hubo otros upgrades a los que les presté menos antención.

La sorpresa este fin de semana fue que en lugar de avisarme que hacían el upgrade de Debian 6.0 (squeeze) a Debian 4.0 (wheezy), el upgrade era a Ubuntu 12.04 (Precise Pangolin).

From Debian To UbuntuMe puse a revisar el blog de DreamHost y encontré esta entrada de hace más de un año donde explican los motivos del cambio.

Uno de los problemas que tiene Debian es que su ciclo de lanzamientos (release cycle) es irregular y el lanzamiento se hace “cuando está listo”. El otro problema (y el más grave para DreamHost es que una vez que sale una nueva versión de Debian, la versión anterior tiene soporte durante alrededor de un año.

Por el contrario, Ubuntu tiene un ciclo regular de lanzamiento de versiones cada seis meses (en abril y octubre de cada año) y, si bien el tiempo de soporte de una versión “común” es de sólo nueve meses luego de publicada, cada dos años (en abril de los años pares) se publica una versión que se llama de Soporte por un largo período (Long Term Support – LTS). Ubuntu garantiza el soporte de cada release LTS por cinco años desde el lanzamiento, con lo cual, una vez que sale una nueva versión LTS, la versión anterior todavía tiene una vida útil con soporte por tres años más. Esto le brinda a DreamHost un período largo y previsible para hacer los upgrades en forma pausada y controlada.

De hecho cuando el 14 de septiembre de 2014 comenzaron las migraciones de Debian 6.0 a Ubuntu 12.04, ya existía una nueva versión 14.04 LTS (Trusty Tahr), sin embargo, la versión que DreamHost tiene probada (porque empezó a hacerlo a mediados de 2013) es la 12.04.

El domingo pasado se produjo la actualización de mi host y, a propósito, dejé una terminal abierta con un par de comandos significativos el domingo a la tarde:


baby@dellores:~ $ ssh upson.dreamhost.com
                         
  _  _ _ __ ___ ___ _ _  
 | || | '_ (_-</ _ \ ' \ 
  \_,_| .__/__/\___/_||_|
      |_|                
 Welcome to upson.dreamhost.com

Any malicious and/or unauthorized activity is strictly forbidden.
All activity may be logged by DreamHost Web Hosting.

baby@upson:~ $ w
 13:19:28 up 209 days, 26 min,  1 user,  load average: 3.17, 5.78, 7.80
USER     TTY      FROM              LOGIN@   IDLE   JCPU   PCPU WHAT
baby@upson:~ $ cat /etc/issue
Debian GNU/Linux 6.0 \n \l

baby@upson:~ $ lsb_release -a
No LSB modules are available.
Distributor ID:	Debian
Description:	Debian GNU/Linux 6.0.6 (squeeze)
Release:	6.0.6
Codename:	squeeze
baby@upson:~ $ uname -a
Linux upson 2.6.32.45-grsec-2.2.2-r3 #8 SMP Mon Oct 10 13:33:17 PDT 2011 x86_64 GNU/Linux
baby@upson:~ $ 
Broadcast message from root@upson (Sun Oct  5 20:42:19 2014):

The system is going down for reboot NOW!
Connection to upson.dreamhost.com closed by remote host.
Connection to upson.dreamhost.com closed.

y el lunes a la mañana volví a conectarme y probé los mismos comandos:

baby@dellores:~ $ ssh upson.dreamhost.com
                                   
                                   
 m   m  mmmm    mmm    mmm   m mm  
 #   #  #" "#  #   "  #" "#  #"  # 
 #   #  #   #   """m  #   #  #   # 
 "mm"#  ##m#"  "mmm"  "#m#"  #   # 
        #                          
        "                          

The programs included with the Ubuntu system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.

Ubuntu comes with ABSOLUTELY NO WARRANTY, to the extent permitted by
applicable law.

baby@upson:~ $ w
 09:24:32 up  8:03,  1 user,  load average: 5.28, 5.06, 5.05
USER     TTY      FROM              LOGIN@   IDLE   JCPU   PCPU WHAT
baby@upson:~ $ cat /etc/issue
Ubuntu 12.04.5 LTS \n \l

baby@upson:~ $ lsb_release -a
No LSB modules are available.
Distributor ID:	Ubuntu
Description:	Ubuntu 12.04.5 LTS
Release:	12.04
Codename:	precise
baby@upson:~ $ uname -a
Linux upson 3.2.61-grsec-modsign #1 SMP Tue Aug 12 09:58:26 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux
baby@upson:~ $ 


En principio todo lo razonable funciona OK. Tuve (como con cada upgrade) algún problema con la wiki que instalé a mano y que es afectada por los upgrades de Python (esto me pasaba también con los upgrades de Debian), pero supongo que lo arreglaré en estos días.

¿Pásguord? ¿Guat pásguord?

Aprovecho que mi amigo Mauricio me conminó a escribir algo por él utilizando el clásico método del halago en un comentario de féisbuc para revivir este blog con un articulito corto y conciso. password security

La pregunta es ¿cómo elegir una buena password? Si uno no está utilizando ninguna ayuda tecnológica para guardar las claves que uno utiliza en distintos lugares como KeePass, LastPass o 1Password (cosa que recomiendo fervientemente, pero es tema para otro artículo), las passwords deberían ser fáciles para uno de recordar (y tipear) y difíciles de adivinar para una computadora que podría tener alguna información sobre vos.

Sin hacer ni remotamente un análisis serio sobre el tema, valga decir que, en principio, cuanto más larga es una clave, más difícil es de adivinar por una computadora, al menos utilizando un mecanismo de fuerza bruta (esto es, probar a lo bestia combinaciones de caracteres hasta dar con uno que funcione).

¿Cómo adivina una clave una computadora?

Si bien hay varias formas, el método más simple para una computadora para adivinar claves es aprovecharse de la velocidad de cálculo de la computadora y utilizar lo que se llama mecanismos de fuerza bruta.

En su forma más básica sería ir probando en orden:

  • A
  • AA
  • AB
  • AC
  • AD
  • AZ
  • B
  • BA
  • BB
  • ..

Eventualmente, va a encontrar todas las combinaciones posibles. Podría empezar en «AAAAAAAA» suponiendo que la longitud mínima es ocho caracteres. Con este método, utilizado en forma pura queda claro que, cuanto más larga es nuestra clave, más difícil es de descubrir.

Con una ayudita del atacado

En general el mecanismo de fuerza bruta puro casi no se utiliza o se deja como último recurso, ya que la gente tiende a utilizar palabras comunes o datos más o menos personales.

Posiblemente lo peor que uno pueda hacer es utilizar una palabra común como password ya que, por más larga que sea, lo más posible es que esté en un diccionario, ya sea «gastroenterologo», «prestidigitation», «Иллюзионист» o «טראַפּעז» y la computadora puede probar con todas las palabras de todos los diccionarios que tenga, rápidamente.

Muchas computadoras cuentan, además, con información que nosotros les dimos, ya sea directa o indirectamente, consciente o inconscientemente como ser, nuestra fecha de nacimiento, nuestro aniversario de bodas, nuestro número de documento, los nombres de nuestros hijos, mascotas, cónyuges, amantes, padres, primos, etc.

Una clave más larga que…

Una primera opción sería poner claves muy largas pero que nos sean fáciles de recordar, como ser un par de versos de una canción o una poesía que nos gusta, una línea de un personaje en una película, etcétera, por ejemplo: «Muchacha ojos de papel, no corras mas, quedate hasta el dia» o «Me parecio ver un lindo gatito, Es cierto! es cierto! He visto un lindo gatito».

Una condición para poder utilizar este tipo de claves es ser un buen tipista, como su servidor, ya que si uno no fue a la Pitman y sólo tipea con dos dedos buscando durante dos segundos la mitad de las letras en el teclado, ingresar la clave va a ser una tortura. Por otra parte, aun tipeando treinta palabras por minuto o más, si la clave se utiliza con cierta frecuencia o se debe ingresar en un dispositivo móvil con un teclado virtual en una pequeña pantalla que no se presta a la velocidad, termina siendo también una tortura.

En mi caso, yo utilizo estas claves muy largas para guardar otras claves dentro de KeePass o para guardar las claves privadas que me dan acceso desde mi computadora a otras sin tipear la clave, es decir, que una clave muy larga tipeada una vez, me da acceso a un montón de lugares sin volver a tipear una clave durante una sesión.

Cortala un poco, querés

Otra posibilidad, para no desgastar tanto los dedos es utilizar una clave más corta (sin exagerar, en principio una clave jamás debería tener menos de ocho o diez caracteres) es utilizar el mismo mecanismo de memoria, pero abreviarlo como proponía Mauricio en su comentario, poniendo sólo las letras iniciales de esas palabras. Así nuestros ejemplos podrían pasar a ser «Modp,nc+,qhed» y «Mpv1lg_Ec!ec!hv1lg». Notar que estas claves, si bien tienen una longitud más corta que las otras, sólo pueden ser atacadas con un mecanismo de fuerza bruta en el que las “ayudas” que pueda tener dicho mecanismo que vimos más arriba como ser: buscar palabras comunes de un diccionario primero, o utilizar datos significativos si se sabe algo de ustedes como fecha de nacimiento, aniversarios, números de documentos o nombres de las mascotas; serían inútiles.

Qué teclas usar (y cuáles no)

Conviene que la clave tenga una combinación de letras mayúsculas y minúsculas, números y quizás algun símbolo (como un punto, un espacio en blanco, un guión, etc). En algunos casos, hay sitios de internet que nos obligan a utilizar esto; cada vez es más común que si la clave no tiene al menos una letra mayúscula, una letra minúscula, un dígito numérico y al menos ocho caracteres, el sitio no la acepte cuando la tratamos de crear.

Dicho esto, hay caracteres que es conveniente evitar ya que no todos los sistemas los interpretan igual: las letras con acento, la eñe, los símbolos de apertura interrogación y admiración y otros que no están entre los que son comunes a todos los idiomas.

El problema con estos caracteres es que si bien existe y normalmente se utiliza un estándar internacional que soporta todos los caracteres utilizados en todos los idiomas en uso, no siempre esto está bien configurado en los servidores y en los clientes, y la posibilidad de que en algún momento tengamos que tipear la clave en una computadora, tableta o teléfono que no esté bien configurado y en consecuencia no podamos ingresar la misma correctamente es motivo suficiente para evitarlos.

Una lista razonable de los caracteres que conviene usar en una password es:

  • Todas las letras mayúsculas y minúsculas del alfabeto inglés (o, si preferimos no hacer referencia a otro idioma, del alfabeto español sin la eñe)
  • Los diez dígitos del 0 al 9
  • El punto, la coma, punto y coma, dos puntos, paréntesis, corchetes, llaves, guión bajo, signos más, menos e igual, barras diagonales y vertical, asterisco, porcentaje, numeral, signo pesos, arroba, signo de admiración e interrogación que cierra (no el que abre), signos de menor y mayor, el símbolo ampersand y el espacio en blanco

Hay que tener cuidado con las comillas dobles y simples (ya que, a veces se transforman en comillas orientadas, que diferencian la que abre de la que cierra), los guiones, que a veces se transforman en guión “ancho” o doble, etc.

Finalmente se terminó haciendo un poco largo, pero espero que la nota todavía sea legible por cualquiera.

Hot patches

Ok, agrego algo que parece relacionado con el sexo en el título, una foto engañosa y ya tengo su atención ¿no?. Bueno, lamento desilusionarlos, pero no se trata de eso.
Hot patches

La semana pasada, me crucé en twitter con el Ksplice . Un producto/servicio que permite aplicar parches de seguridad al kernel de linux sin rebootear el equipo.

La información que aparece a primera vista en el sitio es un poco muy marketinera (bueno, al nivel de márketing que se puede llegar si estamos hablando del kernel de un sistema operativo y no de una aplicación para usuarios finales), pero, por suerte, navegando un poco se encuentra fácilmente un paper presentado en 2009 en una conferencia de la ACM/SIGOPS (que todavía estoy leyendo).

Si bien Ksplice cuesta entre US$3 y US$4 por server por mes, para las versiones desktop de Ubuntu y para Fedora, el servicio es gratuito, así que lo instalé en mi Ubuntu Desktop.

Se instaló un “chequeador de updates” (en python) que corre una vez al día via cron, un daemon “Ksplice Uptrack Manager” que interactúa visualmente (en forma similar al “Update Manager” de Ubuntu), un repositorio apt-get para las actualizaciones y algunas cosas más.

Ayer finalmente apareció un update de seguridad en el kernel de mi Ubuntu, el Update Manager lo instaló pero no me pidió rebootear, con lo cual en mi compu seguía corriendo el kernel anterior (con las vulnerabilidades).

Ksplice Uptrack Manager antes de aplicar el updateHoy a la mañana, cuando llegué, el Ksplice Uptarck Manager me avisó que tenía 4 parches de seguridad para aplicarle a mi kernel (los tres nombrados en el Ubuntu Security Notice USN-1023-1 y uno más) mediante un signo de admiración sobre su iconito en el system tray.

Simplemente apreté el botón Install all updates y los mismos se instalaron sin ningún inconveniente. Ksplice Uptrack Manager antes de aplicar el update

Revisé y el kernel que estaba corriendo era el viejo, sin embargo, el mismo tiene aplicados los parches de seguridad del nuevo kernel.

La próxima vez que rebootee, se cargará automáticamente el nuevo kernel, pero, mientras tanto, funcionalmente, es como si ya estuviera instalado.

Lo seguiré probando algún tiempo, pero tengo la sospecha de que, especialmente para los servidores, vale la pena aún pagar cuatro dólares mensuales por server para no tener que estar rebooteando los mismos cada vez que sale un parche de seguridad para el kernel.

Y después de QZZ-999 ¿qué?

Mi amigo Mauricio se preguntaba hace veinte días ¿qué se acabará primero, las direcciones IPv4 o las patentes argentinas?

Se acaban las IPs

Parece que en uno o dos años finalmente llegará el tan preanunciado fin de las direcciones IPv4 de internet (ya hace más de 15 años que “se acaba en los próximos 5 años“, pero desde hace poco, parece que “se acaba el año que viene“).

OK, es un espacio finito, fue planeado hace casi 30 años cuando no sólo a nadie se le ocurriría pensar que podía haber una computadora (o más) en cada hogar… mucho menos se les podía ocurrir que gran parte de la humanidad tendría teléfonos móviles personales y que estos también tendrían asiganda una dirección IP.

Dentro de todo, y con no pocos malabarismos de por medio, el espacio de direcciones IPv4 se la habrá por 30 años si llegamos a septiembre de 2011.

La solución

La única solución viable parece ser migrar a IPv6 que se comenzó a diseñar alrededor de 1993 y se publicó en 1998. Entre otros cambios, el más significativo es que utiliza direcciones de 128 bits en lugar de 32 bits como IPv4.

Si bien desde su concepción, IPv6 se planteó con un plan de migración, la misma ha sido lenta y, a medida que se comience a forzar debido al agotamiento de las direcciones IPv4, será dolorosa.

Se acaban las patentes

PatenteAhora bien, las “nuevas“ patentes de los automotores en Argentina debutaron en enero de 1995 y ya le quedan sólo 3 ó 4 (a lo sumo 5) años más de vida.

Para colmo, hay que reconocer que en 1994 debería haber sido más previsible el crecimiento del parque automotor argentino en 20 años de lo que en 1981 podría haber sido el crecimiento de internet (que de hecho, no existía ni se llamaba así en esa época) en 30.

El sistema de patentes en Argentina consiste en tres letras seguidas de tres números. Como se utiliza el alfabeto inglés (26 letras, sin eñe), esto da un total teórico de 17.576.000 de patentes únicas (26 3 x 10 3).

Fuera de los “autos mellizos“ los números de patente no se reutilizan aun cuando un vehículo sea completamente destruido y dado de baja legalmente.

Algunos números

Más aún, las patentes que comienzan con la letra “R“ hasta “Z“ se reservaron para repatentar vehículos que ya habían sido patentados hasta diciembre de 1994. Estas son 6.084.000 (9 × 26 2 x 10 3).

Con esto sólo quedan, para autos patentados por primera vez a partir de 1995, las que comienzan con la letra “A“ hasta “Q“, un total de 11.492.000 patentes (17 × 26 2 x 10 3).

A mediados de 2010 habían pasado 15 años y medio y se habían utilizado las patentes que comienzan desde la “A“ hasta la “I“ que son 6.084.000 (9 × 26 2 x 10 3). Sólo quedaban 5.408.000 (desde la “J“ que ya se está utilizando hasta la “Q“, 8 × 26 2 x 10 3).

Si bien esto no parece tan poco, hay que tener en cuenta que los primeros 8 de esos 15 años, la venta de automotores tenía un ritmo muy inferior al actual, incluyendo la crisis de 2001. De hecho, al principio, una letra de comienzo de patente duraba alrededor de un año y medio, a veces más. Ahora se están consumiendo en el orden de dos letras o más por año.

Yo sospecho que si no se frena ni se dispara significativamente la venta de automotores en Argentina, el esquema actual de patentes se agotará a mediados de 2014… no falta mucho… son justo 20 años desde que se creó el esquema.

Me acota Marcelo (en facebook) que actualmente se están patentando en el orden de 600.000 vehículos por año (más o menos “una letra inicial“ por año: 26 2 x 10 3 serían 676.000), con lo cual arañaríamos el 2020 con suerte.

Al menos “la pegaron“ con la reserva para repatentamiento de automotores viejos. Creo que van por la “Y“ y no creo que se repatente mucho más. Los autos viejos que siguen circulando con las viejas placas de una letra y seis o siete números ya es difícil que alguien se tome el trabajo de repatentarlos.

Una modesta propuesta de solución

A diferencia de los complejos mecanismos para migrar el protocolo básico de comunicaciones en una red global de computadoras sin una entidad única de control (aunque sí de asignación de direcciones), hace unos años, cuando se me ocurrió que se acabarían pronto las patentes se me ocurrió un sistema simple y elegante para resolverlo.

Si bien no es brillante, vaya aquí mi pequeño aporte a la DNRPA

Mi idea es agregar una letra más al principio de la patente, de modo tal que las nuevas patentes sean de cuatro letras y tres dígitos.

Esto da un total teórico de 456.976.000 patentes únicas (26 4 x 10 3).

Si bien esto va a requerir una adecuación de los sistemas que utiliza la DNRPA (para que quepa la nueva primera letra), ese será casi el único cambio ya que no será necesario repatentar los automotores que tengan una patente del sistema actual (tres letras y tres dígitos).

¿Cómo es esto? considerando que todas las patentes que sólo tienen tres letras son precedidas por una letra A tácita. Esto es, consideramos la letra A con la misma funcionalidad que el número 0. De este modo, si en 2020 veo una patente “de las viejas“ como ser BBY 965, la consideraré como ABBY 965.

De este modo, y manteniendo la reserva de patentes para repatentar los vehículos del sistema anterior a 1995, la patente que vendrá luego de la última del sistema actual (QZZ 999, o también AQZZ 999) será la BAAA 000.

Las patentes entre ARAA 000 y AZZZ 999 corresponden a vehículos con patentes anteriores a 1995 que fueron o serán repatentados.

La ventaja de este sistema es que es relativamente barato de implementar y, una vez que estén adecuados los sistemas se puede comenzar a utilizar inmediatamente y sin desperdiciar patentes válidas.

De hecho, si se terminara de implementar, digamos, a mediados de 2012, quizás la patente siguiente a MZZ 999 puede ser directamente ANAA 000.

Otras mejoras posibles

Siempre manteniendo la simplicidad de implementación, se me ocurren otras mejoras complementarias (no para incrementar la cantidad de patentes posibles si no para mejorar algún otro aspecto):

  • Cambiar la tipografía: La tipografía cuadradota de las patentes actuales, amén de que puedan ser estéticamente más lindas o más feas que las anteriores tiene varios problemas. En particular, hay muchas letras que se confunden a mediana distancia (ejemplo, la O con la D y con la Q). Esto no ocurría en las patentes que había hasta 1994, con una tipografía mucho más redondeada y con la rayita de la Q mucho más notable.
  • Cambiar el indicador de patente duplicada, triplicada o cuadruplicada (hoy una pequeña D, T o C entre las letras y los dígitos) por un número (y que podría comenzar en 1 o 0 para la duplicada e ir incrementándose).

¿Qué más se les ocurre que se pueda mejorar sin que sea complejo?

¿Qué celu me compro?

El sábado perdí (o me robaron) mi vieja Palm Treo 680… si bien ahora ando con una igual prestada, estoy pensando seriamente en comprarme un teléfono nuevo… el problema es que no sé qué teléfono comprarme.

De hecho, no estoy seguro de conseguir un teléfono con todos los chiches que quiero (no digo necesito, porque no es cierto).

Me gustaría que tenga:
Nokia 1100

  • Android 2.1 (o más nuevo)
  • Teclado físico QWERTY (no me llevo bien con los teclados en pantalla, ni siquiera con el del iPhone que se supone que es de lo mejorcito)
  • Pantalla multitouch de 3.5” o más de buena resolución (800×480 en adelante)
  • GSM/GPRS/EDGE cuatribanda (850/1900 + 900/1800)(uno siempre tiene la esperanza de poder irse de vacaciones a Europa)
  • 3G (UMTS 850/1900/2100)
  • En tren de pedir, también podría tener 3.5G (HSDPA/HSUPA), pero con 3G por ahora me arreglo
  • Wifi
  • GPS
  • Bluetooth con perfil A2DP (estéreo)
  • Lector de tarjeta de memoria extraible (microSD o similar) que soporte tarjetas de 16Gb o más
  • Camara de fotos/video decente con flash (no tiene que ser un sustituto de una cámara dedicada, pero tiene que poder sacar una foto más o menos decente)
  • USB (poder conectarse a una compu en modo USB esclavo como si fuera un pendrive, sin necesidad de drivers en la compu)
  • Plug estándar para headset estéreo (así lo uso para escuchar música)
  • Estaría bueno que también tenga FM, pero puedo vivir sin eso :-)
  • … continuará…

¿Alguien conoce teléfonos con estas características?… lo tengo que usar con Movistar, pero preferiría que no esté lockeado al proveedor.

Más sobre el dispositivo del “sexto sentido” del Media Lab de MIT

Hoy TED publicó una nueva charla de Pranav Mistry sobre el dispositivo del que comentábamos la semana pasada.

Lamentablemente (al menos por ahora), los subtítulos sólo están disponibles en inglés:

Pranav Mistry: The thrilling potential of SixthSense technology

Para muestra, baste un botón…

Ayer comentaba acerca de TEDxBuenosAires.

Para que vean el nivel de las conferencias TED miren lo que comenta Pattie Maes del Media Lab del MIT acerca de las nuevas intefaces de usuario (o “¡Comete esta, Minority Report!):

La charla es de febrero de 2009 y está disponible en el sitio de TED para bajarla (tanto el audio como el video) ya que esta, como todas las charlas de TED están disponibles con una licencia Creative Commons que permite redistribuirla tal cual en forma no comercial haciendo referencia a la fuente.

TEDx Buenos Aires… se develó el misterio

Finalmente, luego de unos meses de lo que podríamos llamar teasers y preanuncios 2.0, con acciones en LinkedIn, Facebook, Twitter (quizás en alguna otra también), se anunció oficialmente la realización de TEDx Buenos Aires el 8 de abril en la Rural.

Para los que no lo saben, TED es una organización que realiza anualmente conferencias (TEDTalks) en Estados Unidos e Inglaterra (y ahora también en India).

Las mejores conferencias se publican en video en el sitio TED.com con una licencia Creative Commons que permite su utilización y redistribución en forma gratuita.

Las conferencias TEDx son eventos “tipo TED“, organizados para distintas comunidades, ya sea por afinidad geográfica, organizacional u otra. Si bien los eventos son con una licencia de TED, los mismos son responsabilidad de sus organizadores.

En este contexto es que se organiza TEDx Buenos Aires, organizado por Santiago Bilinkis y un equipo (que parece un All Stars), ya tiene varios oradores confirmados, entre ellos Adrián Paenza, Alberto Kornblihtt, Manu Ginobili, Roberto Guareschi y Luis Pescetti.

Como podrán ver, la diversidad es uno de los aspectos más interesantes en estas conferencias… espero ansiosamente el 8 de abril de 2010 para asistir.

Bang Beng ¿BING? Bong Bung

OK, yo no entiendo el negocio… nunca supe de negocios, pero Microsoft parece determinado a tener su propio motor de búsqueda en Internet.

El nombre es BING. Lo probé un ratito y no parece tener nada muy emocionante ni ser más práctico que el de Google.

Es posible que sea una gran mejora para el Live Search (el motor anterior de búsqueda de Microsoft), pero, al menos a simple vista, no parece agregar mucho (más bien nada) a quienes usamos Google como nuestro principal motor de búsqueda.

Quizás eso es todo lo que Microsoft necesita… tener un motor aceptable (no malo), ponerlo como página por default en todos los Internet Explorer (inclusive que en cada upgrade el usuario deba manualmente deshabilitar que le cambie la página home a www.bing.com) y listo… una estrategia semejante a la que utilizó el Internet Explorer para desplazar a su entonces archirrival Netscape Navigator siendo este un producto bastante mejor a la vista de quienes probábamos ambos navegadores.

Sin embargo, lo que me preocupa es otra cosa. Desde hace unos 10 años se conocen los googlebombs que es un mecanismo que, dado un grupo de webmasters o bloggers que se pongan de acuerdo (o bots que trabajen bastante bien), consiguen hacer que la búsqueda en google de una frase en particular de como primer resultado una página determinada.

En 2003, la búsqueda de “armas de destrucción masiva“ apuntaba a una página que simulaba un error de explorer diciendo que no podían encontrarse armas de destrucción masiva.

Pero este proceso requiere de un esfuerzo combinado y un par de semanas para lograr el resultado deseado.

No tengo idea de cuál es el algoritmo de indexación de Bing, pero evidentemente es mucho más fácil de subvertir que el de google.

Bing salió a la calle oficialmente el miércoles 3 de junio de 2009. Ese mismo día leí en Tecnozona una nota que hacía referencia a ciertas búsquedas que daban resultados graciosos o indignantes según de qué lado del mostrador estuviese uno parado.

Si buscamos (en páginas de Argentina) ciertas palabras o frases da los siguientes resultados:

Lo sorprendente no es que hayan logrado hacer una especie de bingbomb si no que haya requerido tan poco trabajo (estuvo en línea en forma prácticamente simultánea con el lanzamiento oficial del buscador) y luego de cinco días, hoy (lunes 8 de junio) siguen todas las búsquedas funcionando tal cual… es más, muchas de ellas llegan al primer puesto aun cuando no se busquen específicamente en páginas de Argentina.