• Solaris avanza hacia su versión 11, y habrá algo parecido a Solaris Express en la forma de versiones de prueba para desarrolladores. El código fuente estará disponible después de cada versión;
• OpenSolaris avanza hacia el hiperespacio, y el proyecto Illumos, que comenzó siendo un intento de producir una base de código más libre aún de OpenSolaris, puede convertirse en el primer fork efectivo del anterior proyecto;
• el OGB (OpenSolaris Governing Board) avanza hacia otros proyectos, probablemente relacionados con Illumos y el resto de tecnologías asociadas. Gracias a todos por haber aguantado todo este tiempo;
• SPARC avanza hacia los centros de datos actuales y futuros, en la forma de nuevos desarrollos y servidores que seguirán explotando las bondades (y soportando los defectos) de esta arquitectura. Solaris 11 sacará todo el partido de SPARC (y, probablemente, de Intel x86_64, aunque Oracle tiene más interés en su, ahora, propia arquitectura);
• MySQL avanza hacia toda clase de clientes, como demuestra la publicidad que he recibido de Oracle recientemente por correo electrónico. En contra de lo que muchos pensaban, Oracle no desprecia los kopeks que le pueda proporcionar el negocio de las bases de datos, digamos, pequeñas.

El resúmen no puede ser más claro: todo avanza, pero no todo dentro de Oracle. OpenSolaris queda, pues, como el último intento de Sun por atraer la atención sobre su excelente *nix y formar una comunidad alrededor de un interesante proyecto que, sin embargo, arrancó muy tarde y con unos objetivos vagos (tratar de sustituir Solaris por OpenSolaris cuando éste no estaba listo para la tarea es, cuando menos, insensato). Espero sinceramente que la nueva comunidad que, sin duda, se formará alrededor de Illumos sea capaz de llevar la antorcha mucho más lejos que en su anterior entorno.

De hecho, tal vez esto es lo mejor que ha podido ocurrirle a OpenSolaris: convertirse en el proyecto de una comunidad, independiente de cualquier interés comercial directo de un ente que lo controla y moldea. ¿Será OpenSolaris^WIllumos (y sus derivados) el nuevo Linux? El tiempo lo dirá.

Mientras tanto, no veo el momento de probar Solaris 11 en mi Blade 1000… confiando en que decidan soportar las máquinas antiguas.

Cuando esto ocurre, sólo cabe celebrarlo con un día a día en que no falten la profesionalidad ni el buen humor. Celebrarlo también procurando que cada día sea mejor que el anterior, renovando la confianza en las personas y en las buenas ideas; aunque el trabajo a veces nos aleje del ideal que un Administrador de Sistemas persigue: la excelencia profesional.

Pero, como suele decirse, la única constante del Universo (y más en el laboral) es el cambio. Los caminos que hasta ahora discurrieron paralelos, ahora se separan. Tu compañero busca pastos más verdes, motivado por la búsqueda de esa excelencia que antes decía. Entonces, la madurez te hace sobreponerte a la pérdida que para ti significa y le deseas sinceramente que le vaya bien en su nueva aventura. Los días compartidos no serán fáciles de olvidar, y sabes que el código y correos que escribió harán que siga presente de alguna manera. Otro compañero llegará a ocupar el puesto que él tuvo (no es posible usar la palabra “sustituir” en este caso), y aunque sabes que posiblemente formarás un buen equipo con él, no vas a olvidar a tu antiguo compañero.

Las despedidas se me dan mal. Por eso sólo puedo decir: suerte, compañero. Aunque no creo que te haga falta.

Hace ya un tiempo que en mi DAP dejé de interesarme por las actualizaciones de firmware del fabricante para hacerlo por las de Rockbox, y no me he arrepentido de ello. Al contrario, la última versión estable, la 3.6, es casi perfecta en mi Fuze, siendo una de las posteriores versiones de desarrollo “perfecta” del todo (el soporte de USB sin depender del firmware original ha sido un paso decisivo).

Por otro lado, llevar en el bolsillo un dispositivo que más parece un ordenador que un PDA, y que te lo suelen vender como teléfono, también tiene asociada la tentación de tenerlo a la última. En este caso, pensando en las mejoras de las últimas versiones -algunas de las cuales son muy interesantes para un Administrador de Sistemas- y viendo que ni Google  ni mi operadora de telefonía iban a enviar más actualizaciones por encima de la versión 1.6 de Android a mi, ya considerado “obsoleto”, HTC Magic, decidí mirar a las versiones de la comunidad de desarrolladores.

Dado que el código de Android es abierto y Google lo publica cada vez que saca una nueva versión oficial, no es raro que haya más de un grupo de desarrolladores que tome el código, lo compile con el propio SDK para Android de Google y publique una consolidación en forma de imagen de ROM para instalar en el teléfono. Tal vez la ROM más conocida sea la llamada CyanogenMod, creada por Steve Kondik y el grupo xda-developers. Funciona en HTC Dream y Magic, Motorola Droid y Google Nexus One.

La última versión estable es la 5.0.8, correspondiente a Android 2.1, pero la versión 6 -Android 2.2- está a puntísimo de salir (hoy se ha publicado la primera tentativa de versión estable, 6.0.0-RC1). Yo he instalado la 5.0.8 siguiendo estas instrucciones (se pierde la garantía, es necesario borrar los datos, probablemente te llevarás un susto o dos, tal vez no sea tan fácil, etc) y en el poco tiempo que llevo con ella, además de los efectos especiales y el uso de gestos para ampliar las pantallas, la principal mejora ha sido en velocidad. Puede parecer mentira, especialmente considerando que el mío es una versión 32B, con menos memoria.

Otras cualidades importantes, además del acceso como root al teléfono (requisito indispensable para poderlo actualizar) son el soporte para audio en formato Vorbis (en la próxima versión, también FLAC), la creación de redes con OpenVPN y la compartición de la conexión a través de Bluetooth y USB (en la próxima versión, también con WiFi; a cambio de un buen bocado en la carga de la batería, claro). Todo eso sin olvidar el nuevo lanzador de aplicaciones, el número variable de escritorios (viene configurado con 5, de los que me sobran casi todos), el navegador mejorado, el nuevo marcador telefónico, etc.

Estaré atento a la versión 6, pues puede resultar mejor que la que incorporan los teléfonos que salen al mercado con Android 2.2.

Al respecto de los firmwares alternativos, lo unico que lamento es no haber podido ponerle Linux a mi router WiFi Linksys: la versión de mi router es una de las pocas que hace imposible instalarle DD-WRT. Lástima.

Las mejoras son muchas (las podéis leer en la nota de prensa enlazada más arriba), pero de ellas cabe destacar sobre todo una: virtualización. Red Hat está apostando la casa (y hasta el coche) por la virtualización. Es la palabra de moda, junto con los servicios en la nube. ¿Está justificado tanto cacareo?

Depende. Si lo vuestro es el rendimiento puro, las granjas de síntesis de imágenes, los cálculos masivamente paralelizados para secuenciar el ADN… lo más seguro es que no. Pero si os dedicáis a los servicios de internet y necesitáis varios entornos donde probar las cosas, es bastante probable que salga mucho más rentable adquirir un servidor grande en disco, memoria y procesador, y meter dentro varias máquinas virtuales donde instalar aplicaciones, servicios o infraestructuras. Una vez probado todo, podréis dimensionar correctamente los servidores reales donde irá todo.

O también se pueden poner a funcionar aplicaciones para diferentes clientes. O servidores de pruebas. O nuevas versiones de los entornos, herramientas o sistemas operativos. Las posibilidades son ilimitadas. “Virtualización” es algo más que una palabra de moda.

Queda por ver es si el abandono de Xen en favor de KVM como sistema de virtualización es un acierto o no. Este último requiere el soporte del procesador para lal virtualización completa, mientras que aquél no lo exigía. Dado que hoy en día, los procesadores recientes de los servidores incorporan esta tecnología, así como no pocos procesadores de escritorios (¿quién ha dicho Core i7?); que RHEL5 seguirá estando soportado hasta 2014; y que es probable que en ese tiempo haya alguna actualización, el tiempo para hacer la migración es más que suficiente.

Las ventajas de KVM se derivan, sobre todo, de la compra por parte de Red Hat de Qumranet, su empresa desarrolladora. A partir de ahora, los desarrollos de esta herramienta de código abierto van a estar encaminados a la mejor integración con los servicios que ofrece RHEL, de los cuales me gustaría llamar la atención sobre uno: la virtualización del escritorio.

En efecto, si en los servidores la cosa está más o menos clara (más servidores en menos espacio), en el escritorio pueden existir dudas. Despejémoslas: el hecho de requerir la virtualización completa en el procesador significa que se pueden ejecutar distintos Sistemas Operativos sin modificar dentro de las máquinas virtuales. Gracias al protocolo SPICE (Simple Protocol for Independent Computing Environments), se pueden servir sesiones virtualizadas completas desde un servidor con RHEL6.

En otras palabras, literalmente se puede uno llevar el escritorio de un ordenador a otro, con independencia de que tal escritorio sea en Linux o en Windows. ¿El ordenador de un puesto de trabajo se ha estropeado? Se pone otro, se conecta a la red y ya se puede trabajar en él. ¿Necesitamos trasladarnos temporalmente a otro Departamento para realizar una tarea? Allí tenemos nuestro escritorio. ¿Necesitamos unas herramientas específicas para hacer un trabajo concreto? Elegimos el escritorio que las incorpora. ¿Tenemos que trabajar remotamente? Dependiendo de la velocidad de la red, podremos hacerlo como si estuviésemos sentados ante nuestro ordenador. Y todo, con la posibilidad de realizar copias de seguridad completas de cada entorno, sin abandonar las instalaciones de la empresa; sin olvidar el ahorro en equipos y en su consumo. De nuevo, las posibilidades son ilimitadas. Todo esto requiere un producto que ahora mismo es comercial, así que de momento no puedo hablar de él más que por referencias.

Por otra parte, como podéis imaginar, yo ya estoy jugando un poco en casa con RHEL6 Beta 1 en una máquina virtual, a ver qué sorpresas me da :)

Llevo con Linux desde 1993 y administrando sistemas Linux a diario con distribuciones de Red Hat o sus derivados (Fedora, CentOS) desde 1996. Ya iba siendo hora de ponerme a prueba, además del día a día, así que decidí pasar la prueba del RHCE. Como en *nix pro somos grandes en méritos pero pequeños en recursos, decidí ir directamente al examen (RH302), saltándome el curso (RH300). Dado que según un examinador oficial (RHCX), el RHCE lo suele aprobar a la primera el 40% de la gente que asiste al curso y el 10% de los que no lo hacen, la decisión parecía arriesgada. Pero era un riesgo calculado, así que seguí adelante con el plan.

Lo primero que debería hacer un candidato al RHCE es pasar la prueba de evaluación. Esta prueba es gratuita (requiere registro en Red Hat, también gratuito) y le permite a uno saber su nivel básico. Consta de tres partes, que valoran los conocimientos que se adquirirían en los cursos RH033, RH133 y RH253 (estos dos últimos se comprimen en la mitad de tiempo en el RH300). Si no sois capaces de superar estas pruebas con una puntuación mínima, dejadlo. No lo intentéis. En su lugar, pegáos a los libros, haced los cursos, o ambas cosas. Los conocimientos que se miden son fundamentales para seguir adelante, así que es mejor no perder el tiempo y asegurarse cierto nivel.

Lo siguiente sería un repaso a las cuestiones que formarán parte del examen. Dado que el único misterio con respecto al examen son las preguntas concretas, y no los temas, podemos fácilmente encontrar en Red Hat la guía de preparación. En ella está condensada la planificación a seguir, incluyendo los prerequisitos sin los cuales, es necesario insistir, mejor ni intentarlo. Además, también vemos la lista de habilidades que se van a poner a prueba, tanto en el RHCT como en el RHCE. Si no se supera todo el examen, bien se puede obtener el RHCT (Technician en lugar de Engineer), o bien plantearse desde un comienzo ir a por esta otra certificación.

A continuación, hay que seleccionar el material de estudio. Ya que se trata de un examen práctico, es necesario (¿hay que decirlo?) practicar. Lo voy a repetir por si no ha quedado claro: lo único que cuenta en este examen es resolver correctamente los problemas que se plantean, así que un problema a medio resolver cuenta como no resuelto.

El material de estudio puede venir de muy diversas fuentes, pero la primera que habría que considerar es, precisamente, Red Hat. Muy recomendable la lectura de los documentos Deployment Guide e Installation Guide. Además de practicar (y practicar, no lo olvidemos), puede ser más que recomendable adquirir algún libro, digamos, más (allá va otra vez la palabra) práctico. Hay muchos de ellos orientados a aprobar el examen, de los que habría que seleccionar alguno que tenga (lo habéis adivinado) problemas prácticos que resolver.

Con respecto a esto de practicar (os habéis adelantado esta vez), es recomendable tener un ordenador aparte (o más, para probar los servicios de red) sobre el que hacer las instalaciones, configuraciones y demás operaciones. También puede ser una o más máquinas virtuales, que fue mi opción. En cualquier caso, hay que tener en cuenta que tanto unos como otras pueden quedar bastante maltrechos como resultado de las prácticas, en especial las de resolución de problemas de arranque y de servicios mal configurados. Para esto último, ayuda tener un compañero que nos pueda “sabotear” la instalación (y al cual devolverle el “favor” si es que también se presenta al examen). Yo no tuve esta ayuda, pero me hubiera venido bien.

Una vez superado todo esto, podemos ir a la página de Red Hat y ver cuándo es el próximo examen en nuestro rincón del mundo. También podemos hacerlo al revés, y primero seleccionar la fecha para después hacer el plan de estudio. Este último método, aunque es algo menos seguro, tiene la ventaja de que sube el nivel de adrenalina, especialmente si tenéis que trabajar, tenéis SO (agradezco enormemente su enorme paciencia) o ambas cosas. He de decir que, aunque seguí mis propias recomendaciones de estudio, el grueso del mismo y todas las prácticas tuvieron lugar en las dos semanas previas al examen, incluyendo un catarro que amenazó con frustrar por completo el plan :/

Llegó la hora de la verdad. Éramos diez candidatos en un aula bien dispuesta. Nuestro examinador se preocupó de que estuviéramos cómodos y de que las instrucciones fuesen claras. Incluso explicó la mecánica del examen en inglés para los candidatos que no hablaban español. Nos informó también de que los resultados se nos enviarían por correo electrónico en tres días laborables (de EE. UU.).

Lo primero que hicimos fue rellenar nuestros datos y firmar un acuerdo de confidencialidad (NDA, para el que no sepa español), por lo que lo que os puedo contar del examen es muy limitado. Mucho.

• dura 3,5 horas
• es totalmente práctico (por si no lo había dicho antes)
• hay que llevar DNI o documento identificativo similar
• no se puede usar móvil, PDA, ordenador portátil, apuntes, libros, etc
• se puede escribir en una hoja de papel (suministrada por ellos), que luego recogen
• más vale que hayáis dormido bien y seguido un plan de estudios efectivo
• lo primero, las preguntas que mejor sepáis para conseguir el mínimo de 70 puntos en cada parte
• hay que saberse mover por el sistema, especialmente con la documentación
• no hay conexión a internet
• no hay tiempo que perder
• hay que probar los cambios que se hagan

Las tareas están a la altura de lo que se pide en la guía de preparación, pero una lectura de un libro práctico es más que recomendable. Recomiendo vivamente confeccionar una guía personal de consulta con los puntos que uno tenga menos frescos para su estudio posterior. A mí me resultó sumamente práctico, pues a la hora de repasar, uno puede estar tentado por mirarlo todo y puede no haber tiempo.

¿Que cómo me fue? Teniendo en cuenta la complejidad del examen, el tiempo que le dediqué a la parte práctica y que la noche anterior dormí poco (aún me ponen nervioso los exámenes, ¿podéis creerlo?), el resultado (que recibí esa misma tarde) fue más que satisfactorio: superé los 90 puntos. Hasta te envían un documento PDF para que puedas imprimir tu propio título y colgarlo de la pared, qué majos :)

En efecto, ya en la versión 5.4 se hizo hincapié en la migración del sistema de virtualización de Xen a KVM. El énfasis de la nueva versión está en las optimizaciones relacionadas con su uso, especialmente en lo que respecta a la memoria y al rendimiento de la E/S. Esto, por supuesto, además de las habituales mejoras en el núcleo para apoyar a los nuevos procesadores de Intel y AMD.

La versión 6, que aún no tiene fecha de publicación, saldrá probablemente a lo largo de este año, si bien aún es pronto para saber cuándo. La virtualización y lo relacionado con los servicios en “la nube” destacarán en esta nueva entrega, según lo publicado en septiembre por los responsables de desarrollo del proyecto.

Sé lo que estáis pensando: estáis pensando si no hubiera sido mejor esperar a la publicación de RHEL 6 para pasar el examen de certificación. Mi respuesta es: en algún momento había que tomar la decisión, y de todas formas, la validez de la certificación para RHEL5 aún va a estar vigente unos cuantos años, así que…

¿No os había dicho lo de la certificación? Estad atentos a vuestras pantallas… ;)

Sobre lo primero, el Salt Lake Tribune ha publicado un artículo en el que se deja claro que el jurado ha puesto el punto y final a seis años de litigio, reconociendo que Novell posee los derechos del *nix original, y no SCO (que, recordemos, proviene de una división de Novell llamada Caldera y posteriormente renombrada como “SCO Group”; no debe confundirse con lo que en su momento fue The Santa Cruz Operacion y que posteriormente se renombró a Tarantella). Supongo que esto no será el fin, puesto que el derecho al pataleo y las amenazas vacías son prerrogativa de cualquier empresa o particular, pero a partir de ahora quedará claro que de esto es de lo que estamos hablando, y no de derechos de autor. Una de cal para el mundo *nix. Si es que la cal era buena para algo, que me dicen que sí.

La arena sale en esta ocasión de Oracle. En efecto, nada mejor para una máquina (sea real o virtual) que tener todos sus engranajes en perfecto estado de mantenimiento, engrasándolos cuando es necesario. Y nada peor que introducir arena en tales engranajes. O, como en este caso, cambiar la licencia de uso de Solaris. Oracle, en su intento de sacar hasta el último kopek de sus adquisiciones, ha convertido (afortunadamente, sin efecto retroactivo) a Solaris en un sistema que requiere licencia para uso más allás de los 90 días de prueba que ahora se conceden. Antes, la licencia de uso era a perpetuidad, al margen de que necesite una suscripción para las actualizaciones (esto no ha cambiado).

¿Puede OpenSolaris salvar al mundo libre de esta situación, conservando lo mejor de Solaris? Tal vez… siempre que Oracle no decida que su personal dejará de mantener el código y que al mismo tiempo la comunidad de OpenSolaris esté lo bastante ducha para hacerlo en cualquier caso. El tiempo lo dirá.

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 :)

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 :)

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 :)