Otra vez el Cambio de Horario en Ubuntu

Este post es sólo para comentar, amigos sysadmins, que este domingo a las 00:00 hs. se "atrasará" una hora el reloj del lado este del país, y que todos aquellos que tengan actualizados el paquete tzdata van a tener actualizados el reloj automáticamente, a diferencia de otras oportunidades donde lo repentino de los caprichos las decisiones políticas hicieron que hubiera que hacer esto a mano.

Para comprobar esto, pueden correr en la consola:

marcelo@marcelo-laptop:~$ zdump -v /etc/localtime | grep 2009
/etc/localtime  Sun Mar 15 01:59:59 2009 UTC = Sat Mar 14 23:59:59 2009 ARST isdst=1 gmtoff=-7200
/etc/localtime  Sun Mar 15 02:00:00 2009 UTC = Sat Mar 14 23:00:00 2009 ART isdst=0 gmtoff=-10800
/etc/localtime  Sun Oct 18 02:59:59 2009 UTC = Sat Oct 17 23:59:59 2009 ART isdst=0 gmtoff=-10800
/etc/localtime  Sun Oct 18 03:00:00 2009 UTC = Sun Oct 18 01:00:00 2009 ARST isdst=1 gmtoff=-7200

Las dos primeras líneas representan las reglas con el cambio mencionado. Si no aparece nada después de correr este comando, actualizen el paquete tzdata. :-)

Saludos,
Marcelo

Artículo sobre Optimización en Software

En este artículo el autor (Shlomi Fish) discute un poco sobre optimización de algoritmos, y está orientado bastante a lo pragmático, desmitificando (o intentando derribar) algunos viejos "axiomas" de la programación.

Para mí fue muy interesante la introducción de la idea de que optimizar factores constantes en la complejidad de un algoritmo también sirve; es decir, no sólo reducir órdenes de magnitud como único objetivo al optimizar, sino que también es importante hacerlo en factores. Con lo cual tiende a derribar dentro de su criterio el mito de "O(N²) es igual a O(2N²)", por ejemplo.

Finalmente, dispara un montón de links para otros lados también muy interesantes... en fin, aprendí un montón. :-)

Es lectura para un día lluvioso, ideal para revoleárselo a pibes que hacen Programación II en una facultad.

http://www.shlomifish.org/philosophy/computers/optimizing-code-for-speed/

Saludos
Marcelo
PD: Es más, veo que el sitio mismo del autor tiene bastantes artículos similares sobre computación... será cuestión de agendar el sitio y leerlo de a poco.
PD2: Ignacio: habla de lo "malo" y lo "bueno" que puede llegar a ser el inlining de funciones, vos que sos un defensor tan acérrimo :-P . También habla de la pobre performance de algunas llamadas de la Glib, cosa que vos también nos demostraste en su momento con el Quicksort.

QT será licenciado como LGPL

Creo que es la mejor noticia de los últimos (¿años?) con respecto al mundo del software libre en el escritorio: las bibliotecas de desarrollo QT, en su versión desktop y embedded, piedra fundamental de todo el entorno de escritorio KDE (y de muchísimas aplicaciones más), se distribuirá con licencia LGPL, a partir de su versión 4.5.

Ahora los programadores seremos libres de desarrollar aplicaciones cerradas ("comerciales") o no con QT, tanto para móviles/smartphones (Windows CE, S60) y/o dispositivos varios como para el escritorio (Windows, Linux, Mac, y más). No todos podíamos pagar la licencia comercial de QT (no lo dice, pero era muy salada, por asiento y en euros), y nos perdíamos de usar una de las mejores bibliotecas de desarrollo de su tipo en existencia.

Ajá, y para el usuario "de a pie"... ¿Qué quiere decir? En principio, se me ocurre:

• Firefox (para empezar) y luego un montón de aplicaciones van a tener la posibilidad de integrarse mucho mejor con KDE.
• Gnome y KDE podrán intercambiar código y hasta hacer un proyecto conjunto de librería única (a mediano/largo plazo... quién sabe?). Pero al menos será más sencillo hacer que tanto aplicaciones como escritorios interactúen mejor.
  

Noticias como esta me ponen muy contento, Desde que compró Trolltech (creadores originales de QT), parece que Nokia no para de invertir en el software libre para su propio beneficio (tal como hacen varios otros)...

Ars Technica tiene un buen artículo sobre la noticia, resumiendo la situación anterior de QT y explicando porqué es tan significativa en el "mundillo" del software libre.

(¿Será tiempo de aprender C++?... no creo, tengo la impresión de que no vale la pena... en todo caso prefiero usar QT desde Java.)

Saludos
Marcelo
PD: El 2009 se viene con todo...

Sobre KVM - Virtualización en Servidores

Leyendo la blogósfera, me detuve en esta crónica de una migración de VMWare Server a KVM, explicando las razones de porqué elegir KVM y no el resto. :-)

Las enumero, tratando de traducirlas lo mejor posible:

• El host corriendo KVM es un Linux estándar sin modificar. Para ambos (Xen y VMWare ESX) se necesita correr un Sistema Operativo modificado especialmente (que lo hace relativamente difícil de mantener al día con actualizaciones de seguridad).
• Siendo incluído en Linux, usted obtiene soporte de KVM en el mismo momento que usted compra soporte estándar de Ubuntu Server. Como de todas maneras teníamos planeado adquirir soporte Ubuntu, tuvimos soporte para nuestra plataforma de virtualización sin costo adicional.
• Performance: La velocidad de KVM es muy buena, ya que está basada en extensiones de hardware. (N. del T.: Ojo, tengo entendido que tanto Xen como VMWare también soportan extensiones de hardware en caso de estar disponible).
• VMBuilder: Ubuntu desarrolló una herramienta (ubuntu-vm-builder, ahora llamada vmbuilder) que puede construir un appliance virtual en aproximadamente un minuto. Esta es una mejora enorme en comparación a la forma que solíamos crear VMs (VMbuilder también puede ahora crear imágenes para Xen y VMWare). (N. del T.: En mi experiencia, sirve únicamente si vamos a crear VMs con SO Ubuntu).
  
• KISS - Keep It Simple, Stupid (Mantenlo Simple, Estúpido!): KVM utiliza todo lo que Linux provee de antemano. Cada VM es un simple proceso, usa su planificador de procesos (scheduler), uno puede reasignar la prioridad (renice) del proceso, asignarlo a una CPU específica... esto resulta en una base de código fuente mucho más pequeña que Xen por ejemplo, de manera que asumo que será más fácil y barato mantenerlo a largo plazo, haciendo que el proyecto más confiable.
• Y lo más importante: Las companías involucradas. Aún cuando a KVM le faltan algunas características, los posts en la lista de desarrolladores muestran parches de código desde empresas como RedHat (que compró KVM el año pasado), AMD, Intel, IBM, HP, Novell, Bull... ¿A quién va a creerle, a un proyecto manejado por una única compañía (Citrix, VMWare), o a un proyecto soportado por tantos actores diferentes?
  

Para mí le falta otra cosa importante: Tiene un desarrollo totalmente abierto y es software de cóodigo abierto. :-)

En donde laburo estuvimos metiendo KVM en un servidor y si bien las herramientas de configuración/administración tienen sus quirks (aunque funcionan relativamente bien), la parte de KVM en sí anda perfectamente y con una excelente performance y confiabilidad. ¡Ah! y Canonical ya había anunciado que iba a soportar KVM como plataforma principal de virtualización también, así que... IMHO, KVM tiene todas las de ganar de acá en adelante.

Espero postear próximamente un poco las experiencias que tuve armando VMs con este software, mientras tanto dejo este enlace que resume la mayoría de las cuestiones con KVM en Ubuntu.

Saludos
Marcelo