Qué denominación tan curiosa y un poco chocante, pero el caso es que hoy me he unido a Ibercivis, un proyecto español que usa una infraestructura de código libre, BOINC.
Es una forma de emplear los recursos muchas veces desaprovechados de nuestros ordenadores, para colaborar en uno o más proyectos científicos.
Si además de en Ibercivis nos interesa participar en algún otro proyecto, como por ejemplo el de la vía láctea, puede empezarse por crear una cuenta en un administrador de cuentas como BAM, donde tenemos instrucciones paso a paso para empezar a computar ciudadanamente :-).
Mostrando entradas con la etiqueta informática. Mostrar todas las entradas
Mostrando entradas con la etiqueta informática. Mostrar todas las entradas
sábado, 29 de agosto de 2009
viernes, 24 de julio de 2009
Luna 2
Con algún retraso, ya llegué a la luna, y varias veces, pues el libro "Digital Apollo" en su parte final describe los alunizajes de todas las misiones posteriores a la del Apolo 11, aunque con menor detalle que en este caso. Y desde luego casi ni cita al Apolo 13.
Una de las curiosidades en relación con el software es que este debía colocarse físicamente en la memoria "fija", equivalente a una ROM. En esa memoria, con nucleos magneticos en forma de anillos, el bit 0 o 1 se determinaba por la situación física de un hilo conductor respecto a un nucleo concreto: si pasaba por el interior del mismo, o lo sorteaba por el exterior. En definitiva, cuando el programa ya se había compilado y convertido en ceros y unos que debían escribirse en la memoria, la copia del programa implicaba crear la memoria físicamente a base de pasar los hilos adecuados por cada nucleo. Como eso resultaba muy laborioso, el software debía entregarse con un amplio margen antes de llegar a usarlo en cada misión. Y esa laboriosa y delicada labor de "confeccionar" la memoria la realizaban las LOLs, las Little Old Ladies, las viejecitas, experimentadas trabajadoras del sector textil, que ayudadas de máquinas especiales iban hilando bit a bit el programa en la memoria. Alucinante.
La otra curiosidad más destacable que se revela en el libro es la causa de las famosas alarmas del computador del modulo lunar que precedieron, y pusieron en peligro aparente, al alunizaje del Apolo 11.
La primera alarma se produjo tras llegar a los 37000 pies, cuando el radar de altitud empezó a responder dando su estimación. Cuando se iba a validar esa lectura, saltó la alarma. Aldrin preguntó al ordenador, con un comando, la naturaleza de la misma, con el resultado 1202. Abajo en la tierra los ingenieros del IL reconocieron que se trataba de una "sobrecarga del ejecutivo". El ordenador estaba sobresaturado, algo equivalente en Windows a ver en el administrador de tareas que la CPU está al 100% todo el tiempo. Algo estaba haciendo trabajar al ordenador más de la cuenta, incluso a pesar de que por diseño sólo se debía llegar al 85% de uso de la capacidad del ordenador cuando este estuviera a pleno rendimiento. Los ingenieros decidieron seguir, digamos que hacer caso omiso a la alarma. La alarma volvió a aparecer poco después del primer "seguir sin hacer caso". Pero poco después una acción automática que debía tener lugar se llevó a cabo sin problema. Parece que a pesar de todo el ordenador hacía lo que debía. Los ingenieros seguían estrujandose la sesera para dar con la causa de la alarma, buscando posibles "culpables" en alguno de los comandos al ordenador. A pesar de tanta alarma, Armstrong no abortó el descenso. Tras unos minutos se llegó a los 7000 pies y el ordenador cambió al programa adecuado, la fase de aproximación. Otra consulta a todos los controladores en tierra dió el resultado "GO". A 3000 pies otra alarma, esta vez 1201, del mismo tipo que la anterior, y despues otra 1202. El ritmo cardiaco de Amstrong pasó de los 120 a los 150 latidos por minuto.
El caso es que el único efecto adverso de las alarmas en el alunizaje fué desviar la atención de todos, incluido Armstrong, que miró por la ventanilla la zona de alunizaje más tarde de lo normal, a los 2000 pies, para darse cuenta de que había un gran cráter y una zona con muchas rocas grandes cubriendo buena parte de la superficie. El lugar no era el esperado, porque pronto en el descenso se vió que iban largos, con un poco más de velocidad de la debida. En esa parte final se describen las maniobras del comandante, con el mando para redesignar el punto de alunizaje, y pilotando con el sistema "manual", programa P66, desde los 550 pies. Hasta el esperado contacto, tras el que llegan las palabras de Buzz Aldrin
En el control de la misión el respiro y la alegría no retrasaron la febril actividad para saber la causa de la alarma, pues el módulo lunar debía despegar en pocas horas. Los ingenieros del IL fueron a sus simuladores a intentar reproducir la alarma, y uno de ellos llegó corriendo al laboratorio desde casa, para indicar que había visto ese problema en una simulación causado por el radar de acoplamiento (rendezvous) activado en AUTO al aterrizar. Enseguida se consultó la telemetría, y se confirmó que ese radar estaba activado, en modo SLEW , aunque era innecesario para alunizar. Antes de despegar se indicó al módulo lunar pasar ese radar a modo LGC. El problema se solucionó y la alarma no volvió a aparecer.
Tanto en modo AUTO como en SLEW el radar enviaba sus datos al ordenador para presentarlos en la "pantalla" de la cabina. Resultó que el radar de acoplamiento y el ordenador tenián distintas fuentes de alimentación alterna, de igual frecuencia, pero que cayeron en un ángulo de fase especialmente desafortunado que desincronizó radar y ordenador, causando que los contadores del radar variasen constantemente debido al ruido eléctrico aleatorio, enviando el máximo flujo de datos al ordenador, que se veía obligado a incrementar o decrementar sus contadores para seguir los ángulos del radar, empleando cerca del 15% de su tiempo de proceso.
En tierra se habían hecho pruebas, pero conectando ambos sistemas a la misma fuente de alimentación, que evitaba ese problema.
Como se ve, el peligro se agazapa en los recovecos más inesperados. Y ya tiene guasa que lo que pudo haber abortado el alunizaje fuese un elemento que no jugaba entonces ningún papel y era usado sólo para el acoplamiento del módulo lunar con el de mando, tras despegar aquel de la Luna.
Pero al menos la robustez del diseño del ordenador salvó la situación. Además de tener un margen para encajar el 15% extra, el "ejecutivo asíncrono" diseñado por los ingenieros descartó, ante la sobrecarga, las tareas de baja prioridad, manteniendo las esenciales. Además se usó una "protección de reinicio", un requisito impuesto al equipo de software en 1968, que permitía reiniciar el sistema de forma prácticamente inmediata, nada que ver con los inicios y reinicios que sufrimos en los ordenadores normales hoy en día. Ese reinicio descartaba trabajos incompletos y de baja prioridad y seguía como si nada donde lo había dejado con el resto.
Y otro detalle explicado es que se habían tenido en cuenta reacciones a eventos improbables, y desarrollado errores de ordenador que probablemente nunca sucedieran, entre ellas una alarma indicando sobrecarga en el ordenador del módulo lunar. En una simulación pocos meses antes del despegue del Apolo 11 un controlador abortó la misión a causa de una alarma de programa, aunque el aterrizaje podría haberse completado, un error que preocupó mortalmente a todos, pues un aborto indebido de la misión era casi tan malo como no realizar uno necesario. Tras eso se pidió determinar para cada alarma qué podía pasar y qué se podía hacer. Uno de los ingenieros se hizo una chuleta que dejó en su consola de control. En esa chuleta aparecen los errores 1201 y 1202, y que no son causa de abortar. Cuando un controlador de vuelo pidió ayuda a su equipo de soporte tras la primera alarma 1202, ese ingeniero contestó "We´re go on that alarm". Para que luego hablen mal de las chuletas. Pero esa información no la conocía por ejemplo alguien que debería haber sido informado, el piloto Buzz Aldrin.
Al final, la causa del problema con las alarmas no era un error del ordenador o del software, sino un error de comunicación y en parte de ingeniería de sistemas. En proyectos grandes ( y no tan grandes) el mayor problema acaba siendo que la información que sabe A y puede evitar errores a B, no llega a este. Y la causa del éxito a pesar de todo reside también en mucha buena ingeniería, con amplios margenes, minuciosidad, pruebas, simulaciones, y llegar a explicar cualquier fallo que se produzca.
Sin embargo, en una pauta común y repetida, lo que trascendió a la prensa fué que el culpable era el ordenador. Al controlador que decidió seguir a pesar de la alarma se le recompensó por su "decision to proceed with the lunar landing when computer failed"
Aunque siempre se ha ponderado la actuación de los astronautas, y en todas las misiones Apolo que alunizaron el comandante hizo la parte final en modo "manual", incluso entonces las acciones manuales pasaban por el ordenador. Si de verdad hubiese fallado el ordenador, todavía ahora no haría 40 años de la llegada a la luna.
Una de las curiosidades en relación con el software es que este debía colocarse físicamente en la memoria "fija", equivalente a una ROM. En esa memoria, con nucleos magneticos en forma de anillos, el bit 0 o 1 se determinaba por la situación física de un hilo conductor respecto a un nucleo concreto: si pasaba por el interior del mismo, o lo sorteaba por el exterior. En definitiva, cuando el programa ya se había compilado y convertido en ceros y unos que debían escribirse en la memoria, la copia del programa implicaba crear la memoria físicamente a base de pasar los hilos adecuados por cada nucleo. Como eso resultaba muy laborioso, el software debía entregarse con un amplio margen antes de llegar a usarlo en cada misión. Y esa laboriosa y delicada labor de "confeccionar" la memoria la realizaban las LOLs, las Little Old Ladies, las viejecitas, experimentadas trabajadoras del sector textil, que ayudadas de máquinas especiales iban hilando bit a bit el programa en la memoria. Alucinante.
La otra curiosidad más destacable que se revela en el libro es la causa de las famosas alarmas del computador del modulo lunar que precedieron, y pusieron en peligro aparente, al alunizaje del Apolo 11.
La primera alarma se produjo tras llegar a los 37000 pies, cuando el radar de altitud empezó a responder dando su estimación. Cuando se iba a validar esa lectura, saltó la alarma. Aldrin preguntó al ordenador, con un comando, la naturaleza de la misma, con el resultado 1202. Abajo en la tierra los ingenieros del IL reconocieron que se trataba de una "sobrecarga del ejecutivo". El ordenador estaba sobresaturado, algo equivalente en Windows a ver en el administrador de tareas que la CPU está al 100% todo el tiempo. Algo estaba haciendo trabajar al ordenador más de la cuenta, incluso a pesar de que por diseño sólo se debía llegar al 85% de uso de la capacidad del ordenador cuando este estuviera a pleno rendimiento. Los ingenieros decidieron seguir, digamos que hacer caso omiso a la alarma. La alarma volvió a aparecer poco después del primer "seguir sin hacer caso". Pero poco después una acción automática que debía tener lugar se llevó a cabo sin problema. Parece que a pesar de todo el ordenador hacía lo que debía. Los ingenieros seguían estrujandose la sesera para dar con la causa de la alarma, buscando posibles "culpables" en alguno de los comandos al ordenador. A pesar de tanta alarma, Armstrong no abortó el descenso. Tras unos minutos se llegó a los 7000 pies y el ordenador cambió al programa adecuado, la fase de aproximación. Otra consulta a todos los controladores en tierra dió el resultado "GO". A 3000 pies otra alarma, esta vez 1201, del mismo tipo que la anterior, y despues otra 1202. El ritmo cardiaco de Amstrong pasó de los 120 a los 150 latidos por minuto.
El caso es que el único efecto adverso de las alarmas en el alunizaje fué desviar la atención de todos, incluido Armstrong, que miró por la ventanilla la zona de alunizaje más tarde de lo normal, a los 2000 pies, para darse cuenta de que había un gran cráter y una zona con muchas rocas grandes cubriendo buena parte de la superficie. El lugar no era el esperado, porque pronto en el descenso se vió que iban largos, con un poco más de velocidad de la debida. En esa parte final se describen las maniobras del comandante, con el mando para redesignar el punto de alunizaje, y pilotando con el sistema "manual", programa P66, desde los 550 pies. Hasta el esperado contacto, tras el que llegan las palabras de Buzz Aldrin
Engine stop. ACA out of detent.
Houston, Tranquility Base here. The Eagle has landed
En el control de la misión el respiro y la alegría no retrasaron la febril actividad para saber la causa de la alarma, pues el módulo lunar debía despegar en pocas horas. Los ingenieros del IL fueron a sus simuladores a intentar reproducir la alarma, y uno de ellos llegó corriendo al laboratorio desde casa, para indicar que había visto ese problema en una simulación causado por el radar de acoplamiento (rendezvous) activado en AUTO al aterrizar. Enseguida se consultó la telemetría, y se confirmó que ese radar estaba activado, en modo SLEW , aunque era innecesario para alunizar. Antes de despegar se indicó al módulo lunar pasar ese radar a modo LGC. El problema se solucionó y la alarma no volvió a aparecer.
Tanto en modo AUTO como en SLEW el radar enviaba sus datos al ordenador para presentarlos en la "pantalla" de la cabina. Resultó que el radar de acoplamiento y el ordenador tenián distintas fuentes de alimentación alterna, de igual frecuencia, pero que cayeron en un ángulo de fase especialmente desafortunado que desincronizó radar y ordenador, causando que los contadores del radar variasen constantemente debido al ruido eléctrico aleatorio, enviando el máximo flujo de datos al ordenador, que se veía obligado a incrementar o decrementar sus contadores para seguir los ángulos del radar, empleando cerca del 15% de su tiempo de proceso.
En tierra se habían hecho pruebas, pero conectando ambos sistemas a la misma fuente de alimentación, que evitaba ese problema.
Como se ve, el peligro se agazapa en los recovecos más inesperados. Y ya tiene guasa que lo que pudo haber abortado el alunizaje fuese un elemento que no jugaba entonces ningún papel y era usado sólo para el acoplamiento del módulo lunar con el de mando, tras despegar aquel de la Luna.
Pero al menos la robustez del diseño del ordenador salvó la situación. Además de tener un margen para encajar el 15% extra, el "ejecutivo asíncrono" diseñado por los ingenieros descartó, ante la sobrecarga, las tareas de baja prioridad, manteniendo las esenciales. Además se usó una "protección de reinicio", un requisito impuesto al equipo de software en 1968, que permitía reiniciar el sistema de forma prácticamente inmediata, nada que ver con los inicios y reinicios que sufrimos en los ordenadores normales hoy en día. Ese reinicio descartaba trabajos incompletos y de baja prioridad y seguía como si nada donde lo había dejado con el resto.
Y otro detalle explicado es que se habían tenido en cuenta reacciones a eventos improbables, y desarrollado errores de ordenador que probablemente nunca sucedieran, entre ellas una alarma indicando sobrecarga en el ordenador del módulo lunar. En una simulación pocos meses antes del despegue del Apolo 11 un controlador abortó la misión a causa de una alarma de programa, aunque el aterrizaje podría haberse completado, un error que preocupó mortalmente a todos, pues un aborto indebido de la misión era casi tan malo como no realizar uno necesario. Tras eso se pidió determinar para cada alarma qué podía pasar y qué se podía hacer. Uno de los ingenieros se hizo una chuleta que dejó en su consola de control. En esa chuleta aparecen los errores 1201 y 1202, y que no son causa de abortar. Cuando un controlador de vuelo pidió ayuda a su equipo de soporte tras la primera alarma 1202, ese ingeniero contestó "We´re go on that alarm". Para que luego hablen mal de las chuletas. Pero esa información no la conocía por ejemplo alguien que debería haber sido informado, el piloto Buzz Aldrin.
Al final, la causa del problema con las alarmas no era un error del ordenador o del software, sino un error de comunicación y en parte de ingeniería de sistemas. En proyectos grandes ( y no tan grandes) el mayor problema acaba siendo que la información que sabe A y puede evitar errores a B, no llega a este. Y la causa del éxito a pesar de todo reside también en mucha buena ingeniería, con amplios margenes, minuciosidad, pruebas, simulaciones, y llegar a explicar cualquier fallo que se produzca.
Sin embargo, en una pauta común y repetida, lo que trascendió a la prensa fué que el culpable era el ordenador. Al controlador que decidió seguir a pesar de la alarma se le recompensó por su "decision to proceed with the lunar landing when computer failed"
Aunque siempre se ha ponderado la actuación de los astronautas, y en todas las misiones Apolo que alunizaron el comandante hizo la parte final en modo "manual", incluso entonces las acciones manuales pasaban por el ordenador. Si de verdad hubiese fallado el ordenador, todavía ahora no haría 40 años de la llegada a la luna.
lunes, 20 de julio de 2009
Luna 1
Sí, hace 40 años que el hombre llegó a la Luna. Nos encantan estas puntuales efemérides redondas y señaladas.
En este caso, ese primer paso cósmico destaca por sí mismo. Pensar que alguién paseo por esa esfera desnuda, mudable y misteriosa, y contempló en directo la estampa de nuestro humilde planeta azul. Um...
Pero cómo se llegó a la Luna es incluso más fascinante que ese momento final.
En las películas actuales la promoción va muchas veces acompañada de documentales de "cómo se hizo", que suele ser más corto que la película. En el caso de la llegada a la Luna, la película dura muy poco, unos minutos, pero cualquier documental de cómo se hizo daría para días y días de metraje.
Ahora estoy leyendo "Digital Apollo. Human and Machine in Spaceflight" de David A. Mindell. Hay dos actores principales en este peculiar "cómo se hizo", los pilotos y los ingenieros, que actúan en el escenario de la Guerra Fría, a finales de la década de los 50 y en los 60 del siglo XX.
Pero antes el desarrollo de la aeronáutica ya plantea la dicotomía existente en todo avión, de estabilidad frente a maniobrabilidad, y la necesidad de usar la instrumentación y el control automático para ayudar al piloto. También hay una tensión en la función del piloto, ¿"conductor" (rol pasivo) o "aviador" (rol activo)?. En general los pilotos quieren ser "aviadores", y los ingenieros piensan en "conductores". El mayor progreso se consigue con personas que unen las dos características de piloto e ingeniero. Dos ejemplos señeros, James Doolittle y Charles Stark Draper.
En los 50 el desarrollo de aviones supersónicos pone en primer plano a los pilotos de prueba experimentales, la crema de la crema de los pilotos, que crean su propia sociedad, SETP (Society of experimental test pilots). Su primer banquete, el 4 de octubre de 1957, coincide con el día en que la URSS se adelanta en la carrera espacial lanzando el Sputnik.
La razón de ser de SETP es defender el papel protagonista y activo del elemento humano en el avance aeroespacial, puesto cada vez más en peligro por el avance técnico del control automático. Los pilotos van a tener a favor un factor clave: en la carrera espacial entre las dos grandes potencias los estadounidenses vinculan la democracia y la libertad al elemento humano, el valor de lo individual, frente a la inhumana automatización soviética. La presencia de los pilotos, luego astronautas, será esencial para el apoyo mediático a la apuesta política de Kennedy.
En el libro se repasan en los primeros capítulos los proyectos X-15, Mercury y Gemini. El X-15 es un avión supersónico, lanzado desde un B-52, capaz de sobrepasar la atmósfera, en donde el mayor problema a resolver es el de la reentrada a la misma. En cambio en Mercury y Gemini el piloto va en una capsula lanzada por un cohete similar a los misiles balísticos. En todos esos proyectos hay considerables retos técnicos, pero siempre surge en primer plano cuál debe ser el papel del piloto. En general se adopta una aproximación de ingeniería de sistemas en que el piloto es un subsistema, que debe interactuar con el resto, debiendo entenderse y modelarse por tanto adecuadamente ese subsistema humano.
Al margen de la exposición principal de esos proyectos con pilotos, se menciona el proyecto Polaris con sus misiles lanzables desde un submarino en inmersión, que influirá notablemente en dos aspectos, de gestión del proyecto (aquí nace el PERT) y de control automático. Los misiles deben ser casi completamente autónomos en su posicionamiento y guiado: desde luego no tienen piloto, deben ser precisos, y las comunicaciones entre estaciones de tierra y el misil pueden ser "estorbadas" por el enemigo.
Antes de que volasen las misiones Mercury o Gemini, antes de que Kennedy decidiese en mayo de 1961, tras menos de medio año de mandato, enviar un norteamericano a la Luna, ya se había creado la NASA, que organizó en el verano de 1960 una reunión industrial para definir un proyecto de alunizaje y hacer saber a los posibles contratistas qué esperar. Tras la bofetada soviética en abril de 1961, al ser Yuri Gagarin el primer humano puesto en órbita, los estadounidenses buscaron algo en lo que poder ser primeros, y encontraron el proyecto Apolo. Y desde el principio los consejeros del presidente tuvieron claro una cosa, antes que las razones técnicas o científicas era preciso "vender" el proyecto como la empresa humana de la conquista del espacio pues
En el proyecto Apolo se iba a dar una situación atípica, distinta al resto de proyectos, pues una parte central del mismo se iba a adjudicar, sin concurso (diriamos que "a dedo"), al Laboratorio de Instrumentación (IL) del MIT, no para la fabricación de componentes, pero si para el diseño y gestión del sistema de guía. El IL (más concretamente 3 "lumbreras", Milt Trageser, Hal Laning y Richard Battin ) había trabajado en una idea de sonda a Marte, plasmada en un informe de 1959 en 5 tomos. Además el MIT había realizado la gestión de sistemas para el sistema de guiado e integración del mismo en el Polaris. Una afortunada visita al MIT, en el momento justo, de un responsable de la NASA facilitó una primera idea de diseño del Apolo, con
El "ordenador digital de propósito general" es coprotagonista del libro, aunque aparece tarde, tras un tercio del metraje. Antes han aparecido varios ordenadores analógicos. Pero el digital hace uso de transistores, y enseguida también de los primeros circuitos integrados que aparecen con la decada de los 60. Las responsabilidades iniciales previstas para el AGC, Apollo Guidance Computer, se van a ir incrementando con el paso del tiempo, llegando a la decisión de usarle también como piloto automático, lo que implicaba una práctica interacción directa con todos los componentes del sistema. Esta ampliación de responsabilidad es posible gracias al carácter "de propósito general", frente a un diseño a la medida como otros diseños digitales y todos los analógicos. Y también gracias al uso de circuitos integrados en vez de transistores individuales, con aumento de capacidad y reducción de tamaño y consumo. En esta evolución fue importante la decisión de hacer una primera versión "bloque I" y una posterior evolución "bloque II".
El reto del hardware, su diseño, y alcanzar la necesaria fiabilidad en compartimento estanco sin posibilidad de reparación tuvo su máximo pico alrededor de 1965, con más de 600 ingenieros trabajando en el IL. La producción del bloque I acabó en el otoño de 1966. La producción del bloque II llegó hasta el verano de 1969. La memoria del computador del bloque II era de 36k palabras de 16 bits para los programas y una memoria borrable de 2k, con un reloj a 1024 kHz
Pero hoy no voy a llegar a la Luna ...
En este caso, ese primer paso cósmico destaca por sí mismo. Pensar que alguién paseo por esa esfera desnuda, mudable y misteriosa, y contempló en directo la estampa de nuestro humilde planeta azul. Um...
Pero cómo se llegó a la Luna es incluso más fascinante que ese momento final.
En las películas actuales la promoción va muchas veces acompañada de documentales de "cómo se hizo", que suele ser más corto que la película. En el caso de la llegada a la Luna, la película dura muy poco, unos minutos, pero cualquier documental de cómo se hizo daría para días y días de metraje.
Ahora estoy leyendo "Digital Apollo. Human and Machine in Spaceflight" de David A. Mindell. Hay dos actores principales en este peculiar "cómo se hizo", los pilotos y los ingenieros, que actúan en el escenario de la Guerra Fría, a finales de la década de los 50 y en los 60 del siglo XX.
Pero antes el desarrollo de la aeronáutica ya plantea la dicotomía existente en todo avión, de estabilidad frente a maniobrabilidad, y la necesidad de usar la instrumentación y el control automático para ayudar al piloto. También hay una tensión en la función del piloto, ¿"conductor" (rol pasivo) o "aviador" (rol activo)?. En general los pilotos quieren ser "aviadores", y los ingenieros piensan en "conductores". El mayor progreso se consigue con personas que unen las dos características de piloto e ingeniero. Dos ejemplos señeros, James Doolittle y Charles Stark Draper.
En los 50 el desarrollo de aviones supersónicos pone en primer plano a los pilotos de prueba experimentales, la crema de la crema de los pilotos, que crean su propia sociedad, SETP (Society of experimental test pilots). Su primer banquete, el 4 de octubre de 1957, coincide con el día en que la URSS se adelanta en la carrera espacial lanzando el Sputnik.
La razón de ser de SETP es defender el papel protagonista y activo del elemento humano en el avance aeroespacial, puesto cada vez más en peligro por el avance técnico del control automático. Los pilotos van a tener a favor un factor clave: en la carrera espacial entre las dos grandes potencias los estadounidenses vinculan la democracia y la libertad al elemento humano, el valor de lo individual, frente a la inhumana automatización soviética. La presencia de los pilotos, luego astronautas, será esencial para el apoyo mediático a la apuesta política de Kennedy.
En el libro se repasan en los primeros capítulos los proyectos X-15, Mercury y Gemini. El X-15 es un avión supersónico, lanzado desde un B-52, capaz de sobrepasar la atmósfera, en donde el mayor problema a resolver es el de la reentrada a la misma. En cambio en Mercury y Gemini el piloto va en una capsula lanzada por un cohete similar a los misiles balísticos. En todos esos proyectos hay considerables retos técnicos, pero siempre surge en primer plano cuál debe ser el papel del piloto. En general se adopta una aproximación de ingeniería de sistemas en que el piloto es un subsistema, que debe interactuar con el resto, debiendo entenderse y modelarse por tanto adecuadamente ese subsistema humano.
Al margen de la exposición principal de esos proyectos con pilotos, se menciona el proyecto Polaris con sus misiles lanzables desde un submarino en inmersión, que influirá notablemente en dos aspectos, de gestión del proyecto (aquí nace el PERT) y de control automático. Los misiles deben ser casi completamente autónomos en su posicionamiento y guiado: desde luego no tienen piloto, deben ser precisos, y las comunicaciones entre estaciones de tierra y el misil pueden ser "estorbadas" por el enemigo.
Antes de que volasen las misiones Mercury o Gemini, antes de que Kennedy decidiese en mayo de 1961, tras menos de medio año de mandato, enviar un norteamericano a la Luna, ya se había creado la NASA, que organizó en el verano de 1960 una reunión industrial para definir un proyecto de alunizaje y hacer saber a los posibles contratistas qué esperar. Tras la bofetada soviética en abril de 1961, al ser Yuri Gagarin el primer humano puesto en órbita, los estadounidenses buscaron algo en lo que poder ser primeros, y encontraron el proyecto Apolo. Y desde el principio los consejeros del presidente tuvieron claro una cosa, antes que las razones técnicas o científicas era preciso "vender" el proyecto como la empresa humana de la conquista del espacio pues
es el hombre en el espacio, no simplemente las máquinas, lo que captura la imaginación del mundo
En el proyecto Apolo se iba a dar una situación atípica, distinta al resto de proyectos, pues una parte central del mismo se iba a adjudicar, sin concurso (diriamos que "a dedo"), al Laboratorio de Instrumentación (IL) del MIT, no para la fabricación de componentes, pero si para el diseño y gestión del sistema de guía. El IL (más concretamente 3 "lumbreras", Milt Trageser, Hal Laning y Richard Battin ) había trabajado en una idea de sonda a Marte, plasmada en un informe de 1959 en 5 tomos. Además el MIT había realizado la gestión de sistemas para el sistema de guiado e integración del mismo en el Polaris. Una afortunada visita al MIT, en el momento justo, de un responsable de la NASA facilitó una primera idea de diseño del Apolo, con
Un ordenador digital de propósito general
Un sextante espacial
Una unidad de guía inercial
Una consola para los astronautas
Otra electrónica de soporte
El "ordenador digital de propósito general" es coprotagonista del libro, aunque aparece tarde, tras un tercio del metraje. Antes han aparecido varios ordenadores analógicos. Pero el digital hace uso de transistores, y enseguida también de los primeros circuitos integrados que aparecen con la decada de los 60. Las responsabilidades iniciales previstas para el AGC, Apollo Guidance Computer, se van a ir incrementando con el paso del tiempo, llegando a la decisión de usarle también como piloto automático, lo que implicaba una práctica interacción directa con todos los componentes del sistema. Esta ampliación de responsabilidad es posible gracias al carácter "de propósito general", frente a un diseño a la medida como otros diseños digitales y todos los analógicos. Y también gracias al uso de circuitos integrados en vez de transistores individuales, con aumento de capacidad y reducción de tamaño y consumo. En esta evolución fue importante la decisión de hacer una primera versión "bloque I" y una posterior evolución "bloque II".
El reto del hardware, su diseño, y alcanzar la necesaria fiabilidad en compartimento estanco sin posibilidad de reparación tuvo su máximo pico alrededor de 1965, con más de 600 ingenieros trabajando en el IL. La producción del bloque I acabó en el otoño de 1966. La producción del bloque II llegó hasta el verano de 1969. La memoria del computador del bloque II era de 36k palabras de 16 bits para los programas y una memoria borrable de 2k, con un reloj a 1024 kHz
Pero hoy no voy a llegar a la Luna ...
En los cinco años desde la adjudicación del contrato hasta la preparación para los primeros vuelos del Apolo, el sistema de guía y navegación maduró desde una idea básica, a través de prototipos de laboratorio, hasta hardware de vuelo manufacturado de alta cualificación. A pesar de su pequeño tamaño y modesta capacidad de proceso, el AGC era tecnología punta, incorporando lo último en control de procesos, fiabilidad, diseño de circuitos, y empaquetamiento. En lo que se convertiría en una pauta familiar en el mundo de los ordenadores, la capacidad de memoria se dobló una, y otra y otra vez. Al mismo tiempo, la presencia del computador se entremezcló con los métodos de gestión de sistemas, especialmente cuando el proyecto se volvió más complejo y acumuló retrasos. Los dispositivos electrónicos en la cabina fueron eliminados gradualmente para ahorrar tiempo, peso o coste, y migrados al flexible computador o a los cerebros de los astronautas. Pero según iban saliendo los computadores del Bloque II de las cadenas de producción, la NASA y el IL empezaban a reconocer la tensión que habían añadido a una nueva parte del proyecto, una escasamente contemplada cuando Apolo comenzó: el software.
viernes, 22 de mayo de 2009
Certificados raíz FNMT
Hace unos días actualizé Internet Explorer a la versión 8. De entrada, entre las autoridades de certificación raíz (menú Herramientas / Opciones de Internet, pestaña Contenido, botón Certificados, pestaña Entidades de certificación raíz de confianza ) no estaba la de la FNMT. Pero una vez ya me tocó dar vueltas, como a tantos otros, hasta encontrar el ficherito FNMTClase2CA-FNMT.crt que hay que importar para incluir esa muy importante, en España al menos, Autoridad de Certificación (AC, o CA en inglés). En la versión hispana de Firefox esa AC suele venir preinstalada.
Buscando en http://www.cert.fnmt.es me encontré con más de lo que esperaba.
En la página de ciudadanos se puede descargar el certificado raíz de la FNMT Clase 2 CA.
Pero además hay otra página con los certificados raíz de la nueva Autoridad de Certificación "FNMT-RCM" y también el "AC APE" (Administración Pública Española), derivado de la autoridad "FNMT-RCM".
Como referencia está bien el documento pdf DECLARACIÓN GENERAL DE PRÁCTICAS DE CERTIFICACIÓN que en la página 18 y siguientes presenta las distintas cadenas de certificación empleadas por la FNMT, además de indicar las huellas digitales de cada uno de los certificados raíz. Para el caso de la CA tradicional, "FNMT Clase 2 CA", indica que
Para las otras (nuevas) CA no hay referencias al BOE, pero en el pdf indicado vienen los números de serie y las huellas digitales.
Estas nuevas CA son "AC FIRMA MOVIL” que tiene un único certificado raíz, y "AC RAIZ FNMT-RCM” que tiene tres certificados raíz distintos en base a que se han autofirmado con tres algoritmos distintos, pkcs1-sha1WithRSAEncryption, pkcs1-sha256WithRSAEncryption y pkcs1-sha512WithRSAEncryption. Esos certificados raíz son válidos hasta el 1 de enero de 2030. El certificado de la APE es válido hasta el 2023.
Además de las distintas versiones de hash (sha1, sha256 y sha512) parece que en todos los certificados raíz nuevos la clave utilizada es de 512 bytes (4096 bits) en vez de los 128 bytes del certificado raíz de "FNMT Clase 2 CA", todo para evitar que antes de las fechas de caducidad los certificados raíz se hayan vuelto vulnerables.
Buscando en http://www.cert.fnmt.es me encontré con más de lo que esperaba.
En la página de ciudadanos se puede descargar el certificado raíz de la FNMT Clase 2 CA.
Pero además hay otra página con los certificados raíz de la nueva Autoridad de Certificación "FNMT-RCM" y también el "AC APE" (Administración Pública Española), derivado de la autoridad "FNMT-RCM".
Como referencia está bien el documento pdf DECLARACIÓN GENERAL DE PRÁCTICAS DE CERTIFICACIÓN que en la página 18 y siguientes presenta las distintas cadenas de certificación empleadas por la FNMT, además de indicar las huellas digitales de cada uno de los certificados raíz. Para el caso de la CA tradicional, "FNMT Clase 2 CA", indica que
La huella digital del Certificado Raíz de “FNMT Clase 2 CA” puede consultarse en el BOE nº. 235 (pág. 35194 ) de 1 de Octubre de 1999, en la Orden de 30 de septiembre de 1999 por la que se establecen las condiciones generales y el procedimiento para la presentación telemática de las declaraciones-liquidaciones correspondientes a los modelos 110, 130, 300 y 330.
Para las otras (nuevas) CA no hay referencias al BOE, pero en el pdf indicado vienen los números de serie y las huellas digitales.
Estas nuevas CA son "AC FIRMA MOVIL” que tiene un único certificado raíz, y "AC RAIZ FNMT-RCM” que tiene tres certificados raíz distintos en base a que se han autofirmado con tres algoritmos distintos, pkcs1-sha1WithRSAEncryption, pkcs1-sha256WithRSAEncryption y pkcs1-sha512WithRSAEncryption. Esos certificados raíz son válidos hasta el 1 de enero de 2030. El certificado de la APE es válido hasta el 2023.
Además de las distintas versiones de hash (sha1, sha256 y sha512) parece que en todos los certificados raíz nuevos la clave utilizada es de 512 bytes (4096 bits) en vez de los 128 bytes del certificado raíz de "FNMT Clase 2 CA", todo para evitar que antes de las fechas de caducidad los certificados raíz se hayan vuelto vulnerables.
martes, 23 de septiembre de 2008
Carácter, natural, bit. Unicode.
Un carácter es un signo de escritura o imprenta, como una letra, un número, una coma, una interrogación... El concepto de carácter es abstracto, por ejemplo la "a minúscula" puede visualizarse con apariencias variadas. La apariencia gráfica se determina por el tipo de letra (Arial, Times,...) y la fuente (normal, negrita, cursiva, etc, de tamaños diversos), pero el concepto de "letra a minúscula" es independiente de tal apariencia concreta.
Al llegar la era de la información los ordenadores deben manejar los caracteres normales, y además se empiezan a usar caracteres no visibles, pero que tienen su utilidad, como el retorno de carro y lo que en general se llaman caracteres de control, que informan a las máquinas de cómo comportarse: mueve esa cabezota de impresión al principio de la línea, avanza el rodillito hasta la siguiente línea, pita, etc.
Internamente los sistemas digitales solo entienden secuencias de bits. Un bit, un dígito binario, es o cero o uno, 0 o 1. Por razones históricas esas secuencias casi siempre se agrupan y manejan en grupos de 8 bits, lo que se denomina byte.
¿Como relacionar los caracteres con los bytes? Pues en dos pasos, que en muchos casos se dan a la vez . Empleando una denominación que no puede considerarse estándar, pero que uso consistentemente para diferenciarlos, esos dos pasos son:
Código (coded character set), del carácter al número. Se asocia a cada carácter abstracto un número natural. Como interesa manejar un repertorio de caracteres, podemos visualizar esta asociación como la colocación de cada carácter en una casilla de un casillero, siendo identificada cada casilla del casillero por un número natural, lo que llamaremos punto de código, o en inglés "code point".
Codificación (character encoding form), del número al bit. Regla por la que se asocia un número natural con una pauta concreta de bits. Con 8 bits hay 256 pautas distintas, que se asocian de forma "natural" a los números naturales del 0 al 255, según una regla que puede llamarse sistema binario, según la cual por ejemplo '10000011' corresponde a 131. En realidad este sistema binario se puede aplicar para relacionar cualquier secuencia de bits, tan grande como se quiera, con un número natural. Con 16 bits, 2 bytes, se pueden representar los números del 0 hasta el 65535. Con 4 bytes, los números naturales entre 0 y 4294967295. Pero no tiene que emplearse forzosamente ese sistema binario "natural", y puede haber pautas especiales de bits que no se asocien a un número.
Hace muchos años, cuando los norteamericanos eran casi los únicos en el mundo de la informática, cogieron un repertorio de sus caracteres favoritos, que no pasaban de 128. Les repartieron a su manera en un casillero de 128 casillas. Luego cada casilla la representaron con bits por la pauta "natural" empleando 7 de los 8 bits de un byte. El bit restante se usaba como comprobación contra errores. Lo que resultó es el código de caracteres ASCII (Código Estadounidense Estándar para el Intercambio de Información). Este código engloba tanto la asignación de cada carácter del repertorio a una casilla (código), como el byte correspondiente a esa casilla (codificación). En el ASCII inicial el byte obtenido para cada una de las 128 casillas no era siempre el resultante de aplicar la regla "natural" del sistema binario, por el uso especial del octavo bit.
Pronto se necesitó ampliar el repertorio de caracteres y usar un casillero mayor, de 256 casillas. Se amplió el ASCII rellenando el casillero agrandado, y cambiando la regla de codificación para usar, entonces sí, el sistema binario "natural" y abandonar el bit de paridad.
Pero como los americanos no estaban solos, y hay muchos alfabetos en el mundo, se hizo imprescindible definir más casilleros, cada uno con 256 casillas en las que en cada caso se colocaban distintos repertorios de caracteres, o incluso un mismo carácter se colocaba en distinta casilla. A cada casillero distinto se le suele denominar página de código, o code page, y se distinguen unos casilleros de otros por un número. La página de código 437 es la original del IBM PC, y en ese casillero la "a minúscula acentuada" ocupa la casilla 160. La página de código 1252 es la usada por Windows para el repertorio de caracteres latinos eurooccidentales, y en este casillero la "a minúscula acentuada" ocupa la casilla 225. Hay páginas de código con caracteres de repertorios correspondientes a lenguas de casi todo el mundo.
Y aquí tenemos la babel desatada. Porque casi se podía acertar en suponer que la codificación (encoding) de un byte era la "natural" del sistema binario, y de los bytes obtener el número natural correcto indicativo de la casilla. Pero la casilla ¿de qué casillero? Había que saber la página de código correcta. Y en aplicaciones multilingües podían ser necesarias muchas.
Contra la babel desatada, organización. UNICODE. La solución en esencia es olvidar la multitud de casilleros de reducidas dimensiones. Usar un único casillero que pueda albergar cualquiera de los caracteres que ha habido en la historia humana o que pueda idearse en el futuro: un casillero con 1,114,112 casillas. En vez de imaginar las casillas en línea, para distinguir las partes del casillero este se divide en 17 planos (del 0 al 16), cada plano con 65536 casillas. Cada casilla se distingue del resto por su punto de código (code point), un número natural entre 0 y 1,114,111 aunque lo más común no es usar el sistema decimal, sino el hexadecimal. Todos los caracteres de todos los idiomas conocidos, más todo tipo de símbolos, se reparten por el casillero de una forma convenida que se conoce como Conjunto de Caracteres Universal. A veces se habla de "caracteres Unicode".
Resuelto el problema del código, se agrava un tanto el de la codificación. Para cubrir ese rango numérico hacen falta como mínimo 21 bits, que implica usar 3 bytes. Ademas a los sistemas binarios no les gustan los impares, a veces manejan "palabras" de 2 o de 4 bytes, pero no de 3. Para abordar este tema de la codificación de los puntos de código, se ofrecen varias tipos de codificación. El más simple se denomina UTF-32, y usa 4 bytes para representar cada casilla. Ventaja: uniformidad y rapidez en codificar y descodificar. Desventaja: Salvaje despilfarro de espacio, pues la inmensa mayoría de caracteres realmente utilizados están en casillas de números bajos, que pueden representarse con sólo un byte, o con dos bytes. Por eso se plantean los sistemas de codificación de longitud variable, aquellos que emplean diferente número de bytes según la casilla de que se trate. UTF-16 emplean como mínimo dos bytes (16 bits). El más económico es UTF-8, que como mínimo puede emplear un sólo byte (8 bits). Estas tres formas de codificación son parte del estándar Unicode. Hay otras variantes que no son estándar y es mejor olvidar.
UTF-8 tiene la ventaja de ahorro en espacio, y de compatibilidad con el veterano y muy extendido código ASCII. El lado negativo está en la mayor complejidad en la codificación y descodificación, pero como eso lo hacen las máquinas... Es de esperar que en un futuro sólo se use Unicode (el casillero Conjunto de Caracteres Universal), y como codificación UTF-8 y UTF-16.
Todo esto que parece tan sencillo tiene muchos detalles técnicos que dan para leer largo y tendido. Parte de la codificación UTF-8 consiste en distinguir cuando se usa sólo un byte o cuando se usan más. De los bytes empleados solo algunos bits se emplean para obtener, usando el sistema binario, el punto de código. Hay una pauta de bits reservada para identificar el orden de bytes usados en cada sistema informático (pues usando palabras de 2 bytes, el byte con los bits más significativos puede ir o el primero o el segundo, y habiendo dos posibilidades ...).
Para que la felicidad sea completa, y reconozcamos gráficamente los caracteres, solo falta tener una fuente que represente (casi) todos los definidos en Unicode. En Windows se puede visualizar cualquier carácter Unicode con la fuente Arial Unicode MS.
En todo este ámbito, en que las tecnologías de la información se relacionan con los sistemas de escritura y los lenguajes humanos, puede apreciarse lo fructífero (y arduo) que resulta la cooperación, el entendimiento, la unificación de criterios, y el empleo del discurrir de muchos para el beneficio de todos. Bien por Unicode.
Al llegar la era de la información los ordenadores deben manejar los caracteres normales, y además se empiezan a usar caracteres no visibles, pero que tienen su utilidad, como el retorno de carro y lo que en general se llaman caracteres de control, que informan a las máquinas de cómo comportarse: mueve esa cabezota de impresión al principio de la línea, avanza el rodillito hasta la siguiente línea, pita, etc.
Internamente los sistemas digitales solo entienden secuencias de bits. Un bit, un dígito binario, es o cero o uno, 0 o 1. Por razones históricas esas secuencias casi siempre se agrupan y manejan en grupos de 8 bits, lo que se denomina byte.
¿Como relacionar los caracteres con los bytes? Pues en dos pasos, que en muchos casos se dan a la vez . Empleando una denominación que no puede considerarse estándar, pero que uso consistentemente para diferenciarlos, esos dos pasos son:
Código (coded character set), del carácter al número. Se asocia a cada carácter abstracto un número natural. Como interesa manejar un repertorio de caracteres, podemos visualizar esta asociación como la colocación de cada carácter en una casilla de un casillero, siendo identificada cada casilla del casillero por un número natural, lo que llamaremos punto de código, o en inglés "code point".
Codificación (character encoding form), del número al bit. Regla por la que se asocia un número natural con una pauta concreta de bits. Con 8 bits hay 256 pautas distintas, que se asocian de forma "natural" a los números naturales del 0 al 255, según una regla que puede llamarse sistema binario, según la cual por ejemplo '10000011' corresponde a 131. En realidad este sistema binario se puede aplicar para relacionar cualquier secuencia de bits, tan grande como se quiera, con un número natural. Con 16 bits, 2 bytes, se pueden representar los números del 0 hasta el 65535. Con 4 bytes, los números naturales entre 0 y 4294967295. Pero no tiene que emplearse forzosamente ese sistema binario "natural", y puede haber pautas especiales de bits que no se asocien a un número.
Hace muchos años, cuando los norteamericanos eran casi los únicos en el mundo de la informática, cogieron un repertorio de sus caracteres favoritos, que no pasaban de 128. Les repartieron a su manera en un casillero de 128 casillas. Luego cada casilla la representaron con bits por la pauta "natural" empleando 7 de los 8 bits de un byte. El bit restante se usaba como comprobación contra errores. Lo que resultó es el código de caracteres ASCII (Código Estadounidense Estándar para el Intercambio de Información). Este código engloba tanto la asignación de cada carácter del repertorio a una casilla (código), como el byte correspondiente a esa casilla (codificación). En el ASCII inicial el byte obtenido para cada una de las 128 casillas no era siempre el resultante de aplicar la regla "natural" del sistema binario, por el uso especial del octavo bit.
Pronto se necesitó ampliar el repertorio de caracteres y usar un casillero mayor, de 256 casillas. Se amplió el ASCII rellenando el casillero agrandado, y cambiando la regla de codificación para usar, entonces sí, el sistema binario "natural" y abandonar el bit de paridad.
Pero como los americanos no estaban solos, y hay muchos alfabetos en el mundo, se hizo imprescindible definir más casilleros, cada uno con 256 casillas en las que en cada caso se colocaban distintos repertorios de caracteres, o incluso un mismo carácter se colocaba en distinta casilla. A cada casillero distinto se le suele denominar página de código, o code page, y se distinguen unos casilleros de otros por un número. La página de código 437 es la original del IBM PC, y en ese casillero la "a minúscula acentuada" ocupa la casilla 160. La página de código 1252 es la usada por Windows para el repertorio de caracteres latinos eurooccidentales, y en este casillero la "a minúscula acentuada" ocupa la casilla 225. Hay páginas de código con caracteres de repertorios correspondientes a lenguas de casi todo el mundo.
Y aquí tenemos la babel desatada. Porque casi se podía acertar en suponer que la codificación (encoding) de un byte era la "natural" del sistema binario, y de los bytes obtener el número natural correcto indicativo de la casilla. Pero la casilla ¿de qué casillero? Había que saber la página de código correcta. Y en aplicaciones multilingües podían ser necesarias muchas.
Contra la babel desatada, organización. UNICODE. La solución en esencia es olvidar la multitud de casilleros de reducidas dimensiones. Usar un único casillero que pueda albergar cualquiera de los caracteres que ha habido en la historia humana o que pueda idearse en el futuro: un casillero con 1,114,112 casillas. En vez de imaginar las casillas en línea, para distinguir las partes del casillero este se divide en 17 planos (del 0 al 16), cada plano con 65536 casillas. Cada casilla se distingue del resto por su punto de código (code point), un número natural entre 0 y 1,114,111 aunque lo más común no es usar el sistema decimal, sino el hexadecimal. Todos los caracteres de todos los idiomas conocidos, más todo tipo de símbolos, se reparten por el casillero de una forma convenida que se conoce como Conjunto de Caracteres Universal. A veces se habla de "caracteres Unicode".
Resuelto el problema del código, se agrava un tanto el de la codificación. Para cubrir ese rango numérico hacen falta como mínimo 21 bits, que implica usar 3 bytes. Ademas a los sistemas binarios no les gustan los impares, a veces manejan "palabras" de 2 o de 4 bytes, pero no de 3. Para abordar este tema de la codificación de los puntos de código, se ofrecen varias tipos de codificación. El más simple se denomina UTF-32, y usa 4 bytes para representar cada casilla. Ventaja: uniformidad y rapidez en codificar y descodificar. Desventaja: Salvaje despilfarro de espacio, pues la inmensa mayoría de caracteres realmente utilizados están en casillas de números bajos, que pueden representarse con sólo un byte, o con dos bytes. Por eso se plantean los sistemas de codificación de longitud variable, aquellos que emplean diferente número de bytes según la casilla de que se trate. UTF-16 emplean como mínimo dos bytes (16 bits). El más económico es UTF-8, que como mínimo puede emplear un sólo byte (8 bits). Estas tres formas de codificación son parte del estándar Unicode. Hay otras variantes que no son estándar y es mejor olvidar.
UTF-8 tiene la ventaja de ahorro en espacio, y de compatibilidad con el veterano y muy extendido código ASCII. El lado negativo está en la mayor complejidad en la codificación y descodificación, pero como eso lo hacen las máquinas... Es de esperar que en un futuro sólo se use Unicode (el casillero Conjunto de Caracteres Universal), y como codificación UTF-8 y UTF-16.
Todo esto que parece tan sencillo tiene muchos detalles técnicos que dan para leer largo y tendido. Parte de la codificación UTF-8 consiste en distinguir cuando se usa sólo un byte o cuando se usan más. De los bytes empleados solo algunos bits se emplean para obtener, usando el sistema binario, el punto de código. Hay una pauta de bits reservada para identificar el orden de bytes usados en cada sistema informático (pues usando palabras de 2 bytes, el byte con los bits más significativos puede ir o el primero o el segundo, y habiendo dos posibilidades ...).
Para que la felicidad sea completa, y reconozcamos gráficamente los caracteres, solo falta tener una fuente que represente (casi) todos los definidos en Unicode. En Windows se puede visualizar cualquier carácter Unicode con la fuente Arial Unicode MS.
En todo este ámbito, en que las tecnologías de la información se relacionan con los sistemas de escritura y los lenguajes humanos, puede apreciarse lo fructífero (y arduo) que resulta la cooperación, el entendimiento, la unificación de criterios, y el empleo del discurrir de muchos para el beneficio de todos. Bien por Unicode.
Suscribirse a:
Entradas (Atom)