*nix pro

Es sabido (dentro del mundillo, al menos) que OpenSolaris (la distribución, no el repositorio ni la comunidad) tiene la intención de tomar el relevo de Solaris en la oferta de Sistemas Operativos de Sun. Prueba de ello es que no se ha vuelto a hablar de más prórrogas con respecto a Solaris Express Community Edition (SXCE), siendo la consolidación quincenal 130 (b130) la última prevista.

Dado que SXCE b129 salió hace más de una semana, la última versión se espera en unos días. SXCE era la muestra de lo que sería Solaris Next, es decir, lo que todos esperábamos que sería Solaris 11. Dado que el nuevo plan es que OpenSolaris sea a Solaris lo que Fedora es a Red Hat Enterprise Linux en el casi *nix del pingüino com sombrero rojo, parece que existe un conflicto entre ambos.

Este conflicto es aún más patente si nos damos cuenta de que SXCE y OpenSolaris, si bien comparten código, están basados en filosofías diferentes: SXCE es como Solaris más nuevo código, parte del cual está cerrado; mientras que OpenSolaris es en su mayoría, si no todo, código abierto. Debido a la presencia de código cuya propiedad intelectual pertenece a terceros, Sun no puede abrir todo el código de Solaris/SXCE ni queriendo, por lo que si dejara de distribuirse en la próxima encarnación de Solaris, habría dispositivos que dejarían de funcionar al carecer de controladores, como algunas tarjetas gráficas. Aunque siempre existe la posibilidad de que se distribuyan los controladores en formato binario, la respuesta con respecto a los gráficos no es fácil, pues también se quiere migrar del servidor X11 Xsun (¡adiós, Display PostScript!) a Xorg.

¿Qué va a ocurrir? Esta es una buena pregunta, y yo opino más o menos lo que otros: que la única manera de dar sentido a la situación actual es hacer algo con SXCE antes de dejarlo morir. ¿Qué puede hacerse? Probarlo todo, dejarlo funcionando y lanzarlo al mundo como Solaris 11. Posteriormente y dado el parecido actual entre el hipotético Solaris 11 y OpenSolaris, este último se convertiría en la cantera de la cual saldrían las sucesivas versiones de Solaris. De esta manera, se satisfaría a ambos bandos, al que opina que la compatibilidad de Solaris debe mantenerse y al que cree que una vertiente más moderna está llamada a sustituirla.

El problema de esta solución reside en que retrasa el plan de unificar todo bajo el estandarte de OpenSolaris. Lamentablemente, los intentos de hacer de éste el único sistema operativo de Sun han dado lugar a ciertas incompatibilidades en apariencia arbitrarias, algunas de ellas de fácil solución: la ruta de búsqueda de programas antepone las utilidades de GNU a las propias de Solaris, por lo que se facilita la transición a los que vienen de, por ejemplo, Linux; pero se le dificulta la compatibilidad al cuerpo de scripts desarrollados con sh/ksh. La batalla, lejos de ser trivial, puede dar muchos dolores de cabeza a ambos bandos.

Ante esto, surge otra posibilidad: que Solaris 10 siga existiendo indefinidamente (o por tiempo limitado) para los clientes que paguen el mantenimiento, mientras que los nuevos desarrollos se basen en OpenSolaris. Esto parecería ser una solución razonable, a la que le fallan sin embargo un par de detalles: el deseo de desfasar cuanto antes Xsun y probablemente alguna otra cosa más; y que OpenSolaris no es aún un sustituto real para Solaris en algunos aspectos.

Oracle (que ahora mueve los hilos de Sun) ha tenido históricamente bastante interés en Solaris, y también se caracteriza por tomar decisiones estratégicas sólidas. Sun, por otro lado, ha dado algunos pasos aparentemente confusos en sus últimos años, pero ha demostrado una capacidad técnica realmente brillante. De todo lo anterior y considerando estos últimos hechos, me atrevería a afirmar que Solaris 11 (o algún producto que cubrirá el hueco que muchos consideramos que existe) está a punto de aparecer en el mercado. El tiempo lo dirá. ¿Será una sorpresa de año nuevo?

No “cómo escribir un libro”. En este artículo quiero hablar muy someramente del proceso de creación de un libro con herramientas libres que están disponibles en sistemas *nix populares. Nuestro objetivo es alcanzar un resultado profesional con el mínimo esfuerzo necesario, obteniendo un fichero PDF que pueda enviarse a imprenta (algunas admiten otros formatos, pero este será el que nos dé menos sorpresas al final). Esto es válido tanto para la tripa (el interior del libro) como para la cubierta (el exterior). No hablaré de la sobrecubierta, pero se aplicarían los mismos principios que para la cubierta. Comenzamos.

Lo primero, es la elección del sistema para escribir el libro. Sobre esto hay dos grandes escuelas: la de los procesadores de textos y la de los editores separados del sistema de formato. Si eres nuevo en esto, o vienes de usar un procesador de textos, mi recomendación es el uso del formato OpenDocument. Algunos productos libres que lo editan son OpenOffice.org (tal vez el más recomendable), KWord (de la suite KOffice) y Abiword. Con ellos te sentirás como en casa. OpenOffice.org puede exportar directamente a PDF; los otros no lo sé, pero siempre se puede instalar la impresora virtual CupsPDF y generarlo tranquilamente.

Si, por el contrario, estás acostumbrado a usar $EDITOR (sin olvidar que hay un mundo más allá de Emacs y vi), y tu formación es tećnica, es probable que prefieras un sistema de formato aparte. Por experiencia, recomiendo vivamente LaTeX, aunque también existen alternativas como Lua, DocBook y hacerlo directamente en HTML (esta opción sólo la he empleado para documentos cortos). Me gustaría señalar que los formatos de la familia de  ROFF se han usado profusamente en otros tiempos para estos menesteres. Mi experiencia personal con LaTeX ha sido tan satisfactoria que, a pesar de un corto romance con OpenOffice.org, regresé alegremente y no me he arrepentido. Por lo menos puedo decir que he probado ambos mundos.

Es MUY IMPORTANTE que, sea cual sea el método empleado, nos aseguremos de  que el PDF generado contiene todas las fuentes tipográficas que vayamos a usar. Para verificarlo, basta con ver las propiedades del documento final (con evince, Adobe Reader o cualquier lector de PDF decente).

Una vez elegida nuestra herramienta, será necesario familiarizarnos con ella. Para conseguirlo, nada mejor que acceder a una buena documentación. Hay buenos manuales, dentro y fuera de internet, por lo que en cuanto notemos que nuestros conocimientos flaquean, no debemos dudar en consultarlos. En este aspecto, los procesadores de textos son probablemente más fáciles de usar para el usuario ocasional.

Sea cual sea la herramienta elegida, recomiendo vivamente el uso de plantillas. El objetivo final es producir un PDF con un formato determinado, para lo cual debemos auxiliarnos de una documentación adecuada. Si lo tuyo es aprender cómo se hacen las cosas profesionalmente en cuanto al formato del libro, de la página y del texto, lo mejor será consultar con alguna obra especializada sobre composición tipográfica. Si, por el contrario, no tienes esa necesidad o estás pensando en contratar los servicios de una imprenta (ya sea “bajo demanda” o “tradicional”), es bastante probable que te puedan orientar con algún manual al efecto. En cualquier caso, una rápida consulta con quien tenga que poner sobre el papel tus palabras te dará la respuesta de cómo distribuir las páginas y qué medida del papel usar. Como dije antes, el uso de plantillas te van a permitir cambiar fácilmente la distribución del material sobre la página en toda la obra, así como las tipografías a usar, sin tener que ir cambiándolo fichero por fichero. Cuando tienes más de 50 capítulos, esto puede marcar la diferencia. Con LaTeX, este problema viene resuelto de serie, pero con OpenOffice.org puede y debe hacerse. Basta con elegir estilos lógicos (y no físicos) para los encabezamientos y el cuerpo, para que con un simple cambio todos muten simultáneamente. Insisto, el uso de plantillas nos puede ahorrar un trabajo inmenso, hasta el punto de que algunas imprentas las facilitan.

Una vez terminada la obra (¡qué fácil es decirlo!), ya tendremos la tripa preparada. Llega el momento de preparar la cubierta. De nuevo, la imprenta nos dirá el tamaño del fichero (en cm o en puntos o en la medida con la que trabajen ellos) que le tenemos que facilitar. Hay que tener en cuenta la parte que ellos cortarán, así como el lomo. De ahí que sea necesario saber exactamente el número de páginas de la tripa para determinar las dimensiones exactas. Puede que nos pidan una imagen a una determinada resolución.

Supongamos que dicha imagen es en formato JPEG a 300 puntos por pulgada. Lo primero que tenemos que tener en cuenta es que la imagen debe ir en la máxima calidad posible, lo que en el caso de JPEG significa que hay que generarla sin usar compresión, es decir, calidad 100%. La compresión del formato JPEG es con pérdidas, a diferencia de, por ejemplo,  la del formato PNG. Para ello, podemos usar muchos programas, cuya elección dependerá de cómo tengamos pensado crear la cubierta. La cubierta anterior debe contener el nombre de la obra y el del autor o autores (información que repetiremos en el lomo), siendo típico incluir alguna imagen que represente el contenido o que inspire al lector ganas de leer la obra. La cubierta posterior suele contener un “gancho” (si es ficción) o un resumen (si es ensayo o libro técnico), así como una breve biografía del autor, además del ISBN (si lo tenemos) y su código de barras asociado. El nombre de la editorial y la colección también estarán aquí, además de en el lomo.

Queda claro que la cubierta posterior puede tener menos necesidades gráficas que la anterior, por lo que aquella podría componerse directamente con el mismo sistema que la obra; mientras que la anterior puede requerir cierta edición gráfica. En este último caso, dependiendo de si nuestra imagen es vectorial o no, podemos tratarla con inkscape o con GIMP, respectivamente. En mi caso, para una obra de reciente creación, generé tanto la cubierta anterior como la posterior con LaTeX, y después las ensamblé con inkscape, añadiendo en este último paso la información del lomo.

Para el código de barras del ISBN podemos emplear el paquete pst-barcode de LaTeX y generarlo directamente en el documento. Si no es nuestro caso, podemos buscar e instalar alguno de los generadores de códigos de barras libres que hay, o bien visitar una de las páginas de internet que existen a tal efecto.

Una vez enviadas la tripa y la cubierta, será preceptivo verificar el resultado para cerciorarnos de que todo está en orden. Lo que hagamos después, dependerá de que nuestra intención sea publicar, vender, repartir, o engordar nuestro ego. Una nota final: si nuestro objetivo es distribuir la obra en formato electrónico, no estará de más considerar la conversión a otro formato más idóneo para tal fin; o bien, crear una versión PDF adaptada a los lectores de libros, con márgenes, tipografías y tamaños de letras adecuados. El papel y la pantalla son medios distintos que tienen diferentes necesidades.