Teclarios

La última vez que la ví, mi infancia estaba jugando con un Amstrad CPC, mientras mi adolescencia la miraba con desdén por encima del hombro, con las manos en el teclado de un flamante 286 con monitor a color.

Pero, en realidad, nunca renegué de mi pasado. Cuando con mi siguiente ordenador, un 486, fui capaz de ejecutar un emulador de CPC, los recuerdos de otros paisajes y otros tiempos volvieron a mí, y las tardes de niñez jugando al Ikari Warriors, al Bomb Jack, al Wonder Boy y un largo etcétera compitieron con las del Turbo Pascal, el Pspice, y el C++ Builder.

¡¡Vaya invento amigos!! ¡Los emuladores! Esto era un concepto nuevo… ¡un ordenador dentro de otro! ¿Cómo podía ser?

En un intento de sacar de las viejas cintas del CPC mi código en Basic escrito con dedos de niño, por volver a ver aquellos primeros pasitos que me enseñaron a programar, conseguí montar, armado con un soldador, un cable para conectar, por el puerto paralelo, el CPC con mi 486. Qué cosas… qué cara debió quedárseme cuando, por diferencias de amperaje, quemé la placa del PC, a una semana de los exámenes y con 4 prácticas por terminar… y yo que sólo quería echar una partidita para aliviar tensiones…

Hoy, por otros motivos, quería recuperar mi emulador de CPC. Dejar salir alguna lagrimita recordando otras épocas, cuando era más joven, el mundo iba un poco más despacio, y había tiempo para jugar.

Pero el emulador que ejecutaba en mi 486, y que luego pasó por un Pentium II, y por un Athlon, es para MS-DOS. Por lo que, en realidad, lo he estado usando (hasta la última vez, el año pasado) en Windows 98, 2000 y XP en modo compatibilidad… con un sistema operativo de 1991 (asumiendo MS-DOS 5.0), para emular una máquina de 1984.

Pero en Abril cometí un pecado. En mi nuevo portátil, con 4 GB de RAM (65.536 veces más que mi viejo CPC que, por cierto, aún conservo) decidí instalar Windows Vista 64, para poder direccionar toda esa memoria. Y no leí la letra pequeña… la versión de 64 bits ya no es compatible con MS-DOS (de 16 bits):

Ahora la única opción que me queda para jugar al Ikari Warriors, al Bomb Jack y al Wonder Boy, para no dejar del todo atrás mi niñez, para no convertirme en un adulto miserable que come sopa, que programa por dinero y se ha olvidado de soñar, la única alternativa, digo, es instalar en mi sistema operativo de 64 bits, una máquina virtual con Windows XP (de 32 bits), para que emule a MS-DOS, de 16 bits, sobre el que ejecutar el emulador de un procesador de 8 bits. Sólo así podré cargar los juegos de antaño. Sé que hay emuladores para Windows, pero no son el que he usado siempre, del que me sé las teclas rápidas (soy un teclario, no un ratonario), el que puede ponerse a pantalla completa, el que, ¡santo cielo!, ha estado más en mi disco duro de lo que llegó a estar el CPC encima de mi mesa. Hoy la única alternativa que me queda es emular el CPC dentro de un ordenador virtual que se ejecuta encima de otro.

Me pregunto si pasados otros 10 años, tendré que instalarme un meta-emulador, para instalar Windows Vista, en el que instalar una máquina virtual con XP en la que ejecutar el emulador para poder seguir jugando. La película Nivel 13 viene a mi memoria… Si Von Neumann levantara la cabeza.

Querido Ndugu,

Hoy los programadores de C++ estamos de enhorabuena. El famoso nuevo estándar de C++, conocido entre los amigos como 0x tiene ya el primer borrador completo. El nombre, 0x, era una especie de promesa de la gente del comité que hace años asumió la responsabilidad de tenerlo listo antes de 2010 (la ‘x’ viene a ser el comodín que sería sustituido por el año de publicación, por lo que el estándar tendría la forma C++ 0x y nunca C++ 1x…).

Hace por lo menos dos años que le vengo siguiendo la pista a las reuniones del comité, a las propuestas y a los documentos generados sobre los estudios de las nuevas características que estaban planteándose añadir, y me alegro de que por fin se acerque el momento de poder utilizar el “auto” especialmente en la declaración de variables con tipos parametrizados, los “conceptos” que mejorarán los mensajes de error dados por el compilador, y otro montón de cosas que iban siendo necesarias en C++.

El borrador tiene nada más y nada menos que 1352 páginas (que espero que no tengan en un único documento en Word ). Es un documento que merece la pena conservar aunque la misma portada reconoce que son conscientes de que está incompleto y contiene errores. Pero merce la pena, digo, conservarlo al menos hasta que haya otra versión de borrador más moderna, porque puede que, igual que el documento del estándar anterior, haya que pagar por la versión definitiva.

No es que me de por leerme el estándar de C++ en mis momentos ociosos, pero alguna vez he recurrido a él cuando hacía cosas un poco conflictivas. Y siempre queda bien resolver la cuestión con la frase concreta del estándar que te resuelve la duda… si alguien te viene diciendo que no le funciona, le puedes soltar que su compilador no cumple el estándar, y que la culpa no es tuya

Siempre he creído que trabajar en un comité de estandarización no debe ser nada fácil. Este borrador lo refleja claramente. Pero por si sois perezosos y ni siquiera abrís el enlace para intentar entender el soporte de las hebras (si pasáis de la primera página de la sección habiéndolo entendido, decidlo ), contaré algo yo sobre esto.

En el desarrollo del estándar hay que intentar fijar unas normas de tal forma que sean tan claras que no dejen lugar a dudas sobre lo que quieren decir, ni dejen cabos sueltos que abra las puertas a futuras incompatibilidades entre los implementadores.

A eso hay que añadir la gran cantidad de conflictos de intereses contra los que algunos estándares tienen que luchar, las sugerencias o ideas que reciben los comités, las presiones de tiempo y un largo etcétera.

El libro “The design and evolution of C++” es una buena fuente para darse cuenta de todos estos aspectos, pues describe la experiencia desde dentro (los ejemplos que aquí describo están sacados del libro). Con él se aprende que gran parte del proceso de estandarización consiste en “encontrar la forma de expresar completa y claramente lo que todo el mundo sabe pero resulta no estar escrito en ningún manual”, en aclarar aspectos oscuros que afectan a un pequeño número de programadores, pero que son vitales para los implementadores de los compiladores que en un momento dado se enfrentan al problema de decidir cómo compilar un ejemplo concreto de código.

El libro dedica unas cuántas páginas a resolver el problema de estandarización del método para determinar con exactitud a qué declaración corresponde un nombre cuando se declara una clase. Por ejemplo, ¿a qué x se refiere la implementación de X::f() en el siguiente código?:

int x;

class X {
   int f() { return x; }
   int x;
};

Cualquiera que haya programado un poco en C++ contestará (correctamente) que se refiere a X::x. Podríamos incluso ser capaz de deducir una regla (incorrecta, como veremos) del tipo “en la definición de las clases, los símbolos definidos dentro de ella están disponibles también para las declaraciones anteriores a la propia definición del símbolo”.

Entonces, ¿qué ocurre con este código?

class T {
   A f();
   void g() { A a; /* ... */ }
   typedef int A;
}

Con la regla anterior debería compilar, pues A está definido dentro de la clase T que lo utiliza… pero no. No compila. Y no compila porque en realidad, el primer ejemplo compilaba por otra regla distinta, una cuyo nombre técnico es “regla de reescritura” y que viene a decir que las funciones miembro que se declaran inline deben ser analizadas como si estuvieran definidas inmediatamente después del final de la declaración de la clase. Con esta regla, la implementación de X::f() del primer ejemplo se analiza “después” de analizar toda la clase, y en particular, su atributo X::x.

Y según esta regla, este segundo ejemplo no compila cuando analiza la línea A f(), ya que el tipo A no está definido, pero no da error en la función inline ya que, aplicando la regla de reescritura, al final de la clase A ya está definido.

La regla de reescritura, no obstante, introduce un nuevo problema, a saber: ¿a qué T se refiere Y::f() en el siguiente trozo de código?

typedef char *T;

class Y {
   T f() { T a = 0; return a; }
   typedef int T;
};

El problema surge debido a que la implementación anterior utilizando la regla de reescritura es equivalente a (o mejor dicho, se compila como):

typedef char *T;

class Y {
   T f();
   typedef int T;
};

inline T Y::f() { T a = 0; return a; }

De tal forma que en la definición de Y::f() (dentro de la clase) ésta devuelve un char *, pero en la declaración/implementación posterior, pasa a devolver un entero.

Pues bien, para evitar esto, se introduce una regla más, conocida como la regla de la redefinición del tipo, que dice que un tipo no puede ser redefinido en una clase después de su primer uso en ella. Por lo tanto, el error que da el compilador es algo como “error en la declaración typedef int Y::T, por cambio de significado” (es curioso comprobar que esta regla no se tiene en cuenta en Visual Studio, al menos en las versiones 2003 ni 2005…).

Volviendo al proceso de estandarización, estas dos reglas ya estaban claras cuando el proceso de estandarización de C++ comenzó. En principio, parecían suficientes para cubrir todos los casos pero ahí es donde entra el trabajo de la gente del comité que se dedica a busca casos esotéricos que no sean cubiertos por las reglas. Son fragmentos de código que uno no se encuentra en su quehacer diario pero que, cuando alguien se enfrenta al problema de programar un compilador, debe resolver. Si se utilizan únicamente las dos reglas anteriores, no está claro qué se debe hacer.

El ejemplo que aparece en el libro y que refleja que el trabajo de una de estas personas puede llegar a ser perjudicial para su salud mental es el siguiente (tengo que reconocer que me costó bastante entender qué quería decir…):

typedef int P();
typedef int Q();

class X {
   static P(Q); // equivalente a static P Q; es decir
                // la definición del símbolo Q del tipo
                // P, es decir, función que devuelve un int

                // Q por tanto ya no es el typedef

   static Q(P); // definición de Q como una función que
                // recibe como parámetro a P y que devuelve
                // un entero (int implícito heredado de C).
};

Si obviamos que finalmente eliminaron la posibilidad de omitir el int en el tipo devuelto por una función, el código anterior era válido; “simplemente” declara dos funciones Q con tipos distintos en los parámetros. Sin embargo, si le damos la vuelta a sus declaraciones, estaríamos definiendo dos funciones P. Si quitamos alguno de los typedef tenemos otros significado…

Un ejemplo más sencillo que tampoco era cubierto por las reglas anteriores es:

int b;

class Z {
   static int a[sizeof(b)];
   static int b[sizeof(a)];
};

En este caso, también debería resultar en un error pues b cambia de significado después de su primer uso (aunque no cambia en realidad el significado de ningún tipo).

Espero que estas secciones de código y sus explicaciones hayan sido suficientes para ejemplificar lo duro que debe ser trabajar en uno de estos comités.

Por terminar el post, pongo aquí las reglas que finalmente adoptó el comité en Marzo de 1993:

1. El ámbito de un nombre declarado en una clase es no sólo el texto que sigue a la declaración de ese nombre, sino también el cuerpo de todas las funciones, argumentos por defecto e inicializadores de constructores en esa clase (y sus clases anidadas). Obviamente se excluye en la propia definición.
2. Un nombre N utilizado en la declaración de la clase S debe evaluarse de igual manera en el contexto que aparece y en el ámbito completo de S, entendiendo como ámbito completo la clase S, sus clases base y todas las clases que la encierran.
3. Si reordenando la declaración de miembros conduce a un programa válido bajo las reglas dos reglas anteriores, el comportamiento del programa no está definido.

Apuesto a que muchos de los teclarios tienen un portátil que traen y llevan de un sitio para otro.

Y apuesto a que cuando lo conectan a Internet, les toca reconfigurarlo para poner la IP, máscara, puerta de enlace y servidores DNS de casa, del trabajo, del wi-fi del vecino…

¡Qué latoso resulta! Buscar las propiedades de la red, elegir el interfaz a configurar, pulsar Propiedades, Protocolo IPv4 y, por fin, meter los numeritos de marras. Al menos cuatro o cinco clicks, y varios números a escribir.

Aquellos que usen Linux seguramente sabrán utilizar ifconfig para reconfigurar la red. Por ejemplo:

ifconfig eth0 192.168.1.2 netmask 255.255.255.0


(como administrador) establecerá la IP 192.168.1.2, y la máscara 255.255.255.0 Por desgracia, eso no cambia la puerta de enlace, por lo que, además, hay que usar route para ajustarla:

route add -net 0.0.0.0/0 gw 192.168.1.1 1


Y luego faltan los DNS… que supone tocar el fichero /etc/resolv.conf…

Naturalmente, esto abre la puerta a la automatización, con un sencillo script que haga todo eso. O… mejor aún, dos. El primero llamado casa.sh y el segundo trabajo.sh (o similar). Esto nos ahorrará un buen esfuerzo.

Si usas Debian o algún derivado ([?]ubuntu es el más  representativo), hay otro modo. La configuración se guarda en /etc/network/interfaces y, la gracia, es que se pueden configurar “interfaces lógicos”. Así, podríamos tener:

iface casa inet static
address 192.168.1.2
netmask 255.255.255.0
gateway 192.168.1.1

iface trabajo inet static
address 169.250.27.84
netmask 255.255.255.0
gateway 169.250.27.1


Y luego como root haremos:

ifup eth0=trabajo


(por ejemplo). Aunque quedan algunos pequeños flecos en toda esta explicación (como qué configuración se aplica en el momento del arranque), seguro que serás capaz de rellenarlos.

El principal problema, en realidad, surge con Windows. En este sistema operativo estamos demasiado acostumbrados al uso del ratón, de las ventanas y de los asistentes. Por tanto, es raro plantearse otra opción que no sea la reconfiguración manual.

Sin embargo, también en Windows hay aplicaciones de consola que permiten hacer bastantes cosas (de hecho, casi siempre más cosas que con la configuración gráfica). Una de esas perlas es netsh, el comando de configuración de la red en Windows.

Con ella, podemos configurar la IP, máscara y puerta de enlace en una sola línea:

netsh interface ip set address "Conexión de área local" static 192.168.1.2 255.255.255.0 192.168.1.1 1


(aunque en tu navegador aparezca en dos líneas, debe ser escrito  todo seguido)

Ten en cuenta  que Conexión de área local es el nombre del interfaz de red que tengas. El último número (un 1) es la “métrica” de la ruta por defecto que le estamos dando.

Además, también nos permite configurar los DNS:

netsh interface ip set dns "Conexión de área local" static 213.4.132.1
netsh interface ip add dns "Conexión de área local" 213.4.141.1 index=2


Las primeras líneas (que en realidad debe escribirse en una sola pero en el navegador se corta por su ancho excesivo) establece el servidor primario. Las dos últimas, configuran el segundario; podríamos añadir más incrementando el valor de index.

Con esto, podemos finalmente hacernos nuestro casa.bat y trabajo.bat y tener  la configuración de red a tan sólo un click de distancia.

Aunque, todavía nos queda un pequeño problema… Si escribes el .bat con Notepad, te llevarás una desagradable sorpresa: no funciona. El problema está en que Notepad graba en codificación ANSI (por defecto), mientras que la consola de Windows, por herencia de MS-DOS (sí, has leído bien), usa  “OEM”. Por tanto, la ó y á de Conexión de área local no se verán en el símbolo del sistema tal y como tú lo escribiste en Notepad.

La solución es escribir el script en un editor de consola… pero Microsoft, desde Windows Vista, ya no incluye ni el socorrido edit ni el infernal edlin entre los programas de consola… por lo que te tocará echar imaginación para conseguirlo… Quizá esto te dé una pista de cómo lo hice yo :

echo á > dummy.txt
echo ó >> dummy.txt


Otro fleco de configuración es el cliente de correo. Si el lugar donde trabajas te proporciona su propio servidor SMTP (tal y como ocurre donde trabajamos los teclarios), es posible que no puedas usarlo desde fuera de su red, por lo que desde casa necesitarás utilizar un SMTP diferente. Esta decisión (de los administradores del servidor SMTP) es habitual para evitar el uso fraudulento por parte de terceros.

Además, es posible que desde la red del trabajo tampoco puedas utilizar el servidor SMTP que usas en casa. Esta decisión (del administrador de la red) evita que se envíe spam (intencionadamente, o por culpa de ordenadores zombies).

El resultado de ambas restricciones es que tendrás que usar un servidor SMTP en casa, y otro en el trabajo. Si usas Thunderbird, puedes tener varios servidores configurados (con otros clientes supongo que también), pero sólo uno “activo” para cada cuenta. El resultado es que cuando cambias de lugar, toca reconfigurar cual quieres usar como servidor predeterminado.

¿Podemos automatizar el cambio? Bueno… esto ya es más difícil (y yo no lo he hecho). Por si quieres intentarlo, aquí van algunas pistas. La configuración de Thunderbird está en %APPDATA%/Thunderbird/prefs.js. Para saber la ruta de %APPDATA% en tu caso, puedes escribir precisamente %APPDATA% en la ruta del explorador (o en la ventana de “Ejecutar”). Ahí verás un montón de cosas, entre ellas:

user_pref("mail.smtp.defaultserver", "smtp1");
user_pref("mail.smtpserver.smtp1.auth_method", 1);
user_pref("mail.smtpserver.smtp1.description", "SMTP_casa");
[...]
user_pref("mail.smtpserver.smtp2.auth_method", 1);
user_pref("mail.smtpserver.smtp2.description", "SMTP_trabajo");
[...]


La primera línea indica qué servidor SMTP usarás como predefinido. Cambiando smtp1 por smtp2 habrás reconfigurado tu Thunderbird.

¿Por qué yo no uso esto? Por tres razones:

• Al principio del fichero te dice explícitamente que no lo cambies
• Thunderbird sólo lee ese fichero al lanzarse; si, como yo, hibernas el ordenador y no cierras Thunderbird, el cambio no será visible
• Las herramientas de manipulación automática de ficheros de texto en Windows brillan por su ausencia (o yo, por mi ignorancia…). No hay awk o similar para hacer el cambio.

En cualquier caso, si lo haces y te va bien… ¡¡coméntanoslo!!

Querido Ndugu,

Hay gente que va a Londres y viene encantado con su famosa Torre, con el Big Ben, con Picadilly Circus y con todas esas otras atracciones turísticas famosas.

En mi primer viaje a Londres, lo que yo descubrí fue el Observatorio de Greenwich. Como todo el ejército de turistas que sube las empinadas cuestas hasta el lugar en el que se levanta el edificio, yo iba con la única idea en la cabeza de hacerme una foto con un pie en cada lado “de la tierra”. Y lo hice. Pero el observatorio me deparaba una sorpresa, vaya que sí.

Lo que allí arriba descubrí fue un museo que me respondió a una pregunta que llevaba rondando mucho tiempo en la cabeza. ¿Por qué es precisamente ahí, en Greenwich donde está situada la longitud 0? (resulta curioso ver la entrada de Greenwich en la Wikipedia, en la que cuando indica su localización exacta en longitud y latitud dice textualmente “longitud de 0°0′0″ 0/E(por definición)”).

Uno a uno, los carteles explicativos me hicieron primero ser consciente del problema que en la antigüedad había supuesto el no ser capaces de establecer la longitud exacta en la que nos encontramos (problemática sobre todo en navíos en alta mar), y segundo los distintos métodos ideados para intentar averiguarla. Finalmente, entusiasmado, descubrí que existía un libro, Longitud, de Dava Sobel en el que se detallaban todos los pormenores.

El libro es una auténtica joya, tanto que por aquel entonces me lo leí en su versión inglesa original, y ahora que ha caído en mis manos la versión española he vuelto a leérmelo. Empieza describiendo el verdadero problema que tenían los barcos en sus rutas de navegación de meses. Si bien determinar la latitud a la que te encuentras (lo cerca o lejos que estás del ecuador) es “sencillo” (basta con comprobar a qué altura del horizonte está el Sol al mediodía astronómico), es mucho más complicado saber a qué distancia al Este o al Oeste se está del punto de partida. Y hago notar que digo la distancia de “el punto de partida”, y no la “longitud”, pues en esos momentos no se tenía claro qué punto utilizar como referencia universal, por lo que directamente se utilizaba como referencia el puerto de salida.

En esto consiste la auténtica diferencia, la fundamental, entre latitud y longitud, más allá de la superficial de dirección que cualquier niño puede apreciar: el paralelo de latitud cero está determinado por las leyes de la naturaleza, mientras que el meridiano de longitud cero se mueve, como las arenas del tiempo. Con tal diferencia, hallar la latitud es un juego de niños, y determinar la longitud, sobre todo en el mar, un dilema de adultos con el que se debatieron las mentes más esclarecidas del mundo durante la mayor parte de la historia de la humanidad.

Y el meridiano de longitud cero ha sido móvil hasta el mismísimo Siglo XX. Cuando Tolomeo hacia el año 150 realiza sus cartas en las que aparecen paralelos y meridianos, gozaba de plena libertad para situar el meridiano principal donde quisiera. Decidió que pasara por las Islas Canarias y Madeira, pero después se movió a otros puntos dependiendo del cartógrafo, pasando así a las Azores, Cabo Verde, Roma, Copenhague, Jerusalén, San Petersburgo, Pisa, París, Filadelfia…

El problema, como digo, cautivó a las grandes mentes de la historia de la humanidad, y fue durante mucho tiempo uno de los problemas científicos más conocidos por el pueblo llano. Por ejemplo, en Los Viajes de Gulliver, uno de los personajes se imaginaba siendo inmortal y disfrutando, entre otras cosas, de la resolución del problema de la Longitud. Y es que el problema era mayúsculo: grandes fortunas se perdían en los mares por errores en el cálculo de la posición exacta de un buque cargado de mercancías, especialmente después del descubrimiento del Nuevo Mundo.

No es de extrañar, por lo tanto, que todas las grandes mentes estuvieran al corriente del problema y en mayor o menor medida intentaran solucionarlo. El método que veían más obvio era poder comparar la hora en el puerto origen con la hora en la localización concreta del barco en un momento dado (cuando digo la “hora” me refiero a la hora “astronómica”, no a la hora “oficial”).

Imaginemos que un buen día nos despertamos en un sitio (del hemisferio Norte) y no sabemos dónde. Imaginemos también que tenemos los instrumentos necesarios para saber en qué momento el Sol está en lo más alto del cielo ese día. Gracias a la elevación que consigue el Sol podremos averiguar la latitud en la que nos encontramos. Eso, como ya he dicho antes, se sabe desde hace muchos siglos. Pero ¿cómo calcular la longitud? Si en ese momento llamamos por teléfono, digamos, a alguien en Greenwich y le preguntamos hace cuánto tiempo ocurrió su mediodía astronómico (o lo que es lo mismo, la hora astronómica en ese momento), con un simple cálculo podremos averiguar la longitud: 12 horas de diferencia son 180º, así que con una regla de tres lo tendremos: cada cuatro minutos de diferencia, es un grado de distancia.

El problema principal del método explicado es que las gentes de los pasados siglos no tenían teléfono, por lo que astrónomos y gentes de ciencia en general se devanaban los sesos intentando encontrar un método para conocer la hora en el puerto origen (lo que en el ejemplo anterior coloqué estratégicamente en Greenwich), para saber a qué distancia estaban de él.

Y a eso se dedica la primera parte del libro: a detallar todos los intentos que generaciones y generaciones de grandes mentes hicieron para encontrar una solución a semejante problema. Y descubres que algunos de los grandes avances de la ciencia se produjeron, precisamente, como “efecto lateral” al intentar solucionar el problema de establecer la longitud (o averiguar la hora en el puerto base).

En el transcurso de su lucha por establecer la longitud, los científicos efectuaron otros descubrimientos que cambiaron su visión del Universo. Entre ellos se cuentan los primeros cálculos exactos del peso de la Tierra, la distancia hasta las estrellas y la velocidad de la luz.

Y es que resulta curioso averiguar, por ejemplo, que uno de los métodos ideados consistía en observar las horas en las que los satélites de Júpiter hacían su aparición desde detrás del planeta. Unas tablas calculadas por los astrónomos indicaban a qué hora astronómica del “puerto base” aparecerían los satélites. Los marinos equipados con esas tablas podían comparar la hora local a la que aparecía y, de esta forma, establecer la longitud. Sin embargo, los astrónomos observaron que las tablas predichas contenían errores, y la única explicación coherente que encontraron fue, precisamente, que la velocidad de la luz no era infinita, y que ésta tardaba tiempos distintos en alcanzarnos desde Júpiter dependiendo de a qué distancia estuviera de la Tierra.

Con este método de los satélites de Júpiter, el cálculo de la longitud se precisó bastante aunque, desgraciadamente, no era adecuado para alta mar por la dificultad de ver las salidas y puestas de los satélites en un barco en movimiento. Sí fue útil, no obstante para hacer mapas muchos más precisos pues en tierra establecer la longitud se hacía factible. De hecho, en el libro cuentan que

al examinar un mapa revisado de sus dominios, basado en mediciones precisas de la longitud, el rey Luis XIV de Francia se quejó de estar perdiendo más territorios a manos de sus astrónomos que de sus enemigos.

Y fue para intentar solucionar el problema de la longitud mediante la observación de los astros, en particular, para la elaboración de tablas (efemérides) con las que averiguar la longitud en alta mar en base a las observaciones realizadas en el navío, para lo que el rey Carlos de Inglaterra nombró a Flamsteed su “observador astronómico” personal y mandó construir el observatorio de Greenwich (aún hoy uno de los edificios sigue llamándose Flamsteed House). Era el año 1675. Y, por cierto, desde ese observatorio se hicieron muchas de las tablas de los satélites de Júpiter, haciendo de Greenwich el “puerto base” o lo que es lo mismo el “punto de longitud 0″…

Pero la cosa no quedó ahí. Como el problema no se terminaba de resolver para alta mar, en 1714 el gobierno Inglés convocó un concurso y ofreció una elevada recompensa para el que lograra desarrollar un método capaz de determinar la longitud exacta.

Y por fin llegó la solución. No tenía nada que ver con Júpiter y sus satélites, ni con las posiciones relativas entre Sol y Luna. Ni siquiera tenía nada que ver con los astros.

La solución la trajo, nada más y nada menos, un honrado pero magnífico relojero, John Harrison. Harrison fue capaz de idear los artilugios necesarios que revolucionaron la maquinaria de los relojes, creando relojes que aguantaban las inclemencias meteorológicas y de movimiento de un barco de tal forma que marcaba con una precisión más que suficiente la hora en el puerto base.

El libro cuenta, sobre todo, la historia de este relojero y de los cuatro relojes que creó a lo largo de su vida. Esos relojes que hoy pueden admirarse en la visita al observatorio en el meridiano de Greenwich y que a mí, aquel día de Diciembre de hace ya algunos años, me cautivaron.

Por la longitud de esta reseña, a nadie le sorprenderá mi veredicto…

Nota: imprescindible

Todo el mundo tiene, más o menos, en mente el logo de IBM, con sus tres letras en mayúsculas, “ralladas” al estilo de aquel viejo “papel pijama” que inundó las oficinas de medio mundo, papel contínuo inacabable con líneas de color para facilitar la lectura.

Y, ¿de qué color son esas grandes letras I, B y M?

Azules, claro. Es por algo que se conoce a IBM como “el gigante azul”.

El logo de Microsoft, por su parte, es de color…… ¡negro!. Si bien, según la guía oficial de uso del logo de Microsoft, puede ser usado en video inverso, es decir, en blanco.

Ahora bien… cuando uno piensa en Microsoft no es el negro (o el blanco) el color que le viene a la cabeza. Claramente el color “corporativo” de microsoft es, de nuevo, el azul (seguro que más de uno pensaba que ese era el color del logo…). Para comprobarlo basta darse una vuelta por su sitio web. Resulta de hecho significativo que el favicon de Microsoft sea la M de su logo (… en blanco …) sobre un fondo azul.

Esta predilección por el color azul de Microsoft, les lleva a usarlo incluso en sus famosos “pantallazos azules“, también conocidos como “blue screen of death” (o BSoD)… con lo que consiguen recordarte de quién es la culpa de que aparezcan…

También el color azul surge en el omnipresente bluetooth (”diente azul”), nombre que proviene, al parecer, del apellido de un rey nórdico que unificó las tribus noruegas, suecas y danesas.

Y, a esta lista, se ha unido recientemente el… blue-ray… no, espera… el Blu-ray, sin la e. La wikipedia nos cuenta que el nombre viene … de blue-ray (¿no me digas?). ¿Por qué le quitaron letra ‘e’, entonces? Porque, sigue el wikipedista, en algunos países no se pueden registrar palabras comunes, de manera que así se evitan los problemas de marcas registradas que ya sufrió Intel y que forzó el cambio al nombre Pentium (en lugar del “siga la secuencia” 586).

Claro… que la anécdota de la pérdida de esa “e”, parece que hay quién no la sabe. Y no sólo eso, sino que encima piensa que quién ha escrito el texto original en inglés era tonto de remate y no sabía escribir “azul”…

Resulta curioso que estas cosas les pasen a los que se supone que saben de esto… a la gente de Nero en su publicidad de la versión 8 (pulsando en la pestaña “Convierta y comparta”).

Está claro que algunos traductores no consiguen su verdadero objetivo: pasar desapercibidos.

Querido Ndugu,

Parece ser que decía Marcel Proust que

La sabiduría no nos viene dada, sino que debemos descubrirla por nosotros mismos, después de un viaje que nadie puede ahorrarnos o hacer por nosotros.

Creo que en gran medida tiene razón pero hay ocasiones en las que otros que han hecho ya el camino pueden indicarnos “atajos” que hayan encontrado en su duro paseo, y como “recoger la sabiduría de otros, también es de sabios”, he pensado en compartir dos trucos que mi lento transcurrir por el mundo de la programación me han dejado.

Se trata de dos usos de comentarios que no he leído/encontrado en ningún sitio, que en algún momento “inventé” o mejor “descubrí”, y que no sé hasta qué punto otros viejos programadores de C++ (o en general de lenguajes con comentarios del tipo /* ... */) tienen en su repertorio. Por si resultan no estar extendidos, los grito aquí a los cuatro vientos para que cualquier teclario que los vea pueda aprovecharse de ellos y extenderlos por el mundo.

Mientras se programa, muchas veces estamos haciendo pruebas y queremos activar y desactivar trozos de código. Cuando el código ocupa poco (una o dos líneas), es rápido comentarlas utilizando los comentarios de una única línea. Lo incómodo llega cuando la sección ocupa un número de líneas considerable; en ese caso, es mucho mejor utilizar los comentarios de bloque, /* ... */.

Sin embargo, activar y desactivar una sección de código utilizando esta técnica requiere “visitar” el principio y el final del bloque, para poner o quitar los dos símbolos, el de apertura y el de cierre del comentario.

Y aquí va mi primer “truco”. Ya he comentado anteriormente que no lo he visto en ningún sitio, aunque sí he leido algo similar en el manual de LUA. Consiste en terminar la sección de código que queremos poder activar y desactivar rápidamente con un comentario multilinea vacío, es decir, con /**/. La peculiaridad de este comentario vacío es que puedes antecederlo con otra apertura de comentario multilínea, de tal forma que quede algo como /* ... /**/. El analizador léxico ignorará la segunda apertura, por encontrarse dentro de una sección comentada.

Por tanto, gracias al sencillo paso de colocar el comentario vacío al final de la sección, nos basta con abrir el comentario al principio de la misma para desactivarla:


/*
.... sección larga de código
.... que queremos activar y
.... desactivar fácilmente
/**/


Para volver a activar la sección, basta con borrar esa primera apertura, aunque yo aconsejo a su vez comentarla con un //, ya que de esta forma se sabe en qué sección concreta estaba el programador pensando cuando colocó el /**/.


///*
.... sección larga de código
.... que queremos activar y
.... desactivar fácilmente
/**/


Considero que esta sencilla técnica por sí sola es ya lo suficientemente útil como para darla a conocer a todos aquellos que no hubieran llegado a ella por ellos mismos. Sin embargo, puede darse una vuelta de tuerca más, para obtener otro método también útil en otras circunstancias.

Se da a veces que, siguiendo con la misma idea, tenemos dos secciones de código seguidas y excluyentes con las que queremos hacer pruebas, de tal forma que unas veces queremos compilar la aplicación con la sección de arriba, y otras veces con la de abajo. Por ejemplo:


// Sección 1
CMapLoder::Init();
CMapLoader::LoadMap("mapa1.map");
/**/
/*
// Sección 2
map = new CMap();
map->addEntity(creaEntornoVacio());
/**/


Tenemos dos secciones, una que construye un mapa utilizando un cargador de disco, y otra que lo crea desde código. Una veces queremos utilizar una y otras veces la otra. En este caso, debemos “activar” una sección y “desactivar” otra en cada prueba. Siguiendo con el truco anterior, eso puede hacerse cómodamente poniendo al final de ambas secciones el ya explicado /**/, pero no deja de ser algo pesado, ya que hay que quitar y poner dos aperturas de comentario (en el ejemplo anterior, habría que poner el /* al principio de la sección 1, y quitarlo en el de la sección 2).

Para evitarlo, y este es el segundo truco que quería contar, basta con:

• Colocar un /**/ al final de la última sección.
• Colocar un /*/ entre las dos secciones.

De esta forma, para elegir una u otra alternativa, basta con abrir o no abrir un comentario multilínea al principio de la primera sección, aprovechando que el /*/ que aparece entre ambas secciones unas veces hace de inicio de comentario multilinea y otras veces hace de cierre.

Como ejemplo, a continuación aparece el código con la sección 1 comentada y la sección 2 activa (observar que el /*/ del centro sirve de cierre de comentario multilinea):


/*
// Sección 1
CMapLoder::Init();
CMapLoader::LoadMap("mapa1.map");
/*/
// Sección 2
map = new CMap();
map->addEntity(creaEntornoVacio());
/**/


Y para cambiarlo y activar la sección 1, basta con quitar la apertura inicial (o comentarla con un comentario de línea); en ese caso, el /*/ sirve para iniciar un comentario multilinea que se cierra al final de la sección 2:


///*
// Sección 1
CMapLoder::Init();
CMapLoader::LoadMap("mapa1.map");
/*/
// Sección 2
map = new CMap();
map->addEntity(creaEntornoVacio());
/**/


Probadlo, y veréis lo cómodo que es…

Todos sabemos que las descargas de música a través de internet están ocasionando el fin de la industria discográfica tal y como la conocíamos (and I feel fine). Desde finales de los noventa con la popularización de internet, la industria del disco no es más que un enfermo terminal que a la desesperada prueba todo tipo de remedios inútiles para evitar lo inevitable. Asume que no va a derrotar a la enfermedad, porque se sabe a su merced, pero lucha por robarle a ésta un poco de tiempo y hacer un poco de caja por el camino. El enfermo se resiste tenazmente a morir, pero la situación no va a durar eternamente. La incognita es saber quién va a acabar, de una vez por todas, con su agonía. En ese punto entra en escena Radiohead con un martillo en una mano y una estaca en la otra.

Estos días ha sido noticia que el grupo de Oxford ha anunciado la venta en exclusiva de su próximo disco, In rainbows, a través de su propia web. A simple vista, no parece un gran noticia. Los detalles que la hacen interesante son estos:

• Sólo existen dos modalidades del album: la descarga digital (cuyo precio lo fija el comprador) y la edición coleccionista con CD, CD extra, descarga digital, libreto de lujo, dos vinilos y perrito piloto al precio de 40 libras, es decir… ¡unos 60 euros!
• El precio de la descarga digital lo fija el comprador (ya lo dije, pero es tan original que lo pongo de nuevo): puedes pagar por el disco desde un penique (más los gastos por usar la tarjeta), hasta los ahorros de toda tu vida. No obstante, el lector avezado habrá notado que llegar a pagar 40 libras por la descarga digital es una tontería.
• No tienen contrato discográfico en vigor, ni han firmado con una distribuidora para vender el disco. No porque les faltasen candidatos, sino porque su contrato expiró y prefirieron saber qué era eso de componer por amor al arte y sin ataduras de ningún tipo (ver esta entrevista de marzo de este año).
• No existe una edición estándar en formato físico del disco. Aunque hay rumores de que en 2008 el disco llegará fisicamente a las tiendas para que los materialistas (como yo) podamos acariciarlo en nuestra casa.
• Aunque en España no sean masivamente conocidos, se trata de, posiblemente, y no porque lo diga yo, uno de los grupos actuales más influyentes e innovadores en el terreno musical. No son los primeros en regalar (o casi) su música por internet, pero sí son los primeros artistas realmente relevantes en publicar un nuevo (y muy esperado) disco de esta manera.
• La operación se ha mantenido en secreto hasta 10 días ante del lanzamiento y el album no se ha filtrado a la red antes de la fecha de edición, como es habitual últimamente y como les pasó a los propios Radiohead con su anterior disco.

Radiohead siempre han sido unos tipos raritos. Su música y sus letras hablan de la angustia, la alienación y la paranoia constante que supone vivir en un mundo donde no somos más que peleles en manos de gobiernos, grandes corporaciones y medios de comunicación. Ellos, hasta el momento, vivían bajo el paraguas de una multinacional (EMI), pero ahora, más coherentemente, han decidido ir por libres.

Sin embargo, resulta paradójico que el salirse del sistema vaya a ser una maniobra comercial brillante (o al menos, así parece que será). En primer lugar, la promoción gratuita del disco ha sido descomunal. El grupo no ha dado datos de los pedidos, pero las consultas en los buscadores y las visitas a su web se han disparado. En segundo lugar, el modelo de venta, que no es nuevo, podría funcionar. Y en tercer lugar, al eliminar a todos los intermediarios, los márgenes de beneficios que van a obtener por unidad vendida (a poco que les paguen por el disco) parece que serán superiores a los que consiguen los artistas por los cauces habituales (el famoso porcentaje que muestra que el artista es prácticamente el que menos cobra con la venta del disco).

Evidentemente, aún está por ver si la decisión de Radiohead es una primera sacudida que anuncia un terremoto o si se queda en nada. En España, la noticia no ha pasado de la anecdota. Sin embargo, en Gran Bretaña, donde la música mueve mucho mucho dinero, están tomándose la cosa muy en serio. Diarios como el Telegraph están dedicando un número sorprendentemente alto de noticias a abordar el tema con rigor.

¿Supondrá esto el estacazo definitivo a la industria discográfica o el sistema, como podrían cantar los propios Radiohead, se sacará un as de la manga para que, como siempre, la banca gane?

El desenlace en próximas entregas.

P.D. In rainbows sale hoy, 10 de octubre, a la venta y se puede comprar a través de http://www.inrainbows.com

The Pirate Bay es uno de los trackers para BitTorrent con más solera que recientemente ha aumentado exponencialmente su fama al demandar a las grandes compañías mediáticas por pirateria y sabotaje.

El origen de la historia es la compañía Media Defender, que como puede leerse en su web se dedican a dificultar la propagación del contenido pirateado a través de las redes P2P. Sus tácticas publicamente conocidas incluían llenar las redes P2P de fakes y trazar qué clientes descargaban dichos fakes para en determinados casos emprender acciones legales contra ellos.

Pero sus métodos van mucho más lejos, como se ha demostrado después un grupo de hackers (autodenominados Media-Defender Defenders) consiguiese robar unos 700MB de emails internos de la compañía. De estos emails se deduce que las tácticas de MD eran bastante más agresivas de lo que parecía, en otro caso de lucha antipiratería sin consideración a la legalidad. Partiendo desde la distribución de programas espía (te instalas el fake y el programa mira qué ficheros legales/ilegales hay en tu ordenador) hasta la creación de una nueva red P2P llamada Miivi.com y cuya función era recopilar información sobre usuarios de este tipo de servicios. Después de que el presidente de MD negase públicamente estar detrás de estas actividades, los emails filtrados cuentan una historia distinta.

Y de ahí, a la guerra sucia contra la piratería. Ataques de denegación de servicio contra los trackers, intento de sabotaje de la infraestructura, spam, etc. Filtraciones posteriores detectaron incluso ataques de denegación de servicio contra los sitios web que estaban distribuyendo los emails filtrados.

Y por último, irónicamente, el pirata que ataca al otro pirata con sus armas : The Pirate Bay ha presentado una demanda basada en dichos emails contra Media Defender y sus clientes por los ataques informáticos sufridos por sus servidores.

Qué divertido es esto de Internet…

(Mas información: http://en.wikipedia.org/wiki/MediaDefender)

Una de las grandes verdades del mundo de la seguridad informática es que los sitemas son mucho más seguros que los usuarios. La mejor encriptación no vale de nada si la contraseña está escrita en un post-it pegado al monitor y que los documentos PDF incluyan mecanismos de protección muy avanzados no vale de nada si no se saben usar.

Y esto le ha venido a pasar a la FIA (Federación Internacional de Automovilismo). Para quien no siga estos temas, el entretenimiento automovilístico de la semana pasada orbitó entorno a los líos entre Mercedes-McLaren y Ferrari por un caso de robo de secretos industriales. La primera sentencia decía que no emplumarían a McLaren porque, aunque tenían información técnica de Ferrari, sólo la conocía un ingeniero y no la habían usado. El último giro fue que, tras examinar los emails de Fernando Alonso y Pedro Martínez de la Rosa, la FIA concluyó que esa información la conocía y usaba hasta la señora de la limpieza.

Para demostrar que esto era así y dar imagen de transparencia, la FIA publicó en su web un documento PDF con la sentencia completa y las transcripciones de los contenidos de los emails. Como había secretos industriales en esos emails, Ferrari y McLaren censuraron previamente el documento para ocultar esas informaciones puntuales tras borrones negros.

Pues bien, el PDF publicado por la FIA en su web usa la función del rotulador marcador de word para poner fondo negro a las letras negras y así taparlas. El PDF generado hace por tanto lo propio así que las letras están ahí. Copias el documento, lo pegas en el UltraEdit y voilá, todas las informaciones por las que la FIA ha expulsado a McLaren de la competición y multado con 100M de dólares quedan reveladas.

Demandará ahora Ferrari a la FIA?

(fuente: Hispasec)

Sony tiene un largo historial de políticas agresivas en lo que a protección anti-piratería se refiere. Con el objetivo de proteger sus contenidos, están dispuestos a llegar a límites insospechados, llegando a intrusiones sobre los derechos de los consumidores legítimos que, mediando tiempo y dinero, nunca se sostendrían ante un tribunal.

Por otro lado, los mencionados consumidores legítimos a menudo no disponen de la capacidad de litigar contra Sony. Eso debieron pensar al menos en los ejecutivos de Sony BMG al aprobar el uso de las protecciones XCP y Mediamax. Estas protecciones se lanzaban al insertar el disco de música en el ordenador, instalando (sin conocimiento del usuario) un software para monitorizar el uso y filtrar el acceso del SO al CD impidiendo su reproducción. Para evitar que la protección fuese esquivada, el software se instalaba como un rootkit, haciéndose invisible para Windows (tanto los ficheros como los procesos). Aparte de ser un comportamiento que entra perfectamente en la definición de Spyware, presenta un riesgo de seguridad ya que estas carpetas quedan completamente ocultas incluso para la mayoría de antivirus del mercado.

Y ahora, llega Bioshock. Para los no jugones, Bioshock es un nuevo shooter que ha generado mucha expectación en Internet por su tecnología y ambientación, siendo uno de los juegos más esperados del año. En mitad de la expectación y teniendo en sus manos un producto que podría tener un impacto tremendo en la escena de los FPS durante mucho tiempo, 2K Games decidió confiar su “protección” a Sony y su infame SecuROM. La nueva versión de SecuROM diseñada para Bioshock incluye un protocolo de registro online sin el que no se puede jugar. Éste registro está limitado a dos instalaciones, por lo que después de ejecutar el instalador dos veces, el CD de 60€ queda inutilizado. Según SecuROM, si desinstalas el software, te rebajan el contador, por lo que con ese limite puedes ser feliz y tener tu juego en tu ordenador e incluso en el portátil de premio.

¿Y si quiero instalar mi juego en mis 3 ordenadores? No, si tienes pasta para 3 ordenadores, compra dos copias del juego. ¿Y si formateo mi disco duro sin acordarme de desinstalar primero el juego? Pues espero que no tuvieses portátil y que la segunda vez seas más listo. Pero, mi pregunta es sobre todo: ¿Y si quiero dejarle mi juego a mi propio hermano? No una copia, dejarle mi original para que juegue con él mientras yo no juego. ¿Qué ha pasado con ese derecho? Por si el atropello en sí no fuese suficiente, también han tenido múltiples problemas con los servidores de registro y por lo que parece, lo del contador y desinstalador no funciona. Podéis ver un resumen de las pesadillas de los usuarios y de la cronología de la historia aquí.

Por otro lado, la misma demo gratuita de Bioshock incluía, a espaldas del usuario, el mismo sistema de seguridad. El medio millón de usuarios (yo incluido) que descargamos la demo, hemos instalado sin saberlo SecuROM en nuestros sistemas. ¿Qué quiere decir en la práctica que mi ordenador se haya visto infectado por SecuROM? Pues quiere decir que si lanzo la demo de Bioshock, tengo que desactivar primero todas mis unidades virtuales. Significa que tengo que deshabilitar el “Machine Debug Manager” y que no puedo abrir programas examinadores de memoria como SoftICE o Microsoft Process Explorer hasta que no limpie el sistema. Y limpiar el sistema no es “desinstalar la demo”. De nuevo al más puro estilo troyano, la instalación crea varias null keys en el registro de Windows que no se pueden tocar con el editor del registro. Ya no tengo la demo en mi ordenador, pero sí tengo el virus. Nadie me ha avisado de que se iba a instalar un programa residente en mi ordenador que iba a utilizar cadenas corruptas para evitar que el editor del registro de windows las detectase. Nadie avisa a los compradores del juego en la tienda de que no podrán compartirlo con sus hermanos o amigos (y por compartir no digo copiar).

Y para terminar, una última reflexión: ¿Por qué incluir el sistema de seguridad en una demo gratuita? Según 2K Games, por el miedo a que los hackers malignos pudiesen usar el ejecutable de la demo para preparar un crack, cosa que ya han hecho de todos modos. Bien es cierto que los shooters no son mi género pero, visto lo visto y si hoy me diese por comprar ese juego, tengo una cosa clara: para un usuario, aún dispuesto a pagar por el juego, compensa mucho más usar la versión “limpia” de los hackers malignos que la versión infectada por Sony y 2K Games.