El ruido del disco duro era semejante al de esta maquina mezclando hormigón

El proble ma no eran los archivos en sí mismos ya que mediante buffers que gestiona el propios sistema operativo se consigue un rendimiento excelente, sino por la base de datos mysql. En mi caso, hacía currar a la base de datos de tal manera (con updates, inserts y selects constantes) que el disco duro parecía una hormigonera. Después de estimar el tiempo total de procesamiento en 6 horas pensé que eso le iba a hacer mucha pupa al disco duro duro (además del evidente cuello de botella) y que había que hacer algo. Entonces me dije: “Quiero almacenar los datos en algo que no haga ruido y si es posible que sea rápido” y eso amigos, es precisamente la memoria RAM. Así que vamos al tema.

Lo bueno de usar este método es que no tienes que tocar nada ni de mysql ni de tu programa, ya que para ellos será un dispositivo de almacenamiento estándar. Ahora prepárate un café porque esto va a ser complicado.

            mount -t tmpfs none /media/ramdisk

Ya está, ahora tienes en el directorio /media/ramdisk montada tu memoria RAM. Por supuesto, se reserva sólo una parte ya que el sistema necesita disponer de memoria para funcionar.
En mi caso, copié /var/lib/mysql a /media/ramdisk y luego un enlace simbólico para que mysql accediera a ello sin configurar nada.
Si quieres saber exactamente cuanto espacio tienes puedes usar el comando:

            df -h

Te mostrará algo como esta línea (junto al resto de sistemas de ficheros montados)

            none                  1,7G  384M  1,3G  24% /media/ramdisk

Dispongo de 1,7GigaBytes de almacenamiento en memoria RAM (384 megas usados). Recueda que es muy importante guadar luego esos archivos en tu disco duro porque la memoria RAM no es persistente y todo lo que haya se volatilizará cuando se demonte. En mi caso el tiempo de ejecución del programa paso de unas 6 horas a poco más de 45 minutos, y eso que mi memoria es lenta (667mhz) además de no hacer ningún ruido. Para casos o situaciones concretas este método puede sernos muy útil, incluso he visto casos de un servidor donde hasta los archivos estáticos (css, js, imagenes…) estaban cargados en memoria. Si tenemos en cuenta que en un ordenador todo pasa por la memoria y que el disco duro es con diferencia el dispositivo más lento (y delicado), se pueden obtener tiempos muy buenos en sistemas críticos (ej. una web con millones de visitas). El problema está cuando trabajamos con datos (que pueden cambiar, algo bastante común) y que nunca estarán a salvo hasta que lo volquemos a un disco duro. Para esos casos ya existen las cachés que en el fondo es copiar en memoria aquellas cosas de sólo lectura mientras mientras que los cambios se guardan al momento y posteriormente se actualiza esa caché.

Entradas relacionadas:

1. Borra tus ficheros de manera definitiva Muchos somos conscientes de que borrar un archivo no implica...
2. Eliminar espacio reservado en ext Cuando formateamos una unidad en el sistema de ficheros ext,...

Muy buenas! Seguro que más de uno ha oído hablar de las bondades de las bases de datos llamadas “nosql”. Yo también y la verdad es que me intrigaba mucho así que me puse a analizarlo fríamente. Todos los benchmarks y comentarios de la gente dan como absoluto ganadador a las “nosql”, obligando al destierro a las bases de datos relacionales. Después de analizar qué es cada cosa y las necesidades reales he llegado a una conclusión: Nada más lejos de la realidad. Intentaré explicar lo mejor posible mis razonamientos, quizá de manera demasiado abstracta, del por qué las “nosql” no son la panacea. No obstante, esto es mi opinión y alguien puede pensar que sólo digo chorradas o que en algún aspecto estoy totalmente confundido. Si es así, me gustaría saberlo ya que mi intención siempre es aprender más y nunca imponer mis ideas. Pero siempre desde el respeto Lo primero de todo y de las cosas que más rabia me da es que la mayoría de los benchmarks (muchos son más bien pruebecillas que hace alguien en 10 minutos) miden sólo el tiempo que tarda en leer n entradas o en insertar otras tantas. Bien, ahí la verdad es que las nosql son muy rápidas pero pensemos un poco: ¿qué base de datos se centra exclusivamente en esas tareas? Muy pocas y en casos muy concretos. Normalmente obtener información no es simplemente meter la mano en un cubo y sacarla sino que es algo más complejo. Esta complejidad  se trata de abordar mediante lo que las bases de datos relacionales llaman relaciones.

Por ejemplo, tengo una base de datos en la cual quiero saber cuanta gente es de cada país. Con una sóla consulta sql lo tengo mientras que con una nosql tengo que hacer, el mejor de los casos, tantas consultas como países haya. Ahora dime cuanto tiempo has tardado en hacer todas las consultas. A eso hay que sumarle que estás acoplando tu base de datos a la aplicación, ya que será la aplicación quien mediante funciones propias recorrerá y hará las tareas pertinentes (con su pérdida de eficiencia). Otro factor muy importante son las técnicas y estrategias con las que cuenta un sgbd relacional. Mediante estas técnicas es capaz de acelerar las consultas ya que, como sabe lo que quieres, trata de conseguirlo de la mejor manera posible.  Estas estrategias de optimización son imposibles en una nosql, ejecutarás todas y cada una de las consultas. De esta manera el tiempo total crecerá (en los mejores casos) de manera lineal frente al número de entradas mientras que en una relacional el crecimiento sería bastante más logarítmico.

Cojunto de SGBD Relacionales, los hay de todos los colores. Aunque si sabes SQL podrás manejarte con cualquiera de ellos.

Al usar una nosql estamos renunciando a un montón de funcionalidades. Todo aquel que haya trabajado a un nivel un poco avanzado con bases de datos relacionales será consciente de que hacer una consulta SQL tiene por qué se trivial: cuentas con un montón de posibilidades y hay que encontrar la mejor. Tenemos joins (unir tablas en base a relaciones entre ellas), conjuntos de datos (group by), un completo manejo de fechas (intervalos, sumas, restas, comparaciones…), integridad de los datos, transacciones, excepciones… un sin fin de posibilidades. Tarde o temprano te tocará hacer algo más que leer y escribir datos, y esa tarea la tendrá que hacer tu aplicación (java, php…). En ese momento, justo en ese momento la eficiencia de tu programa caerá por los suelos y todos los milisegundos que has creído ganar te están saliendo caros. Muy caros. Imagina una web donde quieras consultar un trayecto para un día concreto, a unas determinadas horas y que el tren (o lo que sea) pase por unas determinadas estaciones. Hacerlo con una nosql sería realmente doloroso y totalmente inviable.

También existen detalles más concretos como el que voy a comentar. Las nosql no proporcionan ninguna garantía ACID. Por decirlo de manera simple, un sistema ACID cuando dice que un dato se ha guardado, se ha guardado. Ya pueden pasar cualquier cosa que no vas a perder esa información. En cambio, las nosql te pueden decir que ya han guardado el dato pero todavía lo tienen por ahí en memoria de manera temporal y si en ese momento pasa algo “extraño” (se va la luz y el ordenador para, por ejemplo) el dato puede que no se haya guardado (aunque tu pienses que si porque te lo ha “asegurado”) y en ese caso habrás perdido ese dato para siempre. Alguno pensará que esto es una chuminada pero ya me dirás que pasa si surge algún problema de este tipo cuando te ingresen la nómina

Otro tema realmente importante es la integridad de los datos. Esto viene a ser que la información que hay en la base de datos sea útil y verídica. Por ponernos en situación, imagina que tienes una base de datos con autores y libros que han escrito.  En un determinado momento, borras a un autor pero sus libros quedan en la base de datos. ¿A quién pertenecerán ahora esos libros? Tenemos datos que no nos son útiles, sabemos que existen pero… hay muchas lagunas. Otro caso parecido es intentar meter un libro sin indicar su autor. Podemos exigir que todo libro tenga su autor a la hora de insertarlos pero nada nos permitiría saltarnos esta “restricción” en una nosql. Todo esto queda delegado a la aplicación, con todos los inconvenientes que trae. Una buena base de datos es aquella que vela por su integridad. Si unos datos no son fiables, esa información no vale nada. Los datos lo son todo en una base de datos.

Por supuesto no estoy diciendo que las nosql son algo que se debería quemar o guardar en un cajón ni mucho menos. Se diseñaron con un objetivo en mente y la verdad es que lo cumplen muy bien. Este objetivo es el que dije al principio y es insertar muchos datos y acceder a ellos muy rápido, y estos datos no deben ser complejos. Facebook o Twitter dicen que utilizan Cassandra (una base de datos tipo “nosql”) y es normal, ahora te explico. Twitter consiste en insertar mensajes y ver los últimos. Por así decirlo, vas metiendo en un cubo cientos de mensajes y lo único que haces es “ver” los que están por encima. Este es un caso donde una nosql sería lo óptimo. No hay relaciones complejas y el orden viene definido por el orden de inserción (recordemos que ordenar es de las tareas más duras en informática). En Facebook es algo diferente. No puedo decirlo a ciencia cierta, pero aseguraría que no usan (ni tienen pensado hacerlo) una nosql para toda su base de datos. Los casos ideales es en sitios como el muro o comentarios de fotos. El motivo es lo mismo que en caso de twitter. Para el resto, no me cabe la menor duda de que usan algun tipo de base de datos relacional.

Son bastantes diferentes entre sí pero genéricamente se les puede llamar "nosql"

Tarde o temprano se hace alguna relación entre los datos y si esa relación la gestiona el SGBD mucho mejor que manejarlo nosotros a mano. Sinceramente, no me imagino a Facebook haciendo 3 o 4 consultas y luego desde php comprobar las coincidencias para buscar “amigos en común” (de listas enormes). O la alternativa, que sería un trabajo mínimo en php pero una cantidad de consultas exponencial (ambas opciones son totalmente inviables). La única opción donde tendría alguna posibilidad es mediante de la redundancia de datos. Pero la redundancia sería tal que el tamaño de la base de datos sería monstruoso, y toda la velocidad que ganas por ser más rápida podrías perderla por la “distancia” tan grande que tocaría recorrer.

Sin embargo, todas estas limitaciones de las nosql tienen otras ventajas (además de la velocidad). Estas bases de datos son excelentes para sistemas distribuidos y ahora que todo tiende a ponerse “en la nube” se pueden aprovechar desde ese punto de vista. Eso es lo que hace que google ofrezca BigTable en AppEngine (un servicio de hosting). Sin despeintarte puedes tener funcionando un sistema distribuido en tantos nodos como quieras. Esta tarea es bastante más compljea en una db relacional, precisamente por el tema de las relaciones.

Podría simplificar todo esto en una frase: La diferencia entre una db relacional y una nosql es como aquel que le quita los asientos a su coche para que corra más. Correrá más, pero pierdes prestaciones.

Aunque más bien lo relacionaría las churras y las merinas. Se parecen pero son muy diferentes. Pues lo mismo con db relacionales y “nosql”, las dos “guardan datos” pero su finalidad es muy diferente. Y como siempre, queda a criterio del diseñador usar una herramienta u otra (o las dos a la vez).

Para terminar, muchos pensarán que he escogido ejemplos concretos para intentar “machacar” a las nosql. Es cierto, y el motivo es para dar a entender que una base de datos nosql no puede sutituir a una base de datos relacional si lo que tenemos son datos altamente relacionados entre sí. No existen productos milagrosos, todo tiene sus contras. No existe (ni existirá) un sistema gestor de bases de datos (ni ningún software ni cosa en el mundo) que se comporte a la perfección en cualquier situación.

Un saludo y espero que alguien esté es desacuerdo, para así debatir y enriquecer el post un poco

Entradas relacionadas.

¿Qué es XMPP y por qué usar XMPP?

Es un protocolo. Como a muchos eso os dejará igual voy a tratar de explicar que es esto y te darás cuenta del por qué es necesario que sea libre.

En informática un protocolo son una serie de normas para que dos máquinas sean capaces de entenderse. Esto nos da la posibilidad de que dos (o más) máquinas (o programas dentro de una máquina) puedan compartir información, dialogar entre ellas, discutir y llegar a acuerdos, etc. Sí, las máquinas hablan entre ellas, y mucho. Son unas cotorras de tomo y lomo lo que pasa es que no nos damos cuenta. Nosotros sólo vemos el resultado de toda era “burocracia” entre máquinas. Aquellos que nos siguen desde hace bastante igual se acuerdan de la dramatización que hicimos sobre el protocolo DNS, pues esto es igual. Cuando dos máquinas conocen el protocolo son capaces de trabajar conjuntamente pero si una usa un protocolo extraño pues le costará encontrar otras máquinas con la que trabajar. Un símil entre protocolo y cerrado y abierto con la realidad sería el siguiente. Quieres aprender un idioma, vas a una academia donde te dan unas clases pero tienes la posibilidad de ir a la biblioteca pública y coger libros para aprenderlo mejor. También puedes buscar por internet e incluso preguntar a gente que gustosamente te ayudará (siempre y cuando no seas muy cansino claro ). En resumidas cuentas, nadie te pondrá trabas a que aprendas ese idioma.

En cambio, si quieres aprender un idioma pero para conocerlo tienes que entrar en una secta y no hay ningún libro ni persona fuera de esa secta que habla sobre el idioma pues lo vas a tener bastante complicado. Esto equivale a un protocolo cerrado.

Quizá te ronda por la cabeza que ¿Quién en su sano juicio querría usar un protocolo cerrado? Pues en su sano juicio supongo que muy pocos pero el problema es que los usamos sin saberlo (la ignorancia, ese gran arma de los “poderosos”). Como estamos hablando de protocolos de mensajería instantánea os voy a poner un ejemplo de este tipo que seguro que conoces: MSN Messenger. Es un protocolo cerrado y sucio. También si te hablo de uno que usa XMPP igual te suena, GTalk. Podría iniciar un flame war diciendo lo malos que son los de Microsoft y lo bien que me caen los de Google pero eso ya para otro día.

Una duda que puede surgir es que si el protocolo de MSN Messenger es cerrado, ¿Cómo hay tantos programas libres ajenos a la secta que lo “entienden”? En informática esto se llama ingeniería inversa. Consiste en capturar mensajes y volver a enviarlo. observar qué pasa y al cabo de muchas horas ir comprendiendo cómo funciona. Un símil sería como irte a china sin saber nada de chino. Con el tiempo acabarás aprendiendo el idioma (que remedio) relacionando palabras que dicen con acciones que hacen luego. Nunca aprenderás chino como si te explicaran la gramática y todo eso, pero acabarás aprendiendo lo suficiente como para manejarte. Y con el ejemplo de la secta, como un día se le ocurra cambiar cosas del idioma nos han fastidiado. Nos toca volver a hacer todo el trabajo.

Requiere de mucho más tiempo comprender un protocolo de esos que hacer un programa que use el protocolo. De ahí que sea tan importante que el protocolo sea libre, que a nadie le gusta perder el tiempo.

Todo esto de poner facilidades para que los demás te entiendan puede llevar a otra cuestión. ¿Y si no quiero que nadie sepa lo que estoy comunicando? Por ejemplo, yo no quiero que sepan lo que hablo con la gente. Me alegra que me hagas esa pregunta
Eso no forma parte del protocolo sino del canal. No voy a explicarlo porque no viene a cuento pero la solución es usar un canal seguro que en resumidas cuentas en cifrar la información. He de decir que el que un protocolo sea cerrado no es sinónimo (ni mucho menos) de seguridad. La información viaja intacta. Mientras el protocolo cerrado de microsoft es totalmente inseguro (ya que no va cifrado) el xmpp siendo libre es totalmente seguro ya que sí va cifrado. Esto lo demostramos un día cuando crackeamos nuestro wifi y sabíamos lo que hablaba por el messenger. Eso con xmpp no hubiera sido posible (cuantas referencias estoy haciendo hoy). Creo que han quedado explicados los puntos “Qué es” y “Por qué usarlo”. Pasemos a centrarnos en XMPP.

Cómo funciona XMPP

XMPP funciona a base de enviar XML. XML es una manera estándar de enviar información y que a día de hoy está hasta en la sopa aunque, de nuevo, no nos demos cuenta. Por ejemplo, el HTML (lo de las páginas web) es XML. Voy a explicar brevemente como va esto del XML (es realmente sencillo)

<cosa atributo1=valor1>Cotenido</cosa>

la palabra “cosa” se denomina tag e indica el tipo de elemento que es. El resto de campos son bastantes intuitivos. Un ejemplo real de mensaje XMPP sería el siguiente

<message from="maxpowel@wixet.com" to="prueba@wixet.com">Ey tío que pasaaaa</message>

Sobra explicarlo pero esto envía un mensaje de maxpowel@wixet.com a prueba@wixet.com con el contenido “Ey tío que pasaaa”

En XMPP existen 3 tipos de elementos diferentes: message, presence e iq
Message: Son los mensajes que se envían los usuarios entre sí.
Presence: Los eventos de presencia de usuarios. Cuando se desconectan o conectan, cuando cambian de estado, de nombre….
Iq: Sirve para enviar comandos internos. Por ejemplo para iniciar una nueva conexión, informar de errores y cosas que no tienen nada que ver con los usuarios.

Pero antes de poder conectarte te tienes que conectar, verdad? Eso se hace al principio (qué listo) y en este proceso el cliente y el servidor negocian a través del protocolo cómo se sincronizarán, el cifrado que usarán y todas esas cosas.

En el título comentaba algo de BOSH. Eso de BOSH es una pasarela para poder establecer una conexión a un servidor XMPP desde HTTP. Esto es necesario por lo siguiente.
XMPP es una conexión persistente. Se mantiene la conexión desde el principio hasta el final, y mientras se envían todos los mensajes que quieran.
HTTP es una conexión de petición y respuesta. Esto es que tu te conectas y haces una petición. El servidor responde y se termina la conexión.

Con este método haces una petición y estas a la espera de que el servidor responda y en ese momento lanzas otra. Hay otro método (polling) que consiste en enviar muchas peticiones cortitas (cada medio segundo por ejemplo) pero personalmente prefiero la primera.
Esta tarea requiere de una pequeña sincronización. Esta sincronización se hace mediante un numerito que le pasamos en cada petición y que se debe ir incrementando después de cada respuesta NO vacía, luego explico que es eso.

Siempre debemos tener una conexión abierta hacia el servidor. Podemos conectarnos al servidor de dos maneras:
Enviando una petición nuestra (por ejemplo queremos enviar un mensaje a un contacto) o escuchando (nos quedamos escuchando al servidor hasta que nos diga algo).
Sólo podemos tener dos conexiones abiertas y en caso de abrir una tercera o un numero de sincronización incrementado incorrectamente provocada que finalice la sesión (el servidor nos llama violadores y nos manda a paseo).
Voy a explicar qué es un mensaje vacío y la relación que tiene con el número de sincronización. El numerito en cuestión se llama RID y debe ser generado de manera aleatoria. Es importante tener un buen algoritmo que genere un número lo más difícil posible de precedir ya que teniendo el RID junto al SID (un numero que identifica la conexión y se crea en ese momento) alguien podría hacerse pasar por nosotros ya que si envias un SID y un RID correcto la cosa va a funcionar (al ser por HTTP el servidor no tiene manera de conocer de dónde viene la petición). Describo un ejemplo.

Inicio sesión y estoy a la escucha de un mensaje del servidor. Estoy usando una conexión.
Decido que a mi amigo “Prueba” quiero saludarle así que le escribo “Hola”. Esto genera un objeto message que se envía al servidor. En este instante estoy usando dos conexiones. Si se me ocurre enviar otra cosa el servidor nos cerrará sesión y adiós muy buenas. Lo que se debe hacer en este momento es cerrar la primera conexión, que devolverá un mensaje vacío. Entonces NO tenemos que incrementar el RID.
Nuestro amigo Prueba nos responde diciendo “Eyyyy” y el servidor nos lo hace saber, creando un message y a través de la conexión creada nos lo envía. Como dije antes, en HTTP una vez recibida la respuesta se finaliza la conexión. En este momento debemos lanzar una petición para escuchar pero como sí recibimos un mensaje incrementamos el RID. Si no lo hacemos ya sabes lo que pasa. Remarco que mensaje no es lo mismo que message. Message es un tipo de mensaje como también lo es presence o iq.

Esa es la parte complicadilla. Conceptualmente no es complejo ni mucho menos pero crear un algoritmo pues ya tiene algo de tela. Si os interesa saber más hice un plugin jQuery (en javascript) y que en apenas 200 líneas es capaz de manejar ese protocolo y facilitar manejadores de eventos. Puedes ver un poco de documentación en

1. Como configurar Google Talk en pidgin Pidgin, para el que no lo conozca, es un cliente...

Primero quiero venderos la moto diciendo el por qué usar pdns. Como muchos otros, yo también he luchado con BIND (el servidor dns por excelencia) y al principio era un poco reacio a cambiar simplmente por “con lo que me ha costado controlar BIND ahora me cambio?”. Sí, todos los cambios son dolorosos (y más cuando te ha costado tanto aprender a usar algo) pero creedme si os digo que merece la pena al 100%.

El principal problema de uso que le veo a BIND es la extrema dificultad de configuración. Para un experto, con el paso de tiempo se familiariza con todos esos archivos de configuración que ademas de ser muchos son complejos. Cuántas horas gastadas porque faltaba un punto y coma y cosas así…. eso descontando las horas gastadas para aprender el formato de sus archivos de configuración.

Con pdns para añadir un dominio no tendras mas que logearte, pinchar en añadir dominio y ya está!!! Funcionando!! Cuando lo probé por primera vez no me lo creía, tenía que ser un sueño o algo así (acostumbrado a tardar unos minutos en añadir un dominio y recargando el servicio y… que pereza).

Necesitaremos mysql, apache y php para tenerlo todo a funcionando. Yo voy a suponer que ese software ya esta instalado, solo queda el servidor dns.

aptitude install pdns-server pdns-backend-mysql pdns-recursor

Creamos la base de datos, en este caso usare el usuario root

mysql -u root -p

create database pdns;

pdns sera el nombre de la base de datos, puedes poner cualquiera.
Ahora importamos el esquema de la base de base de datos.

mysql -u root -p pdns < /usr/share/doc/pdns-backend-mysql/mysql.sql

Ahora hay que configurar un poquillo a pdns, pero solo un poco.
Editamos el archivo /etc/powerdns/pdns.conf y buscamos una linea donde pone lauch= que esta comentada, entonces debajo insertamos

launch=gmysql

gmysql-host=localhost
gmysql-port=3306
gmysql-dbname=pdns
gmysql-user=root
gmysql-password=rootpass

Cambiado los datos por los tuyos (dbname,user y password practicamente).
Ahora buscamos una linea donde ponga “local-address” y ahí ponemos nuestra ip pública. Muy importante es editar en el mismo archivo “out-of-zone-additional-processing”, que aparece como comentado, ponerlo en “yes” y buscar la linea “recursor” y ponerle “127.0.0.1″. Esto es porque tenemos los dos servicios en la misma máquina, hay quienes dicen que es mejor ponerlos en máquinas diferentes pero yo de momento no voy muy sobrado de servidores jeje. En caso de que tengas hayas instalado pdns-recursor en otra máquina pues pones esa ip.
Entonces, después de lo de mysql la cosa queda así

local-address=ip_publica

out-of-zone-additional-processing=yes

recursor=127.0.0.1

Bien, powerdns ya está configurado así que lo reiniciamos.

/etc/init.d/pdns restart
/etc/init.d/pdns-recursor restart

Para comprobar que esta funcionando probamos a hacer un telnet:

telnet ipdelamaquina 53

y si conecta ya está funcionando!! Si por el contrario nos dice connection refused algo hemos hecho mal…
Ahora bajamos la aplicación web, pdnsadmin desde aquí

http://pdnsadmin.iguanadons.net/index.php?a=files&s=download&cid=3&fid=7

Lo descomprimimos en un directorio accesible por apache (normalmente /var/www) y listo. Lo ideal es crear un servidor virtual solo para eso pero eso ya según vea cada uno.
Ahora entramos desde el navegador y tiene que aparecer algo así:
Esto es el instalador. Damos a continuar.
Nos dirá que demos permisos de escritura a packages y skins. Se los damos y tambien a settings.php
En el siguiente formulario, en master ip ponemos la ip pública. Los nameserver no hace falta ponerlos.
Después de esto ya está! La interfaz es muy intuitiva “Add domain”, “Add subdomain”….
Ahora puedes servir tanto dominios locales como de internet, si pones como servidor DNS a tu máquina será tu servidor quien controle ese dominio. Venga, a disfrutar!

Entradas relacionadas.

Hay mucho criminal que viola y se aprovecha vilmente de las licencias libres. Todos esos criminales (ya sean personas o empresas) merecen toda nuestra repugna. A parte del tema legal que supone violar una licencia libre (que parece no importar a casi nadie a menos que haya billetes de por medio) es más despreciable el cómo se aprovechan y se ríen de la comunidad, que trabaja en un proyecto con su mejor intención para que luego vengan cuatro listillos y… bueno, me voy a cortar la lengua que si no… Aquí dejo el enlace a la lista.

http://ffmpeg.org/shame.html

Por suerte no uso ningún software de la lista pero en el caso de usar alguno, sin duda buscaría una alternativa a dicho software.

Entradas relacionadas:

1. AMD libera el código 3D de los chips gráficos R600 y R700 Por menéame me he enterado de esta buena noticia y...
2. Compiz sigue vivo y coleando A finales del 2008 empezaron a salir algunos folks de...