Los nuevos discos de Western Digital

En estos días tuve la oportunidad de comprar y configurar una máquina Ubuntu con un disco rígido Western Digital de 1,5 Terabytes (1500 Gigabytes aprox.); más precisamente el modelo WD15EARS, con 64 MB de caché, velocidad de rotación que varía entre 5400 y 7200 RPMs (llamado “IntelliSeek“), interfaz SATA II (3 Gb/seg), y que incluye una nueva tecnología de la marca conocida como “Advanced Format Drive” (paper aquí).

Si bien yo pensé que estaba comprando un disco más aunque sólo de mayor capacidad, luego al mirarlo más de cerca en su etiqueta decía:

Resumiendo, dice que:

• Si va a utilizar el disco con Windows XP con una sola partición en el disco, sólo ponga el Jumper en los pins 7-8 del HD.
• Si va a utilizar el disco con Windows XP con más de una partición en el disco, use la utilidad “WD Align”.
• Si va a utilizar otro SO (Windows Vista/7, Mac OS X, o Linux), el disco no requiere preparación adicional para el particionamiento.

“Bueno, total no uso Windows”, pensé. Particioné y formatié con el GParted el disco y me puse a utilizarlo normalmente. No noté nada raro, hasta que unos días después googleando sobre experiencias con éste disco y Linux me encontré con este hilo en el foro de WD (“Problem with WD Advanced Format drive in LINUX (WD15EARS)“). Al parecer, mucha gente utilizando Linux con estos discos notaba una lentitud excesiva en cada cosa que hacía, como si hubiera un problema, no del hardware fallando y perdiendo datos, sino de demoras muy grandes en lectura/escritura. Resultó que aún usando Linux, el disco sí requiere preparación adicional, al contrario de lo que dice el fabricante, como veremos más adelante.

Sectores de 4 KBytes en vez de 512 Bytes, ¿Por qué?

Desde los primeros días de los discos rígidos, la mínima unidad de almacenamiento direccionable fue el sector, de 512 Bytes de capacidad. Esta granularidad se eligió porque siempre fue un buen balance entre la fragmentación interna de los archivos* y el manejo físico del disco relativo a la corrección de errores, flags de inicio/fin del sector más la separación inter-sector (gap). Toda la industria de la PC y el software creado para ella se apoyó en este estándar de facto, y casi ningún utilitario, BIOSes, ni Sistema Operativo se pensaron para un posible cambio… sólo hasta hace unos pocos años.

Western Digital es una de las primeras marcas en sacar al mercado discos con sectores 8 veces más grandes que los anteriores, de 4 KBytes (4096 Bytes); estos discos son etiquetados como que poseen “Advanced Format Technology” (“Tecnología de Formato Avanzado”), y es lo primero que uno debería empezar a mirar al comprar discos nuevos de gran tamaño (1 TB o superior), ya sean de WD o de otros fabricantes. Casualmente (o no tanto), esto incluye al disco que compré.

El motivo del cambio, según lo que explica este excelente post de AnandTech, se debe a que existen 3 factores esenciales que deben compensarse para buscar capacidades de almacenamiento cada vez mayores en el mismo tamaño de disco (que por lo general es de 3,5 pulgadas):

1. Densidad de área: Cuántos bits se pueden guardar en un área determinada (Bits/Pulgada cuadrada). Hasta ahora, con la Grabación Perpendicular, estamos en el orden de unos 300/500 Gigabits por pulgada cuadrada (1, 2).
2. Relación Señal/Ruido: Al leer de los platos del disco, pueden ocurrir fallos, ya que el almacenamiento magnético en definitiva es analógico; y la señal, para ser convertida desde/hacia binario, debe ser procesada. Cuanto mejor sea la relación de la señal con respecto al ruido en el momento de leer o escribir en los platos, más confiable es la operación.
3. El uso del Código de Corrección de Errores – ECC: Cada sector del disco incluye un área reservada para almacenar el ECC, imprescindible para recuperarse ante cualquier error de lectura/escritura.

A medida que la Densidad del Area se incrementa, los sectores (siempre de 512 Bytes) lógicamente se reducen en el área que ocupan físicamente. Esto hace que se incremente el Ruido con respecto a la Señal porque las señales son más débiles y hay más interferencia de los datos adyacentes; por lo tanto el valor de SNR disminuye, y a su vez, la probabilidad de errores de lectura aumenta. Entonces, es necesario mejorar la capacidad del ECC para detectar y corregir errores, generalmente agregándole más bits. Esto requiere de más espacio físico reservado para un sector (siempre de 512 Bytes), y aquí volvemos a empezar.

Lo que sucede es que aquí está el punto; se está llegando a un límite donde no se puede seguir con sectores de 512 Bytes y aumentar el tamaño total del disco, ya que todo este nuevo espacio obtenido con una mayor densidad termina no siendo utilizable, sino que será mayormente para el ECC (es decir, redundancia para contemplar posibles errores).

La solución al problema es que, para almacenar más información globalmente, hay que incrementar la eficiencia del ECC. Y esto se logra haciendo que éste abarque más datos que sólo 512 Bytes; el ECC es mucho más eficiente (ocupa menos espacio en comparación) si su código de corrección abarca más datos, digamos, 4096 Bytes.

Por ejemplo, para detectar y corregir corregir 4096 Bytes divididos en 8 sectores de 512 Bytes (de la vieja forma), necesitamos “gastar” 320 Bytes de ECC (ya que tenemos 40 Bytes por cada ECC de 512 Bytes), mientras que si usamos 1 sector de 4096 Bytes sólo vamos a usar 100 Bytes de ECC. Como se puede ver, uno se ahorra 220 Bytes de overhead por cada 4KB que tiene el disco para guardar cosas; en 1500 GB (= 1.500.000.000 KB / 4 = 375.000.000 sectores de 4 KB * 0,22 KB) son 82,5 GB más de espacio disponible para almacenar datos de usuario y no ECC (un 5,5% más). Esto y sin contar el espacio “desperdiciado” para los gaps entre sectores y el flag de sincronización/inicio de sector (para 4 KB, antes eran 8 y ahora es sólo 1). Además, estos 100 Bytes de ECC mejoran en un 50% la capacidad de detectar errores en “ráfaga” comparado con el anterior, es decir, el nuevo es un mejor y más eficiente ECC.

Por todo esto, para tamaños tan grandes de disco, usar sectores de 4KB nos permite aprovechar de manera más eficiente la mayor densidad del área que disponemos. ¿Y por qué 4 KB? No es un número al azar; coincide con el tamaño de las páginas de memoria en la arquitectura x86 y con el tamaño de cluster por defecto de la mayoría de los sistemas de archivos que pululan por ahí, con lo cual la velocidad de transferencia de páginas desde/hacia el disco no se ve afectada, y la fragmentación interna de los archivos almacenados es la misma que con sectores de 512 Bytes.

Quizás con el gráfico se entienda un poco más; allí se ve cómo ocupan más lugar los 8 sectores de 512 Bytes puestos a la par del sector de 4 KB:

Nuevamente (espero comentarios y corrijo en todo caso), toda esta info está bien explicada en el artículo de AnandTech, en este artículo de Ars Technica, en el Paper de WD y en este artículo de IBM.

Bien, “¿Y qué gano con sectores más grandes? ¿en qué me afecta?”, es lo primero que uno se pregunta. Claramente, y por lo explicado recientemente, se gana en confiabilidad y capacidad de almacenamiento hoy y a futuro. ¿Cuáles son las contras? básicamente, el proceso de migración, que como ya se dijo, deben afrontarse desde varias capas de software, desde el BIOS, pasando por el Sistema Operativo y llegando a las herramientas de defragmentación, clonado y administración de discos.

¿Y qué problema hay con Linux? Particiones desalineadas.

Teniendo en mente esto, esta serie de discos de WD emula ser un disco con sectores “lógicos”de 512 bytes, pero en realidad trabaja internamente con sectores “físicos” de 4 KB. De esta manera, los sectores de 512 bytes lógicos se ven así, dentro de uno de 4 KB:

Recordemos, la mínima unidad “direccionable” real del disco son 4 KB (un sector), y el tamaño de cluster por defecto (la mínima unidad “direccionable” por el sistema de archivos) son 4 KB; esto quiere decir en definitiva que el disco, cada vez que lee y escribe lo hace en unidades de 4 KB. Luego le agregamos la capa de emulación, para hacerlo compatible con los SOs que tenemos ahora. Bien, supongamos que vamos a crear una sola partición en el disco. ¿Qué pasa si esta partición, donde vamos a guardar los datos, comienza en el sector 1 (o cualquier sector no múltiplo de 8 ) del disco en vez del sector 0? Va a pasar esto:

Lo que sucede es que el primer cluster empieza y termina en dos sectores físicos; está “desalineado” con respecto a ellos. En realidad, todos los clusters de la partición estarán de esta forma, comenzando y finalizando a “destiempo” respecto de los bloques físicos. El problema que esto conlleva es que si el SO va a escribir algo en el disco (donde el “algo” es como mínimo generalmente un cluster de 4 KB), supongamos el cluster resaltado en azul, esto se transforma físicamente en:

1. Leer los 4 KB del sector físico 0.
2. Modificar los 7 sectores lógicos afectados por esta operación.
3. Grabar los 4 KB del sector físico 0.
4. Leer los 4 KB del sector físico 1.
5. Modificar el 8vo sector lógico.
6. Grabar los 4 KB del sector físico 1.

Esto es, 2 operaciones de Leer-Modificar-Grabar (RMW) atómicas, una para cada sector físico, que involucra una vuelta (spin) de disco por cada lectura/escritura de la lista enumerada. Es decir, que una partición comience en un sector lógico de 512 Bytes no múltiplo de 8 hace excesivamente lento el acceso al disco porque las operaciones llevan mucho, mucho más tiempo que antes.

Y la cuestión reside aquí; si bien Linux a esta altura ya está preparado para manejar discos con sectores de 4 KB, el problema es que el disco “le dice” a Linux que tiene sectores físicos de 512 bytes por la emulación, cuando internamente trabaja con 4 KB:

marcelo@marcelo:~$ sudo hdparm -I /dev/sdb | grep Sector
	Logical/Physical Sector size:           512 bytes

¿Y cuál es la consecuencia? La posibilidad de no tener los sectores alineados. Fdisk y cualquier software particionador de discos de Linux comienza la primer partición en el sector 63 de aquellos discos que reconoce como de sectores de 512 Bytes**. Esto hace que el disco funcione muy lento, como se describía en el foro de WD que cité al comienzo.

Cómo particionar estos discos en general y en Linux en particular

Bueno, ¿cómo se hace para crear particiones de manera alineada? Es relativamente fácil. Según Ted Ts’o, donde explica que hay un problema parecido con los nuevos discos SSD, hay que ejecutar fdisk con los parámetros “-H 224 -S 56 /dev/sdX”, siendo /dev/sdX el disco en cuestión; esto hace que todas las particiones se creen en la sesión interactiva de fdisk en sectores múltiplos de 8. Otra opción es usar GNU Parted con los parámetros “unit s”, y de esta manera deja a uno configurar el primer sector de cada partición (más info acá).

En mi caso necesitaba crear 4 particiones. Este es un ejemplo de particiones bien alineadas, el último comando es para mostrar el tamaño de cada partición nada más:

marcelo@marcelo:~$ sudo parted /dev/sdb unit s print
Modelo: ATA WDC WD15EARS-00S (scsi)
Disco /dev/sdb: 2930277168s
Tamaño de sector (lógico/físico): 512B/512B
Tabla de particiones. msdos
 
Numero  Inicio       Fin          Tamaño       Tipo     Sistema de ficheros  Banderas
 1      56s          41959679s    41959624s    primary  ext4
 2      41959680s    46161919s    4202240s     primary
 3      46161920s    1673570303s  1627408384s  primary  ext4
 4      1673570304s  2930265855s  1256695552s  primary                       raid
 
marcelo@marcelo:~$ sudo fdisk -lu /dev/sdb
 
Disco /dev/sdb: 1500.3 GB, 1500301910016 bytes
224 cabezas, 56 sectores/pista, 233599 cilindros, 2930277168 sectores en total
Unidades = sectores de 1 * 512 = 512 bytes
Tamaño de sector (lógico / físico): 512 bytes / 512 bytes
Tamaño E/S (mínimo/óptimo): 512 bytes / 512 bytes
Identificador de disco: 0x00094da1
 
Dispositivo Inicio    Comienzo      Fin      Bloques  Id  Sistema
/dev/sdb1   *          56    41959679    20979812   83  Linux
/dev/sdb2        41959680    46161919     2101120   82  Linux swap / Solaris
/dev/sdb3        46161920  1673570303   813704192   83  Linux
/dev/sdb4      1673570304  2930265855   628347776   fd  Linux raid autodetect
 
marcelo@marcelo:~$ sudo parted /dev/sdb print
Modelo: ATA WDC WD15EARS-00S (scsi)
Disco /dev/sdb: 1500GB
Tamaño de sector (lógico/físico): 512B/512B
Tabla de particiones. msdos
 
Numero  Inicio  Fin     Tamaño  Tipo     Sistema de ficheros  Banderas
 1      28,7kB  21,5GB  21,5GB  primary  ext4
 2      21,5GB  23,6GB  2152MB  primary
 3      23,6GB  857GB   833GB   primary  ext4
 4      857GB   1500GB  643GB   primary                       raid

Nuevamente: Lo más importante para que los clusters estén alineados con los sectores físicos del disco es que cada partición debe comenzar en un sector múltiplo de 8, como el 56, 41959680, 46161920 y 1673570304 de este caso.

Conclusión

Bueno, fue un artículo muy largo, donde me pareció que servía explayarse en el porqué de los sectores más grandes y qué problemas trae.  Tuve la grata oportunidad de intercambiar algunos mails al respecto con Aleksander Adamowski, la persona que en la lista de util-linux-ng “descubrió” el inconveniente de la lentitud con esta serie de discos WD a base de un lote de pruebas disponible aquí.

Aleksander me recomendó, en resumidas cuentas, al trabajar con discos > 1 TB “sospechosos” de tener sectores de 4 KB:

• “Las unidades de medida son críticas. Asegúrate que estás realmente operando a nivel de sectores***
• Después , hacer un test de performance es buena idea.
• Para esto, primero trata de crear una partición desalineada, crea un sistema de archivos, y ejecuta el benchmark de postmark usando el archivo de configuración que publiqué (http://olo.org.pl/files/hw/postmark-automated/postmark-quick.conf – por supuesto, modifica la opción “location” en ese archivo acorde al disco a comprobar.
• Luego, borra todas las particiones y haz lo mismo en una partición alineada. Los resultados deben ser mucho mejores en cuanto al rendimiento. Si no lo son, el disco probablemente tiene sectores físicos de 512 Bytes.”

En resumen, hay que estar atentos. Sería bueno que los futuros discos que salgan con sectores de 4 KB informaran al SO qué estructura real tienen, y eliminar el “modo compatibilidad” de una vez por todas.

Espero que les sirva.
Saludos

* En tiempos donde la capacidad de los discos era muy pequeña comparada con los de ahora, el tamaño de un cluster del sistema de archivos era igual al de un sector.

** La utilización del sector 63 corresponde a que generalmente (y por herencia histórica del modelo de direccionamiento CHS) es el primer sector del track número 1. El track 0 siempre se utilizó para el MBR / Master Boot Record.

*** Esto porque por defecto las herramientas de particionamiento Linux no trabajan con sectores; fdisk trabaja con cilindros por ejemplo.

Si andan buscando una placa Wireless PCI 802.11b/g que funcione perfectamente en Linux (y Ubuntu 8.04 para AMD64 para ser más precisos), la D-Link DWA-510 funciona perfectamente.

Esta es la caja en la que vino….

Abrí mi PC, enchufé la placa en un slot PCI libre, arranqué mi Ubuntu, y ya estaba la dichosa barra de calidad de señal. No tuve que instalar drivers ni nada!

Pude configurarle una conexión WPA2 sin problemas, así que si bien leí por ahí que en modo AP todavía no está soportado (tengo que corroborarlo), al menos como uso “normal”, sirve perfectamente. De más está decir que también soporta WAP, WEP y sin encriptación

Lo bueno es que el chipset que trae este D-Link es un RaLink RT2561, que está totalmente soportado por el fabricante, a tal punto que liberaron hace tiempo como GPL el código de los drivers (sin acuerdo NDA de por medio) y permiten la distribución (sin que se modifique) del firmware que los hace funcionar. Mejor aún es saber que estos drivers se encuentran en el núcleo oficial de Linux a partir del 2.6.24, por lo tanto, ya está en Ubuntu Hardy 8.04…

El módulo que lo hace funcionar es el ‘rt61pci’, y aparece en mi lspci así:

05:07.0 Network controller: RaLink RT2561/RT61 rev B 802.11g

Por otra parte, la placa me salió un poquitito arriba de los $100 en Galería Jardín (U$S 30 aprox.), con lo que si bien no es una “ganga”, es una marca reconocida, y funciona 10 puntos en Linux. Además, dudo que hubiera podido conseguir una placa de este tipo mucho más barata.

Además, al ser los drivers GPL, no me tengo que preocupar porque el fabricante cambie de dueño o de parecer, con lo que mi placa siempre va a funcionar (o siempre voy a tener la posibilidad de hacerla funcionar).

También sé que la versión “final” de Ubuntu Hardy 8.04 tenía algunos problemas que por suerte ya fueron solucionados mediante actualizaciones del kernel (específicamente la versión 2.6.24-17 que subieron al repositorio principal este último lunes 26).

Bueno, asi que ahora a disfrutar de la red sin cables…

Saludos!
Marcelo

Aprovechando ayer que tuve “libre” mi día, me puse a instalar los dos SOs BSDs libres que me interesan (aunque por motivos diferentes): OpenBSD 4.2 y FreeBSD 6.2 (para AMD64), cada uno adentro de una máquina virtual de VMWare.

Por si alguien no los conocía, estos sistemas operativos no solamente son “Unix-Like” (es decir, del tipo Unix) como Linux, sino que son Unix; quiero decir, que los BSD son “hijos” del árbol del Unix original, y conservan muy fuertemente sus raíces y filosofía. Además de eso, son Software Libre, están publicados con una licencia mucho menos restrictiva que la de Linux, y son gratis!

La instalación de ambos es MUY sencilla y sorprendentemente corta; no requiere conocimientos técnicos ni del SO muy profundos, aunque es bueno tener el navegador a mano para ir chusmeando en los manuales de instalación[1],[2] porque alguna duda siempre surge.

Además, aunque suma que no tuve que hacerme problema por particiones, al asignar todo el “disco” al SO, también hubiera sido sencilla igual, una vez que uno conoce que los BSDs manejan una “partición” Linux/Windows como un único “volumen” (en BSD se denominan “slices”), que adentro tienen varias “particiones”. De esa manera, uno siempre “ve” desde Linux/Windows una única partición en el disco. Acá se puede ver gráficamente el concepto[3]:

Eso sí, es todo el proceso se realiza modo texto y la de FreeBSD es más bien un “asistente”, me hizo recordar al viejo instalador de Debian (que se puede ver por ejemplo cuando uno instala un Ubuntu Alternate CD).

La documentación y soporte es abundante y excelente en FreeBSD: el Handbook multilenguaje (tiene una calidad impresionante) se combina con un extenso soporte comunitario, en varios lenguajes y y formatos, casos de uso, muchos sitios “extras” dedicados a brindar información; si bien esto es “común” en las distribuciones de Linux más grandes, es algo a destacar, ya que uno no está del todo perdido cuando necesita una mano, y es algo que agradezco cada vez que tengo un problema con el pingüino. El sitio oficial es muy cómodo, y nuevamente, multilenguaje.

En OpenBSD no tienen “handbook”: consideran a los “man” como documentación oficial, y además tienen un FAQ; más allá de esto, tienen listas de correo en unos cuantos lenguajes.

En cuanto a soporte de hardware, creo que por popularidad (y por tener algunos drivers desarrollados bajo NDA), FreeBSD tiene más soporte que OpenBSD (cuyo pilar fundamental es ser lo más libre posible). Aún así, estimo que ambos soportan menos hardware que Linux, aunque para el uso como servidor (mi objetivo) no debería ser un problema, ya que el déficit está por lo general en chips “baratos” usualmente en las PCs de escritorio.

Al utilizarlos (sólo por consola, no instalé X en ninguno), no necesité las vmware-tools, ya que la interfaz de red es detectada automáticamente como placa intel (interfaz ‘em0′). Sin embargo, es bueno destacar que si queremos aprovechar la totalidad de los dispositivos virtuales de vmware, en ambos se pueden instalar, ya que VMWare provee las vmware-tools para FreeBSD y éstas mismas se pueden instalar para OpenBSD (más info acá).

Instalar paquetes es muy sencillo y similar en ambos: los comandos pkg_* te ayudan para instalar los paquetes binarios de los repositorios. FreeBSD trae de “fábrica” el shell ‘sh’ y el OpenBSD trae el Korn Shell para root (‘sh’ para el resto), así que para instalar bash (más dependencias) fue tanto como ejecutar “pkg-add -r bash” en FreeBSD y “pkg-add bash” en OpenBSD (previo hacer un “export PKG_PATH=ftp…” para señalar nuestro repositorio).

También existen los ports, que es un mecanismo que descarga, compila e instala paquetes desde código fuente (siempre desde el repositorio del proyecto o alguno de sus mirrors), usualmente más actualizado que los paquetes binarios.

OpenBSD me interesa con el objetivo de ser Firewall, IDS, Proxy, etc., ya que me pareció muy minimalista, liviano, simple y tiene un claro objetivo de ser seguro. Como desventaja, tiene menos popularidad que su hermano FreeBSD, menos documentación y es algo más lento (ya que su objetivo es otro, ser seguro por defecto).

FreeBSD me da la impresión que es más bien un reemplazo de un servidor Linux (pero de servicios clásicos típicos Unix, como ser Mail, FTP, Web), ya que lo utiliza mucha más gente (una búsqueda por foros, enlaces, etc. da más importancia a FreeBSD) , y quizás por esto está bastante más elaborado que OpenBSD: da la impresión de ser menos “minimalista” y un poco más amigable.

Entre las ventajas de ambos con respecto a Linux es que son sistemas operativos completos, no un conjunto de utilidades que posteriormente son empaquetadas en un CD. Esto quiere decir que cada paquete o port que uno instala está revisado e integrado por la comunidad del proyecto.

Otra ventaja interesante que vale la pena destacar es que con ambos se puede utilizar PF (Packet Filter), que es un filtro de paquetes de red super-poderoso y sencillo de utilizar (al menos más sencillo que Netfilter, el que está incluído en Linux). De hecho, en FreeBSD hay 3 módulos para filtrado de paquetes, aunque PF es el más conocido (al menos por mí, je). Los comandos son parecidos (algunos) y la mayoría iguales a los de Linux.

Personalmente me encuentro cómodo con sus consolas, y es cierto, se sienten más “coherentes” o “prolijas” las cosas, la documentación es clara… aparte, hay detalles que están buenos: por ejemplo, al hacerle un escaneo nmap al FreeBSD, automáticamente hizo un ‘throttle’ de los RST que devolvía al host que escaneaba, aumentando el delay. Y eso sin usar PF. Groso. (aunque nmap se dió cuenta y prolongó el delay, pero bueno, son detalles que valen la pena).

La única duda que tengo es en cuanto a las actualizaciones, es decir, cuando sale una nueva release.. qué hago? (sin volver a instalar, claro está).

Como yapa, me encuentro que dentro de los “artículos” en español, está el de un conocido, la migración de argentina.com a FreeBSD.

Bueno, espero haber dado un pantallazo (con este calorrr) a estos SOs que siempre quise testear, sólo estuve un día y medio dando vueltas con ellos, así que no me “peguen” si le pifié u olvidé algo, comenten y en todo caso con más experiencia armo otro post más adelante.

Espero que pronto les pueda dar utilidad a alguno de los dos en alguna de mis actividades, ya que creo que en la heterogeneidad está la seguridad y el conocimiento, a fin y al cabo.

Feliz 2008 a todos!
Marcelo

Links:
[1]: FreeBSD Handbook:
Inglés: http://www.freebsd.org/doc/en/books/handbook/index.html (actualizado 2007)
Español: http://www.freebsd.org/doc/es/books/handbook/index.html (actualizado 2005)

[2]: OpenBSD FAQ:
http://www.openbsd.org/faq/index.html

[3]: http://www.freebsd.org/doc/en/books/handbook/disk-organization.html [...]

En fin… me enteré hace poquito que Adobe (muy silenciosamente) lanzó su versión 8.1 del “acroread”, es decir, del Adobe Reader para Solaris/Sparc y GNU/Linux/i386. Con este programa tenemos máxima compatibilidad al leer y trabajar con estos archivos.

Lo bueno:

• Anda rapidísimo, vuela comparado con la antigüa versión 7 (siempre sobre Linux); sigue utilizando GTK como toolkit gráfico.
• Eliminaron el modo MDI, que nunca fue soportado por GTK (o sea, lo habían metido “a la fuerza”), con lo cual la versión 7 era un hack horrible al laburar con varios documentos. Ahora está todo en SDI.
• Hay más comunicación con el equipo de desarrollo y el usuario: Adobe creó un blog sobre Acroread para Unix/Linux. Bien, al menos ahora hay una sección exclusiva para los que usamos otros SO.
• El software en general está muy mejorado, bonito, y muy usable (aunque para ser justos, tampoco estamos hablando de una aplicación compleja como un CAD). Diría que podría dejarlo como default para mi sistema.
• Proveen paquetes binarios para instalarlo muy fácilmente: .rpm, .deb y .tar.gz.

Lo Malo:

• Todavía está en inglés (y Francés, Alemán, Japonés… pero en Español, todavía no).
• Usando Compiz en Ubuntu 7.10, los efectos de transición a pantalla completa funcionan pero no del todo bien, y los deshabilité. Tiene algunos defectos gráficos muy pavos y pequeños, se ve que algunas cosas siguen siendo medio ‘hack’ sobre GTK para obtener máxima compatibilidad (será?).
• Me gustaría que se pudiera regular la cantidad de líneas que se baja al darle a la ruedita del mouse, se me hace que es poco.

Lo Feo:

• Sigue siendo código cerrado (por qué, Adobe? Qué ganan?). Eso sí, es gratuito.
• Por lo tanto, no viene en ninguna distribución Linux por defecto.
• Además, para hacerlo andar en mi arquitectura AMD64 (los binarios son para 386), tuve que bajar el .tar.gz y ejecutar el script INSTALL que viene adentro (después me avivé que estaba el .deb, pero siempre para i386, con lo cual habrá que hacer un ‘dpkg -i –force-architecture acroread_xxxx.deb’).
• Y por último, tuve el problemita de que me pedía la librería libgtkmozembed.so [2] (en forma opcional), para lo cual tuve que bajar el XulRunner de Mozilla para Linux 386 (enlace), descomprimirla en algún lado (yo elegí ‘/usr/local/xulrunner32/’) y decirle al Adobe Reader en sus preferencias que lo busque en esa ruta.

Otra Captura:

Comparando cómo renderiza el mismo documento cada uno (Poppler vs. Adobe), va desde algo mejor a mucho mejor el software de Adobe, tanto en calidad (el hinting de las fuentes es mejor), como en la aparición de algunos “artefactos” muy sutiles (por Poppler). Soy un neófito en cuando a teoría de fuentes, pero poniendo un documento a lado del otro, se nota.

Saludos!
Marcelo

[1] En una búsqueda (muy corta) no encontré algún documento que resumiera lo no implementado con respecto al último estándar por Poppler, la librería que interpreta los PDFs para Evince y Kpdf. Sin embargo, puedo afirmar que no implementa todas las características del estándar Pdf 1.7. Acá hay un resumen de la historia.
[2]: En las FAQ del Blog de Adobe está explicado qué es, para qué sirve y como se busca si no es detectado automáticamente. Aclaro de nuevo, es opcional; el programa funciona sin hacer esto, sólo sale un cartelito más o menos molesto diciendo lo que no encuentra.

Ahora, a lo que escribí (20/01/2007):

Cómo instalar Red Hat 6.2 en un VMWare

Dado que estoy haciendo un laburo teórico/práctico sobre seguridad, me interesaba instalar alguna distro vieja de Linux (como Red Hat 6.2), pero sobre una máquina virtual, como VMWare.

Los pasos que seguí fueron los siguientes:

- Quise instalar el Red Hat 5.2 en VMWare. Todo bien, pero en el mismo instalador, al querer instalar un paquete rpm, me daba errores porque no era de la misma arquitectura. Se ve que rpm validaba la arquitectura que tengo (VMWare le debe decir “x86_64″ y no hace match con “x86″), entonces no instalaba (tengo un Ubuntu 6.10 para AMD64). Es algo parecido a lo que pasa cuando querés instalar un .deb de ubuntu x86 en el Ubuntu de 64 bits y hay que pasarle “–force-architecture” al dpkg. La diferencia está en que no podía hacer que el instalador de RH 5.2 ignorara la arquitectura donde estaba corriendo.

- Cansado de querer instalar algún RH viejo en VMWare (había intentado con el 6.2 y el 7.0 antes), probé instalarlo sobre QEmu. Fue tanto como aptguetearlo, crear una imagen (con /usr/bin/qemu-img) ybootear (con /usr/bin/qemu directamente). Pero en vez de probar el Red Hat 5.2 (que es demasiado viejo ya), volví a probar con el Red Hat 6.2 (que tiene más o menos la antigüedad que quiero).

- El RH 6.2 instaló perfecto en el QEmu! (a diferencia de VMWare, que el instalador mostraba un bug… documentado para micros Pentium 4 en adelante).

- Una vez instalado en el QEmu, quería configurar la interfaz de red virtual, para poder acceder a internet y acceder al Ubuntu que lo está corriendo (para hacer pruebas); pero se complicó, ya que si bien al hacer un ifconfig veía la interfaz (Qemu simula tener una placa trivial NE2000), se me complicó porque para hacer andar la red con QEmu hay que simular una interfaz TUN (algo parecido a lo que hicimos con el OpenVPN), pero probé un ratito y como no anduvo, colgué el QEmu.

- Me acordé que el mismo programa de manajo de imágenes de disco (qemu-img) de QEmu soporta el formato de VMWare… así que convertí la imagen del RedHat 6.2 ya instalado en una imagen de disco de VMWare!!!

- Creé una nueva máquina virtual de VMWare y le puse como disco rígido la imagen convertida desde QEmu. Todo anduvo a la perfección; el Kudzu del RH 6.2, corriendo adentro del VMWare me reconoció el “nuevo” hardware (el hardware que emula QEmu es distinto al de VMWare) y listo el pollo. Tengo RedHat 6.2 en el VMWare!

- Hice ping, salgo a internet y todo joyita. Ahora queda hacerlo pelota.

Saludos
Marcelo
PD: Créditos a The Hackademy por el Tux hermoso de este post.

Disfruten!

Son los primeros de la serie 9xxx, los cuales permiten que en mi Edgy vuele de un plumazo a XGL con el fin de ejecutar Beryl… Ahora sólo ejecuto X.org 7.1.1 + Beryl.

Es decir, antes: X.org + XGL + Beryl. (Drivers Nvidia 8xxx)

Problema Principal: OpenGL, XVideo y otras extensiones que renderizaban directamente en la memoria de video (por decirlo sencillo, alguien que aclare acá!) no era directo, sí o sí pasaba por el server XGL.

Consecuencias: Lentitud en cualquier cosa que utilice esas operaciones, como ser juegos o reproductores de video. El smooth scrolling en firefox (ignoro por qué era lento antes).

Ventajas: Efectos 3D en el escritorio! Cubos girando, zoom, exposé y varias cosas bonitas.

Ahora: X.org 7 + Beryl. (Drivers Nvidia 9xxx). Al estar estos drivers preparados para soportar las operaciones de un window manager como Beryl directamente, no hace falta XGL, por lo tanto no hace falta un servidor X (XGL) que haga llamadas OpenGL a otro (X.org). Directamente Beryl hace llamadas a X.org.

Menos Componentes = Más velocidad. Y con más facilidades, como por ejemplo OpenGL renderizando con aceleración directa! (sin trucos, Doom 3 y Quake 4!)

Acá hay una captura de un momento glorioso: OpenGL + Composite + Beryl.

Sí, se comía la CPU (como pueden ver en el sensor de carga de CPU), pero era el glxgears, ya que probé el Tux Racer y el Super Tux (juegos que usan OpenGL) y apenas la CPU llegaba al 40% en los dos casos, corriendo Metacity y Beryl.

Instalación
Desde cero es algo largo, pero partiendo de una instalación de XGL + Beryl es relativamente simple (aunque depende de qué howto hayan seguido). Básicamente, fue:

1 – Bajar los nuevos drivers de NVidia. Usé estos repositorios, que preguntando al mantenedor me dijo que “me quede tranquilo”, que cuando Ubuntu actualice el kernel él iba a actualizar los paquetes.

2 – Probar que todo funcionara como antes (por las dudas). O sea, si quería podía seguir usando XGL.

3 – Cambiar la configuración de GDM para que no arranque el XGL, sino que cargue X.org. Sólo fue modificar el /etc/gdm/gdm.conf-custom (comentando las 3 líneas que había puesto, bah). Lo dejé como cuando vino del CD de instalación de Ubuntu. ;-D

4 – Agregar una opción al /etc/X11/xorg.conf (como se explica acá).

5 – Listo. Arrancar la sesión de mi usuario y probar…

Bueh, es todo lo que me acuerdo; estuve jugando bastante y el sistema está más liviando; aunque me gustaría que en la nueva versión de Beryl (0.1.2, yo todavía estoy corriendo 0.1.1), se corrijan varios errores muy visibles, y se optimice el funcionamiento en general (tiene algunos cuellos de botella todavía).

Taluego
Marcelo

Mi instalación de XGL+Compiz anduvo sin romperse, aunque no lo probé mucho porque el Compiz ese (de Quinnstorm, antes de convertirse en Beryl) era para Dapper… ya cambié el repo a Edgy y estoy usando Beryl 0.1.1 para Edgy. Tiene bastantes mejoras, aunque molesta un poco que tenga taaantas opciones yque siempre haya que estar configurando algo porque se actualizó/cambió. Ojo, son paquetes que están en puro desarrollo, así que si te gusta el durazno… bancate la pelusa.

Lo primero que hice fue levantar el Firefox 2.0 de 32 bits que tengo (tengo Ubuntu 64) ya que la preciosa gente de Adobe tarda siglos en portar a 64 bits su plugin de flash (y no, probé nspluginwrapper y me cuelga el Firefox). Me di cuenta que:

- El plugin “TabMixPlus” no funca en firefox 2. Un garrón, aunque encontré un post en este blog diciendo que están en proceso de sacar una actualización (recordemos que Firefox 2 hizo profundos cambios en el manejo de pestañas). Quise entrar a la home page y veo que se quedaron sin ancho de banda disponible!! que alguien le tire una moneda a ese pibe, esa extensión es imprescindible!!

- Quiero mi “Ubuntu Human Theme” para Firefox 2! (como tiene la versión de 64 bits). Claro, el paquete para integrar los íconos de Firefox 2 al skin de Ubuntu ahora viene incluído en los repositorios de Edgy… y no lo puedo instalar (lo busqué, eh!) como plugin .xpi para el Firefox de 32 bits. Por suerte, (así es el mundo Open Source, je) bajé el correspondiente archivo .deb, lo descomprimí y acá les dejo mi archivo comprimido para que extraigan en el directorio de ‘extensions’ de firefox 2 (calculo que sólo sirve para Ubuntu Edgy).

- Para volver el ícono del Thunderbird a la versión original, el script de este thread anduvo, pero ejecutándolo como “sudo bash /usr/local/bin/restore_mozilla_icons”.

Gracias a Beryl y los parches para que la transparencia de gnome-terminal sea “real” (sólo con X.org 7.1 y window managers que soporten Composite), tengo consola con fondo transparente de verdad!!

Otro problema (bastante importante) fue que las fuentes en Firefox, Gnome-terminal y OpenOffice se veían HORRIBLES. Encontré este thread, que me hizo reemplazar el archivo .fonts.conf de mi home por este:

<?xml version="1.0"?>
<!DOCTYPE fontconfig SYSTEM "fonts.dtd">
<fontconfig>
<match target="font" >
<edit mode="assign" name="rgba" >
<const>rgb</const>
</edit>
</match>
<match target="font" >
<edit mode="assign" name="hinting" >
<bool>true</bool>
</edit>
</match>
<match target="font" >
<edit mode="assign" name="hintstyle" >
<const>hintfull</const>
</edit>
</match>
<match target="font" >
<edit mode="assign" name="antialias" >
<bool>true</bool>
</edit>
</match>
</fontconfig>

Y santo remedio!
Evidentemente, hay problemas con Firefox y su manejo de fonts en linux… :-S

Otro “bugcito”: tengo el problema (según este post somos varios) que nos muestra el splash de arranque en gris (?)

Por ahora, nada más. A medida que vaya encontrando problemitas, voy a ir publicando cómo los fui resolviendo. Por ahora, el balance general es bueno. El sistema vuela, es bastante estable (aún con XGL+Beryl instalado), y sí, es de saber que la actualización desde los repositorios tiende a tener este tipo de “glitches”… pero nada grave en mi opinión.

Las nuevas versiones de las aplicaciones, el arranque un poco más rápido (aunque todavía no creo que se le esté sacando el jugo a este esquema, es muy nuevo), etc. hacen que la actualización valga la pena largamente.

Saludos!
Marcelo

Actualización: También soy víctima de este pequeño “bugcicicicito”:

Demasiado visible como para que saquen Edgy con este bug, no? :-S
En mi opinión esto (y comentarios que ví en varios lados) remarca que Edgy no es una distro LTS; o sea, es un poco más ‘experimental’ y para gente que quiere algo con algunos bugs pero con software más actualizado.

- Para poder instalarlo es necesario aprox. 8GB de disco (muuuy aproximadamente )

- Tuve el siguiente mensaje en la parte de particionamiento de la instalación: “Unable to find a system volume that meets its criteria for installation”. Busqué un poco en el gran oráculo (el de los anteojos) y me dijo que tenía que setear la partición donde iba a instalar Vista como activa (con alguna herramienta como el GParted, por ejemplo). Lo hice y no anduvo, tuve de nuevo ese mensaje super-explicativo….

Como para probar como última vez, tuve que “sacar” mi disco IDE (donde tengo instalado el OSX), dejando conectado el disco SATA. No lo saqué físicamente, le puse “None” en el BIOS. Vista me lo seguía mostrando a pesar de haberlo desactivado en el BIOS (al parecer descubre los dispositivos como Linux, no pasando por la BIOS), pero esta vez no tuve el bendito error, el proceso de instalación continuó.

- El resto fue bastante sencillo. Me detectó todo menos el sonido (una SB 5.1). Apenas arrancó, tuve que configurar la red. En mi opinión, tarde mucho en encontrar el cuadro de diálogo para poner la IP/Default Gateway/DNS de la placa de red ethernet. Como que hay muchos asistentes y formas de configurar la red… quizás todavía no me acostumbro a la nueva organización del Control Panel.

Me meto en Network and Internet -> Network and Sharing Center:

Hice click un poco acá y allá… pero no encontré cómo setearle la IP con esta nueva interfaz. Por suerte para los viejitos como yo está la “vista clásica”.

- Después de eso, Windows Update se ejecutó solito y me instaló unos drivers… entre ellos, el de mi placa de sonido. Sin haber reiniciado, los parlantes ya hacían ruido.

- Probé el IE7 y ví cómo alguno que otro sitio que construimos con los chicos estaba roto. También vi el efecto de flicker, con un menú en Javascript, que se eliminó al instalar los drivers de Nvidia para Vista.

- Instalé la JRE. Al cerrar el item respectivo en el panel de control, veo este cuadro de diálogo:

Y esto?? Mucho no me gusta, me parece excesivo… entre esto, y la pregunta a cada cosa que quiero ejecutar que me pide permiso (UAC – User Account Control)… uno siempre le termina dando “Aceptar”… como que se pierde la utilidad de la “seguridad mejorada” de Vista.

- Las tildes en la configuración en español están al lado de la “p” en vez de al lado de la “ñ”, como en XP.

- Muy buena la Sidebar y los gadgets. Ignoro si se escriben en algún lenguaje tipo AppleScript o Python (“fácil”, a eso me refiero).

- La única aplicación para editar una foto es el Paint. Y lo peor es que no cambió nada! Si pego una imagen menor al tamaño de la imagen “blanca” que está por defecto cuando uno abre el programa, lo blanco queda… es decir, uno no puede elegir “Paste as new Image” siquiera… (Gimp, te extrañooooo….)

- Visualmente, está muuuuy bueno… aunque le falta algo más de “vida”, cosa que sí tiene Compiz…. este desktop, como un todo, tiene mejor integración (quizás por el hecho que Compiz todavía está en un profundo e intensivo desarrollo).

Bueh, en resumen, más allá de los cambios visuales… en un primer approach no hay nada nuevo-nuevo… es decir, las aplicaciones son casi las mismas, no hay ninguna funcionalidad “revolucionaria”. Como en los últimos años, la computación está avanzando de a poco en el desktop, y esta versión (RC1, guarda) de Windows Vista parece reflejar esta tendencia. “Polish and Logical Evolution” lo titularía.

(Bah… es pura facha!!)

Después les sigo contando.

Salutes
Marcelo