viernes, noviembre 25, 2005
Generación de números aleatorios
En How Stuff Works tienen una explicación sencilla de cómo se generan números aleatorios en el ordenador.
Confesiones de un reparador de fotocopiadoras
La verdad es que esto no sé si creérmelo, pero lo ponen en un sitio serio como CNET en un artículo titulado Confessions of a photocopier repairman. Cuentan que, según Canon, un 32% de los técnicos de Canon dicen haber sido llamados en alguna ocasión para reparar un cristal roto por culpa de que los usuarios... ¡se habían intentado fotocopiar partes del cuerpo, entre ellas el culo!
Canon ha decidido aumentar en un milímetro el grosor de sus cristales.
Canon ha decidido aumentar en un milímetro el grosor de sus cristales.
jueves, noviembre 24, 2005
Xbox 360
Hoy asistí a una presentación sobre la Xbox 360. Fue interesante la parte relativa a la arquitectura de la máquina, pero me dejó muchas dudas, algunas de las cuales he estado intentando aclarar ahora con Internet.
El ponente, un hombre de Microsoft, empezó contando que la máquina llevaba una maravilla de tres «procesadores propietarios de IBM». Más adelante aclaró que estaban basados en PowerPC. Dijo que ahora los programadores estaban preparados para aprovechar múltiples CPUs, lo que no tengo tan claro. ArsTechnica tiene un &mdash como casi siempre&mdash interesante artículo sobre la programación de las consolas de nueva generación. Una de sus conclusiones es que, como el coste de desarrollar un juego es muy alto, para amortizarlo se harán más juegos multiplataforma (que funcionen en varios tipos de consolas y el PC) y se harán para el mínimo común denominador, que será dos hilos ejecutándose en una CPU y utilizando sólo la GPU.
Cuentan una anécdota graciosa sobre esto de los hilos: hace años John Carmack modificó el código del Quake III para que funcionase en máquinas con dos procesadores. En su sistema conseguía ganancias de hasta un 40% pero en otros no... y no logró descubrir por qué. Conclusión: «If a programming genius like John Carmack can be so befuddled by mysterious issues coming from multithreaded programming, what chance do mere mortals have?»
Pues en la 360 hay tres procesadores y además cada uno soporta hyperthreading, con lo que puede ejecutar dos hilos a la vez. 3x2 son 6 en mi pueblo, así que programarla no va a ser un juego de niños, a pesar del entorno de desarrollo XNA, basado en Visual Studio, que nos vendió como una maravilla que casi hacía los juegos solo... ¡Ja!
Los detalles de la arquitectura se pueden encontrar en otro gran artículo de Ars Technica.
Una de las cosas que dijo el hombre de la presentación es que llevaba memoria EDRAM. Yo no había oído hablar de eso en mi vida y no he encontrado en Internet un buen enlace al respecto. Por lo visto significa Embedded Dynamic RAM y la proporciona NEC, pero no sé qué la diferencia de otros tipos de memoria. Si alguien puede aportar alguna luz, me permitiría dormir mejor por las noches... ;-)
En cualquier caso, citó un número impresionante: más de 20 GB/s de tasa de transferencia con la memoria.
Con un compañero estuvimos preguntándonos qué operativo llevaría el cacharro. La solución la dan aquí: la Xbox original llevaba un operativo basado en Windows 2000, pero muy reducido; el sistema operativo de la 360 se hizo a partir de este. Es decir, es un hijo de un hijo de Windows 2000.
También habló el ponente sobre la compatibilidad de Xbox 360 con «muchos» juegos de Xbox. ¿Y cómo funciona? Pues según cuentan aquí y aquí por emulación software. Parece que han tenido bastantes problemas porque hay propiedad intelectual de nVidia que no controlaban. En esta otra noticia dicen que la 360 soportorá inicialmente 212 juegos de Xbox original en Estados Unidos, 156 en Europa y sólo 12 en Japón. ¿Por qué la diferencia entre países? Ni idea. Por otra parte, cuentan que Microsoft piensa actualizar el software de emulación para soportar más juegos antiguos.
Otra cuestión que mencionó en la charla el ponente fue la aparición de chips. Dijo que la consola tenía grandes medidas de seguridad pero que, como había 15000 personas intentando romperla por cada ingeniero que Microsoft dedicaba a ello, al final lo acabarían consiguiendo. Me pareció que lo que quería era dar la sensación de que se podría chipear: a fin de cuentas, le interesa que la gente compre la consola y, aunque copie algunos juegos, comprarán unos cuantos, lo que le servirá a Microsoft para recuperar la inversión... O no, porque según cuentan unos que han analizado los componentes de la Xbox 360, se pierden 126 dólares en cada consola vendida y la unidad de juegos de Microsoft es deficitaria.
AnandTech tiene un gran reportaje de la Xbox 360 por dentro con fotos. En él se puede ver el disco duro, que es un Serial-ATA extraíble, y los tres ventiladores. El hombre de Microsoft dijo que cuando estés haciendo tareas de bajo consumo de CPU, como ver un DVD, sólo funcionará uno.
Imagino que lo que más le importará a la mayor parte de la gente es qué tal resultan los juegos. Pues ni idea. Me fui antes de que empezase la demostración: me interesaba más la arquitectura. Cada uno tiene sus vicios ;-)
Actualización: Leyendo la entrada correspondiente en la Wikipedia descubro que la eDRAM es sólo una memoria de 10 MB utilizada como frame buffer. La ventaja es que va a 500 MHz y el ancho de banda con la GPU es de 32 GB/s. La memoria principal del sistema es GDDR3, un tipo de memoria diseñada por ATI (aunque utilizada primero pon nVidia) que es como la DDR2 pero con menos consuma y dispersando menos calor. También se explica cómo llega a los 22,4 GB/s: 700 MHz x 2 accesos en cada ciclo de reloj x 128 bits que tiene de ancho el bus. Este gráfico tiene un esquema con todos los anchos de banda dentro de la máquina.
El ponente, un hombre de Microsoft, empezó contando que la máquina llevaba una maravilla de tres «procesadores propietarios de IBM». Más adelante aclaró que estaban basados en PowerPC. Dijo que ahora los programadores estaban preparados para aprovechar múltiples CPUs, lo que no tengo tan claro. ArsTechnica tiene un &mdash como casi siempre&mdash interesante artículo sobre la programación de las consolas de nueva generación. Una de sus conclusiones es que, como el coste de desarrollar un juego es muy alto, para amortizarlo se harán más juegos multiplataforma (que funcionen en varios tipos de consolas y el PC) y se harán para el mínimo común denominador, que será dos hilos ejecutándose en una CPU y utilizando sólo la GPU.
Cuentan una anécdota graciosa sobre esto de los hilos: hace años John Carmack modificó el código del Quake III para que funcionase en máquinas con dos procesadores. En su sistema conseguía ganancias de hasta un 40% pero en otros no... y no logró descubrir por qué. Conclusión: «If a programming genius like John Carmack can be so befuddled by mysterious issues coming from multithreaded programming, what chance do mere mortals have?»
Pues en la 360 hay tres procesadores y además cada uno soporta hyperthreading, con lo que puede ejecutar dos hilos a la vez. 3x2 son 6 en mi pueblo, así que programarla no va a ser un juego de niños, a pesar del entorno de desarrollo XNA, basado en Visual Studio, que nos vendió como una maravilla que casi hacía los juegos solo... ¡Ja!
Los detalles de la arquitectura se pueden encontrar en otro gran artículo de Ars Technica.
Una de las cosas que dijo el hombre de la presentación es que llevaba memoria EDRAM. Yo no había oído hablar de eso en mi vida y no he encontrado en Internet un buen enlace al respecto. Por lo visto significa Embedded Dynamic RAM y la proporciona NEC, pero no sé qué la diferencia de otros tipos de memoria. Si alguien puede aportar alguna luz, me permitiría dormir mejor por las noches... ;-)
En cualquier caso, citó un número impresionante: más de 20 GB/s de tasa de transferencia con la memoria.
Con un compañero estuvimos preguntándonos qué operativo llevaría el cacharro. La solución la dan aquí: la Xbox original llevaba un operativo basado en Windows 2000, pero muy reducido; el sistema operativo de la 360 se hizo a partir de este. Es decir, es un hijo de un hijo de Windows 2000.
También habló el ponente sobre la compatibilidad de Xbox 360 con «muchos» juegos de Xbox. ¿Y cómo funciona? Pues según cuentan aquí y aquí por emulación software. Parece que han tenido bastantes problemas porque hay propiedad intelectual de nVidia que no controlaban. En esta otra noticia dicen que la 360 soportorá inicialmente 212 juegos de Xbox original en Estados Unidos, 156 en Europa y sólo 12 en Japón. ¿Por qué la diferencia entre países? Ni idea. Por otra parte, cuentan que Microsoft piensa actualizar el software de emulación para soportar más juegos antiguos.
Otra cuestión que mencionó en la charla el ponente fue la aparición de chips. Dijo que la consola tenía grandes medidas de seguridad pero que, como había 15000 personas intentando romperla por cada ingeniero que Microsoft dedicaba a ello, al final lo acabarían consiguiendo. Me pareció que lo que quería era dar la sensación de que se podría chipear: a fin de cuentas, le interesa que la gente compre la consola y, aunque copie algunos juegos, comprarán unos cuantos, lo que le servirá a Microsoft para recuperar la inversión... O no, porque según cuentan unos que han analizado los componentes de la Xbox 360, se pierden 126 dólares en cada consola vendida y la unidad de juegos de Microsoft es deficitaria.
AnandTech tiene un gran reportaje de la Xbox 360 por dentro con fotos. En él se puede ver el disco duro, que es un Serial-ATA extraíble, y los tres ventiladores. El hombre de Microsoft dijo que cuando estés haciendo tareas de bajo consumo de CPU, como ver un DVD, sólo funcionará uno.
Imagino que lo que más le importará a la mayor parte de la gente es qué tal resultan los juegos. Pues ni idea. Me fui antes de que empezase la demostración: me interesaba más la arquitectura. Cada uno tiene sus vicios ;-)
Actualización: Leyendo la entrada correspondiente en la Wikipedia descubro que la eDRAM es sólo una memoria de 10 MB utilizada como frame buffer. La ventaja es que va a 500 MHz y el ancho de banda con la GPU es de 32 GB/s. La memoria principal del sistema es GDDR3, un tipo de memoria diseñada por ATI (aunque utilizada primero pon nVidia) que es como la DDR2 pero con menos consuma y dispersando menos calor. También se explica cómo llega a los 22,4 GB/s: 700 MHz x 2 accesos en cada ciclo de reloj x 128 bits que tiene de ancho el bus. Este gráfico tiene un esquema con todos los anchos de banda dentro de la máquina.
Sun Java Studio Creator
Una presentación en Flash impresionante sobre Sun Java Studio Creator, un IDE para Java que parece especialmente pensado para hacer páginas web (con webservices, J2EE o Java Server Pages).
Las CPUs de Intel y AMD hasta 2005
En Tom's Hardware han actualizado su cuadro de comparación de CPUs. Es un trabajo impresionante donde hacen los mismos benchmarks a una cantidad increíble de CPUs de Intel y AMD.
Han añadido una introducción muy interesante en la que analizan cómo han evolucionado diversos factores. Por ejemplo, el gráfico de evolución de la frecuencia muestra cómo llegó a un pico y empezó a bajar y cómo se separaron AMD e Intel. Algunos datos extraídos del artículo:
Los gráficos de evolución de la disipación y la foto comparando un ventilador de Pentium con uno de Pentium 4 son impresionantes. También son interesantes los que tienen sobre la métrica de moda rendimiento por vatio, es decir, la frecuencia en función de la potencia consumida. AMD gana.
Estos artículos son los que hacen de Tom's Hardware un sitio de referencia.
Han añadido una introducción muy interesante en la que analizan cómo han evolucionado diversos factores. Por ejemplo, el gráfico de evolución de la frecuencia muestra cómo llegó a un pico y empezó a bajar y cómo se separaron AMD e Intel. Algunos datos extraídos del artículo:
- El primer procesador de Intel, el 4004 que salió en 1971, tenía 2300 transistores. El Pentium Extreme Edition 840 tiene la friolera de 230 millones. Vamos, que se ha multiplicado por 100.000.
- En el espacio que ocupaba un transistor, ahora caben 5845.
- Entre 1993 y 2005 la frecuencia de reloj ha pasado de 60 Mhz a 3800.
- Los ordenadores normalitos de la actualidad tienen tanta cantidad de memoria RAM como el doble de la capacidad de los discos duros de gama alta de 1993.
- Convertir un CD a MP3 en 1993 llevaba 5 horas. Ahora, 5 minutos.
- El único superviviente sin cambios casi desde el nacimiento del PC es la disquetera, que fue inventada por Sony.
Los gráficos de evolución de la disipación y la foto comparando un ventilador de Pentium con uno de Pentium 4 son impresionantes. También son interesantes los que tienen sobre la métrica de moda rendimiento por vatio, es decir, la frecuencia en función de la potencia consumida. AMD gana.
Estos artículos son los que hacen de Tom's Hardware un sitio de referencia.
jueves, noviembre 17, 2005
CPUs 4x4
Bueno, 4x4 son 16 y las nuevas CPUs que anuncia AMD para el 2007 son sólo de 4 núcleos... Pero no vamos a dejar que la realidad nos estropée un buen titular, ¿no? ;-)
Lo cuentan en Ars Technica. Dicen que la ley de Moore sigue su curso y, aunque no se pueda aumentar la frecuencia, sí es posible incrementar el número de transistores en cada dado. Así que después de la CPUs de doble núcleo pasaremos a las de cuatro.
Me parece que, por culpa de lo difícil que es escribir aplicaciones que aprovechen la programación paralela, vamos a tener bastante potencia sin utilizar en nuestras CPUs dentro de unos años. Exactamente igual que la gente que utilizar 4x4 para ir por la ciudad. Si al final hasta va a tener sentido el titular... ;-)
Lo cuentan en Ars Technica. Dicen que la ley de Moore sigue su curso y, aunque no se pueda aumentar la frecuencia, sí es posible incrementar el número de transistores en cada dado. Así que después de la CPUs de doble núcleo pasaremos a las de cuatro.
Me parece que, por culpa de lo difícil que es escribir aplicaciones que aprovechen la programación paralela, vamos a tener bastante potencia sin utilizar en nuestras CPUs dentro de unos años. Exactamente igual que la gente que utilizar 4x4 para ir por la ciudad. Si al final hasta va a tener sentido el titular... ;-)
martes, noviembre 15, 2005
El nuevo operador new
Yo soy de la vieja escuela. Creo que con decir que en la carrera media estudié Cobol está todo dicho. Así que hay novedades de las que tardo un poco en enterarme. Por ejemplo, lo del new.
El libro de referencia que tengo de C++ es "El lenguaje de programación C++" de Bjarne Stroustrup, pero el de la época de la carrera: una segunda edición de 1993. Hace doce años. De la versión en español.
De aquella, cuando se llamaba al operador new y no había memoria suficiente, devolvía NULL. Hace un poco un compañero me comentó que eso había cambiado y que ahora lanza la excepción std::bad_alloc. Al menos eso especifica el estándar desde 1998. Y que si quieres que funcione como toda la vida (devolviendo NULL), tienes que poner new(std::nothrow) en vez de sólo new.
Vale. Hasta aquí más o menos claro. Pero ahora empieza lo bueno: el soporte del compilador.
Como todos sabemos, los estándares son los estándares y los compiladores hacen con ellos lo que buenamente pueden.
Lo que hace Visual C++ viene explicado en este artículo. Resumiendo mucho: a partir de Visual C++ .NET 2002, tiene dos versiones; una, la del CRT (en libc.lib, libcd.lib, libcmt.lib, libcmtd.lib, msvcrt.lib y msvcrtd.lib), que devuelve NULL. Otra, la de la librería estándar de C++ (en libcp.lib, libcpd.lib, libcpmt.lib, libcpmtd.lib, msvcprt.lib y msvcprtd.lib), que lanza una excepción. Dependiendo de cuál esté primero a la hora de enlazar, se utilizará una versión u otra.
Lo más gracioso es que cuál se utilice depende en parte de los includes. Si se utilizan sólo cabeceras estándar de C++ (las que no tienen .h, como por ejemplo #include <new>), se utilizará la opción /defaultlib, que hará que se utilice la versión del CRT o la estándar dependiendo de las opciones /M*. Lo habitual será que se utilice la versión de new que lanza excepciones porque aparecerá antes la librería correspondiente en la orden de enlazado.
¿Y qué ocurre en g++? Pues que lanza excepciones. No sé desde que versión, pero probablemente desde la 2.96 por lo menos.
Es muy interesante este mensaje en las news. Trata precisamente el problema de la gente que no sabe lo que pasa con el new. Al final se ponen filosóficos. El autor original del hilo intenta esclarecer qué hacer con los ingenieros que no se actualizan y no saben que new lanza una excepción. Pero como le dice uno después, lo de que lanza una excepción es lo que dice el estándar y:
Complicado problema. Así que, como decía el Fari: «Precaución, amigo programador».
El libro de referencia que tengo de C++ es "El lenguaje de programación C++" de Bjarne Stroustrup, pero el de la época de la carrera: una segunda edición de 1993. Hace doce años. De la versión en español.
De aquella, cuando se llamaba al operador new y no había memoria suficiente, devolvía NULL. Hace un poco un compañero me comentó que eso había cambiado y que ahora lanza la excepción std::bad_alloc. Al menos eso especifica el estándar desde 1998. Y que si quieres que funcione como toda la vida (devolviendo NULL), tienes que poner new(std::nothrow) en vez de sólo new.
Vale. Hasta aquí más o menos claro. Pero ahora empieza lo bueno: el soporte del compilador.
Como todos sabemos, los estándares son los estándares y los compiladores hacen con ellos lo que buenamente pueden.
Lo que hace Visual C++ viene explicado en este artículo. Resumiendo mucho: a partir de Visual C++ .NET 2002, tiene dos versiones; una, la del CRT (en libc.lib, libcd.lib, libcmt.lib, libcmtd.lib, msvcrt.lib y msvcrtd.lib), que devuelve NULL. Otra, la de la librería estándar de C++ (en libcp.lib, libcpd.lib, libcpmt.lib, libcpmtd.lib, msvcprt.lib y msvcprtd.lib), que lanza una excepción. Dependiendo de cuál esté primero a la hora de enlazar, se utilizará una versión u otra.
Lo más gracioso es que cuál se utilice depende en parte de los includes. Si se utilizan sólo cabeceras estándar de C++ (las que no tienen .h, como por ejemplo #include <new>), se utilizará la opción /defaultlib, que hará que se utilice la versión del CRT o la estándar dependiendo de las opciones /M*. Lo habitual será que se utilice la versión de new que lanza excepciones porque aparecerá antes la librería correspondiente en la orden de enlazado.
¿Y qué ocurre en g++? Pues que lanza excepciones. No sé desde que versión, pero probablemente desde la 2.96 por lo menos.
Es muy interesante este mensaje en las news. Trata precisamente el problema de la gente que no sabe lo que pasa con el new. Al final se ponen filosóficos. El autor original del hilo intenta esclarecer qué hacer con los ingenieros que no se actualizan y no saben que new lanza una excepción. Pero como le dice uno después, lo de que lanza una excepción es lo que dice el estándar y:
[...] the difference between an engineer and a scientist is that the engineer considers the practical aspects. In this case, the engineer will look at what his compiler does, whereas the scientist will read the standard :-)
The engineer will do a cost-benefits analysis as to whether to use a new feature, the scientist will generally try to maximize the benefits without too much regards to the cost.
And of course, most developers programming in C++ are probably neither computer scientists nor software engineers, but simply programmers, trying to get the job done that they were told to do, using the tools that they were given.
Complicado problema. Así que, como decía el Fari: «Precaución, amigo programador».
viernes, noviembre 11, 2005
El número camión
Leyendo la discusión sobre eXtreme Programming en Barrapunto me metí la parte correspondiente del famoso wiki de Ward. Como siempre que me pasa cuando me pongo a leerlo, encontré un concepto que me llamó la atención.
Esta vez fue el «número camión», mi traducción para «Truck Number». La definición original es esta:
Pero alguien la corrigió por esta otra:
La idea es que cuanto más grande sea el número camión, mejor, porque más gente deberá tener «un accidente» para que el proyecto tenga problemas.
También hay una versión alternativa que se llama «Smallest Bus Queue Accident». Estos de la programación extrema son unos cachondos.
Esta vez fue el «número camión», mi traducción para «Truck Number». La definición original es esta:
The Truck Number is the size of the smallest set of people in a project such that, if one of them got hit by a truck, the project would be in trouble.
Pero alguien la corrigió por esta otra:
The Truck Number is the size of the smallest set of people in a project such that, if all of them got hit by a truck, the project would be in trouble.
La idea es que cuanto más grande sea el número camión, mejor, porque más gente deberá tener «un accidente» para que el proyecto tenga problemas.
También hay una versión alternativa que se llama «Smallest Bus Queue Accident». Estos de la programación extrema son unos cachondos.
jueves, noviembre 10, 2005
Citas de Knuth
Para la entrada anterior buscaba otra cita de Knuth en lugar de la que puse, una que decía algo así como que cuando la prueba es compleja, tienes que probar formalmente que la prueba está bien, lo que es muy difícil. No la encontré pero me gustó la que puse. En cualquier caso, también me gustó mucho esta otra suya:
Una verdad como un templo.
Tampoco está mal esta otra:
Y esta demuestra el humor que tiene:
Hay más por aquí. Pero no encontré la que buscaba.
It has often been said that a person does not really understand something until he teaches it to someone else. Actually a person does not really understand something until he can teach it to a computer.
Una verdad como un templo.
Tampoco está mal esta otra:
Science is what we understand well enough to explain to a computer. Art is everything else we do.
Y esta demuestra el humor que tiene:
The most important thing in the programming language is the name. A language will not succeed without a good name. I have recently invented a very good name and now I am looking for a suitable language.
Hay más por aquí. Pero no encontré la que buscaba.
La herramienta secreta de Microsoft contra los bugs
Cuentan en un artículo de Wired que Microsoft tiene una herramienta secreta contra los bugs: un analizador estático de código. Si no entendí mal el artículo (no tengo ganas de leerme los más serios que hay en el sitio de SLAM, que es como se llama el invento), es un analizador estático de código. Se basa en hacer una especificación formal del software a analizar.
Hacer especificaciones formales de cualquier programa no trivial es muy difícil. La herramienta está pensada sólo para los controladores de dispositivos, que por lo visto tienen unas reglas muy específicas. Imagino que lo único que puede probar es que no te van a tirar el sistema, no que hacen lo que tienen que hacer de verdad.
Como dijo Donald Knuth: «Beware of bugs in the above code. I have only proved it correct, not tried it.» :-)
Hacer especificaciones formales de cualquier programa no trivial es muy difícil. La herramienta está pensada sólo para los controladores de dispositivos, que por lo visto tienen unas reglas muy específicas. Imagino que lo único que puede probar es que no te van a tirar el sistema, no que hacen lo que tienen que hacer de verdad.
Como dijo Donald Knuth: «Beware of bugs in the above code. I have only proved it correct, not tried it.» :-)
Instalar un servidor de correo con Postfix
En Ars Technica tienen un artículo sobre cómo instalar un servidor de correo con Postfix. Igual me toca hacerlo dentro de poco, así que lo dejo aquí apuntado.
miércoles, noviembre 09, 2005
Los peores errores del software
En Wired tienen un artículo con los peores errores de la historia del software. Empiezan hablando de un error reciente del Toyota Prius que hizo que tuvieran que pasar por el concesionario 160 000 unidades y luego hace un recorrido histórico.
El que más me ha llamado la atención: una explosión en un gaseoducto de la URSS fue causada por un error introducido adrede por la CIA en un sistema informático que los soviéticos habían comprado a los Canadienses. Aunque, la verdad, si lo habían introducido adrede no sé yo si llamarlo bug...
Es también llamativo el error en el Therac-25, un dispositivo médico de rayos X. Dice textualmente el artículo:
Es decir, achaca el error a que el tío que construyó el sistema operativo no había estudiado informática y no sabía lo que era una condición de carrera.
No sé por qué meten en la lista el famoso error en una operación flotante del Pentium, ya que ese era un error hardware, pero está claro que tenía que aparecer el famoso error del Ariane 5. Lo que no sabía es que fue debido a una conversión de un flotante de 64 bits a un entero de 16.
Como dicen en el artículo, los problemas del software pueden causar la muerte de personas, pero más morirían sin él.
El que más me ha llamado la atención: una explosión en un gaseoducto de la URSS fue causada por un error introducido adrede por la CIA en un sistema informático que los soviéticos habían comprado a los Canadienses. Aunque, la verdad, si lo habían introducido adrede no sé yo si llamarlo bug...
Es también llamativo el error en el Therac-25, un dispositivo médico de rayos X. Dice textualmente el artículo:
What engineers didn't know was that both the 20 and the 25 were built upon an operating system that had been kludged together by a programmer with no formal training. Because of a subtle bug called a "race condition," a quick-fingered typist could accidentally configure the Therac-25 so the electron beam would fire in high-power mode but with the metal X-ray target out of position. At least five patients die; others are seriously injured.
Es decir, achaca el error a que el tío que construyó el sistema operativo no había estudiado informática y no sabía lo que era una condición de carrera.
No sé por qué meten en la lista el famoso error en una operación flotante del Pentium, ya que ese era un error hardware, pero está claro que tenía que aparecer el famoso error del Ariane 5. Lo que no sabía es que fue debido a una conversión de un flotante de 64 bits a un entero de 16.
Como dicen en el artículo, los problemas del software pueden causar la muerte de personas, pero más morirían sin él.
lunes, noviembre 07, 2005
¿Has llorado alguna vez... por un juego de ordenador?
Yo no, la verdad. Pero en esta historia de Wired cuentan que mucha gente sí. Parece que la escena más lacrimógena de todos los tiempos en juegos de ordenador es la muerte de Aerith en el Final Fantasy VII. Yo la he visto en el vídeo que tienen en Wired y no he derramado ni una lagrimita. No creo que sea porque yo sea un machote, sino porque a la tal Aerith no la conocía de nada.
viernes, noviembre 04, 2005
Mark Russinovich
Lo mejor de toda la historia del rootkit de Sony es descubrir el blog de Mark Russinovich, de Sysinternals, uno de los tíos que más sabe de programación a bajo nivel en Windows.
Sobre LaTeX
Unas buenas transparencias de introducción a LaTeX. No sabía que se podían hacer acordes de guitarra y partituras musicales. Y por aquí hablan de cómo hacer transparencias.
Vía Barrapunto.
Vía Barrapunto.
