Archivos Mensuales: enero 2009

Mercadeo versus tecnología en discos Western Digital

Estaba leyendo una noticia en computerworld acerca de la salida al mercado del disco duro Western Digital; según la noticia el disco no solamente es el disco comercial con mayor capacidad actualmente (2TB) sino que además es un disco duro “verde”; es decir, bueno con el medio ambiente; comparando el consumo de la tarjeta madre; los microprocesadores de cuatro núcleos y las monstruosas tarjetas de video de 1Gb NVIDIA SLI; no veo como un descenso del consumo en watts de 10 watts (del promedio de la competencia) a 8 watts (lo que consume el disco WD) pueda ser considerado “verde”; además afirma que se calienta menos! (puedo asegurar que mi actual configuración de discos seagate no está ayudando al calentamiento global ni calentando la atmosfera para cambiar el clima ártico); esta paranoia del “verde” se une a la del “light” de la comida; Gelatina Light! (es la misma proteína pura de hueso de vaca; dudo que haya diferencia notable entre comer la normal o la light; pero en fín).

Sin embargo; en la parte técnica si podemos hablar bastante; por ejemplo sobre pérdidas en performance sobre el hecho de ser “verde” y además; del escandalo reciente sobre que los discos duros Western Digital venian con los ticks de descanso de cabezal contados (más o menos; medio millón de ticks; que se pueden alcanzar en un computador medianamente usado alrededor de dos años); al alcanzar este tick final (que supuestamente mide la fatiga del cabezal) se presenta el fatídico caso del “Click of death” que no es más que un fallo intermitente del cabezal de lectura sobre los platos y deja inservible el disco duro (les aseguro que si escuchan el audio que está en la página de Wikipedia recordarán malos y viejos momentos).

Si buscamos “click of death” en Internet; el 70% de las búsquedas; videos de google, de youtube, experiencias en foros y demás tratan acerca de discos duros Western Digital; la razón básica radica en el mismo principio de mercadeo de las bombillas de Edison; si eran eternas, no venderemos nunca más bombillas! (o el principio de Dupont y las Poliamidas eternas con Wallace Carothers); a diferencia de un bombillo que solo nos deja sin luz; en sumatoria he perdido más de 2 TB (lo que mide el nuevo disco) en información en los últimos 5 años, información que estuvo almacenada en discos Western Digital.

¿Quieren llorar conmigo?, una vez perdí una colección de 250Gb en música por tenerla en un disco duro Western Digital; lo más cumbre es que los respaldos (que estaban en otro Western Digital gemelo al primero); se perdieron porque el disco respaldo se dañó aproximadamente una semana después que su hermano.

No suelo hacerle publicidad buena o mala a ninguna marca; pero si quieren cuidar sus datos, les recomiendo que no usen Western Digital.

Y para que comparen como a veces la tecnología no avanza para bien; mi disco duro Fujitsu de 4Gb aun sigue funcionando y sin problemas después de 8 años!

Es que las cosas ya no las hacen como antes! …

[Downadup] Un virus más, Una razón más

Estuve leyendo algunas entradas y artículos (https://forums.symantec.com/t5/blogs/blogarticlepage/blog-id/malicious_code/article-id/224 y http://www.symantec.com/security_response/writeup.jsp?docid=2008-112203-2408-99&tabid=2) sobre el último “gran virus” para los Sistemas Operativos de Microsoft; además de interesarme el algoritmo (o la idea como tal) de generar aleatoriamente 500 dominios y descargarse de alguno de ellos un binario infectado para realizar lo que Microsoft siempre ha llamado “Allow Remote Code Execution” (o como siempre dice la explicación “un atacante malicioso podrá tomar control de su casa, tomar a su mujer e hijos y llevarselos, no sin antes beberse su café); además de generar un http server “casero” con tu computadora para convertirla en un “zombie” más de la red de infección del mundo; lo más interesante del hecho es que no solamente es un virus bastante “expandido”:

mapa de infección del virus downadup

mapa de infección del virus downadup

Sino que; además, el virus ataca de una manera masiva (más de 10 millones de ordenadores en menos de una semana) un agujero que “supuestamente” ya habia sido tapado con un “parche de seguridad”; en efecto, según el siguiente MSB (Microsoft Security Bulletin):

http://www.microsoft.com/technet/security/Bulletin/MS08-067.mspx

Ese “fallo de seguridad” ya habia sido cubierto, por lo que “no debería” estar atacando, pero lo está.

El virus puede viajar en múltiples formas, incluyendo a través de memorias USB donde se esconde en esos archivos “ocultos” (excepto para los usuarios linux) con posibilidad de auto-ejecución (autorun).

El virus ataca cualquier variante del sistema operativo de MS incluyendo Windows Vista y Windows Server 2008 (incluyendo la cosa esa “parecida a Linux” para servidores que se inventaron del “windows sin windows” del Windows core 2008 e incluso el “novisimo” Windows 7) y el único parche actual de seguridad y las firmas de patrones de virus solo pueden EVITAR la infección de un equipo “sin infección”; ya que la única forma de salvación actual (según la gente de Microsoft y Symantec) para equipos ya infectados, es la “reinstalación total del equipo” (o en su defecto, una “facil” lista de 27 pasos que incluye detención de servicios, inicio en modo seguro, descarga por otras vias de aplicaciones de limpieza, modificación del registro, de servicios e incluso buscar los autorun.inf y desktop.ini de todas las unidades y todas las carpetas de sistema y repararlos uno a uno, o sea!).

Parafraseando el slogan de Microsoft; “¿Qué virus quieres limpiar hoy?” …

Y todavia la gente no ve razones para abandonar Windows? …

Un detalle sobre Xen y Debian Lenny

Estuve haciendo pruebas de levantar sobre GNU/Linux Debian Lenny el Xen que “oficialmente” viene para Dom0; el kernel 2.6.26-1 (traido desde Fedora por cierto) y luego de instalarlo y hacer un “update” de todos los paquetes se me presentó el siguiente error:


[2009-01-20 15:28:55 2595] INFO (SrvDaemon:219) Xend exited with status 1.
[2009-01-20 15:29:48 2625] INFO (SrvDaemon:331) Xend Daemon started
[2009-01-20 15:29:48 2625] INFO (SrvDaemon:335) Xend changeset: unavailable.
[2009-01-20 15:29:48 2625] INFO (SrvDaemon:342) Xend version: Unknown.
[2009-01-20 15:29:48 2625] ERROR (SrvDaemon:353) Exception starting xend (no element found: line 1, column 0)
Traceback (most recent call last):
File "/usr/lib/xen-3.2-1/lib/python/xen/xend/server/SrvDaemon.py", line 345, in run
servers = SrvServer.create()
File "/usr/lib/xen-3.2-1/lib/python/xen/xend/server/SrvServer.py", line 251, in create
root.putChild('xend', SrvRoot())
File "/usr/lib/xen-3.2-1/lib/python/xen/xend/server/SrvRoot.py", line 40, in __init__
self.get(name)
File "/usr/lib/xen-3.2-1/lib/python/xen/web/SrvDir.py", line 82, in get
val = val.getobj()
File "/usr/lib/xen-3.2-1/lib/python/xen/web/SrvDir.py", line 52, in getobj
self.obj = klassobj()
File "/usr/lib/xen-3.2-1/lib/python/xen/xend/server/SrvNode.py", line 30, in __init__
self.xn = XendNode.instance()
File "/usr/lib/xen-3.2-1/lib/python/xen/xend/XendNode.py", line 709, in instance
inst = XendNode()
File "/usr/lib/xen-3.2-1/lib/python/xen/xend/XendNode.py", line 60, in __init__
saved_host = self.state_store.load_state('host')
File "/usr/lib/xen-3.2-1/lib/python/xen/xend/XendStateStore.py", line 104, in load_state
dom = minidom.parse(xml_path)
File "/usr/lib/python2.5/xml/dom/minidom.py", line 1915, in parse
return expatbuilder.parse(file)
File "/usr/lib/python2.5/xml/dom/expatbuilder.py", line 924, in parse
result = builder.parseFile(fp)
File "/usr/lib/python2.5/xml/dom/expatbuilder.py", line 211, in parseFile
parser.Parse("", True)
ExpatError: no element found: line 1, column 0
[2009-01-20 15:29:48 2624] INFO (SrvDaemon:219) Xend exited with status 1.

Entonces este fallo imposibilitaba el inicio del Xen Daemon.

La solución

La solución es sencilla y realmente ni merece un post; lo que pasa es que a veces se me olvida y pues de repente a alguien más le sirve.

Simplemente deben eliminar el contenido de la carpeta /var/lib/xend/ con el comando:

rm -fR /var/lib/xend/*

Y listo!, inicien de nuevo el xen (/etc/init.d/xend start); descuiden, las carpetas serán creadas de nuevo al iniciarse el demonio.

A %d blogueros les gusta esto: