*nix pro

¿Qué se necesita para tener una estación de trabajo decente? Dinero. ¿Y si nuestro presupuesto es menos holgado? Ingenio. Seguidme en mi camino hacia la estación de trabajo real con un presupuesto ajustado.

Tomaré como modelo una de las actuales estaciones de trabajo de Sun^WOracle^WSun (¡Sun! ¡!Sun!), concretamente la única que hay en su catálogo: Sun Ultra 27. Elegiré la configuración que me parezca más idónea (y económica), calcularé el precio total y, si se sale del presupuesto, buscaré las alternativas en el mercado o fabricaré una equivalente. Excluiré del presupuesto los periféricos como teclado, ratón, monitor, mitones para teclear en las frías noches de invierno y calientatazas USB para ese reconfortante té de medianoche. La configuración gráfica y de almacenamiento será modesta, mientras que haré énfasis en la memoria y en el procesador. ¿Qué menos que 8GiB y cuatro núcleos?

Sun Ultra 27: caja y fuente, 570€; procesador Intel Xeon 3540, 730€; 4 módulos de 2GiB de memoria, 426,16€; tarjeta gráfica Nvidia Quadro FX380, 137,50€;  lector/grabador de DVD, 80,82€; disco duro SATA de 500GB, 290€. Total sin IVA, 2234,48€; total con IVA, 2591,99€.

Si miramos en la tienda de Apple, el Mac Pro equivalente (con disco de 640GB, tarjeta gráfica Nvidia GeForce GT 120, teclado y ratón) sale por 2784€ (IVA incluido). Morder la manzana no nos lo conseguirá más barato.

Supongamos que estamos dispuestos a ciertas renuncias, concretamente a bajar de un procesador Intel Xeon a un Core i7 (en la práctica, la diferencia podría no ser tan grande como puede parecer, especialmente considerando la relación prestaciones/precio). Intentemos fabricarlo por nuestra cuenta, ajustando algo más el presupuesto, a ver qué conseguimos.

Sin que sirva de publicidad, tomaré prestado el catálogo de PCBox, únicamente porque me caen bien y porque se puede ir allí, pedir los componentes, montar el ordenador y salir por la puerta con la configuración elegida bajo en brazo. El presupuesto, que naturalmente no es vinculante, está sujeto a las variaciones del mercado y a las que uno quiera hacer. No me centraré en modelos concretos, sino que daré una orientación para que cada cual haga su elección. El resultado final es lo que cuenta.

Caja y fuente, entre 50 y 100€, digamos 80€; procesador Intel Core i7 860, 261,70€; 8GiB de memoria, unos 300€; tarjeta gráfica, entre 50 y 100€, pongamos otros 80€; lector/grabador de DVD, unos 20€; disco duro  SATA de 500GB, otros 80€; placa base, unos 100€. Total con IVA: 921,70€.

El único precio que he respetado es el del procesador, con el resto he ido haciendo estimaciones, lo que quiere decir que el resultado puede estar, según las diferentes decisiones tomadas, entre 50€ más arriba y 50€ más abajo. En cualquier caso, la conclusión es clara: si aceptamos la pérdida de rendimiento que supone el cambio de procesador (que, insisto, para la mayor parte de las tareas es poco probable que notemos la diferencia en casa), tenemos un precio final que es la tercera parte del de Apple (aunque éste incorporaba el teclado y el ratón); y bastante menos de la mitad que el de Sun. Por más que nos caigan bien las marcas antecitadas, el kopek es el kopek.

No he incluido el precio del Sistema Operativo porque en Apple viene incuido de serie, y tanto con Sun como con nuestro ordenador de fabricación casera podemos usar {,Open}Solaris o Linux… aunque ahora que lo pienso, al ordenador de la manzana también lo podemos traer al mundo libre con una rápida instalación :)

Muy somera. De hecho, se trata más de una observación sobre la evolución del sonido en el PC que de otra cosa.

Al principio, si estos “locos cacharros” emitían sonidos era porque alguien había decidido conectar a un altavoz algún bit perdido en un puerto de entrada/salida o, como mucho, un temporizador. Con el tiempo, del bit pasamos a los primeros sistemas de sonido digital que permitían voz y música. ¿Quién no recuerda el típico DAC en puerto paralelo que era la salida de impresora? Algunos se vendieron comercialmente (Covox) o se incorporaban en juegos comerciales (Disney Sound Source), pero más de uno se montó uno en casa siguiendo las instrucciones del programa ModPlay de Mark J. Cox.

Posteriormente, llegaron las tarjetas de sonido que solían incorporar, además del DAC de 8 bits, algún circuito adicional para hacer síntesis de algún tipo. Legendario (y denostado por muchos) fue el OPL2 de Yamaha, cuya síntesis FM de dos operadores producía sonidos muy dulces si bien poco realistas. Su especialidad eran los sonidos, digamos, “cristalinos”, llegando a eclipsar en popularidad a su sucesor, el OPL3, jamás explotado de igual manera. En cualquier caso, esta adición permitió comenzar a desarrollar aplicaciones MIDI, incluso como controlador dentro de los juegos.

El siguiente paso de la evolución de estos dispositivos fue hacer la “síntesis de tabla de ondas”, o lo que es lo mismo, almacenar las muestras de los instrumentos musicales en memoria y reproducirlas a diferentes velocidades para lograr hacer sonar cada nota musical en su frecuencia. Al comienzo, estas tarjetas llevaban las muestras en ROM, por lo que había que aguantarse con los instrumentos que traían. Esto imposibilitaba acelerar la reproducción de módulos de Amiga, por ejemplo, lo cual nos lleva de nuevo al DAC incorporado (ya por aquel entonces de 16 bits). Sin embargo, los ficheros MIDI sonaban más realistas en comparación con la síntesis FM de la generación anterior.

Después llegó la instalación de RAM en las tarjetas, descargando al procesador de la reproducción de todo tipo de sonidos, no sólo música. Frases enteras, efectos de sonido, instrumentos alternativos… todo esto podía cargarse en la memoria de la tarjeta, haciendo que un ordenador relativamente modesto pudiera con juegos más exigentes en sonido. Los usuarios de programas de música MIDI también lo agradecieron. En esta fase hay que destacar la Gravis Ultrasound, tarjeta que se hizo muy popular en la demoscene (gracias a la política de documentación abierta de su fabricante, Advanced Gravis), llegando a erigirse como norma industrial frente a la “maligna” AWE32 de Sound Blaster (compañía que no daba demasiadas facilidades). Esta última era una buena tarjeta de sonido, pero también más cara. Sin embargo, el hecho de que se pudiera ampliar a 32M en lugar de sólo 1M como su competidora, la situaba en un plano más profesional.

Avanzamos un poco más: Gravis cae en desgracia y la AWE64 sale al mercado, más barata y con menos memoria (que, al ser especial, resultaba más cara de ampliar). Contrasentidos del mercado. Las tarjetas con síntesis de tabla de ondas son ahora más populares y baratas, aunque no compatibles con la “norma industrial”. Se usan sobre todo en juegos para Windows y aplicaciones MIDI. Prácticamente todos los ordenadores tienen lector de CD-ROM, y los juegos leen la música y sonidos de ficheros (el DAC vuelve a cobrar pujanza…), cuando no son pistas de audio.

La siguiente generación de tarjetas de sonido con tablas de ondas ya no incorporan su memoria propia: usan la del ordenador (SoundBlaster Live y Audigy). Sólo las aplicaciones MIDI sacan partido ya a estas tarjetas. Las más profesionales siguen existiendo y florecen en su entorno especializado. En esta época se popularizan los formatos de audio comprimido (¿ya nadie recuerda el .au? ¿o el .mp2?) y para este propósito, las tablas de ondas no ayudan.

Hoy en día, las tarjetas de sonido pueden tener cualquier número de canales entre dos y ocho y a lo más que llegan es a tener algún tipo de decodificador de audio multicanal (AC3). Pero, sobre todo, lo que llevan son DAC. Muchos DAC. Vuelta al principio.

A veces echo en falta el puerto paralelo :)

Un par de consejos para prolongar la duración (que no la vida, aunque tampoco la afectará) de la batería del Acer Aspire One (AAO).

El primero, reducir el brillo de la pantalla. Esto, que puede parecer evidente, no lo es tanto por dos motivos: el primero, no todo el mundo sabe que la retroiluminación es lo que consume más energía en una pantalla moderna (lo siento, Blackle, llegaste con diez años de retraso). El segundo, en una de las actualizaciones del firmware (que algunos ejemplares llevarán de fábrica) del AAO, Acer decidió que la pantalla no podría situar su brillo por debajo del 46%. ¿La razón? Algunas pantallas sufren de parpadeos por debajo de cierto nivel de brillo.

Si por ventura sois los no tan afortunados poseedores de uno de estos ejemplares, sois valerosos, hábiles y no tenéis miedo a perder la garantía, podéis intentar cambiar el firmware siguiendo este método. Como siempre, no hay seguridad absoluta, pero tanto al autor como a mí nos ha funcionado estupendamente.

El segundo consejo es hacer que el ventilador se active sólo a partir de cierta temperatura. Además de tener una máquina más silenciosa, los miliamperios que se ahorran contribuirán a la duración de la batería. Para conseguirlo en Linux con un núcleo que incorpore el controlador acerhdf (Fedora 12 lo lleva en su última actualización, probablemente también en las anteriores), basta con hacer echo -n “enabled” > /sys /class/thermal/thermal_zone0/mode. Lo ideal es incluirlo en el proceso de carga del sistema (/etc/rc.local es un lugar donde podría estar bien). Así, se activará a los 67º y se desactivará a los 61º. Si véis que se calienta demasiado, es el momento de quitar esta opción. Al igual que antes, no hay garantía, a mí me ha funcionado y después de un par de horas, la temperatura estaba por los 54º, así que no parece haber peligro de que el AAO se fría.

Con estos consejos, hasta es posible que la batería original llegue a durar las tres horas prometidas :)

O, al menos, la explicación que me hubiese gustado leer antes de comprar mi Aspire One.

Si vamos a la página de características del Atom N270, vemos que tiene un único núcleo y la tecnología Hyper-Threading (HT), sobre la cual escribí hace poco. Dado que este es un procesador destinado al mercado de los sistemas empotrados y, de rebote, a ordenadores de muy bajo consumo, parece lógico usar un sólo núcleo. La pregunta es: ¿cómo se llega a ese bajo consumo con un rendimiento razonable?

La carrera del gigahertz hace tiempo que, por fortuna, dio paso a la carrera del rendimiento. Prueba de ello es que hay arquitecturas que, a la misma velocidad de reloj, son más rápidas que otras. La optimización ha venido de la mano de mejoras internas, paralelismo y cambios en los diseños de los buses externos. Para la comparación utilizaré el Intel Atom N270 y el Intel Core 2 Duo E2140, ambos a 1,6GHz, haciendo tareas de compresión de audio.

Si tomamos un fichero de música en formato FLAC y lo convertimos a Vorbis de calidad 5 (una prueba no sintética, sino del mundo real, al menos del mío), obtenemos una velocidad de conversión de aproximadamente 5x en el caso del Atom y de 11,7x en el E2140. En ambos, el procesador se puso a la máxima velocidad, es decir, a 1,6GHz. Mirando las gráficas de rendimiento del procesador, el E2140 ejecutó toda la tarea en el mismo núcleo, mientras que el Atom se repartió entre ambos cauces HT, llegando al 100% de uno de ellos y de un 30 a un 38% del otro. Teniendo en cuenta que se estaba operando desde X Window, es de imaginar que alguna tarea secundaria estaría también consumiendo recursos, pero dado que esto era cierto en ambas máquinas, hay que suponer que la prueba está más o menos compensada.

Lo que resulta de más interés en todo esto es que, observando la gráfica del rendimiento, en el caso del Atom de vez en cuando se pasaba del 100% a un 30% en uno de los cauces, invirtiéndose en el otro. Es decir, ambos se pasaban la tarea de uno a otro. Dado que un cauce puede estar ocupado en un momento determinado, el otro asume la tarea en la medida de sus posibilidades, mientras que cuando el caso es a la inversa, de nuevo se turna para que el procesador siempre tenga instrucciones que ejecutar. ¿El resultado? Un aumento de rendimiento de un 30 a un 38% en las pruebas. Esto equivaldría a un sólo núcleo a unos 2,2GHz sin un aumento notable del consumo, lo cual justifica plenamente la existencia de HT en este pequeño procesador.

Aún así, hay una diferencia bastante grande de rendimiento comparado con el E2140. ¿Qué cambios de arquitectura lo explican? Los tamaños y velocidades de las memorias caché internas pueden tener que ver, pero existe algo aún más importante: el Atom, cuyo objetivo es consumir la menor energía posible, es un procesador que interpreta el flujo de instrucciones tal como le llega. En otras palabras, no tiene la circutería de otros procesadores más potentes, necesaria para la reordenación de instrucciones, que posibilitaría la ejecución fuera de secuencia. Esto hace que, si el código no está especialmente adaptado a la arquitectura del Atom, las instrucciones se ejecuten de una manera menos eficaz de la que podría ser. Lo cual, finalmente, viene a ser la clave del equilibrio entre rendimiento y consumo.

En resumen: el Atom, un procesador de compromiso que suple con eficacia sus carencias con sus habilidades, posibilitando que un sistema alimentado por baterías pueda darnos horas y horas de diversión (o trabajo) con una sola carga. Aunque, eso sí: es poco probable que se convierta en el caballo de batalla de la próxima granja de síntesis de imágenes de Weta Digital :)

Es un hecho. Hace una semana (perdón por la tardanza) se publicó la consolidación B130 de Solaris Express Community Edition. Este hecho no tendría mayor relevancia de no ser porque, tal como explicó Alan Coopersmith antes y después de dicha publicación, SXCE B130 es la última que se hará con soporte para paquetes SVR4 y conteniendo, entre otras cosas, Xsun, los controladores para tarjetas gráficas con código de terceros y CDE.

Para más complicación de la historia, cuando acabe enero se BORRARÁN todas las imágenes de instalación de SXCE de los repositorios de Sun, por lo que actualmente se trata de una carrera contra reloj para conseguir la versión favorita de cada uno. Desde ese momento, las siguientes consolidaciones únicamente emplearán el código que pueda ser publicado en OpenSolaris, y en el formato de paquetes IPS.

Esto significa que, por ejemplo, si sois los afortunados poseedores de una Blade 1000, vuestra mejor opción es pillar la B130 (o alguna que sepáis estable) AHORA MISMO e instalarla para estar a la última (literalmente) antes de que sea demasiado tarde. Yo ya lo estoy haciendo.

Si Sun seguirá actualizando Solaris 10, es para mí un misterio en este momento. Es probable, pero yo no contaría con la compatibilidad con SXCE. OpenSolaris 2010.03 saldrá, para sorpresa de nadie, en marzo. Si será un digno sustituto (controladores aparte), está por ver.

Suerte y buena caza.

Supongo que en el titular hay más de una marca registrada, así que si los chicos de la empresa que antes tenía una “e” por debajo de la línea de escritura me llaman, me disculparé.

Bien, últimamente y a raíz de la aparición en el CES 2010 de ultraportátiles basados en los nuevos procesadores Core i7 mobile se ha hablado bastante de estas dos tecnologías. La primera se estrenó con la versión de sobremesa del Core i7, mientras que la segunda se ha reestrenado (al parecer, con mejor acierto) en el antedicho procesador, si bien data de hace unos años.

En efecto, Turbo Boost (TB), es una tecnología reciente que representa una solución bastante ingeniosa a un problema del mundo real, teniendo en cuenta todos los parámetros implicados (¿será la primera vez que esto ocurre en el mundo de los ordenadores?). Tenemos un procesador con varios nucleos (en el caso del Core i7, cuatro si es de sobremesa; cuatro si es para portátil de gama alta y dos si es para ultraportátil, además de un procesador gráfico más o menos elemental). Si queremos mantener la máxima potencia disipable (TDP, aunque las siglas significan otra cosa) dentro de los límites para que el circuito integrado no se queme, es evidente que habrá que jugar con la tensión de alimentación y la velocidad de reloj para conseguirlo. Además, el problema se agrava porque cada “núcleo” es un procesador completo, y eso significa que vamos a tener que tener en cuenta su actividad. El sistema TB hace justamente eso: a partir de la medición interna de la temperatura, sube la frecuencia de los núcleos mientras sea posible mantener la disipación de energía. Pero si hay menos núcleos activos, calcula cuánto se puede subir la frecuencia de los que quedan; hasta que si sólo se usa uno, la frecuencia puede superar hasta en un 50% (a veces más, a veces menos) a la original.

Vamos a por el siguiente mito: ¿significa esto que estamos ante un magnífico ejemplar para practicar el deporte del overclocking (acelerar el procesador más allá de los límites del fabricante)? Al igual que un procesador menos sofisticado, todo dependerá de en cuanto valoremos nuestros datos y de qué sistemas de refrigeración estemos dispuestos a instalar. Mi recomendación es que los experimentos se hagan en casa y con gaseosa, pero para los aventureros: que un sólo núcleo pueda acelerarse un 50% no significa que el sistema sea estable cuando esta condición se aplica a cuatro núcleos. Además de la temperatura hay que tener en cuenta la alimentación y cómo se afectan entre sí los núcleos y al procesador gráfico incorporado (si existe).

Por otra parte, ya en las versiones más modernas del Pentium 4 (2003) se incorporó Hyper-Threading (HT), que se vendió como una panacea para aumentar la potencia de cálculo, mostrándose ante el sistema como dos procesadores lógicos (que no físicos). Lo cierto es que el aumento de rendimiento era (y sigue siendo) modesto, pero dado el coste que tiene en hardware (ridículo), era una alternativa antes (y un complemento ahora) de los demás avances en tecnología. Entre que la imagen de Intel por aquel entonces sufrió varios reveses y que el aumento en rendimiento era discutible (a veces, causaba una disminución), la cosa no gozó de la popularidad que hubiera podido merecer.

Con el Core i7 parece que están decididos a hacerlo mejor: dado que este invento se basa en usar elementos de los cauces de proceso que de otro modo estarían inactivos, Intel ha aumentado la redundancia de los mismos, además de duplicar el juego de registros. Otros elemento más costosos, como la ALU o la unidad de coma flotante, no lo están, por lo que sólo las operaciones que requieran los servicios de unidades distintas podrán simultanearse. Llenar los cauces lleva su tiempo, por lo que si una instrucción tiene que esperar, puede darse el caso de que el rendimiento baje, en vez de subir. En la práctica, dependerá mucho del tipo de aplicación que se vaya a ejecutar, pero en general se puede decir que el aumento, aun siendo modesto, se va a producir.

Un mito que convendría despejar: el HT no va a causar un aumento desproporcionado del consumo de energía, pues la mayoría de los elementos (si no todos) que entran en juego están ahí siempre.

¿Qué prepara AMD para combatir estas tecnologías? La respuesta no creo que se haga esperar mucho…

… o no tan corriente. En cualquier caso, uno que cualquiera que ahorre un poco (o pida un cŕedito pequeño) se puede permitir: unos 2000€ en un sistema basado en Intel Core i7; de los cuales seguramente una parte importante se fue a almacenamiento (cinco discos de 1,5TiB).

El artífice del logro no es otro que Fabrice Bellard, un nombre conocido en los círculos tecnológicos y que seguramente sonará a los usuarios más avanzados de Linux (sin ir más lejos, ffmpeg es una de sus creaciones más usadas en la conversión de ficheros multimedia). Como él mismo dice, la gracia de batir esta marca no está en el tiempo (la anterior tardó 29 horas frente a sus 131 días), sino en la relación entre la potencia del algoritmo utilizado (comparativamente, 20 veces mejor en este caso) y el coste del equipo usado (millones de euros frente a un par de miles).

Lo cual, finalmente, nos hace llegar a varias conclusiones. La primera, que los ordenadores “corrientes” de hoy en día están llegando a tener una potencia que algunos no hubieran ni soñado hace algunos años. La segunda, que siempre el ingenio será más importante que la fuerza bruta (sin menospreciar a quien batió la anterior marca). Y la tercera, que tal vez Intel debería renombrar su línea de procesadores Core i7. Creo que Core Pi sería un nombre adecuado ;)

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.

No hace mucho he leído un par de discusiones sobre los formatos de audio digital y la “indistinguibilidad” del MP3 (MPEG-1, nivel 3, recordémoslo) y la fuente original. Evidentemente, o bien los voluntarios no han escuchado más que MP3 a lo largo de su existencia, o los equipos de sonido que usaron para las pruebas (auriculares incluidos) no eran de buena calidad.

Sí es cierto que para niveles suficientes de calidad de los componentes y dependiendo del grado de compresión deseado y del entorno en que se escucha la música, se puede lograr un compromiso más que aceptable usando un formato de compresión con pérdidas. Por motivos técnicos e ideológicos, mi formato favorito es el Vorbis (más conocido como “OGG” por el nombre del contenedor Ogg que lo suele incorporar): su calidad suele superar a la del MP3 de velocidad equivalente, además de ser un formato libre de patentes. La duda puede venir cuando necesitamos cierta, digamos, interoperatividad.

En ese caso, mi consejo es claro: capturar el audio en formato FLAC, conservando sin pérdidas el sonido original y (esta, además del ahorro en espacio, es la diferencia más interesante con respecto al formato WAV) permitiendo almacenar las etiquetas de la música como comentarios Vorbis: autor, álbum, fecha, etc. Como suele decirse, hoy en día el espacio en disco (especialmente el externo) es barato.

Posteriormente, dependiendo de nuestras necesidades, podemos generar a partir del fichero FLAC otro OGG, MP3 u otros formatos. En el primer caso, la conversión de etiquetas es directa y el propio programa oggenc se encarga de ello. Para el formato MP3, necesitaremos alguna ayuda extra (flac2mp3 me viene a la cabeza). En mi caso, dado que tanto en el ordenador como en mi DAP tengo la posibilidad de escuchar Vorbis (tanto con el firmware original como con RockBox), es a OGG a lo que he convertido mi música. ¡Problema resuelto y con formatos libres!