Memoria transaccional y concurrencia

En ACM Queue han publicado un articulo que ilustra bastante bien por donde irán los tiros (seguramente) en esto de la programación concurrente. Se trata de Unlocking Concurrency: Multicore programming with transactional memory y describe un poco que es la memoria transaccional y como se programaría en un lenguaje de los de uso cotidiano.

Básicamente se trata de especificar en el lenguaje que secuencias de operaciones forman una transacción de memoria, en la cual, como su nombre indica, o bien se realiza la operación completamente o bien es como si no se hubiese operado con ella, evitando la sincronización manual por parte del programador. Como se encargan de subrayar en el artículo tampoco es la panacea, pero ayuda(ría) mucho a la gestión de la concurrencia.

Sólo falta ahora que se implemente en lenguajes de uso común y deje de ser sólo objeto de investigación académica...

La misma entrada en BP

Una herramienta, no una religión

Entrada interesante en Adding Simplicity - An Engineering Mantra, It's a Tool, Not a Religion!. Traduciendo muy libremente:

Recientemente he estado asistiendo al debate de REST contra SOA. La última semana me vi envuelto en discusiones de C++ contra Java. Esta noche pasada me tropecé con algunos debates sobre Django contra Rails. Me parece que los ingenieros de software somos únicos en el mundo técnico: más que disfrutar con una caja de herramientas variada, discutimos contra su contenido, esperando descartar todas excepto el conjunto más pequeño posible.

[...]

¿Porque debemos trabajar tanto en reducir nuestro conjunto de herramientas hasta la herramienta definitiva? Hay una tendencia a buscar el lenguaje Navaja suiza apoyado por un framework que será la solución óptima para todos los problemas del mundo. La simple realidad es que ese lenguaje o framework no existe. ¿Por qué? Bueno, la solución de problemas informáticos es siempre acerca de adoptar compromisos que optimicen la solución en determinadas condiciones. Si tu problema cumple esas condiciones, perfecto. Si no, estarás usando una herramienta subóptima.

[...]

Es importante tener opciones para resolver los problemas de cada día. Entender las herramientas y su aplicabilidad a un problema dado debería ser nuestro trabajo

En resumen, en lugar de criticar herramientas, aprende su ámbito de aplicación...

La misma entrada en BP

sky2 y sk98lin en Ubuntu

Nota: Esta entrada es obsoleta, porque desde la versión 2.6.17 el driver sky2 funciona correctamente y sk98lin ha dejado de mantenerse. O sea, que hay volver a configurar sky2 y hay que eliminar del fichero /etc/modprobe.d/blacklist la línea blacklist sky2 (si existe)

Referencias:
sk98lin en la wiki de gentoo en la que se explica un poco la historia
Una explicación de la situación el la lista del kernel


Entrada original:

Tenía problemas con el driver de la tarjeta de red, una Marvell Yukon, desde la actualización a Dapper y no lo sabía, porque no la usaba últimamente. Si se hace un uso intensivo de la red (léase P2P ;) ) sky2, que es el driver que ubuntu coge por defecto, se quedaba atascado. El caso es que he buscado (quizás no mucho) y no he encontrado, como suele ser usual, la receta sencilla. Lo que me ha servido a mi es:

1. Instalar las cabeceras del kernel (en mi caso y salvo casos excepcionales linux-headers-generic)
2. sudo apt-get install build-essential (si no lo tenemos)
3. Bajar el driver de http://www.marvell.com/drivers/driverSearchResults.do y descomprimirlo
4. Sustiuir #!/bin/sh por #!/bin/bash en el fichero install.sh
5. En el directorio descomprimido: sudo ./install.sh y damos a 1. Installation
6. sudo modprobe sk98lin
7. añadir la línea blacklist sky2 al final del fichero /etc/modprobe.d/blacklist (edítalo como root o con sudo)

Espero que le sea útil a alguien...
(Basada en dos recetas, para mi, incompletas: http://www.ubuntu-es.org/index.php?q=node/30706 y http://ubuntuforums.org/showthread.php?t=176096 )

La misma entrada en BP