Buenas @vreyes1981
Es por la migración a la versión 3 del museo. La biblioteca estará fuera de servicio hasta que se migre a la nueva versión, con suerte, antes de Navidad donde, además, estarán disponibles los discos de la Micromanía que me enviaste.
Samsung ya ha colocado toda la producción de su memoria HBM4 del año 2026. Para ese mismo año, SK Hynix y Micron casi han alcanzado su límite de producción para la generación HBM3E.
En medio de una crisis de inventario de GPUs, memorias y dispositivos de almacenamiento, el jefe ejecutivo de Microsoft ha dicho que no disponen de la suficiente potencia eléctrica como para usar todas las GPUs que han comprado.
Se ha encontrado un fallo de seguridad en CPUs Zen 5 que consiste en que un error en la µinstrucción RDSEED se esta marcando incorrectamente como correcto, lo que lleva a que el generador de números aleatorios genere claves de cifrado predecibles. Se solucionará con una actualización de AGESA.
Esta semana se ha empezado a meter mano al banco de pruebas. A diferencia del museo, el banco de pruebas es una página bastante activa, con muchas visitas y con participación, por lo que no se van a hacer cambios en caliente como con el museo, de forma que la versión 4 saldrá una vez que esté terminada.
Sobre esta versión, los cambios van a ser esencialmente internos enfocados a la migración a MariaDB. También hay muchas guarrerías en el código del estilo, por ejemplo, de tener las versiones de Windows hardcodeadas (entre otras muchas cosas). En general el código es una monstruosidad en tamaño. Es verdad que está muy bien organizado, bien comentado y con una estructura bastante coherente. La exagerada complejidad viene principalmente de usar el SGBD que creé en su momento, que es lo que estoy eliminando ahora.
Toda esta limpieza va a suponer un antes y un después en las posibilidades de mostrar la información y añadir nuevas funcionalidades, pero va a ser en mayor medida transparente de cara al usuario.
Otro cambio relevante (pero no sé si factible), será el generar las páginas en tiempo real: en estos momentos, cada vez que alguien envía un resultado, un script procesa toda la base de datos y genera una caché, que es la que se usa para mostrar la información en el front-end. Lo que quiero es que todo sea lo suficientemente rápido como para que no sea necesario este proceso de cálculo previo.
Espero tener todo esto terminado en cuestión de un par de semanas.
Enhorabuena por el resultado @cobito, increíble trabajazo. Sin duda, el dueño te debe algo más que el agradecimiento.
Gracias por compartirlo por aquí detalladamente, aunque parezca una circunstancia muy particular y aislada, en realidad nunca se sabe cuándo puede ser necesaria toda esta información.
¡Saludos!
Bueno, pues esto llega ya a su fin. La últimas 13 horas de SpinRite han producido un avance de apenas un 1% con bastantes sectores irrecuperables. Esperaba que fueran apareciendo regiones más fáciles pero está pasando todo lo contrario. A este ritmo, esto no es factible. Por una parte, el disco duro está en las últimas y tenerlo encendido tantísimas horas lo va a terminar de destruir. Por otra parte, no quiero reventar mi portátil con esta operación. Así que he cambiado de planes.
Lo que he hecho es copiar los archivos con copy tal cual. Resulta que desde MSDOS 3.30, cuando se encuentran datos corruptos, pueden aparecer uno de los siguientes mensajes. Este:
O este:
La diferencia entre ambos es sutil: el primero da la opción de Ignorar mientras que el segundo no. Según he podido leer, cuando no aparece "Ignorar" significa que el error está en la lectura del sistema de archivos (ahora entenderéis por qué es lógico que no de la opción de ignorar). Cuando sí da la opción de Ignorar, el error está en la región de datos. Esto es interesante porque desde MSDOS 6.22, cuando se produce un error en la lectura de la FAT, directamente sale un mensaje de error de interrupción no sé cuantas y aborta la operación sin preguntar. En ese aspecto, MSDOS 3.30 es bastante más robusto.
Por otra parte, Seguir e Ignorar hacen esencialmente lo mismo con la diferencia de que Ignorar le dice al programa que todo está bien y Seguir le dice que algo anda mal. La decisión se reduce a si se engaña al programa (Ignorar) o se deja que el programa gestione el error (Seguir). En mi caso, el programa es copy y haciendo pruebas, Seguir no copia nada del archivo mientras que Ignorar sí (con fragmentos corruptos). Y es lógico que cuando hay un error de la FAT no permita Ignorar porque sin esa metainformación, sencillamente no se puede acceder a la región de datos.
También he probado ARJ (2.75a), pero al aparecer el error de lectura desde el disco duro, el programa se cuelga. Así que no es una opción.
En resumidas cuentas, lo que está pasando es que cuando el CRC no concuerda, MSDOS da este aviso y tienes dos opciones: no copiar el archivo o copiarlo tal cual se está leyendo, lo cual incluye sectores corrompidos. Así que en este escenario, la opción ha estado clara: usar MSDOS 3.30 e Ignorar los errores. Al ser los datos relevantes documentos de texto, la corrupción de datos se debería poder corregir a mano si no hay muchos bytes corruptos consecutivos. Y si sí los hay, al menos habrá un fragmento del documento accesible.
Ahora os estaréis preguntando, "vale, ignoras los errores de datos, pero ¿qué haces con los errores de la FAT que no se pueden Ignorar?". La cuestión es que SpinRite ha medio-arreglado los primeros dos mil y pico sectores del disco, dentro de los cuales está el sistema de archivos. Gracias a eso, cuando ha aparecido este error, con Reintentarlo varias veces (raro ha sido el caso de más de 2 veces), ha sido capaz de leer la metainformación.
Así pues, el proceso (tedioso de narices), ha consistido en ir copiando tandas de archivos a un disquete para luego pasarlos a mi PC. La estrategia que he seguido para tener cierto orden (hay carpetas con cientos de archivos que no caben en un solo disquete), ha sido copiar grupos de archivos con una extensión determinada.
Pero esa estrategia no ha sido totalmente acertada porque, por alguna razón (seguramente por la cantidad descomunal de errores), MSDOS 3.30 se ha saltado (no ha copiado) bastantes archivos en cada tanda. Al final, he tenido que crear dos hojas de Excel: una con el contenido de dir (DIR C:\CARPETA > A:\LISTA.TXT), que tiene el árbol completo y otra hoja con los archivos que, efectivamente, se han copiado. Comparando ambas hojas, he podido sacar una lista de archivos faltantes que he copiado uno a uno.
Vamos, un coñazo de narices. Pero al final he podido verificar que lo que tengo en mi PC coincide a la perfección tanto en número de archivos como en número de bytes con lo que reporta MSDOS 3.30 desde el portátil Epson.
He enviado ya el resultado al dueño del disco. Hay muchísimos documentos 100% correctos y otros tantos con algún sector defectuoso (seguramente muy pocos bytes por documento). Espero que le sirva de algo.
Intel ha sido desde siempre uno de los contribuyentes más importantes en el mundo del software libre, y más en concreto, en Linux. Fue el primero en tener controladores libres para sus GPUs en sistemas x86. Pero ahora dice que va a replantearse su participación para evitar que otros saquen provecho de sus aportaciones.
AMD sigue con su política de estirar sus sockets todo lo posible y ha dicho que los futuros Zen 6 serán compatibles con los actuales zócalos AM5. Esto también confirma que a la DDR6 le queda tiempo para aparecer.
Un consorcio de empresas chinas ha presentado UBIOS, un firmware que pretende sustituir al actual UEFI. Tiene soporte para chiplets y procesamiento heterogéneo.
Fujitsu ha presentado un portátil cuya característica más llamativa es que viene con una unidad de DVD. Según parece, el mercado japonés sigue demandado PCs con unidades ópticas.
La Python Software Foundation ha rechazado una subvención de 1.5 millones del gobierno federal estadounidense debido a que una de las condiciones para aceptar el dinero era no fomentar ningún programa que promueva la diversidad, equidad e inclusión (DEI en términos americanos).
Tanto los discos duros como las memorias RAM de gran capacidad han sufrido un aumento de precio significativo en las últimas semanas. Ahora se ha anunciado que los principales fabricantes de unidades SSD están teniendo problemas para cumplir con los plazos de entrega en sus modelos da mayor tamaño.
Alguien ha creado un servidor de archivos con soporte para http, webdav, ftp, tftp y smb/cifs que se puede ejecutar en teléfonos y ordenadores. Está escrito en Python y el objetivo es poder compartir archivos de forma local.
A día de hoy todos los fabricantes de integrados aprovechan chips defectuosos para sacar modelos de menores prestaciones. Sucede por ejemplo en CPUs, donde un integrado con algún núcleo que no funciona como debe, se marca con un modelo que tiene como mucho, los núcleos funcionales. En esta entrada explican cómo Intel empezó a reaprovechar sus chips fabricados a finales de los 70s.
Parece que todavía hay lugar para la esperanza. Desde el grupo de retroinformática me han recomendado una herramienta llamada SpinRite 4 y parece que se están haciendo avances. Es una especie de HDD Regenerator pero tengo que decir que me parece muy sofisticado el funcionamiento. Se dedica a analizar todos los datos (estén bien o no) y si algún bit entra dentro de una región de indeterminación entre 0 y 1, hace un análisis estadístico de los bits adyacentes para determinar el valor real de la indeterminación. El programa es del 96 y funciona en el V30 con MSDOS 3.30.
Aquí dejo una imagen del programa en ejecución:
Después de más de 3 horas en marcha, dice que quedan algo más de 4 días de análisis para terminar:
Tengo la esperanza de que llegue el momento en el que la superficie empiece a estar en mejores condiciones. En estos momentos, está así (R=Recuperado, Puntitos=Bloque 100% correcto, U=Irrecuperable):
No es para tirar cohetes, pero ni tan mal.
Y aquí os dejo un breve video del setup que tengo montado:
En estos momentos, el disco duro vuelve a ser capaz de arrancar MSDOS 3.30 otra vez.
Bueno, pues esto ha llegado a su límite vital. He podido recuperar bastantes cosas pero quedan otras tantas.
He usado ARJ para hacer una copia de todo el disco y cuando ha llegado a cierta carpeta, el disco duro ha empezado a hacer el clásico reintento de lectura de sectores defectuosos.
Ahora ya no arranca. Supongo que si uso un disquete de arranque podré seguir accediendo. Estoy sopesando todas las posibilidades para tener el disco encendido el menor tiempo posible.
Aquí podéis ver cómo se transfieren los datos a un disquete y cómo falla la lectura del disco al final
¡Qué emoción!
El disco en cuestión tenía el mismo problema que el mio: tenía el eje atacado. Haciendo lo mismo que en el mío, se ha desatascado y ha empezado a rotar. Pero desde mi controladora, no se detectaba.
Así que he probado la que me han dado (la que tiene el condensador arrancado). Esa, a diferencia de la mía, sí hace el amago de arrancar pero el cabezal se queda oscilando y no termina de hacer nada. Como tiene el condensador arrancado, se lo he achacado a eso. Entonces he intercambiado las ROMs a ver si era eso para ver si la mía hacía algo, pero nada.
Después he visto que el pegamento de protección de uno de los condensadores variables de la controladora que me han dado estaba arrancado, así que me he puesto a rotarlo con un destornillador y ¡ha arrancado!
Este ha sido el que he tocado:
Voy a preparar unos disquetes con su pegatina y a pasar datos, a ver si es toda la superficie accesible.
También probaré mi disco, a ver qué tesoros me esconde.
PD: Increíble que funcione sin el condensador. Y también increíble que pueda arrancar el MS-DOS 3.30 que trae después de todos estos años.
