Clang ya se autocompila y GCC ya tiene sus primeros plugins

Como puede leer en el blog de LLVM/Clang, el compilador con licencia similar a la BSD patrocinado por Apple:

¡Clang ha completado su primera autocompilación! Hemos compilado toda la LLVM y el propio Clang con Clang, unas 550k líneas de código en C++. Los binarios resultantes han pasado todos los test de regresión y el Clang resultante puede además generar toda la LLVM y Clang de nuevo. Este tercer Clang resultó plenamente funcional completando así el bootstraping .

Más comentarios en OSNews y reddit. En noticias relacionadas, el sistema de plugins de GCC va dando sus frutos y la fundación Mozilla ha desarrollado Dehydra y Treehydra, unos plugins para hacer análisis estático de código C++.

La misma entrada y espero que más comentarios en Clang ya se autocompila en barrapunto.

Triple arranque en un MacMini

Pues conseguí un MacMini basado en Intel de 80 Gb y lo primero que decidí hacer es ponerle tres sistemas operativos ¿Para qué dejarse opciones? El caso es que instalar dos es más o menos fácil, basta con mirar el documento que describe como usar el asistente de BootCamp y/o alguna guía de cómo instalar linux en un MacIntel. Pero instalar tres no es tan sencillo, si uno de ellos es Windows (XP) y existen una serie de sutilezas con las que me he encontrado que quizás le viene bien saber a alguien que busque "por ahí" soluciones.

- Windows (XP al menos) sólo se instala bien en la última partición
- Windows (XP al menos) sólo se instala bien si existen menos de cuatro particiones

Bajo estas dos premisas, el particionado del sistema da muy poco juego, sabiendo que GPT ya crea una que no se puede obviar. Los pasos, muy resumidos, que he seguido para dejarlo funcionando con triple arranque:

- Instalar OSX
- Ejecutar el asistente de BootCamp
- Instalar rEFIt
- Reparticionar para dejar cuatro particiones
- Instalar windows en la última
- Instalar Linux en la penúltima, instalar grub
- Editar desde OSX el fichero refit.conf para que no arranque por defecto OSX
- En Debian al menos no instala por defecto un par de módulos que, en un equipo de estas características puede estar bien para monitorizar la temperatura y la velocidad del ventilador: applesmc y coretemp. Metiéndolos en /etc/modules se soluciona.

Para todo el proceso he seguido varios enlaces, pero los más importantes son:

• Linux en un Mac Mini (Intel Core Duo) que va bastante bien si solo quieres instalar Linux.
• Triple Boot via BootCamp en donde se explica bastante bien todos los problemas que me había encontrado previamente y cómo solucionarlos, sobre todo el famoso cannot find hall.dll que salía cuando trataba de instalar Windows en una partición que no era la última

Bueno, en el camino he aprendido algo, aunque no demasiado, de EFI, GTP y otras hierbas. Quizás haya alguien que encuentre algún error, omisión, que le resulte útil o que quiera añadir algo...

La misma entrada y algún comentario más en Triple arranque en un MacMini en barrapunto.

Facebook publica Tornado, servidor web usado en FriendFeed

Como cuentan en LWN, Facebook ha anunciado el lanzamiento de su servidor web Tornado bajo la licencia Apache. Tornado es un servidor Web no bloqueante escrito en Python, diseñado para gestionar miles de conexiones simultáneas, lo que lo hace ideal para servicios Web de "tiempo real". Tornado es la pieza central de la infraestructura de "tiempo real" de FriendFeed, que tienen previsto mantener activamente. Tornado es similar a "frameworks" Web ya existentes (Django, webapp de Google, web.py) pero se centra en la velocidad y en manejar grandes cantidades de tráfico simultáneo. El código se puede obtener de tornadoweb.org. Lo comentan también en reddit, Slashdot y Hacker News entre otros.

Hay que recordar además que Facebook publicó su versión modificada de memcached, después de haber publicado parte de su código. También recordar que hace poco más de un mes que Facebook ha adquirido Friendfeed.

Más comentarios en Facebook publica Tornado, servidor web usado en FriendFeed en barrapunto

Enlaces varios (VI)

Hace muchos días que no he podido escribir por aquí, así que quizás a alguien le pueda parecer interesante el dump de cosas que tenía semi-guardadas:

• Sobre el lío de la eliminación de los conceptos en el borrador C++0x y su retraso en general:
  • 'Trip Report: Exit Concepts, Final ISO C++ Draft in ~18 Months' de Herb Sutter
  • 'The C++0x "Remove Concepts" Decision' de Bjarne Stroustrup
  • También en Slashdot y reddit
• Smaller is Faster (and Safer Too). De cómo chromium se auto-parchea con diferencias binarias.
• Tech Or Management Beyond Age 39?
• Dos sobre concurrencia y excepciones: 'Answering email about error handling in concurrent code' de Herb Sutter y 'Concurrency and exceptions' de Joe Duffy

La misma noticia y más comentarios en Enlaces varios (VI) en barrapunto

MinGW publica GCC 4.4.0

El equipo de MinGW ha publicado los binarios de GCC 4.4.0 para Windows. De entre las novedades destacan un mejor tratamiento de excepciones, una versión de libstdc++ en forma de librería compartida, y soporte para TLS (thread-local storage), además de todas las novedades de la versión 4.4.0. Hay que recordar que la anterior versión soportada oficialmente era GCC 3.4.5. Más en reddit.

El manejo de las excepciones ha mejorado drásticamente debido a que se ha usado una implementación basada en DWARF, dejando de lado el viejo modelo SJLJ, que ya no estará disponible. Además con esta versión las excepciones ya pueden atravesar las fronteras de las DLL sin problemas.

La misma noticia y más comentarios en MinGW publica GCC 4.4.0 en barrapunto

memcpy y la concurrencia

Si el otro día comentaban en barrapunto que en MS marcaban como peligroso el uso de memcpy hoy podemos encontrar otra razón para usarlo con precaución. En memcpy() concurrency curiosities David Dice habla de un comportamiento antiintuitivo de dicha función que sale a la luz en entornos fuertemente concurrentes: sobreescribir la misma secuencia constante en memoria puede tener valores no válidos temporalmente durante su llamada, leídos por otros threads con resultado catastrófico si no se tiene cuidado. Otro caso más en el que las abstracciones que usamos evolucionan a su manera, quizás con explicación pero con resultados que contradicen la intuición y exigen, a veces, conocer que se cuece allá abajo. (No mucho) más en reddit

La misma entrada y más comentarios en memcpy y la concurrencia en barrapunto

Avances en las implementaciones de C++0x

Por lo que he leído hace un tiempo y ahora puedo comentar aquí, tanto gcc como VC++ se están poniendo las pilas en la implementación de C++0x.

• Vía Drizzt, Qt 4.5.1 y gcc 4.4 leo que entre las más notables novedades de gcc4.4 se incluyen muchas características del C++0x, entre las cuales están declaraciones con auto y la inicialización de objetos con listas. Bien :) Se puede saber más en la página de status de la implementación de c++0x en gcc 4.4 donde se puede ver que la concurrencia no es una de las características más adelantadas, empezando por el modelo de memoria. Tiempo al tiempo...
• En VC++ también van a buen ritmo, lo cual es bueno para el estándar, no como pasó con el VC++6 de infausto recuerdo y larga duración :). En el blog oficial de VisualC hablan de decltype (C++0x Features in VC10, Part 3) repasando esa característica de C++0x que por cierto ya está implementada también en gcc. Además apuntan a las dos entradas anteriores, que también resultan instructivas Lambdas, auto, and static_assert: C++0x Features in VC10, Part 1 y Rvalue References: C++0x Features in VC10, Part 2

Y ya que estamos en el tema dos enlaces de propina: Designing Multithreaded Programs in C++0x de Anthony Williams y GCC C++0x Features Exploration en C++ Soup! y por supuesto la imprescindible wikipedia que tiene un estupendo punto de entrada: C++0x

La misma entrada y más comentarios en Avances en las implementaciones de C++0x en barrapunto

Bitácoras de Programación: selección personal

Llego tarde a la discusión generada con la entrada en la bitácora de leonidas en barrapunto que rvr pasó a portada acerca de blogs y feeds en general relacionados con la programación. Salen por supuesto muchos de los agregadores y planetas que consumo, como reddit, hacker news (uhmm, éste no sale), dzone o planeta código. Pero después de leer todas las respuestas me ha entrado la "necesidad" de hacer mi propia selección personal basada únicamente en gustos. Son bloggers que creo que son un poco distintos y, en su mayor parte combinan el bloguerío con un alto nivel técnico que dejan ver el sus posts. Allá van:

• Mbpfernand0's Blog, el nuevo blog técnico de "nuestro" fernand0. El tema fundamental es la programación y la seguridad, aunque creo que no hace ningún asco a temas relacionados. Por cierto, que promete su propia selección de blogs sobre programación. Habrá que estar atento.
• El valle del Viento Helado de Drizzt, el Drizzt de barrapunto también. Sistemas operativos, compiladores, administración y seguridad. Muy interesante.
• .NET o no .NET, esa es la cuestión. Puedes no compartir sus preferencias tecnológicas, pero para mi es uno de los que mejor escribe y destila conocimiento y experiencia por todos los bits.

En inglés:

• intertwingly de Sam Ruby. La web y sus estándares. Para mí, imprescindible.
• jeffr_tech's Journal. Detalles internos del desarrollo de FreeBSD. No actualiza mucho pero merece la pena estar suscrito.
• daniel.haxx.se de Daniel Stenberg. Del autor de curl y Rockbox entre otros, el blog de un desarrollador prolífico.
• Coding Relic de Denton Gentry. Normalmente sobre Software embebido, pero toca otros palos.
• Ulrich Drepper. El blog del mantenedor de la glib. Poco prolífico, pero para no perderse ni una sola entrada.
• Nynaeve: Adventures in Windows debugging and reverse engineering. No se me ocurriría un mejor título nunca
• Y por fin el imprescindible Sutter’s Mill: Herb Sutter on software, hardware, and concurrency

Ahora no se me ocurre ninguno más, pero pueden ser las prisas...

Actualización: He publicado este texto más o menos en un comentario por aquello de completar la información en su sitio. También lo pongo aquí y lo replicaré en mi bitácora en barrapunto, que a su vez se copiará en planeta código, por aquello de que lo que se replica queda y de que hay URLs que desaparecen...

Erlang 5.7/OTP R13A: soporte para Unicode, mejoras en multicore y SSL

Acaba de salir la nueva versión del conjunto Erlang/OTP, en concreto la versión Erlang 5.7/OTP R13A. La nueva versión de un lenguaje y sus librerías no tiene por qué ser gran noticia, pero en este caso las novedades son tan notables que creo que merece una mención. Entre ellas se encuentran importantes mejoras de rendimiento en entornos multicore y SMP, que es especialmente importante teniendo en cuenta que una de las grandes bazas del lenguaje es su tratamiento de la concurrencia. Además destacan también el soporte para Unicode, posibilidad de usar WxWidgets a través del WxErlang (de momento en beta) y reescritura del soporte para SSL. Muchas de estas características eran necesarias para la introducción de este lenguaje más allá del entorno de las telecomunicaciones que históricamente ha sido su nicho natural. Más comentarios en reddit y Hacker News

La misma entrada y más comentarios en Erlang 5.7/OTP R13A: soporte para Unicode, mejoras en multicore y SSL en barrapunto

Aprendiendo de los errores (II)

Dan J. Berstein reconoció una vulnerabilidad en djbdns y la recompensó con mil dólares y por supuesto no se han hecho esperar reflexiones acerca de la seguridad informática, su (im)posibilidad y su relación con lo disponible del código.

Entonces leo con interés, vía el nuevo subarrapunto de fernand0, un comentario en hispasec que no por evidente debe dejar de repetirse: no existe software sin fallos de seguridad, pero los que menos tienen son aquellos que han sido diseñados y programados desde su inicio con la seguridad y la simplicidad como guía.

Y ello descarta a casi todo el software y probablemente más al comercial, que tiene más presiones para añadir más y más cosas. Recordemos, que como decía Alan J. Perlis A la larga cualquier programa se vuelve rococó. Después escombros. Lo de siempre, funcionalidad contra robustez y simplicidad :)

De todos modos el caso de djbdns es también interesante por el tipo de fallo encontrado. En Hacker News comentaban que el problema era en la implementación de la compresión que usa en el protocolo DNS para sus paquetes, para eliminar redundancias. Y precisamente Bernstein había hablado negativamente del método de compresión (descrito, claro, en el RFC 1035, 4.1.4, página 30) Extractando de la crítica de Bernstein:

Un problema con la compresión DNS es la cantidad de código necesario para analizarla. Localizar de modo fiable los nombres lleva un trabajo que habría sido evitable para una caché DNS. La compresión LZ77 habría sido mucho más fácil de implementar.

Otro problema con la compresión DNS es la cantidad de código necesario para generarlo correctamente. [...]

Otro problema con la compresión DNS es que no es particularmente efectiva. LZ77 habría funcionado mejor en esos tipos de datos y funcionaría mejor con los tipos de registros que se popularizarían en el futuro [...](Y aquí habla de incompatibilidades de algunas versiones de BIND con el RFC)

Muy interesante todo el texto original, incluidas las elipsis ;) anque bastante específicas del caso DNS. Lo que no me ha quedado claro es la razón de no usar LZ77, si fue un caso de Síndrome NIH, de hackerismo o tenía algo que ver con las patentes sobre estos tipos de compresión que llevaban haciéndose desde 1984 como la del LZ78. Pero vamos como regla general parece mucho mejor usar un algoritmo conocido que inventar uno nuevo, a no ser que trabajes en eso, en innovar...

Creo que la moraleja es clara, como se dice a veces exagerando el mejor código es el que no existe sobre todo desde el punto de vista de la reducción de bugs y aún más si se trata de seguridad.

(Esto se llama Aprendiendo de los errores (II) porque ya escribí en su día Bugs antiguos y moralejas , que iba sobre lo mismo, también salía DJB y el DNS, en aquel caso con el bug/error de diseño que explotó Kaminsky)


La misma entrada y más comentarios en Aprendiendo de los errores (II) en barrapunto