La era de Linux ya pasó...

La era GNU/Linux ya fue. Y si no te diste cuenta, eso sucedió durante el año 2004. Ya en el 2005 yo comentaba que hacer una charla sobre Linux era "repetirse", era hablar de temas que el promedio ya conocía. Era imposible sorprender a tu auditorio.

No había nada nuevo para contar.

En 1997, cuando me inicié en el tema, tuve que ayudar a preparar y a dictar una charla sobre "Unix en General" para nivelar los conocimientos de un grupo de personas que terminarían formando parte de un grupo de usuarios de Linux.

Han pasado muchos años, y se sigue escuchando el mismo diálogo monotemático: "Linux esto, Linux aquello, Linux para todo, sin Linux nada, etc".

"Linux ya fue"

Linux es un sistema operativo. Nada más. Es parte de la infraestructura, donde tu montas los proyectos de todos los tamaños y colores. Pero nada más. Es solo "infraestructura".

Ya superamos la revolución; pero parece que en la actualidad no tenemos nada nuevo que ofrecer y tenemos que seguir insistiendo sobre algo del pasado.

Lo que importa ahora, o mejor dicho, lo que siempre importó fueron los proyectos, los nuevos desarrollos, los nuevos paradigmas, los nuevos desafíos, las nuevas herramientas para enfrentar esos nuevos desafíos. Puedes tener un muy buen sistema operativo, pero si no tienes nada para correr sobre él... de qué sirve? ¿si tienes la aplicación que corre sobre el sistema operativo, pero no tienes clientes para ella?

¿No fue eso lo que sucedió con OS/2 de IBM? El mejor sistema operativo derrotado por el peor sistema operativo, técnicamente hablando.

No puedes vivir y sobrevivir repitiendo el mismo "verso"

Los artículos sobre Linux ya no venden como antes. Nadie se le ocurre publicar en una revista como se instala Linux.

¿O me dirás que no te has llevado la sorpresa de que alguien cercano que no tiene nada que ver con la informática te ha preguntado si estabas al tanto de algo llamado Linux?

Unix, Linux ... Linux, el Unix Moderno. Trajimos del cajón del olvido a Unix, y le lavamos la cara. Sí, pero tu me dirás que ahora es "libre"...

Ok, listo. Ya está.

Linux no es "disruptivo"

Entre los "consultores charlatanes" (no me incluyo ;-) está de moda decir que "esto" o "aquello" es disruptivo ("Que produce ruptura brusca"). "Esta" tecnología es disruptiva, la "forma de pensar" es disruptiva, es una "idea" disruptiva.

Linux, fue una tecnología que produjo en su momento una ruptura brusca, pero ya dejó de hacerlo.

¿Qué estamos esperando entonces?

Demos vuelta la hoja.

Estamos perdiendo la "carrera" y todo por quedarnos a observar nuestros propios "espejos de colores".

¿Cual es el nuevo desafío que tenemos por delante? ¿qué es lo que necesita el mercado? ¿estás escuchando a tus clientes? ¿has descubierto las nuevas necesidades y has logrado satisfacerlas con éxito? ¿se te han ocurrido formas de forzar las necesidades en tus clientes?

¿Antes podía vivir sin el teléfono, porqué ahora no puedo vivir sin mi celular? ¿realmente lo necesito? ¿o me obligaron a necesitarlo?

Google usa Linux

¿Eso hace la diferencia? ¿El éxito de Google se debe a Linux?

No nos dimos cuenta que estamos perdiendo la carrera. En el año 2000 dijimos que Linux desbancaría a Windows, y hasta el día de hoy escucho técnicos que lo repiten.

El viejo perdedor a retomado su camino y está dando pelea. Apple, la famosa empresa de productos como Mac, iPod, etc, está siendo el verdadero competidor y se está volviendo a ganar un espacio entre los consumidores.

¿Importa que sistema operativo usa el iPod?

¿Verdaderamente corre el sistema operativo OS X o corre Linux? No hace a la discusión, lo que importa es el producto en su conjunto: infraestructura + software + servicios + calidad + modelo de negocio...

No podemos estar toda la vida repitiendo el mismo mensaje... con el tiempo perderá fuerza.

La era de Linux ya pasó... ya es hora de que hablemos de otra cosa.

PHP6, Framework, Ruby On Rails, Ajax, Videojuegos, Usabilidad, eGovernment, Patrones de Diseño, Desarrollo Agil, Estándares, Web 1.0, Web 2.0, Celulares, Podcast, Webcast, Weblogs...

¿Usaré Linux? Si, donde pueda, pero no siempre ... no me sirve para todas las situaciones.

Pero por favor, no me vuelvan a decir que "compilar el kernel" es fundamental para los negocios de mi cliente.

Cambiar la hora de los servidores GNU/Linux

En mi país, You are Gay, habíamos cambiado la hora para aprovechar la luz solar y ahorrar energía eléctrica. Lo cómico del asunto es que mientras toda la región tenía la misma hora, si tu entrabas a nuestro país debías ajustar tu reloj como si hubieras cambiado de huso horario (aunque es coherente, vivimos a contramano del mundo ;-).

El viernes a última hora recibo el fatídico recordatorio de que habría que actualizar la hora de los servidores el día domingo para que al día siguiente no se generara el problema de que todo registro de horas quedara con 1 hora de atraso (logs, bases de datos, aplicaciones, etc).

Fatídica orden para hacerte perder unos minutos y tratar de recordar "¿cómo era que se cambiaba la hora de los servidores?", más aún si te quieren obligar a venir muy temprano solo para esa tarea... y piensas: "¿y cómo lo puedo hacer a distancia, desde casa, a través de una conexión remota y usando la línea de comandos?"

Y bueno, dicen que "la necesidad es la madre de las invenciones", o debería ser "¿la haraganería nos hace muy creativos?" ;-)

El comando para saber la fecha de nuestro servidor es "date", y el resultado sería:

bd:~ # date
Tue Mar 14 11:22:57 ART 2006

Y el cambio sería con el mismo comando, pasando una cadena de texto:

date --set="10:22:57"

Y si justo haces el cambio de hora cuando cambió de día, simplemente repites la cadena desde la parte que quieres modificar:

date --set="Mar 13 10:22:57"

Otra forma más eficiente es tener sincronizado el reloj del servidor con otro que se encargue de brindar el servicio de NTP:

/usr/sbin/ntpdate time.nist.gov

Si la hora de tu servidor se atrasa, tomará como referencia un servidor externo y será sincronizado cada vez que ejecutemos ese comando.

Se puede agregar al "planificador de tareas" (a.k.a. crontab) para que corra cada una hora:

0 */1 * * * /usr/sbin/ntpdate time.nist.gov > /dev/null

Esperemos que hasta el año que viene no necesite cambiar otra vez la hora de los servidores ;-)

PostgreSQL: crear tablas temporales a partir de una consulta SQL

Siguiendo con mi trabajo de DBA Part Time, tuve que resolver el siguiente problema: en nuestra base de datos existe información de una "compra de mercadería" de muchos ítems que podía ser utilizada como plantilla para otro caso muy similar. Esto permitiría ahorrarles tiempo y trabajo a los usuarios que no tendrían que volver a ingresar toda la información manualmente, solo modificar los datos que cambian.

Esta información se encuentra desperdigada en varias tablas. Mi estrategia es crearme una o varias tablas temporales, obtener los datos requeridos, modificarlos a gusto, y finalmente, integrarlos a la tabla original. Este procedimiento me permite trabajar de forma segura, limpia, ordenada, sin arriesgarme a cometer errores en la tabla original.

Descarto que este tipo de situaciones se deben hacer primero en una base de datos de prueba, documentarlo y armar scripts automatizados (que no dependen de un dato que pueda ingresar de forma errónea), y cuando todo está correctamente verificado, se aplica en la base de producción.

No sería la primera vez que he estado obligado (por las circunstancias ;-) a trabajar directamente en la base de datos de producción, y tampoco la última vez que cometeré errores con pérdidas de datos (quién no escribió alguna vez un UPDATE sin WHERE ;-).

1) Leyendo el manual de Postgres me encuentro que puedo crear una copia de la estructura de una tabla con los datos que yo quiera, de la siguiente forma:

CREATE TABLE compras_tmp AS 
   SELECT * FROM compras WHERE id = '12345';

A partir de la tabla "compras" creo una tabla temporal llamada "compras_tmp" con los datos de la consulta que se extrajo de la tabla original.

2) Luego, modifico en la tabla temporal el valor clave y todos los datos que se requieran.

UPDATE compras_tmp SET id = '999999' where id = '12345';

3) Luego de que los datos fueron modificados, hay que incorporar la tupla a la tabla de producción, ejecutando el siguiente comando:

INSERT INTO compras SELECT * FROM compras_tmp;

Insertando en la tabla "compras" todos los datos que se encuentran en la tabla temporal.

4) Y lo que hacemos siempre los programadores "con aires de DBA", es olvidarnos de borrar las tablas temporales que luego nunca más se usarán:

DROP TABLE compras_tmp;

Espero que les pueda ser útil si alguna vez tiene que hacer algo similar en PostgreSQL.

La definición del día: "Win-dows"

"Win·dows Sustantivo. Una extensión y entorno gráfico de 32 bits diseñado para un patch de 16 bits para un sistema operativo de 8 bits, originalmente creado para un procesador de 4 bits, por una empresa de 2 bits que no tolera ni 1 bit de competencia".

Extraido de BootLog