¿Cómo compilaríamos nuestro código si todos nuestros binarios desaparecieran?

El proceso ocurrirá en etapas. No veremos a un grupo de geeks amontonados en una habitación durante 4 años seguidos de un i7 en funcionamiento que arranca Linux. Esas CPU y arquitecturas grandes y complicadas son solo una pequeña parte del mundo informático moderno. También hay miles y miles de fichas más pequeñas que son mucho más fáciles de levantar.

Empezaríamos con un pequeño chip, como un ATtiny. Se puede programar a través de un bus serie SPI , que está cronometrado al 100 % por el maestro. Esto significa que puede tener un conjunto de 4 interruptores controlados por manos humanas, y si los gira en el orden correcto, puede enviar instrucciones a la memoria del ATtiny.

Ahora el primer programa no necesita ser mucho. Esto es algo bueno, porque mover interruptores así es difícil. La primera aplicación probablemente sería una aplicación similar a un editor de texto que le permite escribir una aplicación con interruptores fáciles de usar (es decir, configure 8 interruptores para un byte, luego presione la tecla "confirmar" para almacenarlo en el programa), y algunos capacidades básicas de lectura/escritura (busque el byte 200, reemplácelo con un e8). Antes de apagarlo, esto se extendería para escribir en la memoria flash del ATtiny. Ahora tenemos una computadora que funciona (aunque sea pequeña). Cuando lo apaga y lo vuelve a encender, puede volver a cargar la aplicación de edición de texto.

Ahora, la siguiente pieza del rompecabezas es usar esto para programar otros chips. Esto es fácil: la misma interfaz SPI que usó para desarrollar la primera aplicación es la que usaría para crear aplicaciones en otras. Podría escribir un segundo programa en la memoria flash que, a pedido, se graba en este segundo chip. Ahora podemos duplicar fácilmente nuestro programa de edición de texto, lo que permite que varios desarrolladores trabajen en los desafíos en paralelo.

Ahora podemos usar esto para programar un chip más grande, como un ATmega. En realidad, podríamos haber comenzado con ATmega, porque tiene una capacidad de programación similar, pero sentí que la historia tenía una sensación más clara si comenzáramos programando algo que es demasiado pequeño para contener cualquier herramienta moderna como un compilador de C++. De todos modos, una vez que tengamos un chip lo suficientemente grande, podemos desarrollar un ensamblador real. Tal vez desempolve una de esas viejas impresoras de matriz de puntos e imprima texto en el puerto paralelo. Quite el polvo de un viejo teclado PS/2 y conéctelo directamente al ATmega. Ahora tenemos un ensamblador completo, con un mínimo de decencia humana.

Ahora comienza la fase de arranque. Podemos usar este ATmega para arrancar algunos de los chips más grandes, como el i7, porque podemos usarlo para programar chips FLASH, como aquellos a los que está conectado el BIOS. No es fácil, pero tenemos muchos ingenieros que todavía tienen que trabajar en esas capas, por lo que alguien recordará lo suficiente para que la BIOS funcione. Con esto, no es descabellado esperar que el teclado y las pantallas funcionen (no más código de impresión en las impresoras para leerlo). También deberíamos poder acceder a los discos duros nuevamente, para que podamos escribir código de manera más permanente. Esperaría, en este punto, que alguien escribiera una versión básica de vi(sí, puede ser más básica quevi), y un ensamblador, los cuales funcionan en un sistema de archivos rudimentario. Todo esto está dentro de las capacidades de los desarrolladores de hoy. De hecho, algunos de ellos pensarían que en realidad es un poco divertido (hasta que se agote el Mtn. Dew).

Ahora para la fase real de arranque. Alguien escribirá un controlador de ensamblaje para acceder a un sistema de archivos moderno, como EXT3. No será bonito, pero es suficiente para encontrar una copia de alguna versión antigua de C de los primeros días de arranque. C se inició escribiendo un compilador de C muy simple que manejaba algunos (pero no todos) de los comandos en el lenguaje C. Este compilador simple se usó luego para desarrollar una versión más avanzada de C, y así sucesivamente, agregando características cada vez que se vuelven más y más fáciles de escribir.

Eventualmente, escribiríamos suficiente compilador de C para compilar GCC. Una vez que compilamos un compilador GCC, los frenos se liberan. En cuestión de semanas, tendríamos todas las aplicaciones de Linux operativas, incluido el propio Linux. A partir de ahí, los otros sistemas operativos podrían impulsarse a sí mismos.

Hablamos por teléfono con algunas de las personas que lo hicieron la primera vez.

No en serio. Tenemos muchos expertos en este campo que todavía están vivos, y es posible que tengan suficiente conocimiento entre ellos para construir un BIOS que funcione. A partir de ahí, podemos llevar a cabo el proceso mucho más rápido que la primera vez: simplemente consultamos al siguiente grupo de expertos para obtener el siguiente conocimiento, que usamos para construir el siguiente nivel de software.

Eventualmente, este proceso llega hasta los expertos de Microsoft y todas las grandes compañías informáticas que fabrican y mantienen los lenguajes que usamos hoy en día, y simplemente presionan F5, compilan el código fuente del lenguaje y nos brindan un nuevo conjunto de binarios.

El mayor problema aquí es la redistribución. Si los binarios de todos han desaparecido, debe reconstruir todas las computadoras o hacer que todos compren una nueva. Y luego, para algunos de los nuevos idiomas que no están preinstalados, debe reforzar sus servidores de distribución para que no se bloqueen cuando todos intenten obtener una copia a la vez.

Hoy en día, no podremos usar ninguna computadora -si desaparecieran todos los programas binarios-, ya que todas tienen algún firmware (por ejemplo, la BIOS) para arrancar, y ese firmware está dentro de alguna ROM (a menudo, alguna Flash ROM).

El tiempo en el que se podía ingresar fácilmente al programa de arranque primordial (sin la ayuda de alguna otra computadora) quedó atrás. ¡En la década de 1960, podía arrancar IBM7094 con conmutadores!

Si cambia su hipótesis a "todos los discos que tengo están borrados" y si su firmware le da algún acceso de escritura (¡y si tuviera toda la documentación necesaria en papel!), podría arrancar su computadora.

Por cierto, supongo que si perdiéramos todos los binarios de software libre en la Tierra tendríamos muchos más problemas que si perdiéramos todos los binarios de software propietario (supongo que en ambos casos el código fuente permanece disponible).

Lea mucho más sobre el arranque , en particular acerca de los compiladores de arranque , por ejemplo, cómo se escribió el primer compilador . Lea también el blog de J.Pitrat sobre el arranque de la inteligencia artificial , está dedicado a los problemas de arranque desde un punto de vista sólido de la IA.

Ver también esta respuesta y aquella a una pregunta muy relacionada. También te puede interesar Linux From Scratch , o Isaac Operating System (escrito en su propio lenguaje, ejecutándose en el bare metal) o incluso MirageOS .

Un problema concreto con el arranque de una computadora completa hoy en día es que es bastante complejo (en particular, pero no solo, debido a las complejidades tecnológicas: los manuales de referencia de Intel x86-64 tienen muchos miles de páginas, y x86 y PC son muy complejos en particular porque por razones históricas y de compatibilidad con versiones anteriores), por lo que llevará mucho tiempo (muchos años de trabajo) y es (lamentablemente) difícil que te paguen por eso. Entonces hay un problema social. Podría ser un poco más simple con otro hardware (por ejemplo, RISC-V , que en realidad no existe o es mucho menos eficiente).

Una pregunta relacionada es cómo reiniciar Internet si o cuando se bloquee.

Apocalipsis ahora

Una mañana temprano, todos los binarios del mundo se desvanecen. Cada pieza de código compilado se ha ido; los datos aún están allí, los archivos de código aún están intactos, pero cada pieza de código compilado se ha ido. Maricón.

Lo primero en la mente de todos no será cómo recuperarlo, sino cómo sobrevivir; los aviones fly-by-wire caerán del cielo, los teléfonos no funcionarán, Internet desaparecerá, los automóviles no arrancarán, las centrales eléctricas se apagarán. Todos esos dispositivos y sistemas, grandes o pequeños, tienen pequeños chips que alguna vez estuvieron llenos de firmware. Por supuesto, cualquier cosa construida en la década de 1980 o antes probablemente estará bien; los automóviles no comenzaron a tener computadoras a bordo hasta la década de 1990, en su mayor parte.

Aún así, esto no es solo un desastre de ingeniería o programación. Es un evento a escala de apocalipsis. Una buena parte del mundo se quedará sin comida, agua o electricidad fiables; la comunicación se cortará por completo.

¿Donde empezar?

El mejor lugar sería un colegio o universidad, ya que lo más probable es que tengan un lector de tarjetas perforadas que funcione (y un generador). Usando tarjetas perforadas como interfaz inicial, nuestros intrépidos programadores podrían comenzar a escribir código inmediatamente.

Por supuesto, esas viejas máquinas son terriblemente lentas y consumen mucha energía. Por lo tanto, nuestros programadores utilizan los sistemas controlados por tarjetas perforadas para programar microcontroladores , o sus primos más rápidos, las microcomputadoras .

Estas pequeñas computadoras necesitarán algún tipo de interfaz; con suerte, hay un viejo teclado controlado por transistores y algunos CRT viejos por ahí. Los teclados modernos y las pantallas LCD dependen del firmware. Con un poco de discusión sobre el código, nuestros programadores tienen una computadora, un teclado, una pantalla y una forma de guardar su código.

Además, se volverá a actualizar cualquier dispositivo con firmware que pueda reescribirse rápidamente; algún hardware antiguo, como las unidades de CD antiguas, tenía muy poco firmware, pero aún podría leer discos modernos.

Fusibles de seguridad

Recuperar lo perdido será mucho, mucho más difícil. Casi todo el hardware moderno no será más que basura; casi todos los chips con un fusible de seguridad quemado serán inútiles, convirtiendo los teléfonos celulares y las computadoras portátiles en ladrillos. Los discos duros, aunque los datos aún existen, no tendrán firmware para extraer esos datos.

La mejor apuesta son las computadoras de código abierto. Alguien, en algún lugar, tendrá un chip flash sin bloqueo de seguridad con algún código almacenado. A partir de ahí, la computadora de código abierto se puede reconstruir y los programadores pueden comenzar lentamente a restaurar el software. De lo contrario, alguien tiene una copia de seguridad de todo su código en una unidad flash barata; con un poco de piratería de hardware, es posible extraer esos datos, aunque será un proceso difícil.

Regreso al futuro

Una vez que las computadoras (por diminutas que sean) estén operativas, la vida será un poco más fácil, pero la mayoría del hardware moderno será inútil. Incluso si se pudiera reconstruir el BIOS en una placa base moderna, las tarjetas de video, ethernet e incluso sonido no tendrían su firmware. El software se restablecería a donde estaba a fines de la década de 1980. Regresaría gradualmente, pero espero que tome más tiempo que la primera vez. Lo del apocalipsis, y todo.

Uno de los problemas más grandes no es la compilación del código fuente porque lo perdería todo, todas las unidades se almacenan en binario, por lo que todo lo que conocemos como tecnología actual sería borrado. Y reprogramarlo todo sería una gran tarea considerando que todos los prototipos o versiones desaparecerían. Esperaría incluso una escasez de alimentos u otros eventos similares considerando cuántas computadoras pequeñas hay en las cosas que usamos con tanta frecuencia en nuestras vidas, como automóviles, administración de la red eléctrica y electrodomésticos.

Técnicamente, el firmware es "hardware", por lo que esperaría que se mantuviera. Supongo que la "desaparición de archivos binarios" tiene más que ver con la eliminación de la información que con una calamidad física que afectó a todos los dispositivos de almacenamiento de información, pero perdió por poco cualquier cosa que no se pareciera a un código de máquina en ejecución. Si efectivamente se mantuviera el firmware, entonces creo que tendríamos una buena ventaja. Deberíamos poder iniciar cualquier sistema que pueda funcionar con firmware y al menos tener un sistema operativo primitivo y capacidad de edición de texto. El problema interesante es que si tenemos el código fuente, pero la mayor parte es electrónico, entonces es prácticamente inútil para nosotros hasta que podamos restaurar los sistemas que pueden leerlo.

Dado que hay tanto software potencialmente utilizable por ahí, tendría más sentido reproducir los compiladores que podrían reconstruir el software. Esto significa que lo más probable es que la sociedad no intente reinventar los lenguajes de programación desde cero hasta que hayamos recuperado los que acabamos de perder. Dado que hemos perdido el uso de Internet y el almacenamiento de información digital, nuestra mejor apuesta es apuntar a los idiomas mejor documentados para los que tenemos libros. Sin duda, un compilador de C será la primera y más importante herramienta de alto nivel en la reconstrucción. Una vez que tenga eso, el progreso se puede hacer muy rápidamente. Luego puede reconstruir sistemas operativos completos, muchas herramientas de software y compiladores para muchos idiomas. Hay una razón por la que este lenguaje de 40 años todavía encabeza la lista de TIOBE. Es el "inglés" del mundo de la programación: torpe, molesto,

Dado que hay tantos expertos en C/C++ en el mundo, una vez que tenga un sistema que pueda ingresar texto y almacenar bytes en el disco, construir un compilador en realidad no debería ser tan difícil. Lo más probable es que un grupo de personas mejore el "IDE" a través del código ensamblador/máquina sin procesar, y probablemente lo reinvente desde cero solo para mejorar la productividad. Muchas partes de un sistema operativo mínimo serían forzadas solo para poner en funcionamiento este primer compilador de C. Pero estoy bastante seguro de que obtener la primera compilación autohospedada del compilador sería el equivalente moral del motor de arranque en un motor gigante que finalmente enciende el volante para que pueda ser autosuficiente.

De hecho, lo más probable es que este proceso ocurra en muchos lugares del mundo. Es muy posible que Rusia o Europa del Este produzcan el primer compilador de C en funcionamiento "poscatástrofe" debido a la cantidad de piratas informáticos/escritores de virus que tienen que comprender el código de bajo nivel. Aunque China tiene muchos piratas informáticos, tienden a tomar caminos de nivel superior hacia los sistemas. Me sorprendería que crearan uno de los primeros compiladores de C desde cero (aunque un gran grupo de estudiantes universitarios emprendedores pueden lograrlo por pura fuerza de voluntad). Los piratas informáticos de EE. UU. y Europa occidental tendrían la ventaja de contar con la mayor cantidad de libros C y manuales de referencia disponibles, y en un idioma que comprendan fácilmente.

Ahora, si el firmware también se elimina, las cosas se vuelven mucho, mucho más difíciles, en la línea de alternar el interruptor como lo describen otros. Eso es tan deprimente que ni siquiera puedo contemplarlo. Pero asumo que los subprocesos se fusionan una vez que llegas a una consola básica (teclado, monitor, almacenamiento persistente... ya sea disco, cinta, flash, etc.).

Aunque muchos lenguajes tienen compiladores autohospedados, la mayoría de los compiladores podrían reconstruirse desde cero en C, y la mayoría de los diseñadores del lenguaje original podrían ayudar en este esfuerzo. Creo que, en general, la reconstrucción procedería mucho más rápido de lo que la gente podría imaginar (desde la consola básica hasta el compilador de C con alojamiento propio en 6 meses o menos). En casi todos los casos, la gente probablemente decidirá que es mejor simplemente reemplazar lo que se perdió y recuperar la funcionalidad que salirse de los rieles y rediseñar las cosas.

Se produciría un rediseño si también perdiera el código fuente . Tal vez la información se retenga en los libros, pero si se perdieran todos los ejecutables electrónicos y la fuente, entonces creo que veríamos un rediseño significativo y un atajo a técnicas más avanzadas. Creo que C todavía se reconstruiría desde cero, debido a su estatus como una especie de lingua franca. Y posiblemente Java y algunos otros lenguajes principales serían revividos (aunque obviamente de implementaciones de sala limpia). Por otro lado, sería mucho más difícil restaurar Linux, Windows o OS X sin ningún código fuente, solo a partir de libros.

Curiosamente, podríamos aprovechar esta oportunidad para eliminar muchas fallas persistentes de los lenguajes, herramientas y sistemas operativos. Tal vez no obtendríamos C exactamente, sino una especie de C99 mejorado con una gran cantidad de elementos heredados eliminados. Por un lado, sería beneficioso para todos simplemente implementar un compilador C99 exacto, para que personas de todo el mundo pudieran intercambiar fuentes C a medida que se reconstruía el mundo digital. Esto desalentaría la innovación. Y por esta razón, lo más probable es que Linux se convierta en el sistema operativo de facto de la nueva era, simplemente porque muchas partes de él podrían restaurarse a partir de libros y conocimientos guardados en ciertos asistentes de alto nivel.

Probablemente, el software propietario simplemente dejaría de competir hasta que se reemplazara la mayor parte de la funcionalidad. Por lo tanto, lo más probable es que la reconstrucción ocurra bajo un modelo muy abierto, a menos que algunos países noten que están progresando mucho más rápido que otros y puedan obtener una ventaja competitiva al cerrar su progreso del resto del mundo. Al final del día, el comercio global obligaría a los países a restablecer los estándares internacionales, por lo que es difícil decir cuánto tiempo podrían sobrevivir esos muros.

Aunque muchos lenguajes fallidos simplemente no se reproducirían (a menos que lo hicieran sus amados creadores), los lenguajes más populares seguramente se revivirían debido al valor acumulado de los programadores con dominio de esos lenguajes. Lo mismo ocurre con las herramientas. Sin embargo, llevaría mucho tiempo reconstruir algo como Microsoft Office o Adobe Photoshop, y mucho menos Windows Server 2012. Es posible que estas herramientas nunca vuelvan a existir, y quizás haya una nueva carrera armamentista para reinventar cada categoría de software desde cero.

Cada tecnología con un estándar publicado superaría a las alternativas propietarias sin un estándar público, simplemente porque los estándares representarían un esfuerzo intelectual preservado en el texto que no necesita ser rehecho. Pero las tecnologías estándar más débiles pueden ser reemplazadas por mejores alternativas simplemente porque el peso del legado se ha quitado y ya no es una gran ventaja para las malas soluciones antiguas.

Cuando hablamos de lenguajes de programación y programación informática en general, hablamos de lenguajes y su nivel de abstracción. Una vez tuvimos paneles de conexión que se usaban para programar computadoras. La mayoría de las computadoras no eran realmente programables, sino que estaban cableadas para realizar cierto tipo de operación. Más tarde llegamos a las computadoras programables.

Al principio, usamos códigos de operación binarios para producir código. Necesitaría conocer cada código de operación que usó el procesador e ingresar su programa byte por byte en la memoria de la computadora. Más tarde se inventó una forma abreviada, que usaba palabras para describir operaciones. Se llamaba forma mnemotécnica. Esto es casi como un montaje moderno. Un segundo paso vino con los ensambladores de macros, que permitieron el uso de macros. Esos son los lenguajes de bajo nivel.

Un lenguaje de nivel medio es algo así como C y PL/I, no son lenguajes muy abstractos. La gente suele considerar que este es el lenguaje de los hackers más extremo: "Oye, estoy usando un lenguaje de abstracción media, esto debería significar que soy un súper hacker". Pero, por lo general, los lenguajes de baja abstracción son más propensos a los defectos. C proporciona llamadas de función básicas basadas en argumentos de función y otras abstracciones menos primitivas como matrices y estructuras. Esto es mucho más fácil de programar que el ensamblaje puro y, si se hace con cuidado, puede incluso dar como resultado un código portátil. Pero C carece de abstracciones como objetos, cadenas (cadenas formales, no cadenas basadas en punteros).

Un lenguaje con un mayor nivel de abstracción es Java o C#. Lamentablemente, ambos idiomas se interpretan en una máquina virtual. Esto significa que la ejecución del código debe traducirse sobre la marcha desde una máquina virtual abstracta a algo que el procesador de nivel inferior entienda. Que es lento. Otro lenguaje que ofrece un nivel muy alto de abstracción es Python, Ruby, etc. Entonces, la gente piensa que los lenguajes de alto nivel deben interpretarse. Object Pascal (el hijo feo rechazado) es tan abstracto como Java pero produce un código verdaderamente compilado (hasta el formato binario).

El código administrado no es el último invento. Implica un precio enorme en velocidad. Es una especie de abstracción, pero no exenta de defectos.

El proceso de creación del ecosistema de un nuevo sistema informático se denomina arranque. Si crea una nueva computadora, deberá realizar dos pasos: crear un compilador que pueda generar código en la forma esperada de esta máquina y un nuevo sistema operativo (que generalmente estará escrito en ese idioma).

Por lo general, comenzará con un compilador cruzado que usará un determinado sistema ya existente para generar código para este nuevo sistema. Luego, este compilador cruzado se usará para crear un sistema operativo básico y compilar el compilador en un binario que se ejecute en esa nueva computadora.

Dado que las máquinas del mundo real se basan en componentes reales, esas máquinas funcionan con un nivel de abstracción bajo. No se pueden tener máquinas virtuales sin máquinas reales, porque una máquina virtual es en realidad un programa de computadora como cualquier otro. Esto significa que entre el código de su programa y el hardware existe un hueco que necesita ser llenado.

tl; dr

Primero necesitará crear un programa ensamblador mnemotécnico desde cero (utilizando su conocimiento sobre las máquinas), luego un ensamblador de macros y luego un compilador verdadero (generalmente para lenguaje C). A partir de entonces podrás compilar todo lo demás.

¿Cómo compilaríamos nuestro código si todos los binarios del mundo desaparecieran [...]

Haga que alguien de la Estación Espacial Internacional use un Soyuz-TMA para bajar con una computadora portátil que aún funciona con todos los compiladores que tienen disponibles. (Oye, técnicamente no están en el mundo ...)

La recuperación sería mucho más rápida de lo que piensas

Encuentra un coche anterior a 1986, conduce hasta el museo de la informática. Inicie el cuadro de Altair, Imsai o Digital Group, e inícielo normalmente: alternar en un cargador de arranque .

Alternar significa configurar una dirección de memoria en los 16 interruptores de dirección, luego configurar un valor de datos en los 8 interruptores de datos y presionar "ESCRIBIR", luego pasar automáticamente a la siguiente ubicación de memoria, repetir el lavado con enjuague.

Un cargador de arranque es un programa extremadamente corto, de ~100 bytes, que puede ingresar datos desde algún otro dispositivo de E/S, como un lector de cinta de papel.

Use el lector de cinta de papel para ingresar su programa, o hey, aquí tiene una idea, ¿qué tal un sistema operativo ? Ya sabes, como Apple Monitor (2048 bytes) que incluía mucho código para emular un TTY en la pantalla y el teclado internos de Apple, no es necesario, solo usa un TTY físico o VT100.

Y ahora hacemos una pausa para almorzar .

Unos pocos cientos de bytes en el sistema operativo le enseñan a leer/escribir una cinta de casete. Otro par de miles le enseñan a leer/escribir unidades de disco. No estoy especulando, así es como funcionaron.

Mientras tanto, se están realizando esfuerzos paralelos

• almacenar el cargador de arranque en la ROM de alguna manera, para reducir los callos en los dedos

• un sistema de archivos de disco primordial

• un editor de texto simple (hmm, ¿los VT100 todavía funcionan?)

• un ensamblador (compilador de lenguaje ensamblador, por lo que podemos decir LDA #INPUT_MODEen lugar de A9 03.).

Y será mejor que cenemos antes de que cierren todos los restaurantes.

En este punto, estamos haciendo la línea de comandos tal como lo hacemos ahora, excepto que usamos un VT100 real en lugar de una ventana Terminal/PuTTY. No tendremos un ls -Rporque aún no tenemos un sistema de archivos recursivo, pero pequeños pasos Ellie.

Hablando de pequeños pasos, comenzamos a escribir lenguajes de alto nivel y desarrollo cruzado; es decir, use el Imsai para realizar una compilación cruzada de 80386 para arrancar el Compaq 386 (tenga en cuenta que su primer código x86 sería nativo de 32 bits y no tendría el concepto de las antiguas barreras de RAM de 64k/1 MB), luego utilícelo para compilación cruzada para PowerMac G3, etc.

La parte difícil es la coordinación.

El problema es que este esfuerzo se lleva a cabo de manera independiente en cada lugar donde existe una máquina Altair/Imsai/Digital Group en funcionamiento. Ahora el desafío es coordinar los esfuerzos cuando los teléfonos no funcionan. Si los teléfonos funcionaran, cualquier módem de 300 baudios de pieza de museo haría que los equipos hablaran y compartieran el código.

Y la compañía telefónica no está ociosa; están tratando de descubrir cómo conseguir algo.

Aproximadamente un día después de que las telecomunicaciones estén listas, alguien habrá (re)escrito el software BBS, suponiendo que no haya encontrado una copia antigua del código fuente de BBS en la revista BYTE. Ahora estamos haciendo lo mismo que hacemos aquí. Esto aumenta balísticamente la velocidad de la reconstrucción, especialmente porque todas las naciones del mundo lo han identificado como una prioridad estratégica nacional.

El firmware es una molestia

Desafortunadamente, muchos componentes hoy en día, como los llaveros USB, tienen un "firmware" ejecutándose en un nivel inferior del sistema, y ​​realmente no tienen una puerta trasera "dura" como el panel frontal de Imsai para forzar la carga de un cargador de arranque. Si ese firmware desaparece, cada máquina tendría que ser pirateada o desechada. Sin embargo, eso no será un problema hasta que entremos en el hardware de 2000, por lo que Pentium y Mac Quadra 800 probablemente seguirán funcionando bien. Y con esos podemos rediseñar/reemplazar al otro.

Es cierto que una Quadra 800 no tiene un panel frontal de interruptores. Sin embargo, tiene rastros en su PCB, y tendría que hacer algo de piratería de hardware para obtener un cargador de arranque, o simplemente aprender a grabar EPROM.

Conocemos el destino

Dado que los problemas de diseño están extremadamente bien definidos y bien entendidos, todo lo que queda es el intercambio de códigos. No necesitamos reinventar la rueda, todos sabemos cómo son las ruedas, solo necesitamos tallar una.

Recuerde, casi todo el código existente lo entiende alguien que está vivo y que, si se le presiona, podría reescribirlo. Mejor.

Sería lo mejor del mundo.

Nos permitiría (je) "reiniciar" el diseño de nuestros sistemas informáticos desde cero, en lugar de arrastrar constantemente la antigua infraestructura heredada que complica todo. El código se simplificaría y unificaría en parte porque tenemos que hacer que el mundo vuelva a funcionar, y no hay tiempo para admitir un montón de formas heredadas de hacer lo mismo. DOSbox desaparecido . Las ventanas se han ido . Flash desaparecido . HTML/CSS/AJAX pantano simplificado . Etc. etc. El gobierno pisotearía todos los temas de patentes debido a la emergencia nacional.

¿Nunca ha deseado poder tomarse un mes y reescribir todo su código de espagueti heredado y estándares obsoletos? Ahora usted puede.

Una vez que tenemos un compilador C89 en funcionamiento , el problema está lejos de terminar: muchos programas no pueden compilar sin el simplismo que requiere gcc, que también es un compilador C++ que requiere bibliotecas C++.

Entonces, para compilar la mayoría del software, necesita un compilador de C ++, y para hacerlo, necesita un compilador de C ++.

Tomará mucho tiempo lograrlo. Y este puede ser tiempo suficiente para hacer que el software C89 sea popular, para tener nuevo software que se escriba desde cero, o se convierta, en C89.

Los lenguajes de programación livianos como luaese son C89, solo se harían cargo de los demás.