Hace poco me cambié a DIGI y quería seguir usando mi router habitual de siempre. La parte positiva es ser de las pocas compañías que dan los datos necesarios para hacerlo. Sin embargo hay un problema: no dan los datos para conectar un ATA propio a la línea de voz. Por otro lado, solo tienen ese problema quienes necesiten línea de teléfono fijo.

Vamos a ver qué opciones tenemos para solucionarlo pero primero veamos los requisitos para ello:

Requisitos

1. Tener una ONT GPON separada del router. En la mayoría de casos de fibra con DIGI, su ONT y router vendrán separados. En fibra DIGI Pro por XGS-PON no existe esa opción (aparte que no pondrías un RT-AX92U ahí, sino algo más potente).
2. Cables Ethernet cortos, de los de tipo "patch", para hacer conexión entre los equipos.
3. Muchas ganas de trastear y no tener miedo a quedarte sin teléfono.

Opción 1: Me da igual la VoIP, solo quiero tener Internet

Aquí tenemos un caso bien sencillo: solo necesitarás tener los datos PPPoE (se piden a DIGI a través de atención al cliente) y conectar el router ASUS a la ONT. Una vez hecho eso, iremos a WAN - Internet Connection e introduciremos

BASIC CONFIG
WAN Connection Type: PPPoE
Enable WAN: Yes
Enable NAT: Yes

WAN IP Setting
Get the WAN IP automatically: Yes

ACCOUNT SETTINGS
Username: <dado por DIGI>
Password: <dado por DIGI>
PPP Authentication: Auto
MTU: 1492
MRU: 1492
Internet Detection: PPP Echo

Después, iremos a LAN - IPTV y configuraremos de la siguiente manera:

LAN PORT
Select ISP Profile: Manual Setting
Internet: VID: 20 PRIO: 0

Tras realizar esto, debería devolver una dirección IP en la WAN, la cual se podrá ver desde Network Map.

IPv6

Sabiendo que DIGI provee también una dirección IPv6 (la dirección IPv4 va por CG-NAT salvo que se pague la conexión plus por un euro extra), también tendremos que configurarla en el router. Para ello, iremos a la sección IPv6 y configuraremos de la siguiente forma:

BASIC CONFIG
Connection type: Native
Interface: PPP
DHCP-PD: Enable
Accept Default Route: Enable
Release Prefix on exit: Enable

Tras aplicar los cambios, debería haber dos direcciones IPv6 en WAN: una de ellas es local (empieza por fe80) y otra de DIGI (empieza por 2a0c).

Opción 2: Tengo VoIP con DIGI y quiero conservarlo

Esta opción no es posible con equipos propios y tenemos que seguir usando el router de DIGI como ATA.

En sitios como Bandaancha nos indicaban (para otros routers) una solución, la cual era crear un servidor PPPoE en el router principal para que el router de DIGI inicie una sesión "de pega" y haga el enlace VoIP. También esos routers pueden configurar múltiples VLAN en el mismo puerto, cosa que este modelo de ASUS no puede. Además, no hay forma sencilla de configurar el servidor PPPoE necesario en el firmware original. Se podría intentar con scripts usando ASUSWRT-Merlin pero sería algo que tendría que configurarse mediante consola y no he encontrado forma viable de hacerlo.

No obstante, hay una alternativa. En redes propiedad de DIGI (fibra smart), el servicio VoIP va por la VLAN 11 mientras que Internet va por la VLAN 20. Solo debemos hacer que, desde la ONT, la VLAN de Internet vaya al router ASUS y la VLAN de VoIP vaya al router DIGI. Eso se puede conseguir poniendo un switch que soporte varias VLAN entre la ONT y los routers.

En mi caso, tengo un Zyxel GS1900 de 24 puertos que compré hace años de segunda mano. Soporta múltiples VLAN sin despeinarse. Ese será quien nos ayude a tener el RT-AX92U como router principal y tener el ZTE H3600P (el que tengo en mi caso) como ATA.

En el switch Zyxel vamos a configurar 3 VLAN: con id 1 tendremos la VLAN por defecto, que usaremos para tener disponible el resto de puertos del switch y extender la LAN del router ASUS; con el id 20 tendremos la red ONT - ASUS (Internet); y con el id 11 tendremos la red ONT - ZTE (VoIP).

Pongo la siguiente distribución de puertos:

¿Qué estamos haciendo con esta configuración? Estamos haciendo lo siguiente:

1. Aislamos la LAN de la interconexión ONT - routers y así podemos aprovechar el resto de puertos para otras funciones.
2. Hacemos que el ZTE no pueda realizar la autenticación PPPoE (de no hacer esto, estaría saltando la IP asignada de un router a otro porque ambos intentan hacer la autenticación)
3. El ZTE tiene acceso único a la VLAN 11 y, como se ha visto en la misma web (Bandaancha) y en la configuración del router ZTE, no se necesita autenticación PPPoE para poder conectar al servidor VoIP, ya que son conexiones independientes.
4. El router ASUS tiene todo el acceso a la VLAN 20 y es quien hará la autenticación PPPoE.

Una vez hecho esto, lo único que toca hacer es configurar el router ASUS tal como se indica en la opción 1, ya que son los mismos pasos. Y ya tendremos tanto internet por nuestro router neutro y el servicio VoIP por el router de DIGI comportándose como un ATA. Sería recomendable, una vez completado todo el proceso, desconectar el WiFi en router ZTE para reducir interferencias.

Fuentes

Pensando en pasar de O2 a Digi NEBA con dudas sobre router, VoIP, CG-NAT y capado datos móviles - Bandaancha.eu
Router Digi para fijo conectado a OpenWrt pide IP por VLAN 11

Hace unos días me encontré con un anuncio en una página de compra-venta online en el cual ofrecían un lote de 10 unidades SSD de la marca Micron de 1 terabyte de capacidad cada uno al justo precio de 350€ el lote. Con ese precio, cada unidad me costaría 35€.

Como cabe esperar, dicho lote era de unidades usadas y quería estudiar si iba a merecer la pena dedicar ese coste para un proyecto que, a diferencia de otros, vaya a completar. Tras ver que el coste por unidad era poco más de la mitad de uno nuevo de gama de entrada consumidor como el Kingston A400 y que merecía la pena por los análisis que leí de otros sitios web, realicé la compra.

De momento llevo un par de unidades revisadas pero las mediciones SMART de las unidades son tal como me indicó el vendedor y todavía tienen capacidad de trabajo de sobra. Habían estado 5 años funcionando y el estado de las celdas estaba determinado en un 95% según cristaldiskinfo y el total de Terabytes escritos o TBW estaba en aproximadamente 50 terabytes. Con esos números y teniendo en cuenta el límite de cada unidad que sería de 400 TBW y siguiendo la misma intensidad de uso, podrían estar funcionando casi 40 años más en las condiciones perfectas. Como he dicho, tienen vida para rato.

Revisé la versión de firmware que llevaban y la versión era la MU04 y me llamó la curiosidad si existía una nueva versión de dicho firmware, teniendo en cuenta que este modelo se empezó a producir hace 10 años. Me imagino que habrá tenido alguna versión más reciente. Busqué por la web de Micron y no hubo éxito, probablemente por ser un modelo fuera de producción. Sin embargo, encontré la última versión (MU05) en una web francesa dedicada a estos menesteres y lo descargué.

Al abrir el fichero zip, solamente estaba el firmware y, para actualizar, se necesita el software que lo escriba en el dispositivo. Por suerte, el mismo sigue disponible en la web de Micron bajo el nombre de "Storage Executive". Bastó con instalarlo, ejecutarlo, ir a la sección dedicada a actualizaciones de firmware e iniciar la actualización manual. Una vez realizado, tendremos un disco con el firmware más reciente.

Se dice que no existe la necesidad de actualizar el firmware de un SSD aparte del riesgo a perder la información pero teniendo en cuenta que los acabo de recibir y ante la posibilidad de corregir errores de la versión anterior, no me importa correr ese riesgo.

Enlaces de utilidad:

• Artículo de análisis del Micron M600
• Página francesa donde se puede recuperar el firmware
• Micron Storage Executive

Este modelo de servidor de la marca HP es muy peculiar: su BIOS tiene uno de los arranques más extraños que he visto y lo digo por lo sucedido a continuación:

Instalando OpenMediaVault (y no arranca)

Aquí no hace falta mucha explicación. Seguí los pasos para realizar la instalación en un SSD SATA. Dentro del servidor, conecté el SDD en uno de los puertos SATA dedicados a los ODD (Unidades de disco óptico), introduje el usb de instalación y seguí los pasos del asistente.

Tal como dicen en la documentación de OpenMediaVault, durante la instalación no se debe incluir ningún dispositvo de almacenamiento más allá del dispositivo destino de la instalación (incluyendo obviamente el instalador). Así hice y no hubo problemas, arrancó el sistema correctamente tras la instalación.

Posteriormente, apagué el servidor, instalé los discos duros en las bahías extraíbles de 3.5'' (hay también una versión con bahías de 2.5'') que hay disponibles en el Proliant ML110, inicio el sistema y surgen los problemas. Realiza el POST correctamente pero no se incia el Sistema Operativo.

Compruebo el orden de arranque y está correcto: arrancar sistema desde un disco SATA en primer lugar.

El sistema de arranque del Proliant

El sistema de arranque de este servidor Proliant tiene los siguientes accesos:

• Arranque desde una disquetera (probablemente mediante USB, ya que no dispone de puerto FDD en placa).
• Arranque desde CD/DVD, a través de la unidad DVD que incorpore (u otra similar).
• Arranque desde el puerto USB: este modelo dispone, aparte de los puertos USB externos, de un puerto USB interno en la placa base además de una ranura SD, también interna.
• Arranque desde un disco SATA.

En este último caso es donde surgió el problema. Dependiendo de cómo esté configurado SATA en la BIOS, tenemos dos situaciones:

• En el modo SATA Legacy, podemos elegir desde qué disco SATA podemos arrancar.
• En el modo AHCI, siempre arranca desde el primer disco conectado.

Y ¿cuál es el primer disco conectado?, pues siempre seguirá este orden:

• Desde la bahía 1 hasta la 4 (si tiene un servidor de 8 bahías de 2.5'' será desde la bahía 1 hasta la 8).
• Si no hay discos instalados, comprobará los puertos dedicados a los ODD.

Debido a esto, no podemos arrancar desde otro puerto SATA.

Solución

La solución es la siguiente:

1. Teniendo en cuenta que tenemos arranque por USB, configuramos la BIOS priorizando la opción "USB Drivekey" y también configuramos los dispositivos USB priorizando el arranque en puertos externos en lugar de los internos (así en caso de algún problema, se puede iniciar por USB externo en cualquier momento).

2. Tener dos pendrives: uno limpio (formateado con tabla MBR) y otro donde hayamos instalado Super Grub Disk (nos facilitará mucho el arranque para el procedimiento). El limpio lo instalamos en el usb interno que tiene la placa base del Proliant mientras que el otro lo instalamos en un puerto USB externo de nuestra elección.

3. Reiniciamos el servidor, tras haber realizado los cambios en los menús de la BIOS.

4. Se iniciará Super Grub Disk y se elige las opción de inicio por defecto. Posteriormente, saldrá un listado con los sistemas operativos que ha detectado en todos los discos.

5. Seleccionamos la primera opción, suponiendo que solo tiene instalado OpenMediaVault. La referencia que saldrá en Grub es Debian GNU/Linux.

6. Una vez iniciado OpenMediaVault, desde la consola de sistema o desde SSH, iniciamos una terminal (o usamos el tty disponible) y buscamos el USB interno (es más sencillo si los dispositivos USB son diferentes). Para ello, ejecutaremos el comando sudo fdisk -l y anotaremos la ruta dev (/dev/sdX).

7. Tras ello, ejecutaremos sudo grub-install --boot-directory=/boot/ --recheck /dev/sdX.

8. Por último, ejecutaremos sudo update-grub.

Con todo esto, ya podremos iniciar OpenMediaVault en un Proliant ML110 G7 con AHCI activo y cuyo disco de sistema esté en otro puerto distinto al primer SATA activo. Es un engorro pero mejor eso que tener que dedicar una bahía extraíble al Sistema Operativo.

"No es un equipo informático, es un electrodoméstico y se trata como tal."

Esta es la frase que recibió el tecnólogo conocido en Twitter como MrChuxMan, quien dirige una pequeña empresa de informática, tras solicitar a la compañía de electrodomésticos Beko el firmware de la placa de control de su lavadora.

El suceso

Su historia comienza con la avería del susodicho electrodoméstico. Ante ello, MrChuxMan decidió apretarse los machos y realizar su reparación. Supuso que el origen del problema era el daño permanente del microcontrolador principal de la placa de control. Vió que el componente era de fácil adquisición y con una sustitución relativamente sencilla: solamente necesitaba el firmware.

Para entrar en contexto, el firmware es el software que define el funcionamiento del microcontrolador: define sus entradas, salidas y qué procedimiento tiene que realizar con ellas. Dicho software se encontraba en el componente dañado, por lo que supuestamente no habría forma de extraerlo para su posterior inserción en el repuesto.

Sin embargo, gracias a que en la Unión Europea existe el "derecho a reparar", las empresas productoras de electrónica de consumo deben dar facilidades para su reparación por cuenta propia. Con ello, se dispuso a contactar con Beko sin resultado positivo, ya que estos últimos no estaban dispuestos a enviarle una copia del firmware del controlador, incluyendo el comentario que da comienzo a este artículo tras insistirles nuevamente.

La opción que daba la compañía era adquirir el componente completo (toda la placa) cuyo coste hacía que no fuese rentable reparar el electrodoméstico, ya que tenía el mismo precio que comprar una lavadora nueva.

Tras las negativas, se puso a intentar sacar el firmware del controlador dañado. Lo logró, aunque necesitará realizar lo mismo desde un aparato en funcionamiento que, casualmente, tiene en casa de su madre para asegurar la integridad del software.

Tras todo este proceso, comunicó al fabricante de electrodomésticos que ha puesto en manos de la Organización de Consumidores y Usuarios (OCU) este asunto para reclamar el no cumplimiento de la resolución europea.

Aparte, indica tanto en Twitter como en su email a Beko que todo lo realizado es legal ya que no ha distribuido ni distribuirá copias del firmware ni ha comprometido la seguridad de la empresa.

"Esto no se arregla como si fuera un ordenador", decían.

Hace unos días cambié de punto de acceso WiFi. Tenía un ZTE F680 como AP, el cual emitía redes 802.11ac con seguridad WPA2 y he aprovechado para cambiarlo por un ASUS RT-AX53U y que emita redes 802.11ax usando WPA2/3 como modo de seguridad suponiendo que los dispositivos WPA2 funcionasen sin mayor inconveniente.

Pues bien, ese no es el caso de las impresoras WiFi de la marca Canon, ya que no conectan a redes WiFi WPA2/3-PSK. Deben ser estrictamente redes WPA2-PSK o inferior. A pesar de la existencia de un modo de compatibilidad que otros dispositivos logran conectar, este no es el caso de este dispositivo.

Así que hay dos opciones: o usar WPA2-PSK en tu red WiFi principal o configurar una red invitada que sea exclusivamente WPA2-PSK.

Y ahora comparto esto para evitar que os tiréis de los pelos y soltéis improperios varios por culpa de un firmware deficiente.

Hoy toca hablar de una vergüenza en el software FOSS y que, en mi opinión, está al mismo nivel que los sabotajes de la Universidad de Minesota al kernel Linux: sin duda hablo del suceso de Marzo de node-ipc.

Me he enterado al ver este vídeo del canal de Youtube Mental Outlaw, el cual recomiendo ver, ya que habla de temas relacionados con la tecnología, da sus posturas sobre ciertas acciones en la industria, así como tutoriales de software y de cocina (sí, de cocina). Como debe ser, lo voy a adjuntar a continuación, ya que aporta el contexto necesario sobre este tema.

También incluyo un enlace al artículo que hace referencia dicho vídeo, donde el asunto tiene mayor detalle y profundidad así como formas de mitigar el problema de seguridad que se ha generado. Recomiendo su lectura (en inglés):

Artículo de blog.snyk.io sobre problema de seguridad en node-ipc

El suceso: versión TLDR

Este suceso está registrado como CVE-2022-23812

1. De acuerdo con la información publicada por Snyk, la versión 10.1.1 de node-ipc incluyó código sospechoso que podía implicar cambios en el comportamiento del módulo (llamadas a servidores externos y presencia de datos en base64).

2. Dicho código tenía un temporizador que ejecutaba operaciones de sistema de ficheros que reemplazaba el contenido de los ficheros que hubiese por el carácter emoji corazón. Este comportamiento se ejecutaba si la IP tenía geolocalización en Rusia o Bielorrusia.

3. Notifican también que se emite otra versión (10.1.2) donde solamente se modifica el fichero package.json. Sospechan en que esta versión está pensada para provocar la ejecución de las actualizaciones automáticas.

4. Finalmente, en la versión 10.1.3 se detecta el borrado del código malicioso.

5. Sale una versión 11 de node-ipc donde se incluye dependencia de un módulo llamado peacenotwar (del mismo desarrollador que node-ipc) donde se incluye un comportamiento menos lesivo que el probablemente provocado por el suceso indicado, pero que (según Snyk) sigue implicando un comportamiento no deseado.

Opinión al respecto

Se le ha ido acuñando a este acto con el término protestware (software protesta) pero me niego a mencionar este suceso como protestware sino como vandalware (vandallism software, ergo, malware). Y lo considero así por la propia definición de vandalismo, el cual es el daño a la propiedad pública o privada de forma intencionada.

El desarrollador de node-ipc, RIAEvangelist, ha cometido no solo dichos actos, sino daños a la reputación del software FOSS.

Prácticamente ha dejado una imagen donde a un desarrollador se le pueden cruzar los cables y provocar daños a otros desarrolladores y usuarios por criterios arbitrarios.
Y probablemente en este caso, detrás de esas direcciones ip no haya un oligarca ruso o bielorruso, sino un desarrollador cualquiera que ni siquiera apoye las derivas bélicas de sus presidentes.

Lo que más me repatea de esto es la respuesta a las quejas al respecto de otros desarrolladores y/o usuarios de Github, bajo el argumento de "es moral porque es para apoyar a Ucrania". No, lo has hecho por puro comportamiento egocéntrico y debería darte vergüenza.
Y no, esto no es un "ups, me he dejado una clave privada en el código fuente", esto lo has hecho a drede y con ánimo destructivo, y es normal que otras personas te lo echen en cara.

Su comportamiento es propio de un pirómano, echando gasolina al fuego. Si quiere ayudar a Ucrania de verdad, colabore con ONGs u organizaciones vecinales. Déjese de protagonismos y menos si va a salir mal parado de sus acciones.

Durante el mes de Diciembre de 2021, han surgido varias incidencias críticas de seguridad en uno de los frameworks más usados en Java: Log4j.

Log4j es una biblioteca hecha en lenguaje Java destinado a la presentación de logs en una aplicación de dicho lenguaje y, actualmente, un gran número de aplicaciones y servicios están usándolo. Un fallo en esa parte puede causar un problema global, tal como se está viendo.

Las vulnerabilidades críticas descubiertas son las siguientes:

• CVE-2021-44228 - gravedad 10 - descubierto el 10/12
• CVE-2021-4104 - gravedad 8.1 - descubierto el 14/12
• CVE-2021-45046 - gravedad 9.0 - descubierto el 14/12
• CVE-2021-45105 - gravedad 7.5 - descubierto el 18/12

Así que, si eres desarrollador y usas Log4j, te va a tocar resolverlo o ya has tenido que aplicar las soluciones dispuestas (mediante actualización de la biblioteca, mitigaciones o buscando otra biblioteca que la sustituya).

La crítica sin control y los memes

Tras este desastre mayúsculo, no falta gente que se lo toma con humor y lo muestra con memes como el que muestro aquí abajo y tampoco faltan personas que ponen el grito en el cielo con mensajes del tipo "Qué desarrolladores más incompetentes", "Seguro que no hacen tests unitarios" o "¿Cómo narices una biblioteca de logging tiene cuatro vulnerabilidades críticas de seguridad?".

Pero hay una cosa que a los críticos de Internet (posiblemente afectados por dicho problema) se les olvida: es una biblioteca de uso gratuito, en la que no se está pagando por el soporte y mantenimiento, con autorización de poder analizar o modificar el código por nuestra parte y mantenida por una organización non-profit (Apache) que se mantiene económicamente con donaciones de empresas y particulares.

Hay que tener la osadía y la poca vergüenza de exigir (no pedir, exigir) la reparación inmediata y urgente del fallo en un producto por el que usas de forma gratuita (salvo que estéis pagando al desarrollador el soporte).

Entonces, ¿quién es el responsable?

Mi respuesta va a doler (y me dolería igual si estuviese en vuestro lugar): la responsabilidad en la cual el fallo afecte a vuestro proyecto es únicamente vuestra. Los desarrolladores de Log4j son responsables del fallo en su parte (y bastante gordo es el fallo que tienen), pero no son responsables de cómo habéis integrado su biblioteca en vuestro proyecto ni de las consecuencias derivadas de ello.

Si vuestro desarrollo de software tiene un fuerte acoplamiento con bibliotecas de terceros que impide que puedas cambiar de biblioteca o aplicar medidas propias de mitigación, es un fallo de desarrollo por vuestra parte. No hay más.

Hay que tener en cuenta que a la hora de añadir una biblioteca externa, se deben aplicar medidas que permitan retirar dicho software de tu proyecto en cualquier momento; ya sea por problemas de funcionamiento o porque ha llegado al final de su utilidad.

Conclusión

Para concluir, os indico unos puntos a tener en cuenta:

• Evita integrar bibliotecas sin ninguna justificación para ello. No es buena idea integrar un módulo para algo que puedes hacer tú en poco tiempo (si tienes un desarrollo en NodeJS, lo comprenderás -> node_modules).

• Evita acoplar tu proyecto a las bibliotecas que integres. Haz una abstracción y así no tendrás problemas cuando necesites cambiarlas o retirarlas.

• Si usas bibliotecas FOSS y encuentras un fallo o problema, comunícalo y, si sabes solucionarlo, presenta un fix. No obstante, ve preparando un plan B en caso de no recibir respuesta.

• Recuerda que una parte considerable de desarrolladores de un proyecto FOSS suelen trabajar por amor al arte, así que no está de más ser un poco considerado a la hora de reportar fallos.

• Por último, si el trabajo de ese desarrollo aporta mucho a tu proyecto, busca si se puede pagar un servicio de soporte al desarrollador o, como mínimo, aportar económicamente o en código a dicho proyecto. Al final, si ese proyecto externo mejora, el tuyo también lo hará.

Hace un tiempo que Devuan publicó la versión 4.0 Chimera como estable, dejando la anterior sin soporte (exceptuando las actualizaciones de seguridad). A modo de resumen solo cabe decir que Devuan es un fork de Debian sin SystemD y abriendo la posibilidad de elegir proceso init entre sysvinit, openrc o runit (por el momento). Si tenéis algún interés en dicha distribución, os incluyo enlace a su web.

Tenía ganas de actualizar a Devuan 4.0 y, por ello, hice una instalación limpia. Salió a la perfección y me dispuse a instalar las aplicaciones que uso diariamente pero hubo un problema con VLC.

Al actualizar VLC a la 3.0.16 (venía de VLC 2), los vídeos en formato HEVC no se mostraban (había sonido pero el vídeo estaba en negro). Buscando en los foros de dicho software, decían que se deshabilitase la acceleración por hardware en la sección Input/Codecs (Herramientas -> Preferencias). Intenté eso y no hubo éxito.

También proponían cambiar la salida de vídeo a D3D11 pero esa opción es exclusiva de Windows, ya que D3D11 es DirectX.

Al no encontrar más soluciones, por desesperación, le dí a Restaurar preferencias para ver si había alguna configuración anómala que haya hecho. Y, por fortuna, eso solucionó mis problemas con VLC y los vídeos en HEVC por el momento.

Así que escribo este pequeño fragmento para quienes se encuentren con la misma situación. Es una puñeta resetear las preferencias pero a veces es preferible probar esa opción (desde luego es mejor eso que quitar la acceleración por hardware). Y recordad que esto puede que funcione en tu caso o que no tenga ningún efecto, ya que el mismo error puede estar causado por otros motivos.

Se viene otro vídeo limpiando teclados.

Ésta vez toca el icónico IBM Model M, donde se hará una limpieza a fondo y, de paso, haremos una restauración de algunos componentes así como también le realizaremos un BoltMod (sustituir los remaches plásticos por tornillos y tuercas).

Es un vídeo bastante largo pero se ha optado por el detalle a ser breve y omitir el trabajo que implica hacerlo.

Da la casualidad que acabo de obtener otro Model M, así que probablemente haya otro vídeo donde podré ser más conciso en el proceso y menos explicativo (lo que viene siendo ir al grano).

En el canal de Youtube se ha publicado un vídeo donde se dedica una jornada de limpieza a un teclado "mecánico" Acer de 1998.

En un principio se pensaba que era un teclado con switches Alps pero, posteriormente recordé que Acer hizo unos mecanismos suyos donde usaban la mecánica de un switch Alps pero con contacto eléctrico producido por membrana (algo parecido al "buckling spring" en los IBM Model M: parte mecánica y conexión eléctrica por membrana).

Lo que sí queda bien claro del vídeo es la necesidad de un buen lavado.

Suele suceder que, dependiendo de la configuración de pantallas que se tenga, el inicio de sesión con LightDM se vea anómalo. Por ejemplo, que la disposición o la resolución de las pantallas sea errónea.

Para resolver ese problema, no pude lograrlo configurando las pantallas con la opción "Aplicar a todo el sistema", sino que toca usar otras formas.

Vi el post que hizo Pavel Selivanov para configurar LightDM a través de un script y xrandr y me dió la idea de aplicarlo para mi caso. La gran diferencia es que no uso su script pero sí las instrucciones para que LightDM lo use.

Para configurar mis pantallas (tengo un sistema multipantalla de tres monitores), he recurrido a usar ARandR, una aplicación para configurar los monitores disponible en los repositorios de Ubuntu.

sudo apt install arandr

Una vez configurados los monitores como uno quiere, se puede guardar la configuración en un script shell. Movemos ese script de nombre por defecto setResolution.sh a /etc/lightdm y creamos o editamos el fichero /etc/lightdm/lightdm.conf.d/50-display-setup-script.conf de la siguiente manera:

 
[Seat:*]
display-setup-script=/etc/lightdm/setResolution.sh

Y con ello, al reiniciar el sistema, se verá el login de LightDM tal como lo queremos.

Fuentes: Pavel Selivanov - Add custom display resolution in LightDM
Foto de cabecera: @yuzhang - usplash

Siempre he tenido un gran interés en lograr formas de reescalado con una pérdida de calidad mínima. En ciertos casos me es suficiente vectorizando la imagen y queda en condiciones para hacer cualquier reescalado, pero hay casos donde hay tal cantidad de colores que es imposible hacer esto (pierdo colores). Buscando alternativas, hallé este método de reeescalado bastante interesante.

Bajo el nombre de waifu2x, es una implmentación en LUA de redes neuronales convolucionales con el objetivo de reescalar imágenes realizado por @nagadomi (Github). Está basado en un paper académico de Chao Dong, Chen Change Loy, Kaiming He y Xiaoou Tang de 2015.

También es capaz de limpiar ruido y artefactos de las imágenes, otro punto a tener en cuenta.

El requisito más restrictivo que tiene es la obligatoriedad de usar tarjetas gráficas NVIDIA, ya que usa CUDA como lenguaje de computación por GPU.

Por último, adjunto una pequeña muestra al principio del artículo, donde se puede ver una comparativa de escalado a doble de tamaño en distintos métodos: usando píxeles vecinos (next neighbour), lanczos y waifu2x.

Probando con vídeos

Un pregunta que llegué a hacerme era si podía hacer funcionar esto con vídeos, ya que daría lugar a poder escalar vídeo en 1080p a 4K o vídeo en resolución 480p a algo situado entre 720p y 1080p. Sobre todo vendría de perlas para contenido en que no pueda realizarse trabajos de reescalado analógico (un VHS no es posible pero sí es viable volver a leer un film cinematográfico en mayor resolución).

En teoría waifu2x no funciona con vídeos directamente, sino que hay que procesar los fotogramas de este para lograr el objetivo. Para ello, me aprovecho de ffmpeg para extraer los fotogramas tal como explican en el README del proyecto.

Ejemplo de cómo proceder

Primero, extraemos los fotogramas y el audio.

mkdir frames
avconv -i data/raw.avi -r 24 -f image2 frames/%06d.png
avconv -i data/raw.avi audio.mp3

Generamos el listado de fotogramas.

find ./frames -name "*.png" |sort > data/frame.txt

Se ejecuta waifu2x. En este caso, solo está haciendo limpieza de ruido.

mkdir new_frames
th waifu2x.lua -m noise -noise_level 1 -resume 1 -l data/frame.txt -o new_frames/%d.png

Por último, se genera el vídeo.

avconv -f image2 -framerate 24 -i new_frames/%d.png -i audio.mp3 -r 24 -vcodec libx264 -crf 16 video.mp4

Ejemplo de vídeo

Tras ello, podemos evaluar el resultado que, en mi opinión, es bastante decente teniendo en cuenta que los fotogramas en un vídeo tienen cierto ruido debido al uso de códecs con pérdida. Yo he hecho un experimento con ello y os lo muestro a continuación (aunque incluye también el tema de la interpolación, cosa que hablaré en otro artículo).

En conclusión, ya tengo otra forma de reescalar imágenes y que me queden bastante mejor que usando bicúbica o lanczos.

Nota adicional: No es necesario instalarse el software, el creador del mismo tiene un portal web para escalar imágenes. Dadle euros para que pueda seguir manteniéndolo si os gusta el resultado.

5/3/2022: He abandonado la idea porque no le he dedicado el tiempo suficiente, tampoco dispongo del hardware que permitiría hacer el proyecto y ya hay otras personas que han hecho este proyecto con el mismo resultado esperado.

Objetivo

Este artículo está basado en una prueba de concepto que quería aplicar desde hace bastante tiempo: montar un cluster Beowulf para cacharrear y probar ciertos conceptos basado en sistemas múltiples.
Las finalidades de este concepto son las siguientes:

1. Construir un cluster tipo Beowulf que requiera poco espacio y poco consumo eléctrico para un servicio 24/7.
2. Montaje de un monitor web que compruebe el estado de los nodos.
3. Aprovechar las funciones del servicio NFS en el nodo maestro para reducir el estrés en las tarjetas SD.
4. Aprender el funcionamiento de balanceo de carga en servicios web.
5. Montar un sistema que permite donar computación a proyectos científicos a través de BOINC (como equipos individuales).
6. Probar la programación en computación distribuida (MPI).

Es obvio que no estoy haciendo nada nuevo ni tiene mayor rendimiento que, por ejemplo, mi estación de trabajo o la computación por GPU. La finalidad de esto es cacharrear, aprender y divertirse (y ya por el título se nota que no estoy siendo serio en esto). Es más, hay unos cuantos proyectos similares de mayor o menor envergadura, como el cluster de la Universidad de Southampton (2012), el primero de una larga lista de clusters usando Raspberry Pi, el corazón de este proyecto.

Empecemos...

1. Hardware

Como ya mencioné, los nodos de computación van a ser ordenadores Raspberry Pi. Muchos van a preguntarse el porqué de ello, habiendo otros modelos de ordenadores en placa única (Single Board Computers) como los ODROID XU4, los cuales son más potentes o incluso haber optado por algunos más baratos basados en, ejem, AllWinner.
Los motivos principales de elección fueron la documentación disponible, la comunidad alrededor del dispositivo y porque encontré las Raspberry a mitad de precio (la caja estaba en mal estado y no lo podían vender).

Pero tengo que reconocer que voy a hacer algo de trampa. El nodo maestro va a ser un pc industrial que tiene un procesador Intel Atom D2550 y 4GB de memoria RAM, encontrado también por Internet (me costó igual que una Raspberry).

Y con ello, paso a mostrar la lista de hardware:

• 7 Raspberry Pi variadas (versión 2 o superior). Concretamente 6 Pi 2 y 1 Pi 3. Esto serán los "nodos de cálculo".
• 1 PC industrial con procesador Intel Atom D2550. Esto será el nodo maestro, el servidor NFS y la puerta de enlace de los nodos. Aunque también valdría un router que permita realizar estas funciones.
• 1 Adaptador AC a 5 puertos USB de 60W.
• 1 Switch Gigabit. Concretamente es un modelo concreto de D-Link, ya veréis porqué.
• 8 cables USB a microUSB.
• 9 cables Ethernet.
• 7 tarjetas microSD.
• 1 disco duro. Esto es para almacenamiento NFS.
• 1 SSD (opcional).
• Soportes para apilar las Raspberrys. Parece que estaban en Amazon pero ya no lo veo. Aun así están disponibles en ModMyPi (aunque son otro modelo)

Creo que el precio por el que compré todo (teniendo en cuenta que muchas partes vienen de segunda mano), fue de 400€ aproximadamente. Se puede ver que hay que tener muchas ganas de ponerse con esto, ya que se puede obtener una tarjeta gráfica de calidad por precio similar y estudiar computación por GPU (OpenCL).

Como podéis ver en la foto, la forma de la torre de nodos es idéntica a la que hicieron en la revista Make: , solo que en lugar de 4 hay 7 nodos. Me inspiré en el diseño que hicieron.

En el siguiente artículo, explicaré el primer objetivo del proyecto: el montaje del cluster. Además, mostraré los trucos que he llevado a cabo para hacer más compacto el sistema. (5/3/2022: No va a haber más partes publicadas. Ver cita al inicio del artículo.)