Lo hice y lo entendí » Hardware

Recuperando los datos de los discos de un fakeRAID

Vicente Navarro — Thu, 06 Oct 2011 18:23:22 +0000

Mi viejo ordenador de sobremesa que no me había fallado nunca desde el 2005 murió hace un par de días. Creo que es la fuente de alimentación, aunque al abrirlo también he descubierto que uno de los anclajes de plástico de la placa base en los que se ancla el ventilador también se había roto y el ventilador no estaba bien sujeto. Sea como sea, he decidido no intentar arreglarlo. Uno ya no tiene tiempo para según que cosas como antes…

Lo único que quedaba era recuperar los datos del sistema. Intentar recuperar los datos de unos discos duros sin daños no sería ningún notición (los conectas a otro ordenador o los pones en una carcasa de disco USB y ya está) si no fuera porque dos de los tres discos duros del sistema estaban en fakeRAID, con RAID 0, tal como conté en Instalar Ubuntu 8.04 Hardy Heron sobre un fakeRAID.

Cuando monté el ordenador y compré aquellos dos flamantes Maxtor SATA de 200GB ya con la idea de ponerlos en RAID 0, la idea parecía muy buena, sobre todo para alguien como yo que sólo tenía los benchmarks en mente. El rendimiento de los discos en RAID 0 era brutal. Pero claro, mantener un fakeRAID tiene muchas complicaciones: Cuesta más instalar Windows (Integrar drivers de SATA/RAID en un CD de instalación de Windows XP), cuesta más instalar Linux (Instalar Ubuntu 8.04 Hardy Heron sobre un fakeRAID), te toca andar personalizando los initrd (Hibernación en Linux con TuxOnIce. Notas sobre los initrd y sobre cpio.)… Y por supuesto, que estás corriendo muchos más riesgo de pérdida de datos.

Pero eso sí, el rendimiento era mucho mejor, así que valía la pena… ¿De verdad? Bueno, al principio sí era llamativo (recuerdo que en el SiSoft Sandra batía récords) pero unos pocos años más tarde añadí al sistema un Seagate de 750GB y bueno, resulta que él sólo ya tenía mejor tasa de transferencia que los dos Maxtor de 200GB en RAID 0.

En cualquier caso, estando obsesionado con que si algún día le pasaba algo a uno de los discos lo perdería todo, he sido muy formal haciendo mis backups semanales y aunque no hubiera intentado recuperar el contenido de los discos, los muy pocos cambios de los días previos no hubieran sido ninguna gran pérdida.

Pero bueno, había que intentarlo. Había llegado el momento: Tenía dos discos Maxtor de 200GB en las manos que habían estado en un fakeRAID de una controladora NVIDIA NForce 4 y el reto era ver si sería posible acceder a su contenido. Durante muchos años me había preguntado si se podría hacer. Mi duda principalmente era: ¿Es necesaria la controladora para que poniendo los discos en otro ordenador un Linux pueda entender a los datos del fakeRAID?

Y afortunadamente, la respuesta ha sido que no.

Puse los dos discos en sendas bases convertidoras de SATA a USB, una de ellas una Sharkoon como ésta (a la que se le rompió la tapa, los discos duros ya no se sujetaban bien, y tuve que retirarla y comprar la otra de marca Zaapa):

y tras conectar las bases a un portátil con Linux y al ejecutar el bendito dmraid, el resultado no pudo ser mejor:

# dmraid -ay -v -v -v 
WARN: locking /var/lock/dmraid/.lock
NOTICE: skipping removable device /dev/sdb
NOTICE: /dev/sdd: asr     discovering
NOTICE: /dev/sdd: ddf1    discovering
NOTICE: /dev/sdd: hpt37x  discovering
NOTICE: /dev/sdd: hpt45x  discovering
NOTICE: /dev/sdd: isw     discovering
NOTICE: /dev/sdd: jmicron discovering
NOTICE: /dev/sdd: lsi     discovering
NOTICE: /dev/sdd: nvidia  discovering
NOTICE: /dev/sdd: nvidia metadata discovered
NOTICE: /dev/sdd: pdc     discovering
NOTICE: /dev/sdd: sil     discovering
NOTICE: /dev/sdd: via     discovering
NOTICE: /dev/sdc: asr     discovering
NOTICE: /dev/sdc: ddf1    discovering
NOTICE: /dev/sdc: hpt37x  discovering
NOTICE: /dev/sdc: hpt45x  discovering
NOTICE: /dev/sdc: isw     discovering
NOTICE: /dev/sdc: jmicron discovering
NOTICE: /dev/sdc: lsi     discovering
NOTICE: /dev/sdc: nvidia  discovering
NOTICE: /dev/sdc: nvidia metadata discovered
NOTICE: /dev/sdc: pdc     discovering
NOTICE: /dev/sdc: sil     discovering
NOTICE: /dev/sdc: via     discovering
NOTICE: /dev/sda: asr     discovering
NOTICE: /dev/sda: ddf1    discovering
NOTICE: /dev/sda: hpt37x  discovering
NOTICE: /dev/sda: hpt45x  discovering
NOTICE: /dev/sda: isw     discovering
NOTICE: /dev/sda: jmicron discovering
NOTICE: /dev/sda: lsi     discovering
NOTICE: /dev/sda: nvidia  discovering
NOTICE: /dev/sda: pdc     discovering
NOTICE: /dev/sda: sil     discovering
NOTICE: /dev/sda: via     discovering
NOTICE: added /dev/sdd to RAID set "nvidia_bdehcbaa"
NOTICE: added /dev/sdc to RAID set "nvidia_bdehcbaa"
RAID set "nvidia_bdehcbaa" already active
INFO: Activating stripe raid set "nvidia_bdehcbaa"
NOTICE: discovering partitions on "nvidia_bdehcbaa"
NOTICE: /dev/mapper/nvidia_bdehcbaa: dos     discovering
NOTICE: /dev/mapper/nvidia_bdehcbaa: dos metadata discovered
NOTICE: created partitioned RAID set(s) for /dev/mapper/nvidia_bdehcbaa
RAID set "nvidia_bdehcbaa1" already active
INFO: Activating partition raid set "nvidia_bdehcbaa1"
RAID set "nvidia_bdehcbaa2" already active
INFO: Activating partition raid set "nvidia_bdehcbaa2"
RAID set "nvidia_bdehcbaa3" already active
INFO: Activating partition raid set "nvidia_bdehcbaa3"
RAID set "nvidia_bdehcbaa5" already active
INFO: Activating partition raid set "nvidia_bdehcbaa5"
RAID set "nvidia_bdehcbaa6" already active
INFO: Activating partition raid set "nvidia_bdehcbaa6"
WARN: unlocking /var/lock/dmraid/.lock

Vemos que el dmraid revisa todos los discos para ver si encuentra metadatos de una de las controladoras fakeRAID que soporta. En este caso, encuentra metadatos de una controladora NForce (“nvidia metadata discovered“) en los discos /dev/sdc y /dev/sdd y así, es capaz de descubrir las particiones que podemos montar sin problemas y recuperar los datos.

Por tanto, la lección que he aprendido esta semana es que la controladora fakeRAID realmente no aporta nada más que el soporte en la BIOS para poder arrancar de los discos en RAID, pero ciertamente, todo el resto del trabajo lo hace la CPU y el sistema operativo. Y de hecho, por eso es un fakeRAID, porque la controladora realmente no hace que la existencia de un RAID sea transparente para el sistema operativo. Como nota curiosa, en el sistema también tenía MS-DOS, y el MS-DOS no necesitaba un driver especial para poder estar instalado en un sistema con fakeRAID como sí necesitan Windows y Linux, por lo que parecería que el RAID sí era transparente para MS-DOS, pero porque en realidad MS-DOS usa llamadas a la BIOS para acceder al disco y era en este caso la BIOS la que hacía el trabajo extra.

:wq

Lo hice y lo entendí © Vicente Navarro 2011 con una licencia CC BY-SA | 7 comentarios
Etiquetas: dmraid, GNU/Linux, Hardware, RAID, SATA, Windows

Entradas relacionadas

Feed enhanced by Better Feed from Ozh

Comentarios sobre la Playstation 3 como reproductor multimedia para una televisión de tubo y sobre GNU/Linux en la Playstation 3

Vicente Navarro — Mon, 26 Oct 2009 09:28:11 +0000

Hace unas semanas estuve buscando un disco duro multimedia con toma de LAN para reemplazar mi vetusto reproductor de DVD (y DivX, Xvid, etc.) que ha satisfecho todas mis necesidades desde hace más de 5 años hasta que me he cansado de ir grabando todo lo que quería ver en DVDs.

En Sobre las VIA EPIA (II): Mi ordenador basado en una SP8000E mostré el sistema basado en una VIA EPIA que monté como teórica solución para todo: Reproductor multimedia, decodificador/grabador de TDT, servidor doméstico, punto de acceso a Internet desde el salón, etc.

Sin embargo, más de dos años después, veo que como servidor doméstico y como punto de acceso a Internet lo he usado muchísimo. Como decodificador/grabador de TDT lo he usado muy poco, pero sólo porque realmente no veo la TDT ni siento necesidad de grabar nada de ella. Y como reproductor multimedia también muy poco, sólo para formatos raros que no funcionaban en el reproductor de DVD. La razón es sencillamente que la calidad de su salida S-Video es muy inferior a la de la señal RGB del SCART de cualquier reproductor de DVDs.

Ya comenté algo sobre las señales que transporta el Euroconector/SCART y la importante mejora de calidad de la señal RGB en ¿Por qué obtenemos una imagen en blanco y negro al usar un adaptador de S-Video a Euroconector?, pero conviene recalcarlo, puesto que mucha gente no sabe que el Euroconector soporta transmitir dos tipos de señales de vídeo, S-Video y RGB, siendo el segundo tipo muy superior al primero en nitidez y calidad de los colores. En la mayoría de reproductores de DVD podemos elegir (como se veía en la entrada sugerida) si el Euroconector debe enviar señal RGB o señal YUV (la que se usa en S-Video y en el vídeo compuesto). Sin embargo, no todos los televisores aceptan la señal RGB. Incluso en televisores que la aceptan, puede que sólo lo hagan en algunos de los Euroconectores (en televisores Sony marcados con 3 puntitos).

Por eso, un HTPC silencioso, de bajo consumo y con una caja adecuada (como los que configura el Tendero Digital) será, en la mayoría de los casos, la solución ideal para el salón siempre y cuando el televisor sea una pantalla plana con conectores VGA, HDMI o DVI. Pero en el caso de seguir usando una televisión de tubo, como es mi caso (y sin ánimo de cambiarla de momento, que ya expresé en La resolución 1366×768 mi preferencia por las pantallas de tubo para contenidos de definición estándar), no hay ningún PC (o al menos no es fácil de encontrar) con salida SCART/RGB que envíe señal de definición estándar y de alta calidad al televisor.

Por tanto, era imprescindible que el disco multimedia tuviera Euroconector con capacidad de enviar señal RGB. Esto no resulta tan fácil, puesto que muchos de los discos actuales te permiten conectarlos a un televisor usando un cable de Euroconector pero sólo a través de la salida de vídeo compuesto y usando un adaptador:

Otros discos sí que llevan Euroconector pero no indican ni en la caja ni en la documentación si éste es capaz de enviar señal RGB, que no todos lo hacen. Finalmente, otros sí que lo especifican claramente, a veces incluso en la caja y otras veces sólo en las especificaciones.

Tras una intensa búsqueda, estos modelos con LAN y SCART/RGB me parecieron interesantes:

Woxter i-Cube X-Div 35 XP Rec, que no soporta MKV. El modelo que sí lo soporta es el Woxter i-Cube 750 MKV, pero en éste el Euroconector no parece que pueda sacar señal RGB, o al menos el manual no lo menciona.
Storex AivX-385HDRW, que soporta MKV usando un PC con Windows como servidor de transcodificación.
o2media HMR-600W, con TDT.

Pero luego en los foros todos tenían sus pegas: que si tarda mucho en abrir los directorios, que si no se puede copiar de la red y reproducir al mismo tiempo, que si a veces se cuelga, que si se calienta…

Hasta que leyendo referencias en algún foro encontré que alguien decía algo así como: ¿Pero para qué queréis un disco duro multimedia existiendo la Playstation 3? Indagué un poco la nueva pista y descubrí que la Playstation 3 parecía ser una opción mucho mejor que cualquier disco duro multimedia. Sobre todo, porque tras el reciente anuncio (18 de Agosto) de la Playstation 3 Slim (con 120GB o 250GB de disco), que ha salido al precio de 299€, el modelo anterior de 80GB se encuentra en tiendas hasta por 259€. Viendo que ninguno de los discos multimedia mencionados anteriormente baja de unos 240€, es cuando empezamos a ver la conveniencia de una PS3. Y cuando te enteras de que la nueva PS3 Slim no permite la instalación de Linux como todos los modelos anteriores es cuando te planteas definitivamente si no es el momento ideal de hacerte con una PS3 de 80GB de las que permite instalar Linux antes de que desaparezcan de las estanterías de las tiendas.

Pero comparar la PS3 con un disco duro multimedia no es comparar peras con peras y manzanas con manzanas, ya que no son exactamente el mismo producto:

El disco interno de la PS3 (80GB) es mucho más pequeño que el de los discos duros multimedia (500GB, 1TB, 1.5TB)
La PS3 no se puede mover y transportar tan fácilmente como un disco duro multimedia
La PS3 tiene lector de Blu-Ray, por lo que podemos leer DVDs y CDs también
La PS3 también nos sirve para jugar y si instalamos Linux sus posibilidades se multiplican
La PS3 no se puede usar simplemente como disco duro externo USB de gran capacidad

Sin embargo, si sólo buscas un reproductor multimedia con disco integrado para el salón con SCART/RGB y red, como es mi caso, la PS3 parece una mucho mejor opción, así que acabé por comprar una Playstation clásica de 80GB.

Y tras unas semanas de uso, éstas son las peculiaridades que me parece interesante comentar de la PS3 como reproductor multimedia:

(...)

Leer el resto de Comentarios sobre la Playstation 3 como reproductor multimedia para una televisión de tubo y sobre GNU/Linux en la Playstation 3 (5,326 palabras)

Lo hice y lo entendí © Vicente Navarro 2009 con una licencia CC BY-SA | 29 comentarios
Etiquetas: FAT, GNU/Linux, MKV, Playstation 3, S-Video, SCART, Televisión

Entradas relacionadas

Feed enhanced by Better Feed from Ozh

Ciertas versiones de Java pueden provocar pantallazos azules en la librería nv4_disp.dll del driver de NVidia

Vicente Navarro — Mon, 19 Jan 2009 21:44:07 +0000

Hace pocos días que tengo mi nueva NVidia GeForce 9800GT, así que no había tenido ocasión de verlo antes, pero ayer fui a abrir el diálogo de configuración de Java JRE en Windows XP e inmediatamente tuve un buen pantallazo azul en la librería nv4_disp.dll del driver de NVidia. La versión del driver es la ultimísima, la 181.20, instalada muy pocos días antes.

De momento no caí en que podría tener que ver con algo de Java, así que me sorprendió mucho y ya pensé: “Ya la hemos liado, o el driver está mal o la la tarjeta tiene algún defecto hardware.”

Sin embargo, mientras reiniciaba el sistema pensé en que lo último que había hecho había sido intentar abrir la configuración de Java. Así que volví a hacerlo y… ¡pum! otro pantallazo azul. Volví a entrar, y probé con alguna web que tuviera applets Java y, de nuevo, BSOD.

Decidí desinstalar el Java JRE para evitar problemas. Era una versión muy vieja, la 1.4.2_09, de cuando instalé ese Windows XP por primera vez, ya que apenas uso Java en Windows en este sistema. Así que fui al panel de Agregar/Quitar programas y comencé la desinstalación. Pocos segundos después, nuevo pantallazo.

- Claro -pensé-, la desinstalación ha lanzado alguna aplicación Java para hacer alguna tarea y ha vuelto a ocurrir.

De modo que tras el n-ésimo reinicio, eliminé los archivos java.exe y javaw.exe del directorio de instalación de Java y, esta vez sí, mutilada la JRE e incapaz de ejecutar ningún código Java, pude completar la desinstalación.

Posteriormente descargué la última versión existente del JRE, la 1.6.0_11, la instalé, y comprobé que podía usarla ejecutando applets en diferentes páginas sin ningún problema.

Por tanto, ciertos pantallazos azules en la librería del driver de NVidia nv4_disp.dll pueden venir causados por una versión antigua de Java. Es algo a tener muy en cuenta porque podríamos tener una aplicación Java que arrancara desde el principio y nos causara una y otra vez pantallazos azules. Se me ocurre como ejemplo el cliente de BitTorrent Azureus.

Investigando un poco más, he encontrado que no soy el precisamente el primero que ha encontrado una correlación entre pantallazos azules del driver de NVidia y aplicaciones Java:

:wq

Lo hice y lo entendí © Vicente Navarro 2009 con una licencia CC BY-SA | Un comentario
Etiquetas: drivers, Hardware, Java, NVidia, Windows

Entradas relacionadas

Feed enhanced by Better Feed from Ozh

Aceleración por hardware de vídeo de alta definición H.264 en Linux con los nuevos drivers 180.x de NVidia

Vicente Navarro — Thu, 15 Jan 2009 21:53:49 +0000

Se ve que este año me he portado muy bien, porque los Reyes Magos me han traído una nueva tarjeta gráfica NVidia GeForce 9800GT con 512MiB de DDR3 para sustituir a mi ya vetusta NVidia GeForce 6600 de 256MiB. La verdad es que no juego mucho, pero de vez en cuando echo alguna canita al aire. ¡Esperemos que esto no tenga consecuencias catastróficas en lo que concierne a mi productividad en el blog!

Uno de los temas que más ganas tenía de probar son las recientemente estrenadas capacidades de aceleración de vídeo de alta definición en H.264 en Linux usando los últimos drivers cerrados de NVidia (versión > 180.x), algo que descubrí recientemente que por fin era posible:

Recordemos que en Windows, la aceleración del vídeo por hardware se hace mediante la API de DXVA, y que en Linux teníamos la API XvMC. Sin embargo la XvMC es bastante limitada y, hasta el momento, los fabricantes (NVidia, ATI/AMD, Intel, VIA) sólo han desarrollado soporte para acelerar MPEG2, aunque esta API también podría ayudar con el vídeo comprimido con MPEG4. En la entrada: Sobre las VIA EPIA (VI): Gráficos y vídeo acelerado por HW en Linux con la EX10000EG, ya estuvimos viendo con los resultados de pruebas reales los grandes beneficios que, con una CPU tan modesta como las VIA conseguíamos usando la aceleración de la GPU.

Pero en realidad, fuera de esos casos tan concretos como el de los procesadores VIA, a nadie le preocupaba en los últimos años la aceleración de vídeo por hardware. Cualquier ordenador reciente era totalmente capaz de mover cualquier vídeo de resolución estándar comprimido en MPEG2 o MPEG4 sin ningún problema. Pero, ¡ay!… llegó la alta definición y yo, con mi Athlon 64 X2 4600+, ya no era capaz de mover una película a resolución 1080p Full HD sin dar saltos de vez en cuando.

Pero gracias a los Reyes Magos y a la tecnología NVidia PureVideo, de nuevo voy a poder disfrutar de la alta definición sin traumas para mi CPU.

Sin embargo, es lamentable que los tres grandes fabricantes no se hayan puesto de acuerdo en una API común, como lo era el XvMC o lo es el DXVA de Windows. La nueva API de NVidia que permite la aceleración de vídeo de alta definición es la VDPAU (Video Decode and Presentation API for Unix) (Phoronix: XvMC To Support More Video Standards?, Phoronix: Mplayer, FFmpeg Gain VA-API Support); la especificación de AMD/ATI es la XvBA (X-Video Bitstream Acceleration) (Phoronix: AMD’s X-Video Bitstream Acceleration); y finalmente, la de Intel es la VaAPI (Video Acceleration API). Una vez más, cada fabricante tirando para su lado y los perjudicados, los usuarios y, sobre todo, Linux, que no va a poder contar con una API unificada frente a lo que ocurre en Windows.

En cualquier caso, veamos cómo conseguir esta aceleración en una Ubuntu 8.10.

(...)

Leer el resto de Aceleración por hardware de vídeo de alta definición H.264 en Linux con los nuevos drivers 180.x de NVidia (1,581 palabras)

Lo hice y lo entendí © Vicente Navarro 2009 con una licencia CC BY-SA | 35 comentarios
Etiquetas: drivers, GNU/Linux, H.264, Hardware, NVidia, Ubuntu, VDPAU, XvMC

Entradas relacionadas

Feed enhanced by Better Feed from Ozh

Midiendo el ancho de banda de red con IPerf (y con scp, netcat, wget)

Vicente Navarro — Sat, 13 Dec 2008 11:11:37 +0000

No sé qué le pasa últimamente a mi router Zyxel 660HW en su función de switch de red para conectar los diferentes ordenadores de casa. Mientras que el ancho de banda de red que debería de permitir para la comunicación entre los ordenadores debería de ser cercano a los teóricos 100 Mbps, hay veces que no hace falta esforzarse mucho para ver que realmente es muy inferior, hasta llegar a ver cosas como esta usando Samba entre un sistema con Ubuntu y otro con Debian:

Sin saber realmente por qué me está ocurriendo esto, este problema me sirve para hablar del IPerf, una pequeña utilidad que nos sirve para medir el ancho de banda efectivo entre dos sistemas de la red usando TCP o UDP. Como está disponible para Windows, y para los diferentes sistemas UNIX (en Debian y Ubuntu existe un paquete en la distribución estándar), podemos usarla entre dos nodos cualquiera conectados a una red para ver el ancho de banda real que, tras quitar las cabeceras y los retardos que introducen los dispositivos de red intermedios, nos queda.

En un extremo la ejecutaremos en modo servidor, con la opción -s:

debian $ iperf -s
------------------------------------------------------------
Server listening on TCP port 5001
TCP window size: 85.3 KByte (default)
------------------------------------------------------------
[  4] local 192.168.1.2 port 5001 connected with 192.168.1.3 port 53490
[  4]  0.0-10.3 sec    116 MBytes  94.1 Mbits/sec

En el otro extremo, en modo cliente, con la opción -c. Por defecto, ambos extremos usan el puerto 5001:

ubuntu $ iperf -c debian
------------------------------------------------------------
Client connecting to debian, TCP port 5001
TCP window size: 16.0 KByte (default)
------------------------------------------------------------
[  3] local 192.168.1.3 port 53490 connected with 192.168.1.2 port 5001
[ ID] Interval       Transfer     Bandwidth
[  3]  0.0-10.1 sec    116 MBytes  96.3 Mbits/sec

Vemos que, de una red de 100 Mbps salen 94-96 Mbps. No está mal.

(...)

Leer el resto de Midiendo el ancho de banda de red con IPerf (y con scp, netcat, wget) (719 palabras)

Lo hice y lo entendí © Vicente Navarro 2008 con una licencia CC BY-SA | 14 comentarios
Etiquetas: dd, Debian, GNU/Linux, netcat, OpenSSH, pv, Redes, Ubuntu, wget, Windows, Zyxel 660HW

Entradas relacionadas

Feed enhanced by Better Feed from Ozh

¿Tendremos algún día un driver abierto de VIA completo?

Vicente Navarro — Wed, 17 Sep 2008 19:56:42 +0000

Los habituales de este pequeño rincón de Internet seguro que ya conocen la importancia de comprar hardware con drivers abiertos.

Así, a menudo he tratado de divulgar el problema que existe con los drivers para los chipsets gráficos de VIA, tanto aquí:

como en Barrapunto:

Y es que existe una necesidad de que VIA facilite (creándolo directamente o ofreciendo la documentación adecuada) un driver abierto y de buena calidad para Linux. Es algo que nos beneficia mucho a nosotros, los usuarios, pero aún más a la propia VIA. ¿Alguien piensa que los modestos procesadores y chipsets de VIA pueden tener algún futuro con un Windows Vista que va a pedales en sistemas de última generación? Evidentemente, no. Su nicho de mercado estrella es el de sistemas enfocados a ser usados con aplicaciones de Internet de bajo consumo, como es el caso de los miniportátiles o nettops.

VIA necesita que su hardware funcione bien en Linux más incluso que nosotros los usuarios. Pensemos en cuáles son los miniportátiles más conocidos que hay en el mercado en el momento de escribir estas líneas: Está el Asus EEE, con procesador de Intel (Celeron o Atom), el Acer Aspire One, también con Intel Atom y el HP Mini Note 2133, el único con hardware de VIA. Todos ellos ofrecen la opción de usar Linux en ellos, como no podía ser de otra forma si queremos hacer un uso eficiente de nuestro “débil” hardware. ¿Es posible que VIA rasque algo en este mercado sin sacar drivers decentes?

Cuando en Enero promovimos la petición online para que VIA creara o facilitara drivers decentes, yo creo sinceramente que sí que conseguimos algo: no que VIA por fin diera su brazo a torcer y lo que antes era un no rotundo pasara a ser un si en letras gigantes. Nuestro logro fue, posiblemente, conseguir que esos directivos de VIA encorbatados y que probablemente nunca habían visto otra cosa que no fuera Windows se dieran cuenta de que algo iba realmente mal en su colaboración con la comunidad de Linux que tan necesaria les iba a resultar en los próximos meses.

Colaborar con la comunidad de software libre no es exactamente lo que ha hecho VIA de crear el sitio http://linux.via.com.tw/ y decir: ¡Ea! ¡Ahí tenéis los drivers que queríais! ¡Pesados! No, eso ya lo teníamos peor o mejor en viaarena.com. Colaborar con la comunidad es enviar parches a los desarrolladores del kernel, mantenerlos, colaborar con los chicos de openChrome para mejorar lo existente, o al menos crear documentación útil. En cualquier caso, podemos consolarnos con que menos es nada.

Cuando en Julio VIA anunció el fichaje de Harald Welte muchos pudimos hacernos ilusiones de que el panorama podía cambiar y que podríamos encontrarnos con una colaboración honesta con la comunidad.

Sin embargo, pese a la aparente voluntad de VIA de cambiar las cosas con este movimiento, parece que nos vamos a encontrar con un escollo mucho más grande que ha estado persiguiendo al software abierto desde hace años: las patentes.

(...)

Leer el resto de ¿Tendremos algún día un driver abierto de VIA completo? (1,533 palabras)

Lo hice y lo entendí © Vicente Navarro 2008 con una licencia CC BY-SA | 5 comentarios
Etiquetas: drivers, drivers abiertos, GNU/Linux, openChrome, VIA, VIA EPIA

Entradas relacionadas

Feed enhanced by Better Feed from Ozh

La odisea de ampliar la memoria a 4 GiB

Vicente Navarro — Mon, 14 Jul 2008 20:19:30 +0000

Mi ordenador principal, que acaba de cumplir 4 años, lleva una placa Asus A8N-SLI Deluxe (socket 939, chipset NForce4 SLI), un AMD Athlon64 X2 4600+ (era 3500+ y lo actualicé), una GForce 6600 de 256 MiB y 2 GiB de RAM Kingston DDR400 PC3200 CL3. Es el mismo ordenador con dos discos en RAID 0 al que le instalé Ubuntu Hardy Heron en Abril.

Pues bien, la semana pasada le compré otros dos módulos Kingston de 1 GiB exactamente iguales que los originales para ampliar la memoria a un total de 4 GiB. La memoria es de una marca y modelo oficialmente soportados por esta placa base.

Yo ya sabía que algo que en teoría debería de ser pinchar & listo (plug & play) a menudo causa problemas, ya que, ¿cuántas veces no nos hemos encontrado con memorias de las que la placa sólo reconocía la mitad? ¿o que colgaban el ordenador a la primera de cambio? ¿o que nos obligaba a bajar la velocidad del bus o los parámetros de memoria en los parámetros de la BIOS? En este caso, no ha sido menos, ya que la dichosa ampliación de memoria me ha tenido un buen número de horas en vilo de saber si algún día podría usar esos 4 GiB de RAM en mi sistema.

Tras pinchar la memoria me encontré la primera cosa extraña: La BIOS había bajado la velocidad de la memoria de 400 MHz a 333 MHz. La verdad es que algo así ya me lo esperaba, ya que precisamente uno de las preguntas de las FAQ de la A8N-SLI es, precisamente:

Why does the memory run at 333MHz if I use four DDR400 512MB/256MB memory modules on A8N-SLI?

To be more compatible and stable with some memory modules, the default clock will be at 333MHz if four DDR400 memory modules are plugged on the A8N-SLI. But you still can set at 400MHz manually in the Bios to gain better performance. Moreover, in order to get best performance and compatibility, please choose those memory modules which are verified by us. You can get the QVL from the link below:

http://www.asus.com/products.aspx?l1=3&l2=15&l3=148&model=375&modelmenu=1

Así que entré en la BIOS, puse la configuración de la memoria en Manual, seleccioné la velocidad de 400 MHz y… el ordenador se colgaba instantes después del comienzo del arranque de cualquier sistema operativo. Y es que al poner la configuración manual de la memoria, los otros parámetros de la memoria como CAS# latency, RAS# to CAS# delay, Min RAS# active time o Row Precharge Time dejaban de configurarse automáticamente, así que tuve que volver a poner la memoria en Auto / 333 MHz y entrar en Linux para ver los parámetros de los DIMMs usando el decode-dimm.pl.

(...)

Leer el resto de La odisea de ampliar la memoria a 4 GiB (2,116 palabras)

Lo hice y lo entendí © Vicente Navarro 2008 con una licencia CC BY-SA | 22 comentarios
Etiquetas: AMD64, GNU/Linux, Hardware, memoria RAM, Windows

Entradas relacionadas

Feed enhanced by Better Feed from Ozh

¿Por qué obtenemos una imagen en blanco y negro al usar un adaptador de S-Video a Euroconector?

Vicente Navarro — Tue, 17 Jun 2008 20:40:47 +0000

Hace unos días leíamos en Al otro lado del mostrador la interesante entrada Televisores CRT para un HTPC, en la que el tendero nos contaba cómo podemos conectar un ordenador a un televisor de tubo de los de toda la vida de los que normalmente no tendrán entrada VGA, DVI o HDMI como los últimos televisores planos LCD/TFT o plasma.

Lo típico es que los ordenadores que tengan salida de TV nos proporcionen señal de vídeo compuesto (con un conector RCA) o señal de S-Video (con un conector Mini-DIN), siendo bastante frecuente encontrar sólo la salida de S-Video en portátiles. Si nuestra televisión acepta entradas de estos tipos, no tendremos ningún problema para usar el ordenador con la tele de tubo. Eso sí, si tenemos las dos, hay que elegir S-Video sobre vídeo compuesto, ya que proporciona mejor calidad de imagen. Además, en el ordenador tendremos que escoger resoluciones muy bajas para que las fuentes se vean de acuerdo a la resolución nativa del televisor (PAL=720×576). Por ejemplo, en mi VIA EPIA la resolución 848×480 se ve de maravilla con mi televisor Sony.

Si el televisor CRT no tiene entradas de vídeo compuesto ni S-Video, la única opción que nos quedará será usar un adaptador de RCA/S-Video a Euroconector (SCART). Son muy baratos, a veces se encuentran hasta por 1€ en bazares, y tienen este aspecto:

Estos adaptadores suelen funcionar bien cuando convertimos la señal de vídeo compuesta, pero sin embargo, con muchos televisores, cuando intentamos introducir la señal de S-Video por el Euroconector nos encontramos con que la señal aparece en blanco y negro.

¿Por qué ocurre eso? Vamos a tratar de verlo en esta entrada.

(...)

Leer el resto de ¿Por qué obtenemos una imagen en blanco y negro al usar un adaptador de S-Video a Euroconector? (1,212 palabras)

Lo hice y lo entendí © Vicente Navarro 2008 con una licencia CC BY-SA | 22 comentarios
Etiquetas: S-Video, SCART, Televisión, vídeo compuesto

Entradas relacionadas

Feed enhanced by Better Feed from Ozh

La TDT en alta definición en España: Llegará pero, ¿la podremos ver?

Vicente Navarro — Fri, 18 Apr 2008 20:54:05 +0000

En Octubre del año pasado, en la entrada La resolución 1366×768, hablaba de la tomadura de pelo a la que nos estaban sometiendo los fabricantes y sus departamentos de marketing al haber semi-estandarizado para los televisores “HD Ready” una resolución a todas luces inconveniente y sin sentido alguno.

Esta vez vuelvo a la carga con el tema de los televisores porque estoy teniendo la sensación de que los consumidores estamos siendo sometidos a una especie de estafa colectiva.

Los televisores planos de alta definición están muy de moda. La prueba está en que todo el mundo quiere comprarse uno, incluso teniendo el de tubo que compró hace unos años funcionando perfectamente. Son las grandes estrellas de la propaganda tecnológica, de los folletos que inundan nuestros buzones del Hiper Luna, Medio Marco, PC Pueblo, Corte Alemán o del Carromato. Los regalan al comprar un viaje, al comprar un coche, al comprar un piso y en la rifa de la asociación de vecinos. Tu vecino ya tiene uno, ¿tú aún no te has comprado uno? ¿Te atreverás a ver las olimpiadas o la Eurocopa sin una TV de alta definición?

Pues resulta que la TDT (Televisión Digital Terrestre), aunque tiene mucha calidad, actualmente no emite en alta definición (HD), sino que emite en definición estándar (SD) o, lo que es lo mismo, la resolución PAL de toda la vida a la que, en términos actuales, podríamos llamar 576i, o 720×576. Sólo TV3 está emitiendo ya HD en su área de cobertura, pero en pruebas, y RTVE emitirá este verano los juegos olímpicos de Pekín también en HD.

Por tanto, con tu nuevo televisor de alta definición, sea HD Ready (con una resolución típica de 1366×768) o sea Full HD (1920×1080), ahora mismo no puedes ver ninguna emisión de TDT en abierto en alta definición (excepto TV3). Es importante entender que la TDT no es alta definición, aunque a través de la TDT podríamos recibir alta definición.

El problema es que casi con total seguridad, aunque se emitiera en HD de forma generalizada, en la mayoría de los casos tu flamante nuevo TV HD no te servirá para poder ver la TDT en alta definición sin un sintonizador externo. ¿Por qué? Pasemos a verlo…

(...)

Leer el resto de La TDT en alta definición en España: Llegará pero, ¿la podremos ver? (2,635 palabras)

Lo hice y lo entendí © Vicente Navarro 2008 con una licencia CC BY-SA | 117 comentarios
Etiquetas: Full HD, HD, HD Ready, MPEG2, MPEG4, TDT, Televisión

Entradas relacionadas

Feed enhanced by Better Feed from Ozh

VIA anuncia una iniciativa para mejorar los drivers de Linux

Vicente Navarro — Thu, 10 Apr 2008 17:04:12 +0000

Hoy los poseedores de hardware VIA nos hemos encontrado con una muy buena noticia en los foros de tkArena, y es que VIA anunció ayer en la Linux Foundation Collaboration Summit una iniciativa para el desarrollo de drivers de código abierto. VIA proporcionará especificaciones técnicas, código fuente y datos sobre sus últimos productos, así como un nuevo sitio web (aún sin servicio) para gestionar todo esto: linux.via.com.tw. La iniciativa comenzará con los chipsets CN700, CX700/M, CN896 y VX800 y pretende que lleguen a funcionen perfectamente en Linux en 2D, 3D y aceleración de vídeo. La nota de prensa oficial: VIA Announces Strategic Open Source Driver Development Initiative.

Los habituales de este blog sabrán que tengo un par de placas VIA EPIA (una SP8000E y una EX10000EG) y que en diferentes entradas he tratado de explicar mi experiencia con ellas en Linux:

A menudo me preguntan que qué tal van estas placas en Linux y la respuesta rápida y directa, escondida entre los centenares de líneas de las entradas anteriores es: Las placas VIA EPIA (y podemos generalizar hablando de cualquier placa basada en un procesador y en un chipset de VIA) funcionan excepcionalmente bien como servidores domésticos de bajo consumo y nulo ruido y también funcionan razonablemente bien para tareas de escritorio 2D (navegar, correo, mensajería instantánea, ofimática, etc.), aunque según el driver y el chipset, también podemos encontrarnos con notorios cuelgues e inestabilidades del driver.

(...)

Leer el resto de VIA anuncia una iniciativa para mejorar los drivers de Linux (1,849 palabras)

Lo hice y lo entendí © Vicente Navarro 2008 con una licencia CC BY-SA | 16 comentarios
Etiquetas: drivers, GNU/Linux, openChrome, VIA, VIA EPIA

Entradas relacionadas

Feed enhanced by Better Feed from Ozh

Petición para que VIA tome una postura clara respecto a Linux

Vicente Navarro — Wed, 23 Jan 2008 22:11:03 +0000

Ya he expresado previamente en varias ocasiones qué pienso de los drivers para chips gráficos de VIA, que son una auténtica chapuza. En Sobre las VIA EPIA (VI): Gráficos y vídeo acelerado por HW en Linux con la EX10000EG hablé bastante (mostrando hechos) sobre ello.

Como hemos ido viendo en distintas entradas sobre las VIA EPIA, la verdad es que casi todo el hardware de VIA se puede configurar en Linux sin problemas. Casi todo excepto el procesador gráfico, que en muchas ocasiones es una fuente horrible de problemas.

Desde hace unos días se viene hablando animadamente en el foro de VIA sobre este tema: Decent Linux Drivers: Seriously, what is going on? y finalmente, el usuario Effenberg0x0 ha creado una:

Petición Online para solicitar unos drivers decentes de VIA para Linux (petitiononline.com)

Tanto si tenemos hardware de VIA y estamos directamente afectados por estos problemas como si sólo somos usuarios de Linux y queremos que este sistema operativo crezca, mejore, que nadie tenga problemas de hardware mal soportado y que los fabricantes (en este caso VIA) comiencen a tenernos un poco más de respeto, creo que es importante firmar. Puede ser buena idea también difundir la petición entre los conocidos que tengamos que puedan estar interesados en este tema. ¡Demostrémosles que los usuarios de Linux cada vez somos más y que no deberían de ignorarnos tan alegremente! (Relacionado: La importancia de comprar hardware con drivers abiertos, Pero, ¿qué les pasa a los fabricantes de hardware?).

Para que todo el mundo pueda entender bien lo que está firmando, he considerado conveniente traducir la petición.

(...)

Leer el resto de Petición para que VIA tome una postura clara respecto a Linux (931 palabras)

Lo hice y lo entendí © Vicente Navarro 2008 con una licencia CC BY-SA | 27 comentarios
Etiquetas: drivers, GNU/Linux, Hardware, VIA, VIA EPIA

Entradas relacionadas

Feed enhanced by Better Feed from Ozh

Pero, ¿qué les pasa a los fabricantes de hardware?

Vicente Navarro — Sun, 20 Jan 2008 11:24:03 +0000

Leyendo a Matt Cutts en Formatting USB hard drives for Ubuntu (Gutsy Gibbon), llego a New Seagate Drives Have Real Difficulties With Linux y a Diane Trout – FreeAgent Drives.

Un Seagate FreeAgent Pro es un disco duro externo de hasta 750GB con USB 2.0, eSata y Firewire (algunos modelos sólo USB 2.0) con este aspecto:

Pues bien, para empezar, viene formateado con NTFS, algo que los usuarios de Linux podemos superar fácilmente usando NTFS-3G o cambiando el sistema de ficheros, pero que por de pronto, ya les obliga a poner en las especificaciones técnicas que en Mac OSX sólo se puede usar para lectura:

Operating System
Windows XP Home, Professional Edition or Windows 2000 Pro
Mac OSx 10.3, 10.4 as read only

Lo que es un desprecio bastante importante a Linux, también lo es para Mac OSX, pero con la diferencia de que mientras que Linux tiene una cuota de mercado -de sistemas que navegan por Internet con él- de un 0.63%, Mac OSX tiene una cuota de mercado de un 7.31% (Mac OS X market share sets new record at the end of 2007).

(...)

Leer el resto de Pero, ¿qué les pasa a los fabricantes de hardware? (718 palabras)

Lo hice y lo entendí © Vicente Navarro 2008 con una licencia CC BY-SA | 12 comentarios
Etiquetas: drivers, GNU/Linux, Hardware

Entradas relacionadas

Feed enhanced by Better Feed from Ozh

VFD, la disquetera virtual para Windows

Vicente Navarro — Fri, 18 Jan 2008 19:57:29 +0000

En Integrar drivers de SATA/RAID en un CD de instalación de Windows XP mencioné un emulador/simulador/virtualizador de disquetera para Windows que me gusta mucho, el VFD (Virtual Floppy Drive):

Los drivers se pueden descargar de la web de Intel, pero son imágenes de WinImage autoextraibles, por lo que si no tenemos disquetera tenemos que buscar una forma de extraer los ficheros, bien usando el WinImage, bien usando un emulador de disquetera como el excelente Virtual Floppy Drive.

Desde entonces tenía pendiente dedicarle una entrada, dado que varias personas me han preguntado por este driver/programa, así que vamos allá.

Una disquetera virtual en Windows no es algo que haga mucha falta hoy en día (y por eso ya los ordenadores no suelen llevar disquetera física), pero sigue habiendo fabricantes que para actualizar la BIOS o para pasar algunos diagnósticos hardware sin entrar en Windows ponen a tu disposición únicamente un .exe que escribe una imagen en un disquete desde el que arrancar. Podemos usar la disquetera virtual para copiar después los ficheros necesarios del disquete virtual al disco duro y usarlos para arrancar desde USB o desde un CD.

También lo usaba, hace bastante tiempo ya, con el Partition Magic y con el Norton Ghost (aplicaciones que ya sustituí hace mucho por el gparted y el partimage). Son aplicaciones que te ofrecen crearte un disquete desde el que arrancarlas fuera de Windows y que podemos usar, de nuevo, para copiar sus ficheros y pasarlos a un USB o CD de arranque. O, por qué no, para almacenar una copia de la imagen de esos disquetes que siempre estará mejor en el disco duro que en los pocos fiables disquetes.

El VFD lo descubrí por otro uso muy curioso también. Un conocido tiene una vieja aplicación de esas en las que un disquete del fabricante es la llave y claro, ya no podía ejecutarla en su nuevo portátil sin disquetera. Buscando en Internet encontré el VFD, que le funciona a la perfección, y desde entonces no ha necesitado nunca más una disquetera de verdad.

El VFD es software abierto, con licencia GPL, y la última versión disponible, la 2.1 del 2004, sigue funcionando perfectamente en todos los Windows de 32 bits actuales. El primer paso es descargar el vfd21-050404.zip (el código fuente vfdsrc-050404.zip también está disponible).

(...)

Leer el resto de VFD, la disquetera virtual para Windows (560 palabras)

Lo hice y lo entendí © Vicente Navarro 2008 con una licencia CC BY-SA | 22 comentarios
Etiquetas: VFD, Windows

Entradas relacionadas

Feed enhanced by Better Feed from Ozh

A vueltas con el “hdparm -B” en Debian Lenny

Vicente Navarro — Tue, 01 Jan 2008 18:24:11 +0000

En estos momentos estoy trabajando con una Debian Lenny/Testing. Estar con una Debian Testing tiene las ventajas de estar muy al día con versiones bastante recientes de los paquetes pero al mismo tiempo te vas encontrando con diferentes problemillas que bueno, al menos sirven para descubrir cosas. Trabajar directamente sobre una Unstable a veces tiene consecuencias desastrosas, como he podido comprobar en alguna ocasión, así que no se lo recomiendo a nadie.

Pues bien, tras una de las frecuentes actualizaciones de Lenny/Testing me encuentro estos errores:

Checking battery state...
/dev/sda:
 setting Advanced Power Management level to 0xfe (254)
SG_IO: bad/missing ATA_16 sense data
 HDIO_DRIVE_CMD failed: Input/output error

/dev/sdb:
 setting Advanced Power Management level to 0xfe (254)

/dev/sdc:
 setting Advanced Power Management level to 0xfe (254)

/dev/sdd:
 setting Advanced Power Management level to 0xfe (254)
 HDIO_DRIVE_CMD failed: Invalid argument

/dev/sde:
 setting Advanced Power Management level to 0xfe (254)
 HDIO_DRIVE_CMD failed: Invalid argument

/dev/hda:
 setting Advanced Power Management level to 0xfe (254)
 HDIO_DRIVE_CMD failed: Input/output error

/dev/hdb:
 setting Advanced Power Management level to 0xfe (254)
 HDIO_DRIVE_CMD failed: Input/output error

Hace ya varios meses de que saltara la bomba aquella de que Ubuntu dañaba los discos duros: Linux no mata discos duros, se mueren solos. Y precisamente en aquella ocasión, pudimos ver que Debian Etch no ejecutaba ningún comando hdparm (fuera de lo especificado en /etc/default/hdparm, claro), por lo que el comportamiento que tuviera el disco sería el que el fabricante le pusiera por defecto, y de ahí la afirmación de que ni Ubuntu, ni Debian, ni ningún Linux estropeaban el disco duro por este motivo, sino que era cosa de los fabricantes que hacían una tecnología de discos duros que por defecto se comportaba de forma dañina para los propios discos.

(...)

Leer el resto de A vueltas con el “hdparm -B” en Debian Lenny (1,067 palabras)

Lo hice y lo entendí © Vicente Navarro 2008 con una licencia CC BY-SA | 11 comentarios
Etiquetas: APM, clicks, Debian, GNU/Linux, hdparm, Ubuntu

Entradas relacionadas

Feed enhanced by Better Feed from Ozh

¿Piensas en si un día te roban el portátil?

Vicente Navarro — Wed, 26 Dec 2007 21:09:55 +0000

Los ordenadores portátiles, cada día más ligeros y móviles ellos, son un caramelo muy apetitoso para los “amigos de lo ajeno”. Y a menudo los solemos llevar con nosotros en lugares en los que éstos abundan: estaciones, aeropuertos, oficinas, hoteles, cafeterías… Conozco de primera mano casos de oficinas en los que el propio guardia de seguridad de la empresa se dedicaba a “tomar prestados” durante la noche los portátiles de los empleados que se los dejaban allí de un día a otro incluso con el Kesington lock puesto. Por la mañana los usuarios llegaban y sólo encontraban un trozo de cable de acero colgando de la mesa. Por supuesto, lo descubrieron, pero los portátiles ya no aparecieron. También conozco otro caso de alguien que se dejó el portátil con un importante trabajo de varios meses a punto de finalizar dentro de la caja fuerte de un hotel que fue fácilmente forzada en un rato que él se encontraba fuera de la habitación. Los casos de maletines de portátiles robados en aeropuertos o en coches aparcados ya ni siquiera son anécdota.

La motivación de un ladrón será mayormente económica y en la inmensa mayoría de los casos no buscará específicamente nuestro portátil, ya que muchas veces será un efecto colateral de un robo más amplio (robo en una vivienda, en un coche, del equipaje durante un viaje…). Sin embargo, también puede darse el caso de que nuestro portátil haya desaparecido por motivos relacionados con la información que contiene.

(...)

Leer el resto de ¿Piensas en si un día te roban el portátil? (2,293 palabras)

Lo hice y lo entendí © Vicente Navarro 2007 con una licencia CC BY-SA | 29 comentarios
Etiquetas: backup, cifrado, ddclient, Debian, DynDNS, geolocalización de IP, GNU/Linux, rsync, seguridad, TrueCrypt, Windows

Entradas relacionadas

Feed enhanced by Better Feed from Ozh

Linux no mata discos duros, se mueren solos

Vicente Navarro — Sun, 28 Oct 2007 09:35:55 +0000

Me encuentro en Kriptópolis y en Barrapunto lo que parece el notición geek del año:

Pues qué malo que es el Ubuntu ese, ¿no? Pues a mí no me lo parece, la verdad. A mí me parece que los fabricantes de discos duros nos están vendiendo productos artificialmente poco duraderos. Vayamos por partes.

Resulta que hay una tecnología de fabricación de discos duros llamada de Load/Unload (Un Whitepaper muy aconsejable en PDF sobre el tema: Ramp : Ramp Load/Unload Technology in Hard Disk Driver, encontrado en Broken HDDs) cada vez más extendida, sobre todo en discos duros de portátil. Consiste en que el cabezal de lectura/escritura, en vez de estar permanentemente volando sobre el disco, se aparca frecuentemente, lo que teóricamente permite una mayor duración del disco, menor consumo y mayor protección contra golpes.

Sin embargo, no se puede aparcar la cabeza un número indefinido de veces, sino que estos discos están preparados para un número máximo de ciclos de carga/descarga del cabezal que según el disco en cuestión puede ser de orden de 300K o 600K ciclos (K=1000). No es que justo cuando se llegue a ese número el disco va a dejar de funcionar de repente, sino que a partir de ahí el fabricante ya considera que puede dejar de hacerlo en cualquier momento. Paul nos cuenta que en varios de sus discos ha llegado a 600K, 900K y 1200K ciclos de carga/descarga antes de que empezaran a dar problemas. Pero eso sólo ¡en un año!

Yo me interesé por el problema nada más leer sobre él porque el disco de 2.5″ de marca Western Digital que tengo conectado a la EPIA EX10000EG (apareció de pasada en la entrada Sobre las VIA EPIA (V) ) hacía clicks muy frecuentemente. Lo notaba mucho porque cuando el disco se quedaba idle durante unos segundos, al volver al trabajajo casi siempre hacía un click que me disgustaba mucho pero que pensaba que sería normal (es un disco nuevo y tras varios tests no había encontrado ningún error). Ahora sé que cada vez que se oye uno de esos clicks lo más normal es que sea el cabezal en un ciclo de carga/descarga.

Pues bien, resulta que consultando los parámetros S.M.A.R.T. del disco con el comando smartctl, me encuentro con que el disco ya ha usado 7755 ciclos:

# smartctl -a /dev/hdc | egrep 'ID|Load_Cycle'
ID# ATTRIBUTE_NAME          FLAG     VALUE WORST THRESH TYPE      UPDATED  WHEN_FAILED RAW_VALUE
193 Load_Cycle_Count        0x0032   198   198   000    Old_age   Always       -       7755

Y no penséis que esta máquina se tira encendida semanas y semanas, ¡no!. Para llegar a ese número de ciclos, ese disco sólo ha pasado por una instalación de Debian y por todas las pruebas que le hice a la EX10000EG, incluyendo varios ratos de reproducción de vídeo. Por tanto, que haya consumido ya 7755 ciclos, que podría ser alrededor del 3% de los que el fabricante permite antes de que el disco sea declarado como “envejecido”, es una auténtica barbaridad.

En unas pruebas rápidas he podido ver que el número de ciclos crece muy rápidamente en pocos minutos y sin apenas usar la máquina:

Sun Oct 28 02:11:51 CEST 2007
193 Load_Cycle_Count        0x0032   198   198   000    Old_age   Always       -       7744
Sun Oct 28 02:15:51 CEST 2007
193 Load_Cycle_Count        0x0032   198   198   000    Old_age   Always       -       7753
Sun Oct 28 02:16:28 CEST 2007
193 Load_Cycle_Count        0x0032   198   198   000    Old_age   Always       -       7754

Como se comenta en los enlaces que hablan del problema, con el comando “hdparm -B” podemos modificar el nivel de gestión de energía que ha de tener el disco (usando APM):

# man hdparm
[...]
-B     Set  Advanced  Power  Management  feature,  if  the drive supports it. A low value means
       aggressive power management and a high value means better performance. A  value  of  255
       will disable apm on the drive.
[...]

Podemos reducirlo al máximo:

# hdparm -B 254 /dev/hdc

/dev/hdc:
 setting Advanced Power Management level to 0xFE (254)

O incluso deshabilitarlo:

# hdparm -B 255 /dev/hdc

/dev/hdc:
 setting Advanced Power Management level to disabled

El caso es que tras hacer lo último, el valor de Load_Cycle_Count en la salida del smartctl ya no crece más que en una unidad cuando arranco, así que me lo he puesto en el fichero /etc/rc.local, para que se ejecute siempre durante el arranque. Los clicks también han desaparecido, así que todo es mucho mejor ahora.

Y es que en este sistema, aunque le puse un disco de 2.5″ para que no consumiera mucho porque la fuente es tan sólo de 60W, tampoco necesito que sea muy estricto en materia de ahorro de energía como si se tratara, por ejemplo, de un portátil trabajando con baterías, y prefiero evitar un envejecimiento prematuro del disco.

El problema con Ubuntu, el que ha creado toda esta alarma, es que en modo laptop, que no está habilitado por defecto, el fichero /etc/acpi/power.sh configura el disco para que ahorre energía de la forma más agresiva posible, con -B 1, haciendo que el disco tenga muchos más ciclos de carga y descarga y muchos más clicks:

function laptop_mode_enable {
...
    $HDPARM -S $SPINDOWN_TIME /dev/$drive 2>/dev/null
    $HDPARM -B 1 /dev/$drive 2>/dev/null
}

En un bug report del problema que ya tiene bastantes meses, alguien ha probado con distintos valores de -B:

-B 128 -> 23 cycles in 10 minutes
-B 160 -> 29 in 10'
-B 180 -> 0 in 10'
-B 196 -> 0 in 10'
-B 200 -> 0 in 10'

Se ha generado alarma por Ubuntu e incluso en algunas otras distribuciones pero, en realidad, hay firmwares y BIOS que ya activan modos APM agresivos durante el arranque, como leemos en Problem with hard drive clicking, y como me ha pasado a mí mismo, que estaba sufriendo el problema con una Debian que no toca absolutamente nada de los parámetros del disco.

¿Y el problema no pasa en Windows? Pues yo no tengo ningún disco que haga clicks y que tenga Windows para probar si tras un rato de funcionamiento el valor de Load_Cycle_Count crece, pero yo esperaría que sí, ya que Windows suele optimizar bastante bien el consumo de energía en portátiles (los fabricantes de los mismos en realidad lo prueban todo en Windows).

Sí que puede ocurrir que en Linux los ciclos de carga y descarga ocurran mucho más a menudo, porque en Linux el kernel y los procesos se dedican a escribir muy frecuentemente en disco, siendo los periodos en los que el disco está idle mínimos. Cualquiera que haya intentado que un disco duro se quede parado tras un periodo de inactividad del sistema en Linux, se habrá dado cuenta de que no es una tarea fácil:

Pero para mí, me parece que lo más importante a recalcar es que en raíz, esto no es un problema de ningún sistema operativo, ni de ninguna distribución: ni Ubuntu, ni Debian, ni Fedora, ni Windows. No perdamos de vista que esto es un problema generado artificialmente por los fabricantes de discos duros que hacen su hardware con absurdas limitaciones.

Y, por cierto, no olvidemos que este es un problema sólo de los discos que se fabrican con esta tecnología de load/unload, a los que también podríamos llamar click-powered hard disks. En otros discos, dicho contador ni se estrena:

# smartctl -a /dev/sdb | egrep 'ID|Load_Cycle'
ID# ATTRIBUTE_NAME          FLAG     VALUE WORST THRESH TYPE      UPDATED  WHEN_FAILED RAW_VALUE
193 Load_Cycle_Count        0x0032   253   253   000    Old_age   Always       -       0

Una curiosidad para acabar: ¿Sabías que con la opción -M del hdparm puedes configurar tu disco para que intente hacer menos ruido?

:wq

Actualización 1/1/08: En A vueltas con el “hdparm -B” en Debian Lenny vuelvo a tratar el tema, enfocándolo esta vez a ver cómo están tratando el problema los desarrolladores de Debian en Lenny.

Actualización 2/5/08: Hace tiempo que está en los comentarios, pero creo que es importante recalcar que en lugar de añadir el comando “hdparm -B 254” al fichero /etc/rc.local, es mejor editar el fichero /etc/hdparm.conf y poner algo así (cambiando el fichero de dispositivo y el valor de apm según nuestras necesidades):

/dev/sda {
apm = 254
}

Seguido por el comando:

update-rc.d hdparm defaults

para que el hdparm se ejecute durante el arranque.

Actualización 5/5/08: Parece que en Ubuntu Hardy Heron no hay /etc/init.d/hdparm, de modo que probablemente siga siendo buena idea usar el /etc/rc.local.

Actualización 24/5/08: La página Bug #59695 High frequency of load/unload cycles on some hard disks may shorten lifetime contiene una excelente explicación del problema así como una lista de discos duros afectados y del valor de “hdparm -B” más conveniente para solucionar el problema en ellos. Me ha gustado especialmente el siguiente párrafo:

The disk Load_Cycle_Count issue appears to be caused by a combination of two problems — The first is overly-aggressive power management from what might be considered buggy hardware. The second is that Ubuntu appears to be touching the hard drive on a regular basis for one reason or another.

ya que afirma claramente lo que yo siempre he defendido en esta entrada: Que esto es un problema de los fabricantes de discos duros. Que se agrava por cómo Linux usa el disco duro, de acuerdo, pero en primer lugar es un problema de cómo los fabrican.

Lo hice y lo entendí © Vicente Navarro 2007 con una licencia CC BY-SA | 171 comentarios
Etiquetas: APM, clicks, Debian, GNU/Linux, hdparm, SMART, Ubuntu

Entradas relacionadas

Feed enhanced by Better Feed from Ozh

La resolución 1366×768

Vicente Navarro — Sun, 14 Oct 2007 22:13:45 +0000

Hace mucho, mucho tiempo, los usuarios de ordenadores con nuestros monitores de tubo sólo teníamos unas pocas resoluciones entre las que elegir, en función de las características del monitor y de la memoria de la tarjeta de vídeo: 640×480 (VGA), 800×600 (SVGA), 1024×768 (XGA), 1152×864 (XGA+?), 1280×1024 (SXGA), 1600×1200 (UXGA). Todas ellas son 4:3 excepto la 1280×1024 que es 5:4… ¿Te habías fijado en que usando esta resolución en en un monitor de tubo 4:3 las fotos salen un poco achatadas? ¿Te habías fijado en que posiblemente tu monitor LCD de 17″ o 19″ con esta resolución nativa tenga físicamente relación de aspecto 5:4 y no 4:3?

La llegada de los DVD, con películas con relación de aspecto 2.35:1 y 16:9 trajo los primeros televisores 16:9 de tubo. Dado que en España las emisoras nunca se han propuesto emitir en serio en PALplus, era para lo único que servían, para ver DVDs. Por cierto, ¿soy el único en el mundo al que le desagrada extremadamente ver emisiones 4:3 achatadas hasta la exageración en lugares públicos y casas de amigos?

Poco a poco, se fueron introduciendo en el mercado monitores LCD, portátiles y televisores con relaciones de aspecto 16:10 y 16:9.

En el mundo de la informática, la relación de aspecto 16:10 es la que está partiendo la pana ahora mismo. La mayoría de portátiles tienen resolución nativa 1280×800 (WXGA), 1440×900 (WXGA+) o 1920×1200 (WUXGA) y en sobremesa, 1680×1050 (XSXGA+) también se ha popularizado en LCDs de 20″-22″. Y es curioso que sean tan populares, porque cualquiera puede darse cuenta que a igualdad de diagonal, una pantalla cuadrada tiene más área que una rectangular, por lo que a menos que el mayor uso de nuestro ordenador sea ver películas, una pantalla alargada , además de que suele ser más incomoda para trabajar, tiene menos área de trabajo. Pongamos un ejemplo en el que la pantalla alargada parte con un poco de ventaja por tener 0.4″ más de diagonal:

Típica pantalla 16:10 de 15.4″ de diagonal:

15.4²=(16x)²+(10x)² → x=0.8162"=2.0731cm

Área=16x·10x=678.67cm²

Típica pantalla 4:3 de 15″ de diagonal:

15²=(4x)²+(3x)² → x=3"=7.62cm

Área=4x·3x=696.77cm²

En cualquier caso, al final esto es algo en lo que los usuarios finales tienen poco poder de decisión, ya que si los grandes departamentos de marketing han decidido que al usuario le atrae más una pantalla alargada que una cuadrada, pantallas alargadas tendremos hasta en la sopa.

(...)

Leer el resto de La resolución 1366×768 (1,559 palabras)

Lo hice y lo entendí © Vicente Navarro 2007 con una licencia CC BY-SA | 72 comentarios
Etiquetas: 1366x768, EDID, Full HD, HD, HD Ready, Televisión

Entradas relacionadas

Feed enhanced by Better Feed from Ozh

Sobre las VIA EPIA (VI): Gráficos y vídeo acelerado por HW en Linux con la EX10000EG

Vicente Navarro — Wed, 10 Oct 2007 17:26:20 +0000

Al final de Sobre las VIA EPIA (V): La EPIA EX10000EG en Linux, decíamos que la parte de los gráficos es la que más trabajo supone y que por eso lo dejábamos para una entrada separada. Así que, sin más dilación, pongámonos a ello. No está de más, por cierto, recordar que yo trabajo en una Debian Etch con un kernel personalizado 2.6.22.6.

El procesador gráfico que lleva la VIA EPIA EX10000EG es el UniChrome™ Pro II, integrado en el chipset CX700M2. Según VIA, este chipset es capaz de:

Integrated VIA UniChrome™ Pro II 3D/2D AGP graphics with MPEG-2/4 and WMV9 video decoding acceleration

No tengo ni idea de si tales afirmaciones son ciertas en Windows (no he probado esta placa con dicho sistema operativo) o son fruto de la benevolencia de alguien en el departamento de marketing de VIA, pero veamos hasta dónde podemos sacarle punta a dichas afirmaciones en Linux.

En principio, leyendo la Operating Guide de la placa, vemos que, aunque sea sobre el papel, VIA nos manifiesta un fuerte compromiso con el soporte de Linux en sus placas:

Linux Driver Support

VIA EPIA EX mainboards have a very high degree of support under Linux.

Support and drivers are provided through various methods including:

Drivers provided by VIA

Using a driver built into a distribution package

Visiting VIA Arena website at www.viaarena.com for latest updates on a monthly basis

Installing a third party driver (such as the ALSA driver from the Advanced Linux Sound Architecture project for integrated audio)

For OEM clients and system integrators developing a product for long term production, other code and resources may also be made available. You can submit a request either through the Developers portal on VIA Arena, or through your VEPD support contact. Alternatively, VIA can work further towards providing additional drivers to suite your specific needs.

Como hemos visto en entradas anteriores (Sobre las VIA EPIA (V): La EPIA EX10000EG en Linux, Sobre las VIA EPIA (III): Linux en una SP8000E), en las que nos hemos dejado absolutamente todos los elementos del hardware configurados a la perfección, podemos aceptar la afirmación anterior sin titubeos.

Sin embargo, aún nos queda configurar los gráficos en esta placa, y nos vamos a encontrar con varios problemas. El primero es que según leemos en la página de man(4) del driver via actual (7.1) de X.Org, este chipset no está soportado aún:

DESCRIPTION
       via is an Xorg driver for VIA chipsets that have  an integrated Unichrome graphics engine.
 
       The via driver supports the CLE266, KM/N400, K8M/N800, PM/N800  and  CN400  chipsets  from
       VIA,  including  2D acceleration and the Xv video overlay extensions.  Flat panel, TV, and
       VGA outputs are supported, depending on the hardware configuration.
 
       3D direct rendering is available using experimental drivers  from  Mesa  (www.mesa3d.org).
       There  is  also  an  XvMC client library for hardware acceleration of MPEG1/MPEG2 decoding
       (available on the CLE266, PM/N800, K8M/N800, and CN400 chipsets) that uses the Direct Ren-
       dering  Infrastructure  (DRI).   The  XvMC  client library implements a non-standard "VLD"
       extension to the XvMC standard.  The current Direct Rendering Manager (DRM) kernel  module
       is available at dri.sourceforge.net.

Si nos pasamos al driver openChrome, nos encontramos con que tenemos que usar la rama experimental para tener soporte del chipset CX700M2 pero que, desafortunadamente, aún no soporta aceleración MPEG2/4 por XvMC.

Nos queda el driver oficial de VIA. Cuando hice la tanda anterior de artículos alrededor de la SP8000E, dado que encontré buen soporte del procesador gráfico tanto en el driver oficial de X.Org como en el openChrome, ni me preocupé en probarlo, ya que en muchos foros leía comentarios bastante negativos al respecto. Sin ir más lejos, en The Different Unichrome family display drivers podemos leer:

The VIA proprietary drivers

The proprietary drivers from VIA contain support for most chipsets, mpeg2 and mpeg4 acceleration, but are of low quality and often unstable. In addition, the 3D driver leaves your system open for attack by malicious clients, and furthermore, applications that accelerate mpeg2 and mpeg4 must be run as root, which is a very bad idea if they contain vulnerabilities (and they do). Avoid using these drivers unless you know what you are really doing! The drivers can be found here. Also, these drivers are distribution specific and a driver for different distribution other than yours might not work.

El desarrollador del driver unichrome.sf.net (que no funciona en chipsets modernos como el CN400 o el CX700, por cierto), Luc Verhaegen, también dice:

Despite VIA’s failure to properly understand and cooperate with Free and Open Source Software communities, this driver is very important. Thanks to VIA’s code releases, however irregular, entangled and buggy, a lot is known about the unichromes, and it is possible to do just about anything you want with them.

Por cierto, Luc tuvo un rifirafe con la moderadora de los foros de VIA, Fiona Gatt en VIA stops providing source: XF40070 is binary only y XF40070 topic locked: Last post removed tras decir en su diario lindezas sobre el driver de VIA tales como:

So, let us review where VIAs stands with respect to free software:

Complete and prolonged (3y+) inability to work with actual free software developers.

Crappy code and sporadic releases, totally unfit for direct use.

Very bad handling of licensing, with proprietary licenses popping up once in a while.

An NDA that, when VIA says so, forces signee to breach the GPL.

Distributes tarball with the binary “libddmpeg.so” and labels the lot as “open source” in direct violation of The Open Source Definition.

No longer distributes a DRI driver now, after having provided DRI binaries for a bit inside their “open source” tarballs. This used to be all source at one point.

En esta ocasión, y puesto que la aceleración de vídeo es importante en mis pruebas, es impensable no probarlo. Así que, ¡vamos allá!.

(...)

Leer el resto de Sobre las VIA EPIA (VI): Gráficos y vídeo acelerado por HW en Linux con la EX10000EG (7,773 palabras)

Lo hice y lo entendí © Vicente Navarro 2007 con una licencia CC BY-SA | 47 comentarios
Etiquetas: Debian, EX10000EG, GNU/Linux, Kernel, MPEG2, MPEG4, openChrome, patch, SP8000E, Televisión, VIA, VIA EPIA, XvMC

Entradas relacionadas

Feed enhanced by Better Feed from Ozh

Sobre las VIA EPIA (V): La EPIA EX10000EG en Linux

Vicente Navarro — Sat, 06 Oct 2007 16:06:45 +0000

Continuando con Sobre las VIA EPIA (IV): Placas con procesador C7 / La EX10000EG, vamos a ver las cosas que tenemos que tocar en nuestro Linux (en mi caso Debian Etch con un kernel 2.6.22.6 personalizado) para sacar el máximo provecho de esta placa.

(...)

Leer el resto de Sobre las VIA EPIA (V): La EPIA EX10000EG en Linux (2,113 palabras)

Lo hice y lo entendí © Vicente Navarro 2007 con una licencia CC BY-SA | 15 comentarios
Etiquetas: Debian, EX10000EG, GNU/Linux, IDE, Kernel, OpenSSL, SATA, VIA, VIA EPIA, VIA Padlock

Entradas relacionadas

Feed enhanced by Better Feed from Ozh

Sobre las VIA EPIA (IV): Placas con procesador C7 / La EX10000EG

Vicente Navarro — Tue, 02 Oct 2007 20:12:47 +0000

Un amigo tiene en la cabeza un proyecto en el que usará varias VIA EPIA EX10000EG para reproducir vídeo en Linux y me ha cedido una de ellas a sabiendas de que yo no iba a poder pasar sin cacharrear un poco con ella y contarle todo lo que fuera descubriendo. Así que en ello estamos, contando.

Sobre las VIA EPIA y el formato Mini-ITX en general y sobre la VIA EPIA SP8000E en particular ya hablé largo y tendido en tres entradas anteriores:

Las EPIA EX (EX10000EG y EX15000EG, una fanless y la otra con ventilador, como siempre), con chipset CX700M2, eran, hasta hace muy poco, las más nuevas de las placas VIA EPIA de formato Mini-ITX. Recientemente aparecieron las SN (chipset CN896, con PCIe), LT (chipset CX700, que es como el CX700M2 pero sin decodificador de TV) y LN (chipset CN700). A día de hoy, las únicas con chipset CX700M2 son las EX, aunque las LT también se pueden pedir con CX700M2 por encargo ( y me imagino que para volúmenes grandes). Las EX también son las únicas con salida DVI.

El que las EX sean de momento las únicas EPIA en la que el conector DVI reemplace al VGA me parece muy sorprendente. El conector apenas ocupa un poco más, y si no se tiene un monitor con entrada DVI, siempre se puede usar un convertidor como éste que me venía en la caja de otra tarjeta de vídeo (y probado con éxito con la EX10000EG):

Y ahondando más en el tema, es especialmente llamativo que esto ocurra incluso en las SN, tope de gama actual, con su procesador C7 de hasta 1.8GHz (con ventilador) y su flamante chipset CN896, que permite un FSB de 800MHz (sólo en combinación con el procesador de 1.8GHz) e incluye el procesador gráfico VIA Chrome9™HC, con soporte de DX9 y certificado para Windows Vista Home Basic, la versión que no incluye el Windows Aero, claro.

(...)

Leer el resto de Sobre las VIA EPIA (IV): Placas con procesador C7 / La EX10000EG (2,194 palabras)

Lo hice y lo entendí © Vicente Navarro 2007 con una licencia CC BY-SA | 9 comentarios
Etiquetas: EX10000EG, Mini-ITX, SCART, VIA, VIA C7, VIA EPIA

Entradas relacionadas

Feed enhanced by Better Feed from Ozh

Fuentes de alimentación ATX: Arrancar una fuente fuera de la caja

Vicente Navarro — Thu, 13 Sep 2007 19:19:33 +0000

Es posible que alguna vez os hayáis visto con la necesidad de probar una placa base con su memoria y su procesador y tal vez disco duro, unidad óptica, etc., fuera de una caja. En servicios técnicos y tiendas como la del tendero digital seguro que tienen que hacerlo de vez en cuando para probar tal placa base o tal componente. En nuestras casas es más raro, aunque puede presentarse alguna vez el caso.

Suponiendo que tenemos una fuente de alimentación ATX disponible, esto no supone mayor problema, de forma que podamos montar fácilmente un entorno de pruebas similar al de estas fotos (encontradas aquí y aquí):

No tiene mayor complicación…. excepto por un elemento clave… ¡El interruptor!

Sí, porque a diferencia de las viejas fuentes AT que llevaban un interruptor conectado a la propia fuente, las fuentes ATX necesitan que les llegue la señal de encendido de la placa base. Esto permite cosas tan interesantes como arrancar el ordenador con el teclado, a una hora determinada, después de perder la alimentación o por Wake on LAN… El interruptor de la caja ahora es un sencillo pulsador con retorno que le da la señal de encendido a la placa base. Como muchos ya sabréis, si lo dejas pulsado varios segundos, el ordenador se apaga.

(...)

Leer el resto de Fuentes de alimentación ATX: Arrancar una fuente fuera de la caja (648 palabras)

Lo hice y lo entendí © Vicente Navarro 2007 con una licencia CC BY-SA | 51 comentarios
Etiquetas: ATX, fuentes de alimentación

Entradas relacionadas

Feed enhanced by Better Feed from Ozh

La importancia de comprar hardware con drivers abiertos

Vicente Navarro — Sat, 01 Sep 2007 09:17:17 +0000

Hace un rato os contaba cómo configurar el Epson 2480 en Linux. Ha sido muy fácil, ¿verdad? Bueno, pues era más bien una excusa para entrar caliente en un tema que quería abordar hace tiempo…

Siendo el caso del Epson Perfection 2480 uno de los casos más fáciles que podemos encontrar para configurar un dispositivo hardware que no esté directamente soportado por el kernel, nos toca reconocer que a Linux aún le queda un buen camino que recorrer en el área del reconocimiento automático del hardware, algo que sin el apoyo real de los fabricantes nunca será posible del todo. Este dispositivo está bien soportado en Linux, pero como el firmware es cerrado, no puede ser incluido en distribuciones que tengan un mínimo reparo a las licencias del software que incluyen.

En la época de Windows 95 anterior a la llegada del 98 teníamos otro escáner, un Mustek Paragon 6000p de puerto paralelo. Estábamos contentos con aquel escáner, aunque como el 486 no tenía EPP/ECP, la velocidad de transmisión de imágenes al PC era lamentable. Pero bueno, el caso es que cuando salió Windows 98, Mustek no sacó drivers para este nuevo sistema operativo. Incluso hoy en día, si vamos a la página de drivers del 600 III EP Plus (¡el 6000p no está!) vemos que sólo hay drivers para Windows 95. ¿Qué pasó? Pues que si migraba no tenía escáner. Ahí me di cuenta de que si el escáner estaba soportado en Linux con un driver abierto (sí que lo está, aunque no sé desde cuándo), jamás me tendría que preocupar en adelante porque un dispositivo hardware dejara de estar soportado. Desafortunadamente, aquel escáner tuvo una muerte temprana, pero si aún estuviera funcionando, yo, en 2007, más de 10 años más tarde, podría poneros capturas obtenidas con él con mi Debian, pero desde luego no podría hacer lo mismo con Windows XP ni con Vista.

Estos problemas le ocurrieron a mucha gente cuando Windows 98 no aceptaba los drivers de Windows 95 y el fabricante no hacía drivers para dispositivos de un año o dos de antiguedad para Windows 98. Volvió a ocurrir cuando muchos dispositivos quedaron en la cuneta en el paso a Windows 2000. Ahora, como los drivers de Windows 2000 sirven para Windows XP, llevamos mucho tiempo sin vivir estos problemas y se nos habían olvidado, pero con la salida de Vista, de nuevo está ocurriendo que ante la ausencia de drivers para Vista, muchos tienen que elegir entre su hardware o Vista (que yo lo tendría claro, pero en fin, para gustos están los colores).

Es el paraíso de los fabricantes. No me extrañaría que desearan con todas sus fuerzas que con cada nueva versión Microsoft cambiara el formato de sus drivers para que todos los usuarios tiraran a la basura sus dispositivos totalmente funcionales y compraran nuevos compatibles con el nuevo Windows Tuerto de turno.

Y es que comprar hardware para el que exista un driver en Linux te garantiza que tu hardware morirá cuando tú quieras, no cuando quiera el fabricante dejar de soportar el dispositivo porque con dos años ya está obsoleto.

Pero no sólo eso: Hay esforzadísimos programadores de drivers de Linux que se lo curran muchísimo para, contra el viento y la marea de los fabricantes que no proporcionan las especificaciones de sus dispositivos, crear drivers usando ingeniería inversa de los drivers de Windows. Su labor es altamente loable, pero no hemos de conformarmos con eso. Un driver obtenido por ingeniería inversa normalmente será de peor calidad que uno hecho a partir de las especificaciones. Así que, como dicen los americanos, tenemos que votar con nuestros euros y favorecer a los fabricantes que proporcionan las especificaciones de su hardware o, incluso mejor, que favorecen e impulsan la creación de drivers abiertos.

El poder está en nuestras manos si lo usamos bien. Si te vas a comprar una tarjeta WiFi fíjate en que Ralink hace un esfuerzo grande para que tengamos buenos drivers para sus chips, fíjate en que Intel proporciona los mejores drivers abiertos de procesadores gráficos de hoy en día, fíjate en que con la ayuda para hacer drivers para Linux que proporciona VIA a los desarrolladores y los que ella misma distribuye, las placas VIA EPIA van mejor en Linux que en Windows…

…y fíjate en que si ahora mismo NVidia y ATI cerraran sus puertas, nos quedaríamos con tarjetas gráficas compradas por entre 100 y 600€ que en pocos meses no servirían para nada que no fuera 2D.

Por tanto, por favor, antes de comprar cualquier hardware nuevo, comprueba previamente si está soportado en Linux. Estarás favoreciendo a los fabricantes que colaboran con la comunidad de código abierto, estarás perjudicando a los que no lo hacen y, sobre todo, saldrás ganando tú. Es posible que no uses Linux ni quieras usarlo en el futuro, pero haciéndolo así sabes que dentro de 10 años, si quieres volver a usar ese dispositivo que tienes en el armario, podrás hacerlo, aunque tenga que ser con Linux.

Lo hice y lo entendí © Vicente Navarro 2007 con una licencia CC BY-SA | 12 comentarios
Etiquetas: drivers, GNU/Linux, Windows

Entradas relacionadas

Feed enhanced by Better Feed from Ozh

El escáner Epson Perfection 2480 en Linux

Vicente Navarro — Sat, 01 Sep 2007 08:56:24 +0000

Hace unos años compramos en casa un escáner Epson Perfection 2480 para un tema muy concreto que tuvimos que hacer en Windows. Es un buen escáner. Como llevábamos tiempo buscando uno que diera una calidad razonable sin llegar al precio de un escáner profesional, cuando dimos con él por fin pudimos respirar, ya que habíamos tenido que devolver varios anteriormente porque de verdad no llegaban al límite de lo aceptable.

Ya no lo habíamos vuelto a usar desde entonces, pero hace unos días lo recuperé para escanear los CDs de la entrada Los Linux de mi vida. Como no podía ser de otra forma, lo hice en mi Debian, así que os voy a contar los pasos que hay que seguir para ello.

1) Instalar el SANE (Scanner Access Now Easy), si no lo está ya:

apt-get install libsane

El paquete libsane-extras contiene soporte para algunos escáneres adicionales.

2) Desde la página lista de escáneres soportados por SANE vamos a la página del driver SnapScan, que es el que hace falta para este dispositivo, que nos informa de que necesitamos obtener el fichero de firmware esfw41.bin de los drivers de Windows.

2a) Descargamos el driver del Epson Perfection 2480 para Windows, que es un fichero zip autodescomprimible. Lo descomprimimos con unzip y obtenemos varios ficheros, uno de los cuales es el ModUsd.cab. Si lo descomprimimos con cabextract encontraremos finalmente el esfw41.bin.

O también:

2b) Si tenemos el driver instalado en Windows, copiamos el fichero de c:\windows\system32

3) Copiamos el fichero esfw41.bin al sitio que deseemos del sistema de ficheros

4) Editamos el fichero /etc/sane.d/snapscan.conf y especificamos el sitio donde hemos dejado nuestro fichero de firmware:

# Change to the fully qualified filename of your firmware file, if
# firmware upload is needed by the scanner
firmware /mi/path/esfw41.bin

5) Editamos el fichero /etc/group y añadimos el usuario que vaya a hacer uso del escáner (no se debe usar root para esto) al grupo scanner.

scanner:x:110:supercoco

6) Usamos unos de los frontends de SANE para escanear, como por ejemplo el XSane, casi tan bueno o más que el software oficial Epson para Windows.

¡Ya está! Como veis, no tiene ninguna complicación. Al final, si no fuera por el fichero de firmware y por tener que darle permisos al usuario para escanear, no habría que hacer nada, sólo pinchar y usar (plug & play).

Lo hice y lo entendí © Vicente Navarro 2007 con una licencia CC BY-SA | 2 comentarios
Etiquetas: Debian, drivers, Epson Perfection 2480, GNU/Linux, SANE

Entradas relacionadas

Feed enhanced by Better Feed from Ozh

Configuración de una Hauppauge WinTV-HVR-1100 en Linux

Vicente Navarro — Sat, 25 Aug 2007 20:22:06 +0000

En Sobre las VIA EPIA (II): Mi ordenador basado en una SP8000E comentaba que tengo una Hauuppauge WinTV-HVR-1100 y tenía pendiente contar cómo configurarla en Linux. Se trata de una tarjeta híbrida, capaz de sintonizar TV analógica, TDT (DVB-T) y radio FM. Usa el chip Conexant CX23880, sucesor de los famosos chips BT878 y BT848 de la empresa Brooktree. En 1996 Brooktree fue comprada por Rockwell International y en 1999 la división de semiconductores de dicha compañía, Rockwell Semiconductor, se segregó dando lugar a Conexant.

Si estás pensando en comprar esta tarjeta, es posible que también te interese considerar a los modelos superiores, la WinTV-HVR-1300, con codificador de MPEG2 por hardware y la WinTV-HVR-3000, con soporte adicional de DVB-S (emisiones por satélite en digital) .

(...)

Leer el resto de Configuración de una Hauppauge WinTV-HVR-1100 en Linux (2,257 palabras)

Lo hice y lo entendí © Vicente Navarro 2007 con una licencia CC BY-SA | 56 comentarios
Etiquetas: CX88, Debian, DVB-T, GNU/Linux, Hauppauge WinTV-HVR-1100, Hauppauge WinTV-HVR-3000, Kernel, lirc, MythTV, V4L

Entradas relacionadas

Feed enhanced by Better Feed from Ozh

¿Cómo hacer cables de red?

Vicente Navarro — Wed, 06 Jun 2007 17:22:00 +0000

¿Qué ocurre si, en la era del todo WiFi e inalámbrico, vives en una comunidad de vecinos en la que por la noche se pueden llegar a ver hasta 15 puntos de acceso diferentes llenando por completo todos los canales disponibles? Pues simplemente que la señal de una habitación no llegas a recibirla en otra. Y si la recibes, es tan inestable que se te corta continuamente. Sí, sí, incluso con una antena de dos palmos…

Por eso decidí hacer llegar a (casi) todas las habitaciones cables Ethernet usando los tubos del operador alternativo de telecomunicaciones, para olvidarme de los cortes e inestabilidades para siempre. Aquí vemos el router Zyxel Prestige 660HW-61 con cables de red y de teléfono saliendo hacia las habitaciones:

Y aquí vemos cómo quedan las rosetas de teléfono y red (es muy difícil encontrar rosetas de red bonitas, y cuando se encuentran, son muy caras):

Y fruto del trabajo hecho, y de los múltiples cables que he hecho a posteriori a petición popular, me declaro una autoridad en la materia y me voy a atrever a contar los difíciles pasos que hay que seguir hasta llegar a tener un cable de red.

(...)

Leer el resto de ¿Cómo hacer cables de red? (733 palabras)

Entradas relacionadas

Feed enhanced by Better Feed from Ozh

Wake on LAN

Vicente Navarro — Sun, 03 Jun 2007 11:08:20 +0000

Hoy en día hay mucha gente que tiene en casa un ordenador conectado a Internet casi siempre encendido y al que se puede acceder desde cualquier lugar, normalmente por SSH en sistemas UNIX (aunque también hay servidores SSH para sistemas Windows, son menos frecuentes, porque las posibilidades que tenemos en la shell de Windows son muy limitadas) y por VNC o RDP en Windows. En muchos casos, es bastante normal que además de ese ordenador siempre encendido se tenga algún otro que sólo se enciende cuando se está en casa.

Pero hay veces que, estando lejos, nos puede interesar encender ese otro ordenador de forma remota porque necesitamos un fichero que tenemos en él o necesitamos hacer algo en él. Para esas situaciones, lo mejor es tener el Wake on LAN (WoL) preparado en esa máquina y las utilidades necesarias para activarlo en la máquina que no solemos apagar.

El WoL es posible en los PCs actuales gracias a las fuentes de alimentación ATX que, cuando el ordenador está apagado, siguen alimentando a ciertas partes de la placa base permitiendo asimismo el Wake on Ring y la posibilidad de arancar el PC sólo pulsando una tecla del teclado o que se encienda a una determinada hora.

(...)

Leer el resto de Wake on LAN (1,947 palabras)

Lo hice y lo entendí © Vicente Navarro 2007 con una licencia CC BY-SA | 75 comentarios
Etiquetas: ATX, C, DynDNS, fuentes de alimentación, GNU/Linux, PC, Wake-on-LAN, Windows, Zyxel 660HW

Entradas relacionadas

Feed enhanced by Better Feed from Ozh

Sobre las VIA EPIA (III): Linux en una SP8000E

Vicente Navarro — Tue, 22 May 2007 22:03:12 +0000

Como ya comenté en Sobre las VIA EPIA (I): Introducción al formato Mini-ITX y a las placas EPIA, las placas EPIA nos ofrecen lo mejor de sí mismo usando Linux. Las optimizaciones por hardware específicas que tienen en la mayoría de los casos son mejor aprovechadas por el sistema del pingüino. Es el caso de la aceleración MPEG2 y el PadLock.

Una referencia importante a la hora de poner Linux en una VIA EPIA es el EPIA HowTo, que desafortunadamente ha dejado de mantenerse, pero aún es una fuente importante de información sobre el tema.

Como comentaba en el primer artículo de la serie, las EPIA con procesador VIA C3 Nehemiah y C7 aceptan cualquier distribución optimizada hasta 686, lo que nos permite instalar prácticamente cualquier distribución de 32 bits actual. Cualquiera de ellas puede funcionar sin tocar gran cosa de la configuración por defecto. En esta entrada voy a contar más bien los detalles que hay que tener en cuenta para optimizar al máximo nuestra EPIA centrándome, como no puede ser de otra forma, en lo que tengo a mano, una SP8000E. Todo lo que comente es válido para una SP13000 y probablemente gran parte lo sea para las placas basadas en el chipset CN700.

(...)

Leer el resto de Sobre las VIA EPIA (III): Linux en una SP8000E (1,642 palabras)

Lo hice y lo entendí © Vicente Navarro 2007 con una licencia CC BY-SA | 70 comentarios
Etiquetas: epiOS, GNU/Linux, IDE, Kernel, openChrome, SP8000E, VIA, VIA EPIA, VIA Padlock, XvMC

Entradas relacionadas

Feed enhanced by Better Feed from Ozh

Sobre las VIA EPIA (II): Mi ordenador basado en una SP8000E

Vicente Navarro — Mon, 21 May 2007 22:04:00 +0000

Como continuación de la entrada anterior Sobre las VIA EPIA (I): Introducción al formato Mini-ITX y a las placas EPIA, en ésta voy a comentar los componentes que seleccioné para mi sistema basado en este formato.

La placa

Cuando yo estaba planificando mi sistema basado en una VIA EPIA, las placas con chipset CN700 acababan de ser anunciadas por VIA y no se podían comprar ni podrían serlo en unos meses, así que me quedé con la mejor opción fanless y chipset CN400 de aquel momento: con una SP8000E.

(...)

Leer el resto de Sobre las VIA EPIA (II): Mi ordenador basado en una SP8000E (1,008 palabras)

Lo hice y lo entendí © Vicente Navarro 2007 con una licencia CC BY-SA | 7 comentarios
Etiquetas: Hauppauge WinTV-HVR-1100, SP8000E, VIA EPIA

Entradas relacionadas

Feed enhanced by Better Feed from Ozh

Sobre las VIA EPIA (I): Introducción al formato Mini-ITX y a las placas EPIA

Vicente Navarro — Thu, 10 May 2007 17:42:51 +0000

En los últimos meses se han popularizado los Mini PCs o PCs SFF (Small Form Factor). Podemos verlos ya fuera de medios especializados, como en El Mundo o en El Pais. En medios más especializados, como Tom’s hardware, llevan bastante más tiempo siguiendo el tema.

Además de los PCs SFF, también están los HTPC (Home Theater PC), PCs conectados al televisor, normalmente con sintonizador, mando a distancia y teclado/ratón inalámbricos , y a poder ser integrados, pequeños y que se puedan usar en el aire, como el de la siguiente imagen (el que yo uso):

Tom’s hardware también se ha dedicado mucho en los últimos meses a estudiar los HTPC, y como ejemplo de HTPC de comprar y usar (sin tener que tocar un destornillador para nada), la línea de Scaleo EV de Fujitsu-Siemens. He tenido la oportunidad de verlos en tiendas y me parecen un complemento excelente para una de esas mega pantallas que tanto se llevan últimamente. Eso sí, estamos hablando de 1200€ para arriba.

Hace algo más de un año yo estaba venga a darle vueltas a todos estos temas. Yo quería un PC para el salón con los siguientes requisitos:

Que sirva para acceder a Internet (Web y Correo) cómodo desde el sofá
Que sirva para tener algunos servidores típicos (p.e. ssh, web)
Que decodifique TDT y la grabe
Que sea pequeño, con caja horizontal y no superior al tamaño típico de un vídeo VHS
Presupuesto del orden de 500€
Bajo consumo para tenerlo siempre encendido con algún programilla P2P (para bajar el Knoppix con Bittorrent, ¡malpensados!)
Y, sobre todo, sobre todo, que no haga ningún ruido

(...)

Leer el resto de Sobre las VIA EPIA (I): Introducción al formato Mini-ITX y a las placas EPIA (2,611 palabras)

Lo hice y lo entendí © Vicente Navarro 2007 con una licencia CC BY-SA | 26 comentarios
Etiquetas: Mini-ITX, OpenSSL, SP8000E, VIA EPIA

Entradas relacionadas

Feed enhanced by Better Feed from Ozh

Integrar drivers de SATA/RAID en un CD de instalación de Windows XP

Vicente Navarro — Sun, 15 Apr 2007 23:07:15 +0000

Recientemente un familar muy cercano se ha comprado un flamante portátil HP Pavilion dw9286ea. Es, y será durante unos meses, un ordenador impresionante, con Intel® Core™ 2 Duo T5600, 2GB de RAM, dos discos de 120Gb, NVIDIA® GeForce™ Go 7600 con 512Mb de memoria dedicados, pantalla BrightView de 17″ y para redondear, sintonizador de DVB-T y mando a distancia.

Viene con Windows Vista, y aunque el Knoppix va de maravilla en él, su propietario prefiere tener Windows XP, ya que los programas de CAD no van bien en Vista ni en términos de rendimiento ni en términos de compatibilidad. En cualquier caso, aunque no usara CAD yo apoyaría la decisión, ya que el Windows Vista parece un sistema operativo mucho más bloated que el veterano XP. Y de cualquier forma, parecería conveniente esperar a que el SP1 apareciera antes de que acabe el 2007.

(...)

Leer el resto de Integrar drivers de SATA/RAID en un CD de instalación de Windows XP (1,617 palabras)

Lo hice y lo entendí © Vicente Navarro 2007 con una licencia CC BY-SA | 235 comentarios
Etiquetas: drivers, nLite, SATA, VFD, Windows

Entradas relacionadas

Feed enhanced by Better Feed from Ozh