La charla a las 9.00 hora local fue retransmitida por algunos medios, en formato nanoblog, actualizada cada pocos minutos, casi como si estuviésemos allí. Y tras un análisis del mercado de descargas, algún anuncio sobre el iPod, etc. Llegó el momento; el momento más esperado por muchos, el nuevo producto era anunciado. Un nuevo portátil the world’s thinnest notebook. Las sospechas de muchos hasta este día se habían confirmado.

De forma precisa unos minutos antes de que Steve entrase en acción, tenían la web “caida”, pero no con una OutOfMemoreyException, umm no! tenían un we’ll be back soon. Y un mensaje más explicativo diciendo que estaban actualizando la tienda.

Un hecho que no se podía dejar escapar por el momento en el que se estaba produciendo, eso significaba para los ojos de muchos que estaba a punto de acontecerse un alumbramiento y efectivamente, así ha sido el Macbook Air, un nuevo modelo ultraligero.

Con unas características extravagantes como la ausencia de dvd o cd, con otras un tanto más extraordinarias:

Pantalla de 13,3 pulgadas (igual que el MacBook)
Grosor de 0.4-1.94 cm
Apenas 1,2 kilos (más o menos similar a otros ultraligeros)
Procesador Intel Core 2 Duo a 1.6 o 1.8 GHz
Disco duro de 80 GB o bien 64 GB de memoria SSD (disco duro de estado sólido)

Nota: un procesador, creado especialmente por Intel para este producto.
Todas las especificaciones en Apple

Lo alucinante es la sincronización, el espectáculo, el marketing y el marketing viral que se ha producido. Todo el mundo expectante por lo que podría suceder, así que al final tenemos lo que esperábamos.

De momento, lo que a mi me ha dolido más a sido la no actualización del Macbook normal, esperaba que lo ampliasen de alguna forma, memoria era raro, quizás HD, aunque tampoco era muy posible, pero quizás cpu o la gráfica, algún detalle curioso, pero bueno, seguiremos al tanto de la exposición que aún le quedan unos días y todo podría pasar.

Aps! Y ahora son Apple, Inc y no Apple Computer, Inc XD, se nota que apple amplia mercado y deja de ligarse única y exclusivamente a ordenadores (bueno, ya se “notaba” antes), quien sabe quizás algún día se meta en consolas y nos sorprenda aún más.

En principio pensé que esto no sería un problema, dado que controlo el usuario root del sistema y no veía que hubiese inconveniente en que el root cambiase una password sin saberla; estaba en lo cierto. MySQL está preparado para eso.

En la documentación de MySQL podéis encontrar como hacerlo, sin embargo, existe un punto que yo en Ubuntu no logré hacerlo funcionar tal como lo describían:

Locate the .pid file that contains the server’s process ID. The exact location and name of this file depend on your distribution, hostname, and configuration. Common locations are /var/lib/mysql/, /var/run/mysqld/, and /usr/local/mysql/data/. Generally, the filename has the extension of .pid and begins with either mysqld or your system’s hostname.

En mi caso no fue posible encontrar este fichero en ninguno de los directorios, por lo que no pude hacer un kill a los procesos de mysql de este modo. Solución (bastante fácil): listé los procesos que coincidían con los caracteres mysql:

ps -e | grep mysql

de esta forma hice un kill de mysqld (llegado a este punto, no recuerdo si también hice un kill de mysqld_safe; aunque sino logras entrar en mysql sin password, está claro que sí, que hay que parar este proceso también) y continué con el resto del proceso. Después, tienes que acceder a mysql con el usuario root, pero sin password y ejecutar el update directamente en línea de comandos de mysql con la nueva contraseña.

Actualización de Ubuntu 6.06 a 6.10 a… 7.04 todo ello de un tirón. Con algunos problemillas que surgieron al actualizarme.

La verdad es que hasta ahora las actualizaciones a versiones de la distribución superiores (upgrades) siempre habían aparecido en el Update Manager sin embargo en esta ocasión no ha sido así para la versión 6.10, de ahí que no hubiese actualizado a ella, más por pereza que por resultar ser un problema.

Para actualizar la versión de Ubuntu 6.06 a 6.10, basta con ejecutar:

gksu “update-manager -c -d”

con ello el interfaz GUI del Update Manager aparecerá informándonos de que hay nueva distribution release. Pues bien, a partir de esto, basta con ir siguiendo las instrucciones que en nuestro caso particular pudiesen ir siendo necesarias para configurarlo todo. En mi caso tuve que respetar algunos archivos de configuración, para no tener que reconfigurarlos. Tras esto, mi sistema siguió funcionando bien; aunque mi comprobación fue bastante breve, porque quería continuar actualizando.

En este caso tuve suerte, pues sí aparecía la actualización de la versión 7.04 y realizé el upgrade directamente y aquí si tuve problemas . Pero no exactamente con la actualización sino más bien con el resultado de la misma.

El primero de ellos fue, que php fue actualizado a la última versión del repositorio de ubuntu y el sistema Serendipity que tenía antes tenía incompatibilidades con dicha versión, por lo que el blog dejó de funcionar hasta que logré instalar la nueva versión y arreglar algunos entuertos. De todas formas esto ha echo mejorar la seguridad de php y también actualizar a la nueva versión del sistema del blog, lo cual nunca bien mal. Además he cambiado el template, he dejado el default, pero casi que me gusta más que el que tenía antes.

Otra cosa mala, esta vez por mi culpa es que olvidé la password de mysql, pero eso… eso ya, es otra historia.

Claro, para los excépticos estas líneas no son todo código, ciertamente, pero vamos, si quieres hacer un cálculo, tienes que aproximar de alguna manera y más cuando existen muchos programadores en el equipo, que no tienen porqué seguir las mísmas normas a la hora de codificar, dejan más espacios en blanco, escriben comentarios, parten las llaves otra línea nueva etc.

La verdad es que si te planteas esto, tienes algo claro: necesitas establecer qué es una línea de código. Y no lo es una línea que contenga { o } o una línea en blanco, etc. En este caso he encontrado que si miras los saltos de línea, no sería demasiado acertado, entonces ¿qué hacer? Pues buscando cómo hacerlo me he topado con algo curioso, contar los “;” que existan, ya que nuestro lenguaje en este caso java,y casi todas las líneas terminan con él, así que nos sirve la aproximación.

Si esto lo piensas hacer con un lenguaje de programación, te dolerá la cabeza , pero claro, si tienes un linux a mano (yo lo tengo )… las cosas salen rápidamente:

$ cat `find . -name *.java` | egrep “;” | wc -l

la primera busca todos los archivos java que encuentre, la segunda filtra para dejar las líneas que contenga “;” y la tercera cuenta las líneas.

En nuestro caso, han salido 15.565. ¿Pocas? ¿Cuántas tenéis vosotros? ¿Son proyectos grandes? La verdad es que me gustaría comparar, sólo por curiosidad.

He visto en la web de IBM que los sistemas operativos para los que que esta JVM es distribuida son:

- Linux® on x86
- Linux® on PowerPC® 32-bit
- Linux® on PowerPC® 64-bit
- Linux® on AMD64/EM64T
- IBM AIX® on PowerPC 32-bit
- IBM AIX® on PowerPC 64-bit

Al ver esto, se me plantea una duda con respecto a la elección de IBM de no soportar plataformas Windows. Siendo totalmente prácticos e irreflexivos, podríamos pensar que esta estrategia está totalmente equivocada, tengamos en cuenta que la mayor parte de usuarios cuentan con Windows como sistema operativo; y claro, esto podría llevarnos a fabricar la hipótesis, ¿algo errada!, de que su estrategia empresarial está totalmente equivocada, dado que de esta forma no van a conseguir que su JVM sea utilizada por el público en general, ni por los desarrolladores que tengan que trabajar en entornos Windows, que son unos pocos.

Quizás, la hipótesis pueda ser otra. IBM como gigante de la informática que es, cuenta con muchas vías de negocio dentro de la compañía y una que no debemos olvidar son sus máquinas. Dispone de una vía de negocio muy amplia con el negocio de servidores. No parece extraño pensar, por lo tanto, que si optimizas un JVM para los sistemas operativos que más se utilizan en tus máquinas, a la vez estás haciendo más atractivo el potencial que ofrecen tus servidores frente a los del mercado. En este punto no podemos olvidar que el principal representante de Java, Sun MicroSystems, también trabaja en ese mercado.

Por otro lado, me asalta la curiosidad. Si planteo un caso hipotético, un caso en el que el usuario de partida trabaja sobre windows, y realiza todo su desarrollo en dicha plataforma, necesita utilizar un JDK para ella, pongamos por caso que utiliza el de Sun, tras meses de desarrollo, su aplicación a sido preparada para un JDK, y ha sido más que probada, hasta la saciedad si se ha contemplado bien el tiempo de pruebas dentro del proyecto. Cabe hacerse la pregunta de si verdaderamente dicho software debe terminar o no ejecutándose en una JVM para la que apenás ha sido probada. Podrían presentarse, ¿incompatibilidades? Entiendo que no deberían de ser con respecto al lenguaje, pero cuando uno hace las cosas de diferente manera (me refiero a la JVM de IBM) se enfrenta a que quizás lo que el programador consideró más óptimo en un JDK-SUN no lo es en un JDK-IBM, por lo que parte del trabajo que se realizó en la fase de pruebas de desarrollo se ha perdido por completo. Además si hacemos bien las cosas, el salto de desarrollo a preproducción, implicará en la mayoría de los casos un tiempo extra para ver si el JDK-IBM continúa funcionando correctamente y nos ese mayor rendimiento del que hablábamos.

Preguntas que se me ocurren para aquellos que hayáis cambiado de un JDK-SUN a un JDK-IBM: ¿Es considerable el tiempo empleado en probar con un JDK y luego con el otro? Dado el modo en el que se suelen hacer las cosas para los cambios de desarrollo a preproducción y finalmente a producción, ¿os arriesgaríais a cambiar de una a otra?

A todo esto, ¿no os parece que así se pierde, un poco, una de las principales características de java, la multiplataforma?

(Más características).

dynamic DNS service update utility not in use
…done.

En mi caso lo había instalado con synaptic y tras configurarlo, le copie el fichero de propiedades que tenía de antes y el mensaje vino al hacer un restart.

La solución es sencilla, basta con ejecutar:

dpkg-reconfigure ddclient

Lo dejo aquí como apunte, para la próxima . Por cierto que synaptic no tiene la culpa, con aptitude me daba el mismo problema.

Eso sí, por si tenía algún truquillo tiré de google y visité algunas webs, para no liarla, y me encontré con esta: railes.net mini-guía que lo explicaba, funcionó a la primera.

source .bashrc

esto se utiliza cuando modificamos el archivo de configuración de la shell bash (.bashrc), y queremos que haga un restart para que carge los nuevos cambios. La verdad no ha sido excesivamente fácil encontrarlo, y eso que sabía que existía. En la mayoría de los sitios te dicen que hagas un logout de la sesión y vuelvas a entrar, tras haberlo modificado.

Otro comando que va a hacer las delicias de más de uno, por lo menos yo lo hechaba en falta… y es que en linux existe de todo , es:

which application

con esto conseguimos que nos diga la ruta de la aplicación, útil cuando instalamos con apt-get o sus homónimos.

Si queréis algunos más, aquí tenéis.

Podemos utilizar aptitude, este también utiliza apt para trabajar, sin embargo presenta ciertas mejoras frente a apt-get; entre ellas:

- cuando desinstalas un paquete, aptitude desinstala los paquetes que se instalaron como dependencias. En el caso de apt-get esto no ocurre, quedando librerías en el sistema que luego deberías controlar mediante ciertas herramientas. Puedes utilizar deborphan o un frontend gráfico como gtkorphan.

- en tu /etc/apt/sources.list puedes introducir varias distribuciones, por ejemplo la estable y la de desarrollo y especificar el tipo de distribución en función del paquete que vayas a instalar.

- resuelve de forma más eficaz las dependencias en actualizaciones complejas, donde hay conflicto entre paquetes, actualizaciones parciales del sistema

Podéis encontrar una lista de los comandos básicos de aptitude, aquí, aparte de un ejemplo utilizando apt-get y aptitude en el mismo caso de instalación.

Un detalle, si instalas con apt-get, y luego no esperes que las dependencias sean bien removidas con aptitude, no funcionará.

aptitude también tiene un sistema de menus para utilizarlo, en lugar de hacer uso de la línea de comandos, por si queréis utilizarlo, basta con escribir aptitude en línea de comandos y podréis echarle un vistazo. Es un frontend basado en ncurses.

Si esto de la línea de comandos te parece un poco lejos te tu realidad o prefieres probar algo con un frontend en GTK, puede probar synaptic, lo malo es que utiliza apt por debajo, con lo cual no estarás haciendo uso de las buenas funcionalidades de las que he hablado antes.

También existen otras herramientas para los que no utilicéis debian:
- urpmi: para mandriva.
- yum: utilizado para los sistemas de paquetes de Red Hat.
- apt4rpm: un creador de repositorios para paquetes RPM de Red hat.

La última vez que hice esto tuve que bajarme el binario de la web de Sun y seguir el proceso de instalación. Lo que pasa que desde entonces ha llovido mucho, y para los que no lo sepáis, desde hace un tiempo se puede instalar la máquina virtual y algunas cosas más desde los repositorios de apt. El único problema que podríais encontrar, es que los repositorios por default de apt no incluyen el necesario para instalar la máquina virtual de Sun.

Investigando por la red, conseguí encontrar algo interesante: aquí; sin embargo antes de poder ver cuales eran los repositorios que debía configurar, me acordé de synaptic, y decidí probar a ver que tal funcionaba. Y he ahí donde encontré un tesoro: AQUÍ.

Al hilo de esto os voy a comentar una cosa interesante. Por defecto las distribuciones que yo he instalado últimamente, si no le dices lo contrario, suelen instalar el gcj, que es la máquina virtual de Java de GNU, bien, pues existe un archivo interesante en la configuración de Linux: /etc/jvm en este se lista los directorios por orden de preferencia donde quieres que se busquen tus máquinas virtuales, en mi caso como siempre suelo utilizar la de Sun Microsystems, he eliminado el directorio de gcj y he dejado sólo el del jdk de sun.