Archivos Julio 2008

Si yo les muestro esta gráfica y les digo que representa el aumento en la tasa de mortalidad por cancer de mamas en Chile, ¿cómo reaccionarían?

Y si a esto agrego que las dioxinas provocan cancer de mamas y de próstata, entonces probablemente entren en pánico, dadas las últimas noticias, y prometan no comer nunca más una chuleta de cerdo en su vida.

Pero no deberían reaccionar así, porque este es un gráfico muy malo, de hecho deberían por lo menos pedir que le pongan algunas etiquetas para saber de que estamos hablando.

Bueno, acá está el gráfico, algo mejor:

¡Ah, pero esa es otra cosa!, o sea, para empezar estamos hablando de datos de hace 5 años. Además, no sé si notaron que la escala del gráfico está distorsionada. Hay un chiste que dice que "para los periodistas tres datos de cualquier cosa constituyen una tendencia", pero estos datos no representan tendencia alguna. ¿Cómo han sido históricamente estos datos? y ¿qué pasa desde el 2004 en adelante?

Según el Ministerio de Salud y el Instituto Nacional de Estadísticas (fuente), la tasa de mortalidad ha sido así:

Las pido que contrásten con la gráfica presentada por el Senador Girardi, que representa los mismos datos, pero presentados de una manera distinta (con una escala distorsionada):

Lamentablemente no tenemos datos para el 2004 en adelante, pero lo interesante es que las proyecciones del Ministerio de Salud son a la baja,

El tema es delicado, por cierto, y nuestra industria probablemente tendrá que mejorar sus estándares de calidad, pero no hay que caer en el pánico, y pensar de que tendremos una epidemia de cancer por comer carnde cerdo.

Yo no sé cuanto afecta este tipo de noticias al mercado de la carne de cerdo, pero considerando que en el último tiempo, dado el aumento del costo de los alimentos, el cerdo se ha vuelto en una alternativa más económica ante el costo de la carne de vacuno. Entonces hay que ser claro y preciso con estos asuntos, porque afecta a mucha gente (productores y consumidores).

La ignorancia mata, y mata de miedo. Una persona ignorante, es temerosa, y el anumerismo es una forma de ignorancia, una persona que sabe manejar los números, no se asustará tan fácilmente ante estas noticias, y no se tragará noticias alarmistas tan facilmente.

Las dioxinas han estado con nosotros desde que aprendimos a usar el fuego, y se sospecha de que pueden ser un agente cancerigeno. De hecho, es probable que al calentar alimentos con recipientes plásticos en nuestro microondas estemos liberando dioxinas.

Pero, ¿cuál es la probabilidad de morir de cancer por comer cerdo envenenado por dioxina?

No tengo idea, pero el Senador Girardi tampoco, porque los estudios que él muestra, corresponden a estudios sobre la contaminación de dioxina debido a la exposición directa, por manipulación de pesticidas, y otras causas. No podemos sacar conclusiones con respecto al cerdo contaminado por dioxina.

Además, el efecto es acumulativo, pero puedes exponerte a las dioxinas por diversos medios, no sólo por comer cerdo contaminado.

¿Vas a vivir asustado, y no comer cerdo, porque te mostraron un gráfico mal hecho?

Mejor, relajate, y deja de calentar tu comida con envases plásticos en el microondas, eso parece que es más peligroso.

Este sábado finaliza en Santiago de Chile el Cuarto Torneo Interescolar de Robótica organizado por la Universidad Andrés Bello.

"Este año se inscribieron 1.120 estudiantes en total. En cada una de las jornadas del Interescolar competirán 280 alumnos, divididos en 70 equipos de 3 a 4 personas cada uno. 35 de ellos se medirán cada día en la categoría Básica (7°, 8° Básico y 1° Medio) y los otros 35 en la categoría Intermedia (2° a 4° Medio)."

Más información en esta dirección.

Fuente: Sitio UNAB.

Como dicen en XKCD, "Padres hablen a sus hijos sobre Linux, antes que otros lo hagan"

Traducción:

viñeta 1: Linux Una Historia Real, Semana Uno:
- Hola es tu primo, tengo un nuevo computados y no quiero Windows. Me puedes ayudar a instalar "LINUX"
- Seguro

viñeta 2: Semana Dos:
- Dice que mi XORG está roto. ¿Qué es un XORG? ¿donde puedo buscar algo?
- Hmm, dejame mostrarte las páginas de man.

viñeta 3: Semana Seis:
- Debido a problemas con auto-config estoy dejando Ubuntu por Debian
- Uh,
- ¿o Gentoo?
- Uh, Oh.

viñeta 4: Semana Doce:
- No contestas el teléfono desde hace días.
- No puedo dormir, tengo que recompilar el Kernel
- Llegué demasiado tarde.

"Padres hablen a sus hijos sobre Linux, antes que otros lo hagan".

Bruce Schneier, escribe sobre la necesidad de diseñar el software pensando en la seguridad desde el principio.

El ejemplo planteado por Schneier es interesante, se trata de djbns, un servidor DNS que no sufre de la grave vulnerabilidad que está atacando a otros servidores DNS, porque fue diseñado desde el principio pensando en que podría ser objeto de toda una clase de ataques, de los cuales el "Ataque Kaminsky" sería un caso particular.
Daniel J. Bernstein, el autor de djbns, estudió la seguridad del DNS, y con eso pudo diseñar su software en forma segura.

Pero, como hemos discutido muchas veces, el software evoluciona, y es por eso que surgen bugs y problemas de seguridad, tal como el caso de la vulnerabilidad DNS detectada por Kaminsky.

Schneier tiene razón, parchar a gran escala no funciona bien, es caro, ineficiente, y toma mucho tiempo, a pesar de todos los empeños. Si usaramos un "diseño inteligente"¹, consideraríamos los aspectos de seguridad desde el principio.

Nos encantaría que todos los desarrolladores de software, siguieran los consejos de Schneier. Pero el software debe adaptarse a su entorno, para poder sobrevivir. Estas adaptaciones incluyen las modificaciones por "las necesidades del negocio", la presión por terminar en plazos ajustados, con presupuestos insuficientes, o se le exige al software ser flexible, al grado de se llega a exigir la capacidad de nuevas características casi todos los días. También ocurre, que entender como funciona el software es algo que toma tiempo, incluso para los mismos que lo hemos diseñado.

Esa es la paradoja, nos gustaría creer que existe un diseño inteligente, porque sería más facil entender la vida, pero no es así, por más que queramos, la vida sigue las reglas invisibles de la evolución. Del mismo modo, en el diseño del software, aunque tenemos más libertad, y somos como pequeños dioses que podemos dictar la arquitectura completa de nuestro software, este sigue las reglas invisibles de la evolución del software, similares a las que dictan la evolución de la vida.

Por supuesto que no todo es "azar y necesidad", y el ejemplo del trabajo de Bernstein es algo que debemos estudiar, e incorporar en nuestros diseños.

No, el diseño inteligente tampoco existe en software, pero al menos podemos aspirar a un diseño más seguro.

[1] Esta nota estuvo a punto de titularse "diseño inteligente", pero me rehuso a darle la más mínima ayuda a los que promueven la ignorancia .

Con respecto al nuevo DELL-E Slim, comenta Alan Kay en la lista IAEP :

Nice irony, given that it was Dell's refusal to make such a machine that got OLPC started ...

Linda ironía, dado que fue el rechazo de Dell de construir esa máquina la que provocó el inicio de OLPC...

Algunas aclaraciones sobre que significa este apoyo financiero, para aquellos que se sientan despitados con las notas periodisticas:

1. Todos los sponsors platinum aportan la misma cantidad de dinero, al menos 100.000 dolares al año, y se sabe que hay al menos 3 patrocinadores en esta categoría: Google, Microsoft y Yahoo.
2. Efectivamente, la licencia Apache, permite incorporar el código fuente dentro de un producto comercial cerrado sin necesidad de publicar los códigos fuente, un modelo que es visto con buenos ojos por los sectores más "conservadores" dentro de Microsoft.

history.forward()

El título de la nota de Ramji es muy claro: history.forward().

Pero esta es noticia que no nos sorprende, al menos no debería sorprender a los lectores de este blog.

Hace rato que venimos informando de cómo se está integrando el opensource dentro de Microsoft. No ha sido un proceso fácil, por cierto, pero es algo inevitable. Yo creo que hay mucha actitud pragmática, y la necesidad de adaptarse para sobrevivir en un nuevo escenario.

Como un ejemplo, Ramji nos cuenta que el equipo de Microsoft SQL Server desarrolló un driver nativo para PHP, y en los laboratorios opensource han parchado AdoDB para que use este nuevo driver, probándolo con más de 100 aplicaciones PHP comunitarias.

Hace unos meses atrás el equipo del servidor apache visitó Microsoft con el fin de obtener información técnica interna de primera fuente. Tuvieron acceso amplio y colaboraron en forma abierta con el equipo de Windows 2008 y de IIS.

¿Está Microsoft comprometiéndose seriamente con el opensource? No es menor que hayan colaborado en un proyecto que usa la LGPL, algo que hace un tiempo atrás habría parecido impensable. Por supuesto uno puede ver esto de manera cínica, o decir que Microsoft ha sido obligado a seguir este camino. La verdad es que en parte es eso, pero también hay una necesidad de negocios sumamente pragmática.

Hay que seguir observando el curso de estas acciones. Por supuesto que en muchas partes, sobre todo en nuestro medio local, las viejas y cancinas discusiones bizantinas continuarán, pero es claro que hay un segmento importante de Microsoft que está en otra actitud más abierta y colaborativa, probablemente porque es inevitable, y están reconociendo que el opensource será una de las fuerzas dominantes de nuestra industria en el futuro.

Con el fin de preparar una nota que me solicitaron de Fayerwayer, les hice algunas preguntas a los muchachos ganadores de la fase final de la Olimpiada Nacional de Informática.

Estas son sus respuestas y las comparte con ustedes, con el fin de que conozcan un poco más a estos muchachos. (fotografías cortesía de la ONI en Flickr)

¿Cuál es tu nombre, tu edad, en que curso estás y en que colegio y ciudad estudias?

CS: Mi nombres es : cristian andres silva lara, mi curso: 4ºto medio I del Liceo José Victorino Lastarria, estudio en : Santiago, Providencia

NL: Nicolas Emilio Lehmann Melendez, 17 años, cuarto medio colegio aleman de san felipe

VI: Mi nombre es Vicente Iglesias, tengo 16 años, y estoy en Segundo Medio en el Colegio San Ignacio El Bosque de Santiago.

JP: Juan Manuel Parraguez tengo 17 año y voy 4º Medio en el instituto san martín de curico.

¿Cómo te enteraste de la ONI?

CS: porque todos los dias leo fayerwayer, y como los lunes en canal 13 cable dan fayerwayertv en Estamos Conectados, yo lo veo los martes online y una de las noticias en la pagina de estamos conectados estaba la info de la ONI.

NL: En Fmat (un foro referente a la matematica) se publico un anuncio.

VI: Me enteré de la ONI leyendo el blog de UCPN.cl (la dirección es esta). Desde ahí entre a la web de la ONI y me inscribí...

JP: Lo leí por casualidad en una página de Internet.

¿Has tenido apoyo de tu colegio para participar en este evento?

CS: No, todo lo que hize fue por cuenta propia, yo creo que el colegio ni siquiera se entero de que yo participe, o por lo menos que existia un concurso asi para estudiantes.

NL: Para nada, todo lo he hecho en conjunto con mi familia.

VI: En mi colegio existe un grupo, llamado MediaLab, en donde se incentiva a los alumnos a desarrollar sus proyectos. Nos juntamos todos los viernes y en casi todos los recreos, así que en ese espacio pude practicar un poco para el concurso. Hay un profesor encargado casi exclusivamente en ayudarnos y guiarnos en este tipo de iniciativas, lo que es, para mi, un apoyo increíble por parte del colegio. En ese sentido estoy muy agradecido.

JP: Sí el colegio me ha dado el apoyo y las facilidades para participar en la ONI.

¿Cómo ha sido el apoyo de tu familia?

CS: Total, acá toda mi familia me apoyo, desde mi abuelita que no entendia mucho, hasta mi hermano que fue practicamente mi maestro en esto de programar.

NL: Muy bueno. Ellos me apoyan en todo. (Mientras no deje de estudiar para la psu).

VI: ¡La ayuda de mi familia ha sido inmensa! De partida, mis papás siempre me han apoyado, y comprendieron rápidamente que yo no era como la mayoría de los niños que disfruta jugar a la pelota, sino que, por el contrario, leer libros y hacer muchas preguntas sobre los temas más diversos (dirigidas casi siempre a ellos), así que les estaré agradecidos por siempre. Mis hermanos también, aunque sean más chicos, me apoyan en todo lo que hago, lo que es muy grato. Mi familia es muy unida, por lo que atribuyo a ellos mucho de lo que he aprendido; es esta paz que existe la me permite tener ganas de aprender y de conocer.

JP: Incondicional, siempre han estado apoyandome en todo lo que decido hacer.

¿Qué te pareció la organización del evento? ¿Que es lo que más te sorprendió? ¿tienes alguna crítica o sugerencia?

CS: La organizacion del evento la encontre espectacular, no dejaron ningun detalle al azar, desde que me vinieron a buscar a santiago, hasta que me vinieron a dejar, nos ofrecieron todas las comodidades posibles, y la municipalidad se porto exelente con nosotros. Lo que mas me sorprendio fue el nivel tecnologico al que esta buin, y la seguridad que otorga la ciudad, recuerdo que iba saliendo de la municipalidad y en la plaza de armas lo primero que veo es a un tipo con un macbook air sentado en una banquita, como si fuese lo mas normal del mundo, en verdad eso me dejo impresionado.No tengo ninguna critica con el evento, sugerencia, pues simplemente que se siga haciendo y que sigan por el camino del bien, seleccionando a los mejores informaticos del pais.

NL: Para una primera realización me parecio muy bien organizada. El trato que se tuvó con nosotros fue espectacular y la unica sugerencia sería que falta una mejor divulgación, pues siento que me entere por pura casualidad.

VI: La organización del evento me pareció increíble. Estaba todo muy bien preparado y previsto. Creo que el comité organizador de la ONI y la municipalidad de Buin se merecen un aplauso.
Me sorprendió, al momento de inscribirme, que fuera la Municipalidad de Buin quien organizara el evento, pero luego, en la competencia, me di cuenta del porqué: Buin es una comuna inserta en el siglo XXI, donde hay Wifi en las plazas, un sitio web estupendo (a excepción de la página de inicio, que no funciona), y es un lugar donde las iniciativas de sus habitantes son realmente tomadas en cuenta y llevadas a cabo.
Mi única sugerencia sería que hizo un poco falta de difusión, para que más gente participara.

JP: Me gustó mucho la organización y sobre todo la acogida que nos dieron, quizás una de los problemas de la oni fue la publicidad, espero que lo mejoren para la próxima olimpiada.

¿Desde cuando que usas computadores? ¿Desde que edad navegas en internet?

CS: Mi primer computador lo tuve en el 2000 (aca le tenian miedo al y2k, si no me equivoco ese es el virus que no recuerdo que hacia cuando el pc llegaba al año 2000) a la edad de 10 años, y bueno ese pc lo tenia conectado a internet pero por telefono.

NL: Uf computadores desde muy pequeño, debo haber tenido unos 8 años, no recuerdo que maquina era, pero el SO era windows 3.1, pero ocupaba más D.O.S. En internet partí con una conexión telefonica de 56, de esas que habia que conectarse despues de las ocho para que saliera más barato, no recuerdo que edad tenía, pero fue cuando se empezo a masificar el uso de internet en nuestro país.

VI: Uso computadores desde los siete años, más o menos, y navego en Internet desde los nueve.

JP: Desde los que tengo 8 años tuve mi primer computador, y a los 13 años Internet.

En que lenguaje programas, y desde cuando?

CS: Yo programo en .c desde 2 dias antes de la primera fase de la oni (21 de junio) y 1 semana antes de la fase presencial, que era cuando estaba en vacaciones de invierno,(19 de julio), es decir aprendi c en 7 dias, ahora yo habia tenido encontrones con el lenguaje .c en 8vo basico cuando tenia 13 años.

NL: Programo en C++ y mi historía es un poco anecdótica. Cuando era chico tuve una visión y quería aprender a programar para hacer juegos, habré estado una semana aprendiendo pascal pero despues me desanime cuando no pude usar los paquetes graficos. Así segui un tiempo sin hacer nada, hasta que aprendí HTML y luego javascript, creo que fue la epoca en que más aprendi. Ahí estuve pegado como seis meses o quizá un poco más. Despues de eso me aburrí, porque no se me ocurría una tematica para mi sitio y el año pasado retome la programción, estudié un poco de C por un fin de semana, luego me aburrí. Y este año cuando supe lo de la competencia me animé denuevo. Me conseguí un libro de c++ en internet y le dí una semana duro al asunto. Y esa sería mi historia.

VI: Partí "programando" en Flash 4 a los nueve años, en tercero básico. En cuarto básico (a los diez años) le pedí a mi papá que me comprara un libro de Visual Basic. El señor de la librería le dijo que pensaba que no era un libro para mi edad, pero él le respondió "vamos a ver que pasa", y me lo compró. En los recreos me pasaba mitad leyendo el libro, mitad jugando con mis amigos. Luego empecé a ayudar a mi papá con unos sitios web en ASP que había hecho, y entonces aprendí HTML y me atrajo automáticamente el diseño web. Ya aburrido del ASP, empecé a buscar algún lenguaje más potente y me "enamoré" de Ruby on Rails. En octavo básico aprendí C, porque siempre tuve el sueño de programar algún día un Sistema Operativo. Investigué los fundamentos de Ensamblador, pero no pude aprender nada, y, para la competencia, me dispuse a aprender C++.

JP: Pascal, hace 1 año.

¿Que opinan tus padres sobre tu pasíón por los computadores?

CS: Opinan que esta bien, que es la herramienta de mi futuro, aunque tambien se enojan porque llego del colegio al pc, o me levanto y lo enciendo, y a veces me quedo hasta altas horas de la madrugada en el computador.

NL: Aveces no le gusta mucho, porque dicen que paso mucho tiempo pegado al computador, mientras podría hacer algo más productivo o sano (y es verdad), pero en el fondo les gusta que me maneje un poco en este mundillo, sobre todo cuando tengo que ayudarlos a solucionar problemas.

VI: Opinan que, mientras no sea lo único que haga, esta bien.

JP: Que aveces soy algo obsesivo con el computador y dejo de lados mis deberes.

¿Es importante que todos los niños y jóvenes tengan acceso a las TI?

CS: Creo que todos tienen que tener acceso a las tecnologias informaticas, pero en su debido momento y con su debida madurez, recordemos que es una espada de doble filo.

NL: Por supuesto. Yo considero las TI como una herramienta para hacernos más facil la vida y cualquier persona debería tener acceso a ellas.

VI: Creo que es importantísimo que todos los niños y jóvenes tengan acceso a las tecnologías de la información, porque les permiten estar conectados con el mundo. Tenemos meternos en la cabeza que Internet no es sólo un lugar para subir fotos y chatear, sino también es la fuente de información más grande que jamás a existido en la Tierra.

JP: Sí, las tecnologías de la información ayudan al mejorar el aprendizaje.

¿Que tal el nivel de las preguntas y problemas con que te enfrentaste en la ONI?

CS: Debo reconocer que habian ejercicios bastante dificiles, pero creo que eso recae en que en 2 dias aprendi a programar lo basico, y en la semana de vacaciones aprendi lo demas, entonces donde yo estaba contra el tiempo aprendiendo c. creo que no aprendi lo suficiente y por eso quizas para mi fueron mas complicados los ejercicios.

NL: Aunque me costaron bastante, no creo que el nivel sea muy elevada, más bien es una falencia en mi conocimiento. Pues en esto de la programación no llevo mucho y me falta mucho que aprender, ademas de que no le dedico gran parte de mi día.

VI: En la competencia había de todo. Teníamos que resolver una relativamente fácil, y dos más complejas.

JP: Los encontré un poco difícil, pero si me hubiera preparado mejor se me habría echo mas fácil.

¿Qué le preguntarías a los organizadores de la ONI?

CS: si es que las volveran a realizar, y de ser asi, que cuenten con todo mi apoyo!

NL: ¿Como se hacia el problema de Petrobuin?

VI: Más que preguntarles algo, sólo me gustaría expresarles mi enorme agradecimiento por su trabajo en estas primeras olimpiadas de informática. Pero una buena pregunta, mitad en broma, mitad verdad; podría ser ¿cuándo partimos?

JP: ¿cómo encontraron el nivel de los concursantes, que expectativa tenían?

En mayo pasado les comenté sobre Randy Pausch, ayer nos enteramos de su fallecimiento, les vuelvo a dejar su charla que lo hizo reconocido en internet:

Probablemente un usuario novicio no sabrá cómo responder esta pregunta, pero si eres un usuario más avanzado me dirás que has revisado la barra de direcciones de tu navegador, que te has preocupado de no seguir un link que recibiste por email, o tuviste la precaución de escribir la dirección que te entregó tu banco, caracter a caracter, con mucho cuidado.

¡Es más! Te entregaron un aparatito, que te dijieron que está sincronizado con un super califragilistico mecanismo al que sólo accede un servidor de tu banco, y que asegura que, si alguien llegase a adivinar tu clave, el numerito mágico que este dispositivo te entrega impide que otro pueda ingresar al web del banco haciendose pasar por tí.

Estás tranquilo y seguro de que todo funciona, porque además tu proveedor de internet te ha prometido que se preocupa de tu seguridad, protegiendote para que no entren virus, bloqueando puertos que no vas a necesitar, y evita que te lleguen emails no solicitados, que podrían tratar de engañarte.

Pero tengo que decirte que todo eso es una falsa sensación de seguridad.

Porque intentar clonar un sitio web como el de tu banco es algo que un ladrón informático intentará hacer.

Me dirás que no pueden clonar la dirección web del banco, porque hay instituciones que se aseguran que funcione todo el sistema de nombres de dominio, para que nadie se adueñe de la dirección de otros.

Efectivamente, hay una enorme infraestructura montada sobre un servicio llamado DNS que permite que puedas llegar al servidor asociado a la dirección que ingresaste en tu navegador, y esas instituciones efectivamente se preocupan de que las direcciones sean entregadas a quienes corresponden.

Es un complejo servicio, que funciona muy bien, a una velocidad asombrosa y que permite que toda la web sea lo que es.

Pero esa maquinaria, tan compleja y maravillosa tenía (tiene) un fallo en su diseño original, un error tan grande que ha sido manejado en secreto, y de forma coordinada por importantes firmas y proveedores de internet en todas partes del mundo, para que sea reparado antes de que algún delincuente haga uso de esta vulnerabilidad.

Porque esta vulnerabilidad permitiría engañar a tu computador, a tu navegador, y cualquier otros programa que use direcciones basadas en nombres, enmascarando un servidor fraudulento, redirigiendo el tráfico a donde no corresponde.

Las consecuencias serían muy graves, por eso que se ha hecho esta coordinación a nivel mundial.

Pero lamentablemente, al menos en Chile, y al parecer en España también, nuestros proveedores de internet aún no han reparado el problema, a pesar de que tienen la solución desde hace semanas.

Algo que es tan urgente, aún no ha sido ejecutado, con la prontitud que esperaríamos, no sabemos las causas, pero creo que danlo mismo la razón de la demora, es obligación de los ISP brindar un servicio seguro que nos proteja de potenciales problemas como los descritos, o al menos si es cierto lo que ellos mismos dicen, de que toman medidas, que atentan a la neutralidad de la red, para protegernos, entonces con mayor razón deberían demostrarlo parchando sus servidores DNS vulnerables.

¿Quieres saber si tu proveedor de internet se ha preocupado de reparar sus servidores DNS? visita esta dirección, y presiona el botón que dice Check My DNS, esperemos que se pongan las pilas pronto nuestros proveedores de acceso, porque tenemos razones para sospechar que pronto se empezará a hacerse mal uso de esta vulnerabilidad.

(Those who do not understand Unix are condemned to reinvent it, poorly)

Henry Spencer, el geek que salvo Usenet, y autor, de regex y de Los 10 mandamientos de los programadores C.

(No, no es el padre de Shawn de Psych(Psych_character))

Aunque era una helada tarde en la comuna de Buin, disfrutamos de una cálida ceremonia de premiación a los ganadores de la Primera Olimpiada Nacional de Informática.

Allí estaban felices, los cuatros competidores que se presentaron finalmente a la final, en la que salió ganador Vicente Iglesias, del Colegio San Ignacio El Bosque.

Felicitaciones a él, y a los otros tres ganadores que conformarán el equipo que nos representará en Egipto.

En la fotografía vemos a los cuatro finalistas, y al equipo organizador, formado por los hermanos Cristobal e Israel Leiva, y Mauricio Iturriaga, ingeniero informático que los ha apoyado y que encabezará la delegación.

Pueden leer una nota en la edición del domingo en El Mercurio, uno de los pocos medios que cubrió este evento.

Este es un momento importante, estos chicos están haciendo historia, porque, aunque la IOI lleva 20 años realizándose, esta es la primera vez que nuestro país tendrá una representación oficial y elegida con un mecanismo transparente que involucra la participación a nivel nacional.

El proceso de preselección involucró la participación de más de 40 jóvenes (a pesar de que hubo sobre 50 inscritos, sólo 40 cumplían los requisitos).

Espero que el próximo año muchos más jóvenes se interesen en participar, y que el evento tenga más cobertura de los medios y apoyo de todos los que estamos interesados en desarrollar las TI en Chile.

La nota lamentable fue la no presentación de los 3 representates del Instituto Nacional, quienes se marginaron de la competencia, y que al parecer están buscando clasificar a la IOI por "otros medios".

Es cierto que existe situación que necesita una aclaración, y que está aprovechando cierto personaje (cuyas motivaciones no conocemos). Pero recordemos que la única representación oficial chilena invitada formalmente por la IOI es la seleccionada por la ONI, además de ser la única organización que cuenta con el apoyo oficial del nuestro gobierno.

Ustedes saben que no basta poner un sitio web y decir que tenemos la olución al Transantiago (la que genra un error 404, por cierto) como proclama este "representante de la IOI" para obtener automáticamente credibilidad. Este señor ha estado aprovechándose de la falta de organización de nuestro país en este tema para establecerse dentro de la organización de la IOI, pero eso se acabó, ahora hay un mecanismo oficial, avalado por la principal autoridad educacional de nuestro país.

Todos los que hemos apoyado este evento, vamos a asegurarnos de que se respete este resultado, transparente, oficial y participativo, como el único válido para definir quien representa a nuestro país.
Yo espero que los jóvenes del Insituto Nacional dejen de lado la natural ambición, y las seducciones de este señor, y sepan que lo que importa es ganar honestamente la representación del país, y no entrar por secretaría, como les prometió este personaje. Si, lamentablemente, ellos insisten en esa participación en la IOI, avalados por este señor, entonces nuestro país solicitará que se elimine nuestra bandera del evento y que no se considere como representación oficial de nuestro país.

Mañana 19 de julio es la fase final y presencial de la primera Olimpiada Nacional de Informática, a realizarse en Buin.

Los finalistas son:

Nicolas Lehmann - San Felipe, Valparaíso (Ganador 2da fase online)
Manuel Pérez - Santiago (Ganador 1era fase online)
Vicente Iglesias - Las Condes, Santiago
Francisco Hernández - Santiago
Matías Durán - Peñaflor, Santiago
Cristian Silva - Santiago
Juan Manuel Parraguez - Curicó

De entre ellos saldrán los 4 seleccionados chilenos a la Olimpiada Internacional de Informática a realizarse en Egipto en agosto.

Felicitaciones a todos ellos, a sus padres, y profesores que deben sentirse orgullosos también.

Más informaciones en el sitio oficial de la oni: www.oni.cl

A través de la iniciativa lanzada el 14 de diciembre del año 2006 por Presidencia de la República, denominada Proyecto de Conectividad Educativa de Informática Básica para el Aprendizaje en Línea (CEIBAL), el gobierno uruguayo en una decisión histórica, asume el desafío de distribuir gratuitamente
computadoras portátiles entre todos lo niños y niñas de Educación Común (1ºa 6º grado) y sus respectivos docentes de las escuelas públicas de todo país. -- CEIBAL en la Sociedad del Siglo XXI

El tema de qué hacer con la educación en Chile es complejo, y por supuesto está en una profunda crisis. Por supuesto no soy experto en educación, pero, soy de los que cree que es un imperativo incorporar las Tecnologías de la Información en el proceso educativo, por eso que he estado interesado y promovido en este blog todo lo relacionado con el proyecto OLPC (One Laptop Per Children, Un Laptop Por Niño).

CEIBAL , en Uruguay, es el más ambicioso de los proyectos que está siendo desplegado usando esta tecnología. Pero no se trata de entregar computadores a los chicos uruguayos. Es un proyecto más ambicioso, y que se propone transformar la sociedad uruguaya e integrarla verdaderamente en la sociedad de la información.

La fotografía muestra uno de los tantos encuentros de formación de docentes realizados por el proyecto CEIBAL. Ya antes publiqué una presentación con la experiencia piloto, que llevó a una de las conclusiones más importantes, es vital preparar al docente.

Uruguay está dando un ejemplo de cómo se deben implementar este tipo de programas. Sin improvisaciones que sólo generan bochornos, y en una maravillosa publicación, preparada para orientar a padres y educadores nos enteramos cómo se está implantando este proyecto.

Se trata del libro CEIBAL En la Sociedad del Siglo XXI, disponible para ser descargado desde el sitio oficial del proyecto.

A través de esta publicación no sólo nos enteramos del plan de implantación del proyecto, sus lineas de acción, objetivos, sino que también vemos una visión que pretende aprovechar esta oportunidad para llevar a toda la sociedad uruguaya hacia la sociedad de la información y presenta a los padres y educadores todas las posibilidades que se abren con el uso apropiado de las TI.

Porque no se trata de regalarle notebooks a los niños más aplicados y estudiosos. Para muchas familas este programa significa integrarse realmente a los servicios de e-government. Tal como está pasando en Perú, muchos niños uruguayos guiarán a sus padres y los introducirán en las ventajas de usar la red para mejorar su calidad de vida, accediendo a información, realizando trámites, y participando de las posibilidades que está brindando la web cada día.

Porque los computadores no sólo sirven para que los niños jueguen, o hagan sus tareas. Además son dispositivos que estarán transformando a esas familias, convirtiéndolos en usuarios activos, cultos, dominando los mínimos necesarios, dejando de ser analfabetos tecnológicos. Se convierten en personas más preparadas para aprovechar las ventajas de las nuevas tecnologías, que no pierden su identidad, y no tienen por qué, pero que amplían su mundo, y tienen mayores posibilidades, gracias a estas.

El gobierno uruguayo es valiente y decidido. Por que entregarle estas herramientas de coordinación, comunicación masiva a la gente puede ser "peligroso", los políticos le tienen miedo a este tipo de cosas, darle a la gente la oportunidad de comunicarse y expresar sus ideas, manifestar su descontento, a través de las redes sociales, y otros medios, requiere coraje.

A mi me gustaría que nuestras autoridades leyeran esta referencia uruguaya, que aprendieran y se dieran cuenta de lo ridículas que resultan las promesas presidenciales del 21 de mayo.

Yo los invito a leerlo, y a apreciar la experiencia uruguaya, a ver cómo este documento orienta y educa a los padres, para que entiendan las ventajas de internet, los problemas que podrán encontrar, y la forma en que el proyecto protege los contenidos que sus hijos accederán.

Es una publicación muy cuidada, entretenida amena, con ilustraciones muy entretenidas de Ricardo Pisano Copani, recursos a los que pueden acceder por internet, glosarios y guias.

¿Saben una cosa? Los chilenos nos estamos convirtiendo en unos pedantes, que sólo discuten sobre lo que hay que hacer, pero incapaces de hacer nada. Llenos de certezas entramos en discusiones que no valen la pena, cuando en realidad deberíamos dedicarnos a habalr menos y a hacer más. Aprendamos de nuestros hermanos uruguayos.

Si este blog fuera como alguna vez pretendí que fuera, me gustaría que se pareciera a Word Aligned, y para que tengan una idea de que les estoy hablando, he traducido un artículo de ese extraordinario blog, espero que lo disfruten (incluso los que son menos técnicos).

Detén el reloj, aplasta el bicho [1]

Por Thomas Guest (Word Aligned)

¿Cuál de estos relojes es el mejor?

Podríamos fácilmente argumentar que el que está detenido.

¿Podemos? En "Los Dos Relojes"[2] Lewis Carroll argumenta de otra manera.

¿Qué es mejor, un reloj que da la hora exacta una vez por año, o un reloj que es puntual dos veces por día? "Este último", contestarás, "incuestionablemente". Muy bien, ahora atiende.

Supongamos que tengo dos relojes: uno no funciona en lo absoluto, y el otro se retrasa un minuto al día: ¿cuál preferirías? "El que se retrasa", replicarías sin ninguna duda. Ahora observa: el que se retrasa un minuto al día tiene que emplear doce horas, o setecientos veinte minutos, hasta que de nuevo señale la hora correcta; por consiguiente es puntual una vez cada dos años, mientras que el otro es puntual evidentemente siempre que sea la hora por él indicada, lo que ocurre dos veces al día.[3]

Esta es una distracción divertida, pero no realmente problemática: por supuesto que el reloj que pierde tiempo es de uso más práctico, aún así es paradojal, mientras menos tiempo pierda menos a menudo dice la hora correcta. Un reloj que pierde sólo un segundo al día sólo indica la hora correcta cada 118 años aproximadamente.

Software Bugs

Mencione estos relojes defectuosos porque estoy pensando sobre los fallos en el software (bugs) y como los buscamos y corregimos.

El código que es obviamente correcto es más fácil de detectar que aquel que es casi correcto, y detectar fallos es previo a corregirlos. Esto implica - construyendo sobre la terminología de Carroll - que es improbable que despachemos muchos relojes detenidos, pero si no somos cuidadosos podemos terminar despachando unos pocos que pierden tiempo. Y, en general, el código que es obviamente erróneo es más fácil de corregir que el código que es casi correcto. Una función terriblemente rota claramente necesita un replanteo; mientras que una que casi funciona puede simplemente ser ajustada hasta que parezca funcionar, a menudo resultando en un error más sutil.

Fugas y Carreras

C y C++ proveen buenos ejemplos de lo que estoy hablando. Consideren un programa que usa mal la memoria. Un intento de alojar un espacio de trabajo de 4294967295 bytes falla instantáneamente [4]; una lenta fuga de memora, como el reloj lento, puede causar un daño no perceptible por un periodo extendido.

Herramientas decentes detectarán fugas de memoria. Condiciones de carrera (race conditions) en un código multi hebras son dificiles de seguir y pueden mostrarse elusivas durante las pruebas del sistema. Más de una vez he dejado un programa corriendo en un depurador (debugger), siendo alimentado con entradas al azar, con la esperanza de de que una rara y aparentemente aleatoria condición gatille una interrupción en la ejecución.

Decent tools detect memory leaks. Race conditions in multi-threaded code are harder to track and may prove elusive during system testing. More than once I've left a program running under a debugger, being fed random inputs, in the hope some rare and apparently random condition will trigger a break in execution. ¡Denme código realmente roto cualquier día!

75% correcto vs 50% correcto

Acá hay dos implementaciones de una función en C para encontrar el punto medio entre un par de valores enteros positivos y ordenados, aproximando hacia abajo. Antes de seguir leyendo, pregúntese cuál es mejor.

int midpoint1(int low, int high)
{
return low/2 + high/2;
}

int midpoint2(int low, int high)
{
return (low + high)/2;
}

Midpoint1 es un reloj detenido, retornando 3 en vez de 4 como el punto medio entre 3 y 5, por ejemplo. Entrega la respuesta incorrecta el 25% del tiempo -- fatalmente erróneo si fuera usado en el corazón de, digamos, una búsqueda binaria. Creo que podríamos detectar fácilmente el problema.

Una corrección obvía sería la mostrada en midpoint2, la que retorna 4 como el punto medio entre 3 y 5.

Midpoint2 es un reloj que se retrasas, sin embargo. Si la suma low + high produce un desbordamiento (overflow) el resultado es indefinido. En mi implementación obtengo un valor negativo -- una cosa peligrosas si lo usamos como índice de un arreglo. Este es un defecto notorio y muy real, y nuy bien documentada en una nota de Joshua Bloch subtitulada ""Casi todas las búsquedas binarias y merge sorts están rotos":http://googleresearch.blogspot.com/2006/06/extra-extra-read-all-about-it-nearly.html".

Bloch ofrece más de un arreglo así que voy a notar acá que:

• este defecto simplemente no existe en lenguajes de alto nivel como Python o Haskell, donde los enteros sólo están limintados por los recursos de la máquina.

• Pienso que Bloch no es justo al sugerir que el análisis de Jon Bentley del capítulo 4 de Programming Pearls es incorrecto. El seudo código de ese capítulo está escrito en un lenguaje tipo C algo entre C y, y de hecho uno de los ejercicios propuestos de Bentley es examinar el efecto del tamaño de las palabras (words) tiene en este análisis.

• En cierto sentido midpoint2 está más roto que midpoint1: sobre el rango de las entradas bajas y altas, la suma desborda y gatilla el defecto el 50% de las veces.

Algoritmos Probabilisticos

Los computadores se suponen que son predecibles y típicamente buscamos programas correctos. No hay razones por las que consideremos programas que sean suficientemente correctos, sin embargi, y de hecho muchos programas que son suficientemente buenos para ser útiles también tienen fallas. Los avisos de Google, por ejemplo, analizan el contenido de las páginas webs y despliegan enlaces relacionados. El algoritmo usado es secreto, ingenioso y rápido, pero a menudo resulta en errores semánticos y, en ocasiones, errores ofensivs. Pocos podrían negar cuan útil ha sido para Google este programa, sin embargo.

Acá hay un ejemplo más interesante de un algoritmo, el cual, como un reloj que se atrasa, es casi correcto:

def is_fprime(n):

"""Usa el teorema pequeño de Frmat para adivinar si n es primo.
"""
from random import randrange
tries = 3
xs = (randrange(1, n) for _ in range(tries))
return all((x ** n) % n == x for x in xs)

 

No entraremos en las  matemáticas aquí. Una rápida ejecución con esta función parece prometedora.

>>> all(is_fprime(n) for n in [2, 3, 5, 7, 11, 13, 17, 19])
True
>>> any(is_fprime(n) for n in [4, 6, 8, 9, 10, 12, 14, 15])
False

De hecho, si le damos un trabaj real con algunos números grandes, lo hace bien. Lo he usado para adivinar cual de los números entre 100000 and 102000 son primos, comparando la respuesta con el resultado corercto. Tiene una tasa de éxito mejor que un 99% (en términos de relojes, pierde 8 minutos al día) y al aumentar tries mejora su desempeño.

Mejorando is_fprime

Mientras mejor  is_fprime se desempeña, menos probable es detectar lo que tiene de malo. Lo que es peor, no puede ser mejorado con ajustes simples. Sin embargo mientras más alto ponemos el valor de la variable  tries no tenemos una función correcta. Podríamos aún tomar una prueba al azar de la función y probar todo valor de x en el rango 1 a n dentro del predicado:

def exhaustive_is_fprime(n):
    return all((x ** n) % n == x for x in range(1, n))

exhaustive_is_fprime es muy caro para ejecutar y ocasionalmente retornará True para algún número compuesto. Si quieres saber más busca por los números de Carmichael.

El punto que quiero establecer es que código que es casi correcto puede ser peligroso. Estamos tentados a corregirlo haciendo ajustes a una implementación existente, aunque, este caso, se requiere de una revisión completa. En contraste, todos sabemos lo que se necesita hacer con el código que es claramente erróneo.

Programación defensiva

Todos hemos visto esas funciones nerviosas que van más allá de su interfaz declarada en un intento de protegerse de los usuarios descuidados.

/**
 * Retorna el valor máximo encontrado en el arreglo de entrada.

 * Pre condición: el arreglo no debe ser vacío.

 */
int nervy_maximum_value(int const * items, size_t count)
{
    int M = -INT_MAX;
    
    if (items == NULL || count == 0)
    {
        return M;
    }
    for ( ; count-- != 0; ++items)
    {
        if (*items > M)
        {
            M = *items;
        }
    }
    return M;
}

int maximum_value(int const * items, size_t count)
{
    int const * const end = items + count;
    int M = *items++;
    
    for ( ; items != end; ++items)
    {
        if (*items > M)
        {
            M = *items;
        }
    }
    return M;
}

Cualquiera que ha tratado de liberar un producto de software sabe lo que se siente deslizarse por la pendiente de esta curva. Probamos el sistema, encontramos defectos, los corregimos, repetimos. Al principio puede ser estimulante en la medida que los "bichos" con corta vida son aplastados, pero hacia el final del juego es desmoralizante ver cómo los defectos son reportados y no pueden ser reproducidos, y nos encontramos sin progresar.  Cuando finalmente dibujamos una linea y despachamos el producto lo hacemos sospechando que los peores problemas aún están por ser encontrandos. Para ponerlo en forma sucinta:

Ship happens!

Una combinación de técnicas nos ayuda a escapar de esta imagen depresiva. La más obvia sería evitarla: más que intentar una liberación tipo "big-bang" cada pocos años, podemos movernos hacia una liberación más continua e incremental. Una arquitectura desacoplada ayuda. De ahí la insistencia en pruebas unitarias. En vez de agitar el sistema y ver cómo caen los bichos, deberíamos desarrollar un conjunto de errores automatizados que activamente buscan los varios caminos a través del código y ejercitan los casos de borde.  Dentro de la base de código, la programación defensiva puede causar que los defectos se atrincheren. En vez de eso, deberíamos adoptar un estilo más confiado, donde el código falla en forma dura y rápidamente.

¿Cómo llego a funciona ese código alguna vez?

Han arreglado un defecto y luego se han preguntado ¿cómo pudo ese código haber funcionado antes de que lo corrigieran? Es una pregunta importante y una que requiere investigación. Quizás el defecto que arreglaste está compensado por programación defensiva en otro lado. O quizás hay vastas rutas a través del código que aún deben ser probadas.

Conclusiones

Imágenes tomadas de Word Aligned, del artículo original.

En el que se supone es el sitio tecnológico más importante de nuestro país, de lo único que hablan es del nuevo iPhone 3G, y todos los fanboys de Steve Jobs están histéricos con la novedad. Pero una noticia de impacto tecnológico enorme, no ha sido ni siquiera mencionada levemente.

Porque en Europa se aprueban medidas para intentar controlar y acabar con la neutralidad de la red. Sabemos que hay parlamentarios chilenos que han prometido torpedear el actual proyectosde neutralidad en la red.
Además nuestros parlamentarios les encanta seguir estos ejemplos de sus pares europeos, así que no me extrañaría que terminemos con una ley igual de mala y que va en contra de nuestra libertad.

Pero a los "sitios tecnológicos", de acá y de allá, lo único que les importa es el nuevo iPhone, no se dan cuenta que a Apple le interesa mantener el control de todo el stack tecnológico, tal como apunta Ricardo Galli, y que son parte interesada en todas estas medidas.

Las noticias importantes, y que nos afectan (o afectarán) pasan piola, para muchos la tecnología es el nuevo Soma. No me interesa seguir leyendo sitios que la reparten.

Sucede que en estos días me pidieron ayuda para revisar un sistema (escrito mayormente en C) en que participé hace 6 años atrás. En el proceso descubrimos varios errores que sólo se hicieron evidentes ahora que se intentó una actualización del sistema operativo. Errores que nunca aparecieron en 6 años de operación continua.

Considero que no se llega a entender bien un sistema hasta después de observarlo detenidamente durante mucho tiempo. Puedes volver a revisar un código que escribiste hace meses, o años atrás, y siempre encontrarás un detalle. Puede ser un error grave, que sólo aparece como warning, y que en un ambiente no produce problemas, pero que "estalla" al correrlo en otro.

Al revisar tu viejo código sucede que te das cuenta de malas decisiones de diseño, o notas que puedes hacerlo mejor (normalmente porque has ganado experiencia y sabes como escribir mejor código). Otras veces descubres serios fallos de seguridad, que son sutiles, pero que no puedes ignorar. errores que no notaste en un primer momento, o que no pudiste revisar (siempre falta tiempo).

Algo parecido es lo que ha pasado recientemente con el problema en el diseño del DNS, y que tiene de cabeza a los administradores actualizando y parchando los servidores DNS.

La lección es que nunca podemos asegurar que, dado que un sistema lleva mucho tiempo funcionando correctamente, está libre de errores.

Este año se acaba el mundo (otra vez).

Bueno, ya hemos hablado sobre el fin del mundo por culpa de la tecnología. Pero esta nueva "amenaza" es bastante interesante.

La causa sería la activación del Large Hadron Collider, el acelerador de partículas más grande construido hasta ahora. El LHC es el proyecto más importante de la Organización Europea para la Investigación Nuclear (CERN).

En el CERN es donde nació la Web, que fue un proyecto propuesto por Tim Berners Lee con el fin de compartir el trabajo de los investigadores a través del mundo usando internet, pero esa es otra historia.

El CERN es el mayor centro de investigación en física nuclear del mundo, y el LHC es el experimiento más importante en ejecución en este momento.

En esencia el LHC es un muy frio tunel (a 2 grados Kelvin, 271 grados centigrados bajo cero) de unos 27 kilómetros de circunferencia, donde colisionarán protones a muy altas energías.

¿Para qué?

Con el fin de encontrar y observar por primera vez una partícula predicha, pero aún no observada por el modelo estándar de las partículas elementales. Se trata del "Bosón de Higg":http://es.wikipedia.org/wiki/Bos%C3%B3n_de_Higgs.

El experimento permitirá confirmar la existencia de esta partícula elemental, y con esto saber por qué todos los cuerpos tienen masa. Por que sabemos que todos los cuerpos tienen masa, y que esta es equivalente a la energía, pero no sabemos en realidad qué es la masa, y cómo los cuerpos la adquieren.

Por esta razón que incluso un permio Nobel llegó a denominarla la "Partícula de Dios".

En realidad el LHC es una máquina extraordinaria, y peligrosa, pero no en el sentido de poder destruir el mundo. Efectivamente, la energía interior es enorme, y si algo falla se puede producir una explosión, que probablemente pueda destruir el laboratorio, pero ese no es tipo de catástrofe que andan anunciando algunos.

Siempre que el hombre se ha enfrentado a este tipo de experimentos surgen los temores más catastróficos. Cuando se probó el primer artefacto nuclear algunos especularon que la explosión de la primera bomba atómica quemaría la atmósfera. De hecho, cuando se iba a romper la barrera del sonido también se habló de la destrucción de la atmósfera.

En este caso se ha especulado que durante el experimento se podrían formar agujeros negros estables que se tragarían nuestro planeta. O que surja materia exótica, que vaporizaría a la Tierra en segundos.

Los científicos han medido los riesgos probables, y han hecho dos estudios, el primero en 2003, y uno muy reciente, que permiten descartar estos escenarios catastróficos.

La verdad es que se han observado en la naturaleza la caida de rayos cósmicos con 100 millones de veces más energía que la generada en el LHC, y nunca se ha visto que se formen agujeros negros ni hasta ahora se ha quemado nuestro planeta.

Bueno, este debe ser cómo el décimo fin del mundo que me toca presenciar, así que no me preocupo mucho, puede que termine pasando algo como lo que describen en xkcd:

traducción

* El Large Hadron Collider, CERN
* Okey, el momento de la verdad
* VVVVVRRRRMMMMMMM
* ¿Viste el Bosón de Higgs?
* NOP
* Uh...
* Bueno entonces...
* Hasta que los teóricos vuelvan, ¿te parece que le demos a unas palomas con el rayo de protones?
* Ya estoy en eso. Cool! Ya le dí cancer a un helicóptero.

Este año cumpliré 42 años, y 42 es un "número extraordinario", como todos saben (o deberían saber), 42 es es la respuesta a la pregunta sobre el sentido de la vida, el universo y todo lo demás.

Así que me voy a permitir practicar un poco la apofenia durante estos meses que quedan para llegar a mi cumpleaños, sólo por que es entretenido, no porque esté volviendome loco, o me rinda ante el anumerismo, así que no se preocupen.

Y es que resulta que se han entregado 42 premios Turing, porque el mismo Alan Turing falleció a los 42 años, porque probablemente el 42 es la clave para entender la distribución números primos, y porque los 8 dígitos de PI a partir de la posición 242.422 son 42 42 42 42, y por supuesto porque 42 es uno de los números.

Probablemente Douglas Adams nos hizo una revelación importante, ¿quien sabe?, así que he creado la categoría 42 para este blog, donde estarán estas "peladas de cable", pero que les aseguro que serán entretenidas.

Aunque ustedes no lo crean, Microsoft publica software OpenSource.
De hecho hay 2 licencias de Microsoft aprobadas oficialmente por la OSI, la Microsoft Public License (Ms-PL), y la Microsoft Reciprocal License (Ms-RL).

NDoc era un proyecto opensource bastante popular entre los desarrolladores que estabamos usando Microsoft.Net 1.1. La verdad es que era muy util al permitir generar documentación para nuestro código fuente a partir de las anotaciones puestas en nuestros programas.

Lamentablemente el proyecto nunca tuvo un apoyo de la comunidad, aunque se hicieron gestiones para tratar de obtener el apoyo oficial de Microsoft, nunca se obtuvo una respuesta positiva, y en febrero de 2006 su autor, Fabrice Marguerie anuncia que no puede continuar soportando este proyecto y que renuncia a seguir soportandolo dado el anuncio oficial de Microsoft de construir una herramienta que hace lo mismo. Aunque el caso no es tan trágico como lo que le pasó a Jamie Cansdale, demostró que Microsoft a pesar de lo que declara Ballmer, no está muy interesado en apoyar los proyectos comunitarios de los desarrolladores, y prefiere desarrollar sus propias herramientas.

Microsoft nunca toma una decisión del todo clara con este producto, y aunque lo puso a disposición en forma gratuita, en una movida extraña, decide colocarlo en CodePlex, el portal de de aplicaciones Open Source soportado por Microsoft (la competencia a Sourceforge).

Pero la comunidad se pregunta, que pasa con Sandcastle, ¿es un proyecto Open Source? y si no lo es, que hace en CodePlex? La comunidad de desarrolladores de CodePlex empezó a presionar para que Microsoft tomara una decisión, o lo licenciaba OpenSource, o lo sacaba del portal.

El equipo de Sandcastle avisa que decide retirar el proyecto del portal. Pero la verdad es que Sam Ramji, el hombre a cargo de Opensource en Microsoft, les ordenó retirar el proyecto de Sandcastle e incluso presenta sus excusas a la OSI, y pide disculpas a la comunidad open source en general.

Es más, Ramji se compromete a que la política oficial de Microsoft con respecto a los proyectos open source en Codeplex será aceptar sólo proyecto con licencias apobadas por la OSI.

Esta historia tiene un final feliz, sin embargo, porque después de pensarlo muy bien, y quizás tras algunas discusiones internas Microsoft decide publicar el código fuente de SandCastle.

Ramji anuncia:

Tengo el placer de anunciar que el equipo del proyecto Microsoft SandCastle ha reconfirmado su fuerte soporte a la Ms-PL y está preparando la liberación de todo el código fuente para el proyecto en forma inmediata. Este fue un esfuerzo no trivial y los aplaudo por esto. Creo que estas acciones demuestran la voluntad de Microsoft para acatar la inspección in situ de la Definición Open Source con respecto a la liberación de proyectos de código abierto en CodePlex...

Algunos sienten que fue draconiano retirar el proyecto de Codeplex, otros que no fuimos lo suficientemente lejos; otros se disgustaro porque amaban el proyecto y no podían encontrarlo; algunos pensaron que nos estabamos imponiendo un estándar más alto que el necesario. Creo que en la medida que continuemos construyendo nuestras prácticas a lo largo de la compañía para participar en el desarrollo opensource, debemos tratar de lograr los estándares más altos posibles.

Como ven, Microsoft está en crisis, el OpenSource ya se les instaló y cada vez irá aumentando, como un virus, así que sospecho que Jeff Attwood tendrá una respuesta inesperada a su pregunta: ¿por qué Microsoft no puede liberar software Open Source?

"¡Es que nunca entiendes!, pero si ellos entienden, entonces tu entiendes, ¿entiendes?" -- Crush La Tortuga, en Buscando a Nemo

Andrew Stanton es la voz original de Crush, la tortuga padre de la joven Squirt, la tortuguita que guía a Marlin y Dory para que tomen la famosa corriente australiana oriental, C.A.O. Sucede que la voz de Squirt es del hijo de Brad Bird, mi director y guionista favorito, de quién hemos comentado antes su trabajo en este blog. El enlace está hecho, me gusta encontrar esas conexiones en la historia de la gente.

Pero Bird es uno de los genios recién llegados a PIXAR, Stanton ha estado desde el principio en la compañia, y ya nos había sorprendido gratamente con Buscando a Nemo el 2003.

Ahora Stanton se supera, con WALL-E.

Una de las características del trabajo de Stanton que me gusta, es esa capacidad de darle vida y expresividad a sus personajes. Por ejemplo, en Nemo, los peces no dejan nunca de ser peces, y les da expresividad con un conjunto limitado de movimientos. Ahora el pie forzado es más dificil, porque WALL-E no sólo es un robot, sino que uno de forma muy especial, que nos recuerda esas sondas enviadas a explorar marte, pero que tiene unos ojos llenos de vida.

WALL-E es en parte, la primera comedia romántica de PIXAR, el mismo Stanton lo dice en una entrevista:

"Lo que realmente me interesó era la idea de que la cosa más humana en el universo fuera una máquina porque está mas interesas en encontrar cual es la razón de vivir, que la gente real. El mandamiento más importante que Cristo nos dió es el amor, pero no siempre es nuestra prioridad. Así que vine con esta premisa que puedo demostrar lo que estaba tratando de decir, que el amor irracional derrota la programación del mundo. Tienes a estos dos robots que están tratando de ir por encima de sus directivas básicas, literalmente su programación, para poder exprimentar el amor".

Esa idea es bonita. Yo no soy cristiano, ni creyente como Stanton, pero entiendo lo que quiere decir, y me quedó muy claro con su película. Y estoy de acuerdo, rorque el amor irracional es realmente lo que nos puede salvar, de muchas cosas.

WALL-E es también es una muy buena película de ciencia ficción, y de aventuras.

Desde el punto de vista de la ciencia ficción, no sólo está la referencia al modelo de los robot asimovianos, sino que muchos tópicos importantes, como el desaste medio ambiental al que nos dirijimos, o los peligros de la alienación del ser humano por la tecnología.

Ustedes saben que me gustan los robots, así que esta película era muy esperada por mí, pero vayan a verla, lo van a pasar muy bien, porque es una película muy entretenida y muy bien hecha, para disfrutar con los hijos, o en pareja. WALL-E es uno de los robots más adorables del cine, magistralmente expresivo, simpático y hace que a su lado R2-D2 parezca una antipática lata con ruedas.

Un nuevo estudio, avalado con credenciales bastante respetables "demuestra" que los computadores para los niños en el hogar tienen efectos negativos en la educación de los niños, y que es cuestionable la utilidad de esfuerzo a gran escala para darle acceso a computadores a niños en situación precaria, si es que no se pone atención en la forma en que los padres controlan el uso del computador.

La historia es así, en el año 2005 el gobierno rumano decide entregar un voucher para que los niños y jóvenes de menores recursos pudieran adquirir un computador para el hogar. Como parte del programa, el gobierno rumano puso a disposición de los interesados sobre 500 paquetes educativos, los que debían ser instalados sin costo por las empresas retail que vendieran los computadores.

El año 2007 se realiza una encuesta para investigar el impacto de esta medida en Rumania, y se encuentra que muy pocos computadores tenían instalados los paquetes educativos, que los resultados fueron negativos en cuanto al desempeño escolar. Finalmente sólo disminuyó la cantidad de horas viendo televisión, las que fueron reemplazadas por horas usando el computador, y en general los niños con computador presentaron un peor rendimiento escolar. Sólo en los casos en que había una figura de autoridad en la casa (normalmente la madre), que vigilara el uso del PC los jóvenes tuvieron un mejor rendimiento.

Pero, ¿que pasó? ¿que fue lo que estuvo mal con el proyecto rumano?

Primero, parece que en su afán de probar que es malo entregar computadores a los niños estos investigadores descuidan gravemente sus matemáticas. El modelo propuesto está mal aplicado, como demuestra Tony Forster.

Pero la verdad es que ignoran varios hechos de sentido común, que Ivan Krstic se encarga de aclarar.

Primero, el voucher sólo cubría la compra de un computador, no existía un incentivo para cubrir los costos de internet, en esencia la mayoría de los computadores estaban desconectados.

En segundo lugar, la elección del hardware no es la adecuada, tal como apunta Krstic, el hardware a usar en este tipo de programas debe tener las siguientes características:

Propiedad, tiene que ser algo que los niños puedan poseer, porque un computador compartido en la sala de clases sólo opera en las aulas y cuando hay profesores, y cuando no hay otros niños compitiendo el tiempo en el computador.

Portabilidad, los chicos deben ser capaces de llevar el dispositivo junto