Un año después...

Cuando faltan unos días para que el NAS cumpla su primer año, ha petado uno de los discos. Desde hacía unos meses se escuchaba un clic muy de vez en cuando. Hace unos días, el clic fue muy insistente así que presencié en directo la muerte del disco. El NAS estuvo unos minutos intentando acceder y mientras tanto no era posible acceder al sistema de archivo. Después de ese tiempo, el led de actividad del disco cascado se quedó permanentemente encendido y el RAID siguió funcionando con normalidad. Esa misma noche pedí un disco igual (la verdad es que los Red NAS de 4TB EFAX empiezan a no ser tan comunes). Ayer lo recibí y le pasé un escaneo de superficie física (como hago siempre que compro un disco mecánico). Y anoche cuando lo pasó sin novedades, procedí a la sustitución.

Ha estado reconstruyendo el RAID5 durante 11 horas y vuelve a estar como al principio, con lo que el el NAS en general y el RAID en particular han cumplido como se esperaba. Ahora me toca tramitar el RMA del disco cascado y ese me lo quedaré como repuesto o como ampliación del RAID si me quedo sin espacio (lo que llegue antes).

Sobre el hardware, la placa base con CPU integrada parece una buena elección. Además del silencio y el bajo consumo, no he tenido problemas de cuelgues, inestabilidades y demás. También un ofrece una potencia de procesamiento más que suficiente. Incluso en la reconstrucción del RAID que es una operación costosa, no se llegaba a cargar al 100% uno de los núcleos (el resto de núcleos en reposo). El NAS ha estado funcionando con el disco externo USB de 2.5" con el sistema desde que petó el pendrive y, aunque no es lo ideal, creo que va a seguir así. La mejor solución a futuro será poner una unidad SSD M2.

Y sobre la caja, parece que los leds azules que indican la presencia de disco en la bahía, se están apagando. Es posible que se estén quemando. Podría ser suciedad pero el led verde de actividad (que está justo debajo) luce tan brillante como el primer día, así que tiene pinta de ser un fallo de diseño.

Después de un par de días pasándole un memtest y después de haber comprobado que los tres discos están correctos, hoy me he dispuesto a instalar OMV. Desafortunadamente, parece que esta distro no se lleva muy bien con las instalaciones en pendrives. La instalación ha tardado casi hora y media (cuando en máquina virtual es cuestión de minutos). Cuando el sistema está recién arrancado, la interfaz va bastante lenta pero al cabo de un ratillo empieza a ir bien.

He probado en los 4 USB de la parte de atrás (dos USB 2.0 y otros dos USB 3.x). En todos va igual de mal, pero qué se le va a hacer... Mientras el RAID vaya a velocidad de crucero no tengo mayores problemas con esto.

Ahora estoy creando el RAID 5 y tardará unas 5 horas. Aquí tenéis un par de fotos.

Con la puerta cerrada:

Y con la puerta abierta:

Cada caddy tiene dos leds: de alimentación y de actividad. En la parte de abajo hay 6 leds: alimentación, actividad de discos general, 3 para 3 interfaces de red y uno para alarma. Los 4 últimos no los uso porque no tengo donde conectarlos. Curiosamente, el led de actividad de disco general no siempre se corresponde con la actividad de los discos, supongo que porque ese indica las peticiones de la controladora y los de los caddys indican el movimiento real de datos.

Otro comentario importante sobre esta placa que podría hacerla no apta para sistemas ZFS: no todos los SATAs van igual de rápido. Tiene dos controladoras: una Intel y otra ASMedia ASM1061. La Intel va a máxima velocidad: durante las pruebas de la superficie de los dos discos conectados a ella, la velocidad de lectura iba a unos 320MBytes/s en cada uno con ambos discos leyendo a la vez. En cambio, en el tercer disco, se medían unos 270MBytes/s. Si conecto dos discos a la ASMedia, la velocidad de lectura de los dos a la vez, cae hasta a unos 180MBytes/s cada uno. Desde el punto de vista del rendimiento, no debería de ser dramático ya que al final la tarjeta gigabit es el mayor cuello de botella, pero no me gusta que sea así y menos cuando ZFS tiene pérdidas de datos cuando hay diferencias de rendimiento importante entre discos.

EDITADO: Parece ser que cuando se instala OMV en un pendrive, es muy recomendable instalar el plugin openmediavault-flashmemory para que se copien ciertas carpeta a una ramdisk y así alargar la vida de la memoria. Para instalarlo, primero hay que instalar omv-extras ejecutando en consola como root, esto: wget -O - https://github.com/OpenMediaVault-Plugin-Developers/packages/raw/master/install | bash

@Fassou que va, suelo ser bastante austero con las cuestiones estéticas. Ahora eso sí, la caja tiene una cantidad generosa de leds en el frontal que ya mostraré cuando esté todo montado.

Esta es la parte superior:

Desde aquí se ve la disposición de los 4 conectores SATA y cómo no es posible usar cables con codo de 90º. Una de las cosas que me ha gustado es el hecho de que los 4 discos se alimentan con un solo molex, lo cual es de muy agradecer para ahorrar cablerío.

El ventilador que está justo detrás de los conectores SATA (la PCB tiene agujeros para ayudar a la ventilación), me ha resultado muy silencioso y el flujo de aire no está mal.

Este es uno de los laterales:

En este lateral de la placa se conectarán dos cables SATA más. En total: 4 satas y el de alimentación de la ventilación. Aquí hay espacio de sobra porque han dejado 4cm para poder poner una tarjeta PCI-e.

El otro lateral:

Aquí se ve el follón de cables de alimentación. 8 hilos van al molex (tiene 2 cables por clavija) y luego el manojo ATX hacia la placa. La fuente por cierto, queda en voladizo anclada sólo pro los 4 tornillos en uno de los extremos. Queda bien fijada pero al ser tan larga y pesada no hubiera estado mal tener la posibildad de atornillarla en el otro extremo. La fuente trae una pieza metálica para ello pero la caja no tiene orificios para tornillos.

Y esto es lo que menos me gusta:

Los módulos de memoria van montados verticalmente, el conector de alimentación ATX está justo en frente de este módulo y la chapa de los caddys está justo encima. Aquí los cables tienen que estar bastante doblados. Y justo a la derecha de la alimentación, están los conectores de pulsadores y leds de la caja. Pues con estos dos manojos de cables conectados junto a las memorias y con esa distancia, hay que meter la placa con mucho cuidado de que no roce por abajo.

@_Neptunno_ yo ahora mismo al reves; me apetece perder un poco de tiempo con estas cosas. Es algo que nunca he tocado y siempre le he tenido curiosidad. Hace años (antes de los SSD) me picó el gusanillo por ganar velocidad y ahora me ha vuelto el interés porque la colección de discos duros que tengo es engorrosa, poco eficiente con el espacio, poco fiable y hasta cierto punto, caótica.

Bueno, sigamos con el lío.

La posibilidad de comprimir datos de ZFS con FreeNAS junto al uso de la RAM como caché ha hecho que esta opción despierte mi interés. Lo de la RAM como caché me resulta interesante más como una forma de reducir la actividad de los discos duros y aumentar su vida útil que como un medio de aumentar el rendimiento. El rendimiento no es importante para mi más allá de tener tasas de unas pocas decenas de MB/s que me permitan hacer streaming de video.

Freenas

Voy a repetir el mismo ejercicio que he hecho con OMV (con algunos añadidos).

Montando RAID-z (equivalente a RAID5)

Las unidades RAID en FreeNAS se llaman "pools". Parece ser que la creación de un "pool" consume unos 4GB de disco. De esa forma, si uso 3 discos de 8GB, tengo como resultado una unidad de 12GB. Por confirmar esto, he puesto 3 discos de 4GB obteniendo una unidad resultante de 4GB.

Dejemos de momento los 3 discos de 8GB para hacer el RAID-z.

Las opciones "ADD DATA/CACHE/LOG/SPARE" no sé para qué son y la verdad es que no me motiva demasiado averiguar para qué están ahí. El proceso de creación es bastante rápido:

La unidad parece que se monta en /mnt:

Compresión

Antes de hacerle perrerías, quiero probar una de las características que podría hacer decidirme: la compresión.

Primero voy a copiar un video susceptible de alcanzar un alto grado de compresión (es un archivo mp4 con bitrate constante y pocos cambios en la imagen) usando lz4 (la opción que viene por defecto y que, según he leído, tiene la mejor relación ratio de compresión/consumo de CPU).

El archivo mp4 ocupa 3.5GB:

El resultado es bastante espectacular (ocupa menos de la mitad) y durante la copia, el consumo de CPU más allá del demonio sshd, ha sido muy reducido.

Después de borrar el video, ahora voy a copiar la base de datos del foro (Redis) que tiene un tamaño de 1.4GB:

Aquí el ahorro es menor (un 25% aproximadamente).

Borro todo y copio 1GB de fotos JPG:

Apenas un 10% y aquí el uso de CPU sí ha sido bastante elevando.

Borro todo y copio el episodio de una serie en H.264 que ocupa 2.7GB:

Este también ha sido un proceso intenso en consumo de CPU. El ahorro es de solo un 3%.

Si se copia una imagen ISO de una distribución Linux, el ratio vuelve a ser del 3%.

Para terminar, se lo voy a poner fácil. Voy a copiar 1.5GB de logs Apache de una de las webs:

Pues nada, el archivo de 1.5GB pasa a ocupar 140MB.

Para ponerlo en perspectiva, suponiendo el peor caso posible (el vídeo con un ratio del 3%), en un sistema de archivos de 8TB, supondría un ahorro de unos 240GB. Si se ponen como ejemplo la fotos JPG, el ahorro sería de cerca de 800GB.

En mi caso, tengo claro que merece la pena la compresión, sin ningún tipo de duda. Además existen otras medida de ahorro como la "deduplicación" que hace que varias copias de un mismo archivo ocupen sólo como uno de ellos. Esto es algo que no voy a usar y no lo voy a probar, pero el concepto es sencillo.

Peta un disco duro

Al quitar un disco duro sale esto:

Cuando se añade un disco en blanco, hay que hacer clic en el icono de configuración del "pool" luego en "Status":

Ahí seleccionamos "Replace" en el disco que ha desaparecido:

Finalmente, seleccionamos la unidad en blanco que se ha introducido:

El proceso tardará un rato:

Al final es la misma historia que con OMV.

Ampliación de capacidad añadiendo un nuevo disco

Al intentar expandir el "pool", no he podido (me da un error diciendo que no hay suficientes discos). Según la documentación, no es posible añadir un sólo disco en un RAID-z sino que sólo se pueden añadir el mismo número de discos que había inicialmente, en este caso, 3 discos. Con eso, se conseguiría algo similar a un RAID5+0, que no es lo que yo estoy buscando, porque ese caso implica tener dos discos de paridad en vez de uno solo.

Es decir, que sólo se puede hacer un RAID-z equivalente a un RAID5 en la creación del "pool" pero luego ya te quedan anclado con eso.

Esto la verdad es que es una gran decepción.

Ampliación de capacidad intercambiando un disco de 8GB por uno de 12GB.

El proceso va a ser el mismo que hice con OMV: reemplazar un disco y regenerar RAID, reemplazar el siguiente, etc.

Cuando finaliza el proceso, no encuentro ninguna opción para expandir el sistema de archivos. Leyendo por ahí, dicen que debería ser un proceso automático en el momento en el que todos los discos sean del mismo tamaño, pero después de reiniciar el sistema, sigo teniendo 14GB disponibles.

Así que no sé qué hacer para que vea la nueva capacidad (unos 20GB).

Conclusiones

Ventajas de OMV: Sencillo, estándar, estable, más posibilidades de ampliación, basado en Debian.
Desventajas OMV: Simple/obsoleto (no tiene compresión ni caché).

Ventajas de FreeNAS: incluye últimos avances (compresión, cifrado, protocolos de comunicaciones).
Desventajas FreeNAS: no-estándar*, menos estable, menos posibilidades de ampliación, basado en FreeBSD**.

*Según he leído, FreeNAS activa características de ZFS que no están marcadas como estables. Eso tiene dos consecuencias negativas de peso: una es que la mayoría de distros no son capaces de leer las particiones ZFS creadas en FreeNAS (en caso de fallo, esto es crítico) y la otra es que se están usando caracterísiticas no tan probadas.

**Esto es una opinión personal. Por ejemplo, no sé cómo se lleva el soporte de hardware en FreeBSD (si en el futuro decido poner un Zen8, ¿va a detectar correctamente todo mi hardware? ¿va a usar las técnicas de ahorro de energía? etc, etc, etc). No me hace gracia tener mis datos en manos de un sistema que no conozco. Todo esto tiene además una serie de ramificaciones que no me gustan: ¿qué ocurre si el soporte de FreeNAS desaparece? ¿Qué ocurre si por la razón que sea, no puedo usar FreeNAS para recuperar mis datos? ¿Y si tengo que echar mano de la consola? Ni si quiera sé instalar paquetes en caso de que necesite herramientas que no vienen por defecto.

Si os digo la verdad, desde que he descubierto que no puedo ampliar el "pool" añadiendo discos (que es la forma más económica y sencilla), se me ha caído el mito. Si fuera a montar un RAID con 16 discos con vistas a que me duren 20 años, es probable que eligiera FreeNAS. Pero quiero empezar con algo básico (3 discos) e ir ampliando conforme lo vaya necesitando. Y para eso, FreeNAS me parece una mala opción.

En la próxima entrega, hablaré de la configuración de hardware. De momento, encontrar una caja que me guste está siendo complicado.

He añadido los componentes que vienen en la descripción y me salen 1322€ con componentes que no son refurbished y la primera licencia de Windows 11 Home que he encontrado sin rebuscar. Así que tiene pinta de que sale más o menos por lo mismo comprarlo montado que por piezas.

Estaría bien saber para qué se va a usar: entiendo que es para jugar. La configuración es sí, me parece equilibrada aunque estoy fuera de onda con el tema de las tarjetas gráficas. A ver si alguien te puede echar una mano en esto.

@jordiqui No olvides validar el resultado. Así tenemos una referencia de ese maquinote en la base de datos y se pueden generar comparativas.

@pos_yo Pues lo había pensado tanto para ffmpeg como para la IA. Aunque sea pequeña, lo mismo algo hace. Pero estoy ocupado al 100% (a ver si este finde puedo publicar la versión 4 del banco de pruebas y paso a lo siguiente) por lo que no he podido probar.

Una cosa que sí me preocupa un poco de usar la GPU para codificar video es que hace bastantes años (no sé si el tema habrá cambiado), la GPU aceleraba pero la calidad de imagen era sustancialmente peor que hacerlo con CPU.

Esto está mal a varios niveles. Estoy viendo que cuando python se está ejecutando, todo lo demás va lentísimo y viceversa. Por ejemplo, si hay un proceso de ffmpeg consumiendo un solo núcleo, la velocidad de python (consumiendo 11 en vez de 12 núcleos) cae en picado. Igual pasa al revés.

Sospecho que hay un cuello de botella importante con la memoria y esta no es precisamente lenta (6400MT/s 30-37-37-96 en dual channel). Pero es que el modelo de traducción se dedica a machacar 20GB de RAM, así que es normal que el equipo flaquee por ahí.

Lo que voy a hacer es hacer que python se pause automáticamente cuando vea que hay algún proceso de ffmpeg o whisper en marcha. Creo que es la forma más eficiente de hacerlo todo y de sacarle todo el jugo a la CPU.

Lo de las prioridades lo voy a olvidar ya que parece que el tema no va por ahí, aunque tengo curiosidad sobre por qué no hace caso.

Buenas.

Estoy haciendo cosas con el Ryzen 9 9900X (12 núcleos con SMT desactivado) y quiero priorizar procesos. He estado leyendo sobre el concepto de niceness en Linux que traducido como amabilidad, es bastante intuitivo (cuando más amable es el proceso, más deja pasar a los demás y cuando más incívico y maleducado, se cuela todo lo que puede). Tiene un valor de -20 (más prioritario) a 19 (menos prioritario). Nice lo he usado en el pasado y nunca he tenido problemas, pero al ver el comportamiento que veo ahora, he tenido que documentarme un poco. Aunque no encuentro una solución al tema.

En esta máquina se ejecutan tres tipos de procesos:

• ffpmeg que está configurado para acaparar un hilo de ejecución con un niceness de 19.
• whisper que está configurado para consumir 4 hilos con un niceness de 0.
• python que está configurado para consumir todos los hilos disponibles con un niceness de 19.

Esos valores de prioridad no son casuales: ffmpeg funciona muy rápido con esta CPU, por lo que no me importa que pueda consumir muy pocos recursos. whisper es bastante más demandante y quiero que consuma siempre todo lo que haya disponible. Y Python es muy demandante, pero sencillamente quiero que consuma lo que les sobra a los demás, compartiendo lo que sobre con ffmpeg.

Esta es una caputura de top:

Cuando también hay un proceso de ffmpeg y la CPU está ocupada, consume muy poca CPU (menos del 30%), que es lo que quiero que haga. Pero como veis en la imagen, python está consumiendo prácticamente 6 núcleos mientras que cada proceso de whisper no llega a 2. Y las prioridades, como se puede ver, están correctamente configuradas.

¿Por qué sucede esto y cómo lo podría solucionar?

Gracias.

Este hilo forma parte de la guía para montar un servidor en Debian.
Recuerda que el contenido de Hardlimit está bajo licencia Creative Commons.

---

Procedimiento

Como root:

a2enmod rewrite
nano /etc/apache2/sites-available/000-default.conf

Añadir dentro de la sección VirtualHost correspondiente una sección Directory:

<Directory "/var/www/html">
   Require all granted
   Options Indexes FollowSymLinks MultiViews
   AllowOverride All
</Directory>

/etc/init.d/apache2 restart

Explicación

El archivo .htaccess es un archivo de configuración de vital importancia que se aplica a cada subcarpeta de nuestro servidor. En él podemos hacer cosas como bloquear ciertas páginas, limitar el enlazado de cierto material (como imágenes) y muchos más.

Para habilitarlo, lo único que tenemos que hacer es activar el módulo rewrite, así que escribimos en consola como root:

a2enmod rewrite

Ahora debemos editar con Nano el archivo000-default.conf como root:

nano /etc/apache2/sites-available/000-default.conf

Ahí debemos crear una sección Directory dentro de una sección VirtualHost. Eso se hace copiando el siguiente texto dentro de una sección VirtualHost:

<Directory "/var/www/html">
   Require all granted
   Options Indexes FollowSymLinks MultiViews
   AllowOverride All
</Directory>

En el campo Directory deberemos poner la carpeta donde queremos que .htaccess funcione. Si queremos habilitar .htaccess en unas carpetas y deshabilitarlo en otras, podemos usar un esquema como el siguiente:

<Directory "/var/www/html">
   AllowOverride None
</Directory>

<Directory "/var/www/html/wordpress">
   Require all granted
   Options Indexes FollowSymLinks MultiViews
   AllowOverride All
</Directory>

Una configuración funcional quedaría así:

De esta forma, .htaccess funcionará en /var/www/html/wordpress pero no en /var/www/html.

Cada sección Directory es independiente y puede haber tantas como necesitemos en una sección VirtualHost.

Por último reiniciamos el servidor Apache con:

/etc/init.d/apache2 restart

@Clipper Suponiendo que la cuarta y quinta lineas son preguntas:

Lo del ratón seguramente se deba a que lo tienes conectado en el bus USB 3.x. Para que funcione, o bien lo tienes que conectar a uno 2.0 o bien desactivas el 3.x desde la BIOS (cada BIOS tiene su nombre para hacer esto).

Sobre DVD vs Pendrive, ya es una cuestión de gustos. A mi me gusta más el USB porque es reutilizable. Hace años que no uso discos ópticos en mi PC principal, la verdad. Aunque también es verdad que el DVD es menos susceptible de dar problemas en estos casos.

Y sobre la tarjeta SD, no debería haber problemas. Nunca he arrancado desde una de ellas, pero la mecánica debería ser la misma que arrancar desde un pendrive. Buscando por ahí, parece que se puede grabar usando una herramienta llamada woeusb (si no viene por defecto en Ubuntu, la tendrás que instalar):

sudo woeusb --device carpeta/windows-10-image.iso /dev/sdX

También se puede usar dd, pero el proceso es bastante más complejo.

Si he entendido bien, ¿de repente la placa base no detecta tu unidad SSD y tienes problemas para instalar Windows en un disco mecánico?

Antes de nada, activa en la BIOS el modo IDE/Legacy o como se llame para el disco duro (debería haber al menos dos modos: IDE o AHCI). Si sigue sin funcionar la instalación de Windows 7 en el disco mecánico y quieres darle el intento a Linux, tienes que descargarte una imagen actualizada.

Es normal que una versión tan antigua de Ubuntu no detecte tu tarjeta de red. Si lo único que tienes a mano para bajar cosas es una Raspberry Pi, bájate una versión reciente cerrando el entorno de escritorio. Cuando esté en modo consola, bájate la imagen y cópiala en un pendrive para arrancar desde ahí:

wget http://releases.ubuntu.com/19.10/ubuntu-19.10-desktop-amd64.iso
sudo dd if=/carpeta/ubuntu-19.10-desktop-amd64.iso of=/dev/sdX bs=1M

La X tiene que corresponder con la letra de unidad de tu pincho USB. Si no sabes cual es, ejecuta

df

Asegúrate de que la letra es la correcta. Si te equivocas, te quedarás también sin RPi.

@alberto-brasil Nunca he usado el administrador de máquinas de Qemu; siempre lo he hecho por consola. Mi consejo es que copies la imagen iso desde el pendrive al escritorio o cualquier otra carpeta local de Ubuntu Mate en Raspberry Pi.

El mensaje de error que recibes se debe a que Qemu está intentando arrancar desde un disco que no es arrancable (probablemente un disco duro virtual virgen). Así que tienes que configurar la máquina virtual como para que arranque desde la ISO. He instalado virt-manager (la GUI que usan en el video que has puesto) y trastendo un poco, parece que para añadir la ISO tienes que hacer esto:

· Cuando inicies el gestor, haz clic en el asistente para crear una nueva máquina.

· Ahí eliges la primera opción: instalar con imagen ISO y eliges el archivo que has copiado al directorio local.

Continuar con todos los parámetros que te pide: memoria RAM (no pondría más de 768Mb), CPUs (no más de 3), una unidad de disco virtual (de tamaño no superior al espacio disponible en la tarjeta SD)...

Al arrancar seguramente te ha salido esto:

Haciendo clic en el icono de información sobre el hardware virtual, debes asegurarte de que la unidad de CDROM está habilitada y que tiene la máxima prioridad en el arranque:

Sobre todo, asegúrate de que has elegido el archivo ISO y no una unidad física ya sea el pendrive o la tarjeta SD.

@alberto-brasil dijo en Projeto que precisa rodar windows no raspberry pi3B:

Muchas gracias por tu respuesta
Estoy tratando de instalar a través del Exagear desktop junto con Wine que me han dicho que funciona muy bien pero me no entiendo los comandos que se necesita escribir.
No os quiero dar mucho trabajo sería posible enviarme un paso a paso de cómo instalar windows en esos emuladores?
Estoy muy agradecido por tu atención,
¡Gracias amigo!

Ok, ese es un tema diferente. En la guía de Raspi también hay un apartado dedicado a Exagear (apartado 6); ahí tienes una explicación detallada de los comandos que necesitas. Además, el año pasado hicimos por aquí un análisis de Exagear 2 donde puedes ver más ejemplos.

En resumidas cuentas, Exagear no es un emulador como Qemu en que se virtualiza una máquina completa sino que ofrece una consola x86. Es decir, Exagear te permite ejecutar programas x86 para Linux en una Raspberry Pi con un rendimiento bastante decente. Pero NO puedes instalar Windows. Para usar programas para Windows tienes que seguir el mismo procedimiento que en Linux para PC: hay que instalar Wine.

Básicamente, una vez que has ejecutas Exagear, el procedimiento a seguir es el mismo que si estás ante un PC con Linux. Lo que hace es convertir la Raspberry Pi en un PC x86 (con Linux).

En el siguiente video puedes ver un ejemplo de la ejecución de Counter-Strike en una Raspberry Pi (insisto en que dentro de la guía y el análisis que te he enlazado ha más ejemplos incluyendo procedimientos, comandos, etc):

En Reddit he visto publicada esta animación donde se pueden ver imágenes REALES de cómo beben RAM los distintos navegadores web:

Inquietante...

La prueba de concepto de la cuarta (y última) fase del navegador de archivos, está implementada. La idea aquí, más que añadir funcionalidad pura, era poder demostrar si esto era posible. ¡Y es posible!

Consiste en poder ejecutar los ejecutables desde el navegador. El sistema detecta automáticamente el tipo de ejecutable y lo lanza en MS-DOS 6.22 o Windows 95/98. Además, se ha querido probar otra cosa relacionada con todo esto que de momento queda limitado a algunos formatos de imágenes y sonidos: poder visualizar los archivos en software nativo. De momento, se pueden ver gifs/jpegs en Internet Explorer 3/4 y BMPs en el Paint de Windows 95 y los tres formatos en Imaging. Además, se pueden escuchar .wav en las grabadora de sonidos de Windows.

Algunos ejemplos (para que se oiga sonido, hay que hacer clic en la pantalla de la emulación):

Ejemplo 0: Demo del Tomb Raider II Gold
Ejemplo 1: Demo del Theme Hospital para DOS
Ejemplo 2: Demo del Theme Hospital para Windows 95.
Ejemplo 3: Demo del International Rally Championship (- para frenar, tecla a la derecha de la Ñ para acelerar, z/x para girar):
Ejemplo 4: Demo del Duken Nukem 3D (no seleccionar tarjeta de sonido porque no incluyeron los archivos de audio y falla)
Ejemplo 5: Demo del Epic MegaPinball.

Las emulaciones de Windows 95 además vienen en dos sabores: con profundidad de color de 32 bits y de 8 bits, de forma que se puede experimentar con paletas en imágenes y se mejora la compatibilidad en software. De esa forma tenéis Windows 95 a 8 y 32 bits y Windows 98 SE a 32 bits, por lo que tenéis varias vías en caso de encontrar incompatibilidades.

Ejemplo 5: Imagen jpeg desde Internet Explorer 3/4
Ejemplo 6: Imagen bmp desde MS Paint
Ejemplo 7: Sonido desde la grabadora de sonidos de Windows 95

En la anterior versión de museo, era posible emular algunos programas de MS-DOS, pero había un condicionante muy fuerte: el programa tenía que estar contenido en un .zip y eso implicaba preparar emulaciones individuales, lo cual era costosísimo en tiempo. Ahora, gracias al HLFSv2 (¡Hardlimit File System!) la flexibilidad es absoluta y se puede manejar cada archivo individualmente, esté donde esté y a una velocidad asombrosa. Y eso sin contar con que se rompe el límite MS-DOS y se amplia, en teoría, a cualquier sistema x86 (aquí hay todavía kilómetros de tela que cortar). Con esto, ya hemos superado con creces la funcionalidad de la anterior versión y hasta donde sé, somos los únicos en poder ejecutar programas de esta forma.

Este tema está verde todavía y se irá puliendo muy poco a poco: por ejemplo, desde MS-DOS y Windows 98 no es posible leer a partir del cilindro 1024 del disco disco (encontraréis errores de lectura en carpetas muy grandes: >500MB): si os pasa esto con Windows 98, usad 95. Además, la unidad virtual sólo tiene soporte para archivos en formato 8.3 y otras cuestiones.

En otro orden de cosas, desde el buscador de archivos, ya es posible buscar archivos. Las búsquedas son en el sistema de archivos completo hasta que se visita un medio/disco concreto. A partir de ahí, las búsquedas se acotan al medio o directorio de forma recursiva. La búsqueda, a diferencia del multimedia, ordena por número de repeticiones, es decir, que los archivos más populares aparecen antes. También se añade una selección de "medias" en la propia búsqueda.

Con esto, ya me he quedado a gusto y se cierra esta temporada de desarrollo intenso de museo. De aquí a finales de mes, se van a consolidar y documentar los cambios y no habrá nuevas características mayores (más allá de pequeños arreglos).

El museo, como plataforma, está ya definido.

Ahora lo grande vendrá ya de parte del contenido, independientemente de que exista mucho margen de mejora en todo.

PS: La idización del media va por el 33%, así que en una dos semanas más, estará prácticamente todo.

Esta semana estrenamos la primera fase del navegador de archivos. Todos los archivos de casi todos los discos están ya indexados y son navegables. Se han quedado en el tintero un par de MDF/MDS de la Micromanía que no hay forma de extraerlos a pesar de que sí es posible la mayoría de MDF/MDS.

Aquí tenéis un disco donde, además de aparecer la información que ya se anunció, ahora incluye la lista de archivos y carpeta navegables.

Además del explorador de archivos, es posible ver información detallada de cada archivo junto a duplicaciones, es decir, archivos que podrían tener nombres, fechas y otros atributos distintos pero cuyo contenido es el mismo. La información que se muestra es la siguiente:

• Nombre del archivo en el medio y ruta actuales.
• Fecha de creación original en el medio.
• Tamaño en formato ISO/IEC 80000-13 binario.
• El tipo de contenido de forma descriptiva (de aquí para la mayoría todavía no saldrá informació; ya se irá añadiendo).
• Tipo de MIME (no es 100% preciso, pero casi).
• Una descripción más detallada del contenido del archivo, por ejemplo, si es un ejecutable autoextraible, se dan detalles del contenido encapsulado.
• Una firma MD5
• Una firma SHA256

Aquí un ejemplo de pkunzip.exe que es un archivo bastante popular.

En esta primera fase, ha sido un reto el poder determinar el conjunto de caracteres del sistema de archivos. Unas veces se usa UTF-8, otras veces se usa CP850 y hay por ahí un par de imágenes que tienen pinta que salieron mal de origen por algún fallo en el software de creación (según parece, no era raro en los 90). En cualquier caso, los nombres de los archivos se muestran correctamente con sus eñes, acentos y demás independientemente del formato original.

Tenemos 570.000 archivos. Esto viene de los medios de las cinco publicaciones que tenemos de momento, que se están usando como referencia para todo el desarrollo antes de añadir mucho más.

También se ha comenzado con la segunda fase del navegador, que consiste en extraer todos los archivos extraibles. Y de los extraidos, repetir la operación recursivamente. En estos momentos somos compatibles con mas de 70 formatos de comprimidos de todas las épocas que se determinan por heurística, no por extensión ni por número mágico, lo cual evita que ningún archivo compatible se escape. Sobre esto, cuando esté pulida esta primera versión del extractor, se pondrá en producción. Con el tiempo, se irán añadiendo más formatos pero de momento nos quedamos con esos 70-80 para priorizar otros aspectos.

En otro orden de cosas, se ha hecho un cambio en la configuración de v86 que hace que la respuesta de las máquinas virtuales sea ahora mucho más rápida (ejemplo). Era algo que yo no notaba por ir en local, pero ahora que todo el tráfico para por un VPS, me doy cuenta de detalles de rendimiento mejorables (dependientes de la latencia).

Y para terminar, se ha corregido la algoritmia detrás del nuevo sistema de traducción de páginas haciendo que ahora se rendericen las páginas mucho más rápido (esto afecta tanto al museo como al banco de pruebas). Este cambio, además, ha dejado de romper ciertas funciones como la lupa en las revistas y la captura del puntero del ratón en las virtualizaciones.

Pensaba que esto estaba controlado pero no (es lo que tiene hacer las cosas por primera vez). Este fin de semana ha habido una gran cantidad de cortes; mis disculpas por no haber planificado esto bien ni haber dado los avisos oportunos. El tema está, en principio, solucionado y a partir de ahora, debería ir bien y sin cortes.

En resumen, OVH tiene un sistema anti-DDoS (no configurable ni desactivable) con el que los paquetes UDP son siempre sospechosos y cuando se supera cierto umbral (no sé si de tasa de datos o de tasa de paquetes), este sistema bloquea la IP desde la que vienen los paquetes. Como mi servidor estaba usando UDP para conectarse con el VPS, cuando había un poco más de actividad de lo normal, saltaba y tiraba todos los servicios. """Sencillamente""" he tenido que pasar a usar el protocolo TCP.

Para aprender, perder (medio fin de semana).

Gracias @_Neptunno_

A mi desde siempre me ha llamado la atención lo de tener mi homelab... desde mi primera conexión de 56kbps allá por el 2000, ya estaba trasteando con servidores de Counter-Strike, aunque con aquel ancho de banda, sólo me admitía a mi (por local) y a otro jugador.

Bastante más tarde (en realidad fueron pocos años después), cuando empezaron las duplicaciones de velocidad del ADSL, Jazztel implementó el fastpath en sus conexiones hasta 20MBps (con subidas de cerca de 1Mbps), me permití hacer un servidor de Counter Strike Source para 16 jugadores. ¡Y tuvo bastante éxito!

Después de aquello empecé a alojar mi blog personal en una Raspberry Pi. Ahí fue cuando empecé a aprender Linux a nivel administrativo. Y cuando recibí Hardlimit (que todavía estaba en vBulletin), apañé un Netbook (Atom N270 con 1GB de RAM) y aquello iba como un tiro. Eran tiempos más sencillos donde sólo se estilaba el PHP y MySQL

Poco a poco me he ido complicando la vida hasta lo que hay ahora. Y la verdad es que, haciéndolo, se aprende un huevo de todo, por ejemplo, hasta hace 6 meses no tenía ni idea de lo que era un acuerdo de Peering entre proveedores y vivía en el inocente mundo de que mi conexión era (en términos relativos por Mbps) equivalente a la de un centro de datos

Siguiendo con el tema de las VPS, CDNs y demás, el problema de Cloudflare es que ni con un contrato de pago (básico) dejan claras las limitaciones ni de ancho de banda ni de tráfico. Y, efectivamente, Peertube mueve unos cuantos teras al mes, lo cual me deja con la duda y la incertidumbre.

A mi me gusta más el estilo de la VPS, porque al final la gestiono como una máquina más y en el caso de OVH, dejan totalmente claro todas las características y limitaciones. Además de que tiene un precio muy bueno, todo sea dicho.

Y volviendo a la migración, anoche estuve haciendo las primeras pruebas montando un NAT básico. Esta mañana me he tirado unas cuantas horas intentando levantar Nginx desde el VPS pero hay muchas cosas que se complican enormemente, principalmente con Peertube y Mastodon ya que, entre otras cuestiones, necesito tener acceso a un punto de montaje con los datos y al final queda una configuración bastante sucia, complicada de mantener y poco eficiente. Y no solo eso, sino que Mastodon, por diseño, no admite un proxy inverso fuera de localhost, por lo que encima tendría que modificar código interno de la plataforma. Vamos, que es una tocada de narices en toda regla y en realidad, los beneficios son pocos.

Así que finalmente voy a dejar un simple NAT.

Desde ya, todo el tráfico está pasando por OVH. Los que os conectáis desde España, no notaréis ninguna diferencia. La gente que viene de otros países y continentes, sí verán una calidad del servicio muy superior.

Sobre los dominios, la gente de noip son unos listillos y en vez de generarte una clave de migración automáticamente (como hacen los registradores normales), tienes que abrirles un ticket y esperar a que te respondan con la clave. Así que supongo que esto se hará la semana que viene.

Por fin he podido poner orden en todo el contenido del museo. He rescatado un disco de 2TB del trastero que va dar bastante margen para seguir con esto. Además, he podido acomodar espacio en el disco de copias, por lo que la parte que más me incomodaba de usar un disco de estas formas, está resuelta.

Así de primeras, ya están todos los discos de revistas que había. @vreyes1981, ya están tus discos de la Micromanía, en concreto del año 2002 (año completo) y 2003 (hasta abril), que es lo que me habías subido. Si tienes más material por ahí, no dudes en ponerlo (avísame si lo haces para ir añadiéndolo).

También se ha terminado de definir la estructura de la base de datos para dar el siguiente paso: el explorador de archivos. La fase inicial permitirá navegar por el árbol de directorios de todos los discos diponibles y en el siguiente turno del Museo, debería quedar operativo. Ya veré si a la próxima dedico tiempo al banco de pruebas o al museo.