domingo, 27 de abril de 2008

La informática de antaño

   Estaba haciendo limpieza el otro día en el trastero y al abrir un par de cajas me he encontrado con todo tipo de hardware que me ha hecho recordar cómo era todo en el mundo de la informática hace algunos años. Me he decidido a hacer unas cuantas fotos y a recordar...

Tarjetas perforadas: Datan de los años 1960-1970 y se utilizaban para introducir instrucciones en los ordenadores. Actuan como un código binario en función de si están perforadas o no. Como véis tengo unas cuantas, en total hay 25 perforadas y 4 vírgenes. He querido destacar un fragmento de código de una tarjeta en la que se ve una fecha: 31 de Marzo de 1981, seguramente era para sacar un listado a final de mes. Por aquel entonces sólo utilizaron la fecha con formato 31.03.81 y no se preocuparon de lo que ocurriría en el año 2000... ;-)
   He hablado con mi padre puesto que las tarjetas eran suyas y las utilizó en el trabajo hace mucho y me ha contado que tenían una especie de máquina de escribir en la que tecleaban la instrucción en Cobol y cuando la terminaban la máquina perforaba la tarjeta. Así, iban construyendo el programa línea a línea y al final colocaban todas las tarjetas en un alimentador de hasta 5000 tarjetas que se encarga de leerlas e ir ejecutando el programa. Estos programas corrían contra un host IBM 3090 que estaba en Alemania (mi padre trabajaba desde Madrid). He buscado información de esa máquina y para aquella época era impresionante: dos o cuatro procesadores y 64 ó 128 MB de almacenamiento (según modelo). Y estamos hablando de principios de los 80!.


Disquetes 8": Los empezó a utilizar IBM a finales de los 60 para cargar el microcódigo de arranque en sus mainframes System/370. Antes de disponer de esta unidad de disco utilizaban unidades de cinta para realizar esta carga, pero el proceso era muy lento. Si os fijáis en el de la izquiera, podéis ver que la capacidad era de sólo 1024 bytes, es decir, un "miserable" Kbyte!!.


Disquetes 5.25": El primer prototipo se diseñó en 1975 y surgió por la necesidad de cambiar los discos de 8" que resultaban demasiado grandes. Seguramente los más viejos del lugar recuerden las disqueteras de sus primeros 8086 y la "gran cantidad de información" que podíamos almacenar en estos disquetes. En las fotos véis que la capacidad había aumentado considerablemente, yo tenía de 360 KBytes y de 1.2 MBytes. El disquete de arriba a la derecha es la versión 3.21 de D.O.S.


Disquetes de 3.5": Surgieron a mediados de los 80 como sustitutos de los de 5.25". Por aquel entonces éstos últimos ya no resultaban nada prácticos y además se podían estropear con mucha facilidad. Así, después de diversos formatos e intentos por reducir el tamaño se llegó a los discos de 3.5" que todos conocemos. Las ventajas eran innumerables: formato mucho más pequeño, más capacidad debido al rediseño que se hizo, estaban protegidos por una pequeña chapita,... De estos seguro que sí os acordáis todos. Como podéis ver tengo unas cuantas cajas con juegos clásicos (Monkey Island, Doom, Maniac Mansion,...), multitud de programas (WordPerfect, dBase III,...), discos de arranque... grabados en disquetes de 3.5" y la mayoría comprimidos con el mítico ARJ.


Platos de disco duro: Aunque seguro que la mayoría ha desarmado algún que otro disco duro, los platos de abajo son los normales de discos duros de 3.5" y los de arriba son de discos duros mucho más antiguos. Seguramente no tenían ni siquiera 20 MBytes de capacidad, por lo que os podéis hacer una idea de cuando serán.


Placa de 486: Esta es la placa de un 486DX 50Mhz. Como véis por aquel entonces no había slots PCI y lo máximo eran los nuevos slots VESA Local Bus que creo que nunca llegué a utilizar.


Memorias SIMM de 30 contactos: Las que utilizaba en la placa anterior con mi 486. Empecé con 4 Mbytes cuando me compré el ordenador pero un año después lo amplié con 8 MBytes más. Con esos 12 Mbytes era capaz de ejecutar todos los juegos nuevos sin ningún problema y el ordenador iba muy fluido. Todavía conservo 16 módulos (recordad que iban de 2 en 2) de diversos tamaños que en total suman 152 MBytes de RAM.


Tarjetas gráficas ATI Mach: Todavía conservo un par de tarjetas gráficas de la época. La de abajo es una ATI Mach32 ISA y la de arriba una ATI Mach64 PCI. ¡Qué buenos ratos me hicieron pasar las dos!.


Tarjetas de red: Todas 3Com de diversos modelos. Las de la izquierda son de 10 MBits/seg y conexión ISA, las inferiores de 10 Mbits/seg y conexión PCI y las superiores de 100 Mbits/seg y conexión PCI.


Tarjetas de sonido: Las míticas Sound Blaster AWE 64. ¿Quién no ha tenido una Sound Blaster en su máquina?.


Controladora SCSI: Tiene conexión ISA y creo que nunca la llegué a utilizar, tengo poco que añadir...


Unidad de cinta: En la época de los discos duros de 120MB que parecía que nunca los ibas a llenar y que al final terminaban llenos de juegos (de MS-DOS, claro). La unidad de cinta era perfecta para poder hacer backups de tus juegos y los pocos datos que se acumulaban por aquel entonces. La capacidad era abrumadora porque en una sóla cinta entraban 340MB!. Tenía una unidad externa que se conectaba al puerto de paralelo y posteriormente me hice con esta interna que se conectaba al cable de la disquetera. Las transferencias eran bastante lentas pero podías dejar el backup lanzado y cuando volvías tenías todo tu disco duro en una pequeña cinta.


Cintas de backup: Como ya he comentado tenían 340 Mbytes de capacidad que incluso se podían duplicar si los backups se hacían con la compresión habilitada.


Pentium MMX: Este micro fue una mejora realizada a los primeros Pentium que les añadía las Multimedia Extensions.


Pentium Pro: Fue el procesador diseñado por intel para reemplazar a los Pentium originales. Se utilizó básicamente en servidores y estaciones de trabajo de alto rendimiento y su característica principal es que estaba diseñado para poder montarse en placas bi-procesador.


Placa Pentium 2: Esta era mi placa para el pentium 2 a 300 Mhz que tuve. Esta placa ya llevaba memoria SDRAM, tenía slots PCI e ISA y además introducía el AGP para la conexión de la tarjeta gráfica. Este ordenador me estuvo acompañando muchos años y todavía funciona. En la entrada Servidor Raid 1 en Preproducción de marzo de 2007 comentaba que lo había montado de nuevo para hacer una prueba del raid 1 en linux con hardware real.


Pentium 2: Intel creó este micro después del Pentium Pro. La principal característica que más llamaba la atención era su enorme tamaño y su encapsulado. Era algo totalmente distinto a lo que estábamos acostumbrados a ver.


Memoria SDRAM: Este tipo de memorias ya no era necesario montarlas de 2 en 2 y fueron las precursoras de las actuales DDR, DDR2,.... Se podían mezclar de cualquier tamaño y funcionaban sin problemas. La mayoría de los módulos que tengo funcionan y en total suman 896 MBytes de RAM repartidos en los 10 módulos que se ven.


Tarjetas PCMCIA: El principal uso de este tipo tarjetas es para utilizarlas como expansión en los portátiles. Así, en los tiempos en que éstos no tenían ni modem ni tarjeta de red integrados con una simple tarjeta pcmcia se podían ampliar. Este tipo de tarjetas se podían conectar y desconectar en caliente (el famoso plug&play).


Discos duros: En total tengo 14 discos duros IDE de los que seguramente no debe funcionar casi ninguno. Son discos muy antiguos y su capacidad va desde los 850 MBytes a los 4.2 GBytes. Los fabricantes son Seagate, Sansumg, Quantum y Fujitsu.


   A todo esto que habéis visto hay que añadirle multitud de cables IDE, cable de red, conectores DB25 y DE9 desarmados y listos para soldar en un cable, cables de audio de los que se conectaban a la tarjeta de sonido y al lector de cd's, algún lector de cd's y grabadora antigua, tres modems de 33.6 bps y 56 bps... y diverso hardware más.

   Quiero dar las gracias a mi padre que ha estado muchos años dedicándose a esto y gracias al cual he podido estar cerca de todo lo que acabáis de ver. Muchas veces he pensado que si él hubiese sido albañil, fontanero, mecánico... en lugar de informático, yo no habría llegado donde estoy ni tendría esta pasión y afición que tengo por la informática. ¡Muchas gracias papá!.
   Además, tampoco me olvido de mi mujer por dejarme conservar todas estas reliquias y cacharros viejos como los llama ella en el trastero...

jueves, 17 de abril de 2008

Un diez para el SAT de Rimax

   Hace un año mi hermana nos regaló una cámara de vigilancia de bebés para que la tuviéramos lista para cuando naciera Judith. Durante todo este tiempo la hemos estado usando por las noches para vigilarla por si se despierta, llora o le pasa cualquier cosa. Es muy útil y práctica porque no te tienes que levantar de la cama y puedes ver en cualquier momento cómo se encuentra.

   El caso es que la semana pasada se nos estropeó el adaptador de corriente de la cámara y con las pilas casi seguro que no nos duraba encendida toda la noche. Miramos en la web de Rimax en el apartado de garantías y el servicio que ofrecen es de lo mejor. Te dan 2 años completos de garantía para todos sus productos. Se compromenten a recogerlo en tu casa, repararlo o sustituirlo por uno nuevo en caso de no poder hacerlo y enviártelo de nuevo a casa sin ningún coste adicional. Al día siguiente de tramitar la garantía se pusieron en contacto conmigo por email solicitando una copia del ticket para comprobar la fecha de compra. Me dijeron que les indicara claramente cual era el cargador que fallaba (cámara o monitor) y que me enviarían uno nuevo. Como el del monitor también me fallaba a veces les pedí los dos. En dos días llegó por mensajería un paquete con los dos cargadores nuevos y desde entonces ya podemos usar de nuevo la cámara por las noches.

   Cuando elegimos la cámara no conocíamos el excelente servicio post-venta que tiene Rimax. Esto ha hecho que a partir de ahora, cuando tenga que comprar cualquier gadget mire si Rimax tiene algo que me interese, porque es una marca que voy a tener muy en cuenta en el futuro. Escribiendo este post me he acordado de las peleas que tuve durante casi 6 meses con Panasonic por un móvil que le regalé a mi mujer hace más de 4 años, pero esa es una historia para otro post...

lunes, 7 de abril de 2008

¿OOXML?... No, gracias


   Se ha hablado y escrito mucho la semana pasada sobre la aprobación de OOXML por parte de ISO como estándar. En los medios más importantes se recogen numerosos comentarios, críticas, lamentos,...
Se habló tanto en slashdot como en barrapunto de la aprobación por parte de ISO. Kriptópolis también se hizo eco de la noticia y posteriormente se conocieron la manipulación de Polonia y las irregularidades de Noruega.

   A partir de ahí han habido numerosas declaraciones. Uno de los que más duramente han cargado contra ISO y OOXML ha sido Mark Shuttleworth (fundador de Ubuntu) que no se ha mordido la lengua.
Pienso que devalúa la confianza que las personas tienen en los procesos de estandarización. Es triste que ISO no quiera admitir que todo el proceso ha fallado gravemente. Cuando tienes un proceso construido sobre la verdad y cuando se abusa de esa verdad, el proceso se debería parar.

   Y para finalizar Rosa García, presidenta de Microsoft España nos sorprendió el pasado viernes con esta entrada en su blog. Desde su posición es lógico que tenga que defender OOXML, pero clama al cielo lo que comenta en el artículo. De hecho, lo leí el viernes por la noche y no tuve más remedio que contestarle en su blog:
Iván
04 abril 23:52
(http://lopezivan.blogspot.com)
¡Qué fuerte me parecen estas palabras!

Todo el mundo sabe que lo único que quería conseguir Microsoft con la estandarización es obligar a todo el mundo a usar su formato. Vale que dices: "...tras el último anuncio de interoperabilidad de Microsoft, a corto plazo será posible “guardar como” ODF desde cualquier aplicación de Office por defecto si así se desea."
Quien va a usar eso?. El usuario de "a pie" no sabe nada de formatos ni tiene idea de nada. Si cuando va a guardar su documento el formato que aparece por defecto es ooxml, pues ese será con el que se guardará.

Otro: "El estándar presenta algunas limitaciones en diversos aspectos, como la gestión de fórmulas en hojas de cálculo o las funcionalidades de accesibilidad, para garantizar que las personas con discapacidad puedan utilizar los documentos en formato ODF pero, en cualquier caso, Microsoft no se opuso en su momento a la estandarización de ODF".
Comentas que existen muchos formatos de imágenes, de compresión de videos,... y que ODF tiene algunas limitaciones. La solución pasa por una revisión del estándar ya existente, no por hacer uno nuevo.

Otra perla: "El proceso de estandarización de Open XML ha sido transparente y ha cumplido todos los requerimientos de ISO. El estándar se ha aprobado por mayoría absoluta, con el apoyo del 86% de los países miembros de ISO. Por encima de cualquier otro condicionante, el respaldo de la gran mayoría de los países representados en ISO demuestra que la lógica técnica es la que finalmente se impone."
Toda la blogosfera y muchísimos medios se han hecho eco de lo que ha ocurrido con las votaciones y cómo se han amañado. ¿Cómo es posible casos como el de Noruega que con 19 votos en contra y sólo 5 a favor, el país vote sí?. Está claro, se han movido maletines y se ha sobornado a mucha gente.

Más: "Desde el momento en que ECMA e ISO aprueban el formato Open XML como estándar internacional, Microsoft deja de controlar este formato, que pasa ahora a depender de los cuerpos de estandarización internacionales".
No nos engañemos, con esas 6000 páginas de especificación, muy pocas empresas distintas a Microsoft van a ser capaces de implementar completamente el formato, por lo que al final, sólo serán los productos de Microsoft los que lo puedan utilizar bien.

Entiendo que tienes que defender a tu compañía pero hay cosas que comentas que no son normales. En fin...

Saludos, Iván.

   Para finalizar, yo lo tengo muy claro. No pienso instalarme office 2007 (todavía utilizo el 2000 las pocas veces que entro en windows) y no pienso utilizar ooxml. Convertiré todos mis documentos a ODF y haré "campaña" con familiares y amigos para que utilicen ODF en lugar de ooxml.
   ¿Alguien piensa qué ocurrirá con sus documentos dentro de 15, 20 ó 50 años si están todos bajo control de Microsoft?. Yo no pienso pasar por el aro. Cuando la gente empiece a instalarse masivamente el office 2007 en sus casas (pirata, por supuesto) y empiecen a enviar las típicas chorradas en ooxml, simplemente les responderé a su email diciendo que si desean que ese documento lo pueda utilizar todo el mundo, lo conviertan y lo envíen con un estándar de verdad como es ODF y no con otro conseguido a golpe de talonario. Eliminaré el email y listo, una chorrada menos.

martes, 1 de abril de 2008

Convertir un raid 1 a un raid 5 sin formatear

   Hace un mes Javier Ros me contaba que se había montado un servidor Ubuntu en casa con un raid 1 para almacenar sus datos siguiendo mi artículo del Raid 1 en Linux. En ese mismo comentario me planteaba que se le estaba llenando el raid y que en lugar de hacer un nuevo raid 1 (puesto que necesitaba dos discos adicionales) había pensado en hacer un raid 5 añadiendo solamente un disco más. Así, me pasaba un enlace que había encontrado en el que se muestra cómo pasar de un raid 1 a un raid 5 sin necesidad de formatear y sin perder la información.

   Como sabéis, no me creo las cosas si no las pruebo. Además he estado buscando información sobre cómo funciona un raid 5 y cómo puede ser posible hacer el cambio sin perder los datos. Así, en este artículo vamos a ver un poco de teoría, posteriormente la conversión de un raid 1 a raid 5 siguiendo el tutorial inicial añadiendo mis propios comentarios, y finalmente mis impresiones sobre el raid 5.

Un poco de Teoría
   Un raid 5 es la evolución lógica de un raid 4. Divide los datos en bloques y distribuye la paridad entre el total de discos del raid. Así, se elimina el problema del raid 4 de tener la paridad en un único disco y que éste se convierta en un cuello de botella. Este tipo de raid tiene una tolerancia a los fallos de un disco. Si uno falla el raid puede seguir funcionando y cuando se reemplaza el disco que ha fallado, se puede reconstruir la información que falta partiendo de la existente en el resto de discos.

   El cálculo de la paridad se realiza con la función lógica XOR cuya característica es que devuelve 1 si los bits de entrada son diferentes y 0 si son iguales. Esta es una característica muy importante puesto hace que dicha función sea reversible. Veámoslo con un ejemplo para que quede más claro:
 BinarioDecimal
A11000110198
B0010010137
XOR11100011227

   Como hemos dicho, la función es reversible, por lo que si "le damos la vuelta":
 BinarioDecimal
A11000110198
B11100011227
XOR0010010137

   Es decir, que partiendo de A y teniendo la paridad podemos calcular B. Esta propiedad también se aplica a A XOR B XOR C XOR D ... XOR N = PARIDAD, de manera que si tenemos un raid de N discos y falla cualquiera, la información que falta se puede calcular sin problemas partiendo del resto de datos y de la paridad.

   El truco para realizar la conversión consiste en que si aplicamos dicho algoritmo a dos discos, lo que obtenemos es que los dos discos se quedan en espejo!. Esto es así porque la paridad de un único bloque es él mismo, debido a que el algorimo del raid 5 necesita al menos dos bloques. Así, la única diferencia entre un raid 1 de dos discos y un raid 5 de dos discos son los metadatos. Si reemplazamos estos metadatos convertiremos el raid 1 en un raid 5.

La parte práctica
   Ahora ya sí, con la teoría aprendida vamos a realizar la conversión. Partimos de un sistema Debian ya instalado con un raid 1 creado con 2 discos y al 99% de su capacidad.
shian:~# df -h
Filesystem Size Used Avail Use% Mounted on
/dev/md3 496M 464M 6.3M 99% /mnt/md3

  • Desmontamos el raid y lo paramos.
    shian:~# umount /dev/md3
    shian:~# mdadm --stop /dev/md3
    mdadm: stopped /dev/md3
  • Creamos el raid 5 con los dos dispositivos del raid 1 (sdf1 y sdg1).
    shian:~# mdadm --create /dev/md3 --level=5 --raid-devices=2 /dev/sdf1 /dev/sdg1
    mdadm: /dev/sdf1 appears to contain an ext2fs file system
    size=524160K mtime=Wed Mar 26 16:43:27 2008
    mdadm: /dev/sdf1 appears to be part of a raid array:
    level=raid1 devices=2 ctime=Wed Mar 26 15:09:37 2008
    mdadm: /dev/sdg1 appears to contain an ext2fs file system
    size=524160K mtime=Wed Mar 26 16:43:27 2008
    mdadm: /dev/sdg1 appears to be part of a raid array:
    level=raid1 devices=2 ctime=Wed Mar 26 15:09:37 2008
    Continue creating array? y
    mdadm: array /dev/md3 started.
  • Podemos observar cómo se reconstruye el raid y en la información detallada vemos que ya es un raid 5.
    shian:~# cat /proc/mdstat
    Personalities : [raid1] [raid6] [raid5] [raid4]
    md3 : active raid5 sdg1[2] sdf1[0]
    524160 blocks level 5, 64k chunk, algorithm 2 [2/1] [U_]
    [=====>...............] recovery = 27.1% (143104/524160) finish=0.5min speed=11008K/sec

    shian:~# mdadm --detail /dev/md3
    /dev/md3:
    Version : 00.90.03
    Creation Time : Wed Mar 26 17:19:26 2008
    Raid Level : raid5
    Array Size : 524160 (511.96 MiB 536.74 MB)
    Device Size : 524160 (511.96 MiB 536.74 MB)
    Raid Devices : 2
    Total Devices : 2
    Preferred Minor : 3
    Persistence : Superblock is persistent

    Update Time : Wed Mar 26 17:20:16 2008
    State : clean
    Active Devices : 2
    Working Devices : 2
    Failed Devices : 0
    Spare Devices : 0

    Layout : left-symmetric
    Chunk Size : 64K

    UUID : df77ed88:83aa5bac:daa25bcf:b5b2c6e7
    Events : 0.2

    Number Major Minor RaidDevice State
    0 8 81 0 active sync /dev/sdf1
    1 8 97 1 active sync /dev/sdg1
  • Ahora añadimos el nuevo disco para tener los 3 que queremos en el raid 5 y ampliamos el dispositivo. Podemos comprobar que se ha añadido el nuevo disco que se está redimensionando el raid.
    shian:~# mdadm --add /dev/md3 /dev/sdh1
    mdadm: added /dev/sdh1

    shian:~# mdadm --grow /dev/md3 --raid-disks=3 --backup-file=/tmp/raid1-5.backup
    mdadm: Need to backup 128K of critical section..
    mdadm: ... critical section passed.

    shian:~# cat /proc/mdstat
    Personalities : [raid1] [raid6] [raid5] [raid4]
    md3 : active raid5 sdh1[2] sdg1[1] sdf1[0]
    524160 blocks super 0.91 level 5, 64k chunk, algorithm 2 [3/3] [UUU]
    [=>...................] reshape = 8.3% (44544/524160) finish=2.6min speed=2969K/sec
  • Forzamos la comprobación del filesystem y lo redimensionamos.
    shian:~# e2fsck -f /dev/md3
    e2fsck 1.40-WIP (14-Nov-2006)
    Pass 1: Checking inodes, blocks, and sizes
    Pass 2: Checking directory structure
    Pass 3: Checking directory connectivity
    Pass 4: Checking reference counts
    Pass 5: Checking group summary information
    /dev/md3: 20680/131072 files (0.6% non-contiguous), 491521/524160 blocks

    shian:~# resize2fs -p /dev/md3
    resize2fs 1.40-WIP (14-Nov-2006)
    Resizing the filesystem on /dev/md3 to 1048320 (1k) blocks.
    Begin pass 1 (max = 64)
    Extending the inode table XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
    The filesystem on /dev/md3 is now 1048320 blocks long.
  • Después de montar de nuevo el raid, comprobamos el nuevo tamaño (los 500MB del nuevo disco):
    shian:~# df -h
    Filesystem Size Used Avail Use% Mounted on
    /dev/md3 992M 465M 476M 50% /mnt/md3
  • No se nos puede olvidar finalmente modificar el archivo /etc/mdadm.conf para que se actualicen los datos de nuestro nuevo raid 5.
    shian:~# cd /etc/mdadm
    shian:/etc/mdadm# cp mdadm.conf mdadm.conf.`date +%y%m%d`
    shian:/etc/mdadm# echo "DEVICE partitions" > mdadm.conf
    shian:/etc/mdadm# mdadm --detail --scan >> mdadm.conf

  • Conclusiones
       Hemos visto que es posible realizar la conversión de un raid 1 a un raid 5 sin perder los datos y sin necesidad de recrear el raid desde cero. Aún así, la pregunta es ¿merece la pena pasar a un raid 5?.
       Depende. Para un entorno doméstico sin mucha carga y sin un uso muy intensivo yo diría que sí. La alternativa a tener un raid 5 pasa por un raid 10, pero en este caso ya necesitaríamos 4 discos en lugar de tres. La capacidad del volumen total sería la misma en ambos casos, pero para el raid 10 utilizaríamos un disco más!. En el lado positivo tendríamos dos discos de redundancia a fallos (uno de cada mirror), recuperaciones mucho más rápidas y mayor rendimiento.
       Por contra, el principal problema del raid 5 es el tiempo de recuperación en caso de fallo de un disco y el pobre rendimiento que obtenemos cuando se está realizando dicha recuperación. De nuevo, en un entorno doméstico esto no debería representar mayor problema, pero aún así es un hecho a tener en cuenta antes de tomar la decisión final.