Entradas de la categoría ‘Informática en general’
Adiós al ZX Spectrum Vega Plus (o cómo no hacer una campaña de crowdfunding)
Estamos de acuerdo en que siempre existe un elemento de riesgo a la hora de respaldar una campaña de crowdfunding, incluso aunque dicha campaña esté respaldada por una figura mítica del mundo de la tecnología ochentera —como es Clive Sinclair— o, incluso, aunque el mecenazgo esté sobrefinanciado, algo que siempre parece ser un punto a favor para la credibilidad de la operación. Siempre hay una posibilidad de que la empresa no llegue a buen puerto, y el Sinclair ZX Spectrum Vega Plus es un ejemplo brillante de ello.
El crowdfunding en Indiegogo del Vega+ rompió su objetivo de financiación y, para el 27 de marzo del año 2016, contaba con un 367% de recaudación con respecto a la cifra original solicitada (100.000 £). Ganando el respaldo de Sir Clive Sinclair y teniendo detrás a la compañía Retro Computers Ltd., que ya había hecho ver la luz (con éxito) un año antes al hermano mayor de esta consola portátil, el Sinclair ZX Spectrum Vega (sin Plus), todo apuntaba a que la maquinita iba a ser un éxito de mercado sin precedentes; ¿quién no quiere jugar a sus legendarios juegos de ZX Spectrum en una portátil con un diseño de lujo? El retro y la nostalgia mandan.
Sin embargo, los problemas comenzaron a aparecer. Lo que iba a ser liberado en octubre del propio 2016, comenzó a retrasarse hasta llegar a febrero de 2017. Pero eso no es del todo un contratiempo, siempre y cuando los responsables sepan comunicar correctamente el progreso y las trabas a los patrocinadores, y es precisamente lo que no ha ocurrido aquí: problemas empresariales que llegan por boca de terceros, muy escasas imágenes del desarrollo del producto o simplemente diseños renderizados, fotos con pantallas rotas y planteamientos totalmente distintos al original, nulo intercambio de mensajes entre los desarrolladores y los mecenas, parca información sesgada y un largo etcétera.
Al final, y entrados ya en marzo, los aportadores a este crowdfunding se han hartado y han comenzado a pedir la devolución de su dinero sin más pretexto, disculpa ni subterfugio. La reacción de Indiegogo ha sido fulminante, cerrando unilateralmente el micromecenazgo del Vega+ y dando carpetazo a esta tomadura de pelo de manera tajante.
Los detalles sórdidos de esta problemática campaña fueron dados a conocer ayer mismo en una explosiva investigación de la BBC. Según el artículo, Retro Computers Ltd. pidió a la BBC que retrasara su cobertura debido a «amenazas creíbles de violencia» contra los empleados de la compañía. La BBC ha asegurado que ha pospuesto la publicación del artículo para proporcionar a Retro Computers Ltd. la oportunidad de compartir pruebas de las amenazas, cosa que no se ha producido.
Suponemos que esto se ha ido al traste definitivamente. Y es una pena, porque el proyecto era bonito, entrañable y atractivo, aunque no todas las voces del entorno retrotecnológico estén de acuerdo con esta afirmación. Desde luego, para hacer lo que han hecho, habría sido mejor que ni siquiera hubieran empezado. Siempre nos quedará una Nintendo DSi XL con el emulador ZXDS de Spectrum, hoy por hoy, la mejor forma —portátil— de disfrutar de nuestros míticos títulos del gomas con harta diferencia.
El bikini más antiguo (y famoso) en formato GIF
En los tiempos de las BBS, las imágenes más codiciadas en formato GIF que corrían entre módem y módem eran las de mozas en bikini o ligeras de ropa, y es que proporcionaban una estimulación «cultural» (aceptable en clasificación PEGI 12) para los adolescentes masculinos de la época.
Así como ya contamos en su día que la primera imagen digital de la historia fue una fotografía del hijo de Russell Kirsch y, también, que una foto subida de tono de Lena Söderberg para la revista Playboy sirvió para desarrollar los primeros algoritmos de compresión de imagen, hoy traemos a la palestra a Cheryl Tiegs, muy probablemente la primera modelo en bikini (formalmente un bañador) aparecida en un archivo GIF.
El fichero —que contiene la foto que se puede ver aquí arriba— está digitalmente fechado el día 29 de octubre del año 1987, esto es, sólo cuatro meses después de la fecha de publicación de la primera especificación GIF (15 de junio de 1987), la conocida como GIF87a, la configuración original y primigenia del estándar para imágenes de color indexado, que utilizaba compresión LZW y tenía la posibilidad de estar en formato entrelazado.
La imagen, en sí misma, proviene de una fotografía obtenida por Walter Iooss Jr. (un fotógrafo estadounidense especializado en instantáneas deportivas) para la edición de trajes de baño del anuario ‘Sports Illustrated Swimsuit Issuen’ de la revista ‘Sports Illustrated’ en 1978. Cheryl Tiegs es una modelo y diseñadora de moda estadounidense —hoy tiene ya 69 años— a la que frecuentemente se considera como la primera supermodelo americana. Esta foto suya de 1978 y, sobre todo, otra conocida como Pink Bikini del mismo año, han llegado hasta nuestros días como imágenes icónicas de la cultura pop de los setenta americanos; el traje de baño transparente produjo un gran escándalo en aquel entonces.
La fotografía fue digitalizada, con un escáner de mano, directamente desde la propia revista. No se conoce su autor legítimo, pero probablemente fuera Jim Maxey, fundador y presidente de la afamada BBS Event Horizons, quien creó y originó muchos archivos GIF en los primeros días del formato.
El nombre original del archivo en TEIGS.GIF
(el apellido de la muchacha mal escrito), es un GIF, como decíamos, del tipo 87a no entrelazado, de 640 x 350 píxeles (EGA), con una profundidad de color de 4 bits (16 colores) y originado en una plataforma IBM PC o compatible.
Cómo funciona la pantalla azul de la muerte en Windows
Casi todos los usuarios de Windows han oído hablar —si no experimentado— la infame «pantalla azul de la muerte» (BSOD). Este término ominoso se refiere a la pantalla de fondo azul que se muestra cuando se bloquea Windows, o deja de ejecutarse, a causa de un fallo catastrófico o de una condición interna que impida al sistema continuar funcionando.
Windows se bloquea (se detiene la ejecución y se muestra la pantalla azul) por muchas razones posibles. Un ejemplo muy común es una referencia a una dirección de memoria que causa una infracción de acceso, ya sea por intentar escribir en memoria de sólo lectura o por una operación de lectura en una dirección que no está asignada o mapeada. Otra causa común, por ejemplo, es una excepción inesperada o un «cuelgue». Los bloqueos también ocurren cuando el kernel de un subsistema (el administrador de memoria, el administrador de energía…) o un controlador (de pantalla, de red…) detectan inconsistencias en su propio funcionamiento.
Cuando un controlador o subsistema, pues, provoca una excepción ilegal, Windows se enfrenta a un difícil dilema: se ha detectado que una parte del sistema operativo con capacidades de acceso a cualquier dispositivo de hardware y a la memoria válida ha hecho algo que no se suponía que debería hacer. ¿Por qué significa eso que Windows tiene que fallar? ¿No podría, simplemente, ignorar la excepción y dejar que el controlador de dispositivo o el subsistema continuaran como si nada hubiera pasado?
Existe la posibilidad de que el error fuera aislado y de que el componente se recuperara de alguna manera. Pero, lo más probable, es que la excepción detectada resultara en problemas más profundos como, por ejemplo, una corrupción general de la memoria o un funcionamiento errático de un dispositivo de hardware. Permitir que el sistema continúe funcionando, probablemente, daría lugar a más excepciones, y los datos almacenados en el disco u otros periféricos podrían resultar corruptos; esto supone un riesgo demasiado elevado. Así que Windows adopta una política rápida de error al tratar de evitar que la corrupción en la RAM termine por extenderse al disco.
Independientemente de la razón de un bloqueo de sistema, la rutina que realmente realiza el bloqueo se conoce con el nombre de KeBugCheckEx
. Esta función toma un código de parada (a veces llamado código de comprobación de errores) y algunos parámetros más. Una vez que KeBugCheckEx
filtra todas las interrupciones del sistema, cambia la pantalla al modo de gráficos VGA de baja resolución (implementado por todos los sistemas Windows y soportado por todas las tarjetas de vídeo actuales), pinta el fondo de azul y, a continuación, muestra el código de detención, seguido de algún texto que sugiere lo que el usuario puede hacer.
La primera línea de la sección de información técnica enumera el código de parada y los parámetros pasados a KeBugCheckEx
. Otra línea, cerca de la parte superior de la pantalla, proporciona el texto equivalente del identificador numérico del código de parada. Cuando un parámetro contiene una dirección de un código de sistema operativo o de dispositivo, Windows muestra también la dirección base del módulo en el que se encuentra la dirección del fallo, la fecha y hora (curiosamente con un valor hexadecimal en el formato timestamp de Unix) y el nombre del archivo del controlador de dispositivo. Esta información por sí sola podría ayudar al usuario a identificar el componente defectuoso.
Aunque existen más de 300 códigos de parada únicos, la mayoría son bastante raros de ver. En su lugar, sólo algunos pocos códigos de detención comunes representan la mayoría de los fallos de sistema de Windows.
Por último, el módulo KeBugCheckEx
recurre a la llamada de comprobación de errores de todos los controladores de dispositivos (registrados en la función llamada KeRegisterBugCheckCallback
), lo que permite a los controladores la oportunidad de detener esos dispositivos. Para terminar, accede al módulo KeRegisterBugCheckReasonCallback
, el cual permite a los mismos controladores anexar datos en el volcado de bloqueo o escribir información de volcado del fallo en dispositivos alternativos.
El impacto del microprocesador Zilog Z80 (RetroEuskal 2016)
Bajo el paraguas de la Euskal Encounter 24, que se ha celebrado en el BEC vizcaíno del 22 al 25 de julio, se ha oficiado este año la decimotercera edición de la RetroEuskal, un evento retroinformático en el que se puede visitar un museo ambulante de cacharros antiguos, disfrutar de charlas, torneos, proyecciones y concursos, y hasta hacer uso de un juegódromo para deleitarse con ordenadores clásicos y videoconsolas viejunas. Y todo ello de la mano de la Asociación RetroAcción.
Este año, como de costumbre, nos hemos dado una vuelta por allí para disfrutar del evento. La exposición anual siempre atiende a un tema concreto, y esta vez se hace llamar “El impacto del microprocesador Zilog Z80“. En síntesis, un montón de vitrinas que guardan antiguas piedras preciosas de la tecnología (desde hace cuarenta años hasta nuestros días) en las que un Z80 tuvo o tiene cabida de alguna u otra manera, como un ZX Spectrum, un MSX, una Sega Mega Drive, una Game Boy o un reproductor de MP3.
Con respecto a las charlas, pudimos disfrutar del siempre genial Andrés Samudio con su ponencia titulada «XYZZY: 40 años de ‘Colossal Cave’, el comienzo de las aventuras«. En ella, Andrés (mítico director de Aventuras AD) desgranó la historia de ‘Colossal Cave‘, la primera aventura conversacional para un ordenador, y cómo llegó a convertirse en su ‘La Aventura Original‘. La segunda de las charlas se dio en llamar «Kasparov vs Deep Blue: la lucha del hombre contra la máquina«, ofrecida por Alberto Lozoya Rodríguez (físico por la UPV/EHU), en la que se desgranó la evolución de las primeras máquinas para jugar al ajedrez y se desembocó en el propio Deep Blue, el ordenador que consiguió derrotar a Gary Kasparov.
También tuvimos torneos de ‘Quake‘, ‘Duke Nukem 3D‘ y ‘Street Fighter II‘, un concurso de disfraces para conseguir imitar a la mascota del evento, Patxibot, y un montón de consolas antiguas, ordenadores, máquinas arcade y hasta un pinball para poder jugar y cacharrear a tope.
En fin, todo un lujazo de fin de semana que reunió a lo más retro del panorama en un evento muy bien organizado. ¡Nos veremos en la próxima RetroEuskal!
Cuando el rover Curiosity llevó un ‘bug’ informático terrestre a Marte
Hace un par de años se descubrió un error informático que tenía ya 20 años de edad en el momento y que se localizó en multitud de dispositivos como coches, aviones, teléfonos móviles Android, maquinas que usan código abierto y hasta en el mismísimo Curiosity, el vehículo que la NASA envió a Marte en noviembre del año 2011.
El error se encontraba en el algoritmo de compresión de datos Lempel-Ziv-Oberhumer (LZO), creado por Markus Oberhumer, que fue el que descubrió y dio a conocer el fallo y compiló la nueva versión 2.07 del código corregido.
El algoritmo LZO fue creado en 1994 y, desde entonces, ha sido incluido en infinidad de sistemas, como por ejemplo OpenVPN, FFmpeg y el kernel de Linux. Oberhumer aseguró en su momento que la vulnerabilidad en el antiguo código podría provocar desbordamientos de búfer, denegaciones de servicio y ejecución remota de código bajo las condiciones necesarias, las cuales requieren tamaños de búfer enormes, e infrecuentes, y donde haya que descomprimir más de 16 MiB (224 bytes) dentro de un sola llamada a una función.
El impacto más grave cayó sobre plataformas de medios populares de FFmpeg y Libav, y muchos proyectos dependientes de ellos, como VLC Media Player y Handbrake. Los usuarios no actualizados y afectados pudieron ver comprometidas sus máquinas cuando reproducían películas, o audio, desde sitios maliciosos. El fallo también afectó a microcontroladores Linux utilizados en muchos dispositivos y máquinas, como coches y otros vehículos.
Un bug en toda regla que los humanos llevamos hasta Marte y que podría haber causado un conflicto interplanetario. O no.