Find out what I'm doing, Follow Me :)

Free Software Song… hackers, you’ll be free

La Free Software Song («Canción del Software Libre») es una canción filk escrita por Richard M. Stallman que tiene como tema el software libre. La canción está fijada a la melodía del tema folk búlgaro Sadi Moma.

Letra

Join us now and share the software:
you’ll be free, hackers, you’ll be free;
join us now and share the software:
you’ll be free, hackers, you’ll be free.

Hoarders may get piles of money
(that is true, hackers, that is true);
but they cannot help their neighbors
(that’s not good, hackers, that’s not good).
When we have enough free software
at our call, hackers, at our call,
we’ll throw out those dirty licenses
ever more, hackers, ever more.
Join us now and share the software:
you’ll be free, hackers, you’ll be free;
join us now and share the software:
you’ll be free, hackers, you’ll be free.

Traducción al castellano

(Español Latinoamericano)
Unánsenos ahora y compartan el software
serán libres, hackers, serán libres;
unánsenos ahora y compartan el software:
serán libres, hackers, serán libres.
Los avaros pueden conseguir montones de dinero
(eso es cierto, hackers, eso es cierto);
pero no pueden ayudar a sus vecinos
(eso no es bueno, hackers, eso no es bueno).
Cuando tengamos suficiente software libre
a nuestra disposición, hackers, a nuestra disposición,
tiraremos esas sucias licencias
para siempre, hackers, para siempre.
Unánsenos ahora y compartan el software:
serán libres, hackers, serán libres;
unánsenos ahora y compartan el software:
serán libres, hackers, serán libres.

Traducción al castellano

(Español Ibérico)
Uníos a nosotros y compartid el software:
seréis libres, hackers, seréis libres;
uníos a nosotros y compartid el software:
seréis libres, hackers, seréis libres.
Los avaros pueden conseguir montones de dinero
(eso es verdad, hackers, eso es verdad);
pero no pueden ayudar a sus vecinos
(eso no es bueno, hackers, eso no es bueno).
Cuando tengamos suficiente software libre
a nuestra disposición, hackers, a nuestra disposición,
nos cargaremos esas sucias licencias
para siempre, hackers, para siempre.
Uníos a nosotros y compartid el software:
seréis libres, hackers, seréis libres;
uníos a nosotros y compartid el software:
seréis libres, hackers, seréis libres.
Fuente: Wikipedia
icon for podpress  Free Software Song - Richard Stallman (Capella): Download
icon for podpress  Free Software Song - Versión de Fester (Funky): Download
icon for podpress  Free Software Song - Versión Jono Bacon (Metal) : Download

Google libera VP8


Se ha confirmado en la conferencia Google I/O: VP8 es libre. No sólo se anunciado esta liberación del códec, sino que también varias entidades han mostrado su respaldo a VP8.

El primero en hacerlo ha sido el propio Google, anunciando que todos los vídeos de YouTube estarán disponibles codificados con VP8. La causa de esta decisión es el ancho de banda ahorrado con este códec, que recordemos que con la misma calidad que H.264, ocupa hasta un 50% menos.

Opera también ha dado su respaldo al códec VP8 con la presencia de su CTO (Chief Technology Officer) en el evento, que ha mostrado cómo su navegador ya soporta a la perfección la reproducción de vídeo con este códec. También Mozilla ha anunciado soporte para VP8 al poco de conocerse la liberación, y, al igual que Chromium, ya están disponibles nightly builds que funcionan con VP8.

Además de estos, otra empresa muy grande apoyará VP8: Adobe. Su CTO, Kevin Lynch, ha anunciado que las aplicaciones Adobe soportarán este códec junto con el resto del estándar HTML5. En estas aplicaciones se incluye también Flash, que de esta manera trata de evitar quedarse atrás con respecto a las aplicaciones que usen HTML5. Otras empresas también han expresado su apoyo al códec de Google, tales como Skype, Logitech, Nvidia, Qualcomm o Texas Instruments.

El formato de archivos de vídeo resultantes será WebM, que contendrá el vídeo codificado con VP8 y el audio con Vorbis. La licencia es similar a la BSD, con todo el código libre. Además, Google ha creado el WebM Project, para formar una comunidad alrededor de este códec y proporcionar varios recursos a los desarrolladores y usuarios: codificadores, código del códec, documentación, SDKs…

¿Qué podemos esperar de esto? ¿Qué códec de vídeo se impondrá en la web? Mirémoslo desde varios puntos. Por ejemplo, desde la perspectiva de los desarolladores web. Firefox, Chrome y Opera acaparan el 40% de usuarios de Internet, un porcentaje muy importante. Además, VP8 proporciona más facilidades y herramientas para codificar que H.264. Sumando esto al hecho de que además es software libre y no hay problemas de licencias, parece claro que los desarrolladores web optarán por VP8.

Si cambiamos a la perspectiva de los navegadores, todo se reduce a un argumento muy simple: YouTube. Este portal de vídeo acapara, según Alexa, el 25% de todo el tráfico de Internet, y se podría decir que todos los usuarios ven vídeos de YouTube como mínimo una vez a la semana. Un navegador que no soportase vídeos de YouTube no sería muy cómodo para los usuarios, que cambiarían a otras alternativas rápidamente.

Todo esto que expongo aquí son extremos. Es poco probable que YouTube sólo muestre vídeos con VP8, y algunos desarolladores codificarán con lo primero que tengan sin preocuparse en excesivo por el formato. Por lo tanto, creo que lo que vamos a ver a partir de ahora será una batalla entre los dos códecs muy igualada, aunque desde mi punto de vista VP8 se acabará imponiendo porque da más facilidades a los desarolladores y usuarios de aplicaciones relacionadas con el vídeo, es gratuito y libre, y porque cuenta con el apoyo de un gran número de empresas importantes del sector de la informática.

Más información | Mozilla Blog
Más información | Chromium Blog
Más información | WebM Project Blog
Sitio Oficial | WebM Project

The Linux Command Line

The Linux Command Line es un libro, escrito por William E. Shotts Jr., que aglutina en sus 522 páginas todo el material publicado en LinuxCommand.org, pero con mayor detalle.

En el libro se recogen variados temas relacionados con la línea de comandos, desde una introducción para los que desconozcan totalmente su uso, hasta avanzados shell scripts con los que tomar el control de cualquier máquina.

Lo mejor de todo es que The Linux Command Line está disponible para descargar gratuitamente en formato PDF y bajo una licencia Creative Commons.

Cómo la vibración y el ruido afectan el rendimiento de discos duros


Quién no ha echado maldiciones por el ruido que provocan algunos discos duros en pleno funcionamiento? Pues yo sí, y seguro que muchos de Uds. también, pero sepan que el ruido no sólo afecta al usuario sino también al mismo dispositivo. Pero claro, no a nivel hogareño que con suerte tendremos dos discos duros (en otros casos unos cuantos más), sino en el área de servidores en donde deben tener racks con muchos HDDs (Hard Disk Drive).


Resulta que las vibraciones que provocan tal cantidad de discos girando incesantemente a la vez en un rack provocan problemas de rendimiento graves en estos aparatos.
En palabras didácticas de Hitachi, el gigante fabricante de discos duros (traducción libre):
"Uno de los mayores problemas de rendimiento para los discos duros es la vibración. Tal como una aguja en un disco de vinilo, el cabezal del disco debe seguir una delgada pista de datos para poder leer (o escribir) información.
Perturbaciones físicas pueden lanzar el cabezal fuera de la pista y causar un retardo mientras el actuador se reposiciona. En discos duros modernos, balanceados, la vibración normal no lo afecta en absoluto, sin embargo, el movimiento circular y la vibración rotacional (como podría ser en un rack de discos muy grandes) puede causar serias interrupciones en el funcionamiento. La caída de rendimiento en estos casos puede ser enorme."
Pero se está trabajando para solucionar esto. En un estudio realizado por Julian Turner, los racks normales fueron reemplazados por uno realizado de fibra de carbono especializada, el AVR-1000, diseñado para disipar las vibraciones de un amplio rango de frecuencias y las conclusiones fueron elocuentes, el incremento del rendimiento en la lectura aleatoria aumentó entre un 56 a 246% y un 34 a 88% en las escrituras aleatorias. Las lecturas y escrituras secuenciales, eso sí, tuvieron un incremento bastante menor.

Parece buena hora para que los discos SSD (solid state drive) se masifiquen.

Ya lo saben, jamás le griten a sus discos rígidos porque pueden desatar su furia y tirarse a huelga, tal como lo hacen los del video a continuación:

Flash vs HTML5



En una esquina se encuentra HTML5 apoyado por Apple y en la otra FLASH  muy conocido por todos. En la actual pelea entre HTML5 y Flash, mucho se ha dicho acerca de las ventajas y desventajas de cada una de las tecnologías, siendo uno de los argumentos más recurrentes en contra de Flash el hecho de que usa muchos recursos de la CPU para ejecutarse, mostrando un pobre desempeño, lo que motiva a muchos a darle su apoyo al nuevo estándar HTML5.

Para salir de esta duda y basarnos en algo un poco más técnico que en la desordenada opinión de los usuarios respecto a su experiencia con cada una de las implementaciones, Jan Ozer, especialista en tecnologías de video y autor de 13 libros al respecto, puso a prueba a Flash contra HTML5 haciendo uso del códec H.264 en plataformas Mac y Windows, en diferentes navegadores cada uno. Vamos por parte.


failappleadobeEn OS X Snow Leopard se muestra la cara más fea de Flash, puesto que en un MacBook Pro Core 2 Duo a 3.06GHz y 8GB de RAM, en Google Chrome tanto Flash como HTML5 fueron igual de malos, usando cerca de un 50% de carga en la CPU. En Safari la cosa se pone mejor para HTML5, que consume un 12.39% de la CPU, mientras que Flash 10.0 un 37.41% y la versión 10.1 usa 32.07% de los recursos. En Firefox los porcentajes en Flash rondan el 40% de uso en procesador, sin tener pruebas en HTML5 pues este navegador no puede hacer uso del códec H.264.

Por otro lado, Flash se comportó mejor en una plataforma con Windows 7 que incluso era menos potente que la de Mac: un Core 2 Duo a 2.2GHz y 2GB de RAM. Safari en Flash 10.0 usó un 23.22% de CPU, y acá afírmense, pues la versión 10.1 de Flash consumió solamente un 7.43% de procesador. Safari en Windows no corrió video en HTML5, por lo que no hay comparación al respecto.

Sin embargo, a la hora de hacer comparaciones entre HTML5 y Flash, bajo Google Chrome Flash Player 10.0 es un 24% más eficiente que HTML5, mientras que Flash 10.1 es mejor que HTML5 en un 58%.
Por otro lado, y para seguir alardeando frente a OS X, en Firefox Flash 10.0 usa en 22% de la CPU, mientras que en Flash 10.1 este consumo baja drásticamente hasta el 6%. Caso parecido es el de Internet Explorer 8, donde esta diferencia va desde un 22.41% en 10.1 cayendo al 14.62% en Flash usando su versión más reciente. Ninguno de los dos navegadores reproduce video HTML5.

¿Conclusiones de estos resultados? Primero, sólamente en OS X y bajo Safari HTML5 rinde mejor que Flash, mientras que en el resto de los escenarios, incluyendo Windows, ambos se igualan o derechamente Flash derrota a HTML5, tanto en su versión 10.0 como por paliza en 10.1, así que la inclusión del nuevo estándar HTML5 para usuarios de Windows no parece ser tan escandalosamente necesaria.

Sin embargo, es en Mac OS X donde el problema se ve grave, pues el desempeño de Flash deja muchísimo que desear mientras que la nueva versión de Flash mejora notablemente el rendimiento del plugin en Windows, y eso es debido a que se integró la aceleración por hardware para Flash usando la GPU, cosa que en OS X no es posible hacer, pues Adobe alega que Apple no facilita el acceso a las APIs que se requieren para desarrollar esta tecnología en Mac, así que mientras Apple no deje a Adobe implementar esto, Flash andará mal, pues no hay acceso al hardware para que el plugin no sea totalmente dependiente de la CPU.

Pero la pelea entre Apple y Adobe es grande, y con un Steve Jobs que derechamente odia a Flash, no se ve mucha luz al final del túnel para los usuarios de OS X, mientras que por otro lado, HTML5 no parece mostrar méritos para convertirse en un digno reemplazante para Flash, excepto en Mac, donde el peso de no tener aceleración por hardware es demasiado, mientras que en Windows y usando la versión 10.1 de Flash, el tema es pan comido.

Fuente: CHW

Desaparecer en la era de las Comunicaciones.


En la era de las comunicaciones, donde un click pone al descubierto la vida privada de muchos de nosotros. Donde se transmiten miles de megas de información por segundo. Una era en la cual estamos hiperconectados, con los amigos, los compañeros de trabajo, la familia. Donde basta prender la PC (máquina sin la cual ya no concebimos nuestra vida) para leer los diarios del mundo, estar al día de la información que uno desea. La computadora es casi el centro de nuestra vida.(es mi caso) Nuestro entretenimiento, nuestras relaciones sociales, nuestro trabajo, todo pasa por el monitor.

Pero esto no es todo. Muchas veces, sin percatarnos de ello, dejamos rastros digitales que nos convierten en seres totalmente “ubicables“. Sí, así es. Cuando compramos un libro  o algo mas y lo pagamos con tarjeta de crédito dejamos un rastro. Aunque no lo crean, emitimos una señal fácilmente rastreable. Muchos sabrán que un celular encendido es un celular sobre el cual se conoce su ubicación.

Ahora bien, todo esto nos inclina a preguntarnos, ¿puede uno desaparecer en este mundo sin dejar rastro? ¿cómo seria desaparecerse durante un tiempo? ¿podríamos huir con la finalidad de borrar nuestro pasado y escribir una nueva vida? es decir, ¿desparecer en un lado y volver a empezar en otro?

¿Les suena remota la idea de escaparse y empezar de nuevo? No es algo que sucede tan esporádicamente como podríamos pensar. En EE.UU, según las autoridades policiales, desaparecieron en 2007 casi 200 personas de más de 18 años. Pero esta cifra representa apenas una fracción de los desaparecidos voluntarios, mucha gente no da aviso a las autoridades.Según un estudio realizado en el Reino Unido, en 2003, dos tercios de los adultos desaparecidos lo hicieron deliberadamente. En nuestro pais (Nicaragua) el indice de personas desaparecidas se mantiene a 10 personas por semana segun datos de la policia Nacional.

Pero como dije más arriba, aunque quisiéramos desaparecer, debemos tener en cuenta que en este mundo en el que vivimos, estamos dejando una suerte de “pistas digitales” a cada movimiento. Sino, piensen en la cantidad de información que deliberada y voluntariamente dejamos en las redes sociales.

Es por esto que los que cuentan con una verdadera ventaja son los investigadores privados quienes pueden usar las bases de datos gubernamentales y privadas con referencias cruzadas, valerse sin esfuerzo de la distribución pública de la información por internet y por televisión e investigar archivos corporativos para encontrar a su presa sin moverse de su escritorio.

 
A Evan Ratliff, un periodista de la revista Wired, le fascinó la idea de desaparecer y desafiar a sus lectores a que lo encuentren. Él planeó dejar su vida cotidiana durante 30 días, sin abandonar los EE.UU, sin decirle ni a su familia, ni más íntimos amigos, ni a su editor, dónde estaría.

Además, Evan prometió conectarse regularmente a internet: chequear su correo, conectarse a Facebook, Twitter, etc. Además, continuaría frecuentando los lugares que a él le gustan, no se escondería en una cabaña en la montaña.

Evan tuvo 24 horas “de gracia” para huir. La revista Wired publicó información periódicamente sobre el “fugitivo”.

Quién lo encuentre debía decir una palabra clave (Fluke), acto seguido Evan se pondría en contacto con su editor, a quién le diría otra palabra clave (que sólo sabían ellos dos) y esa sería la contraseña para indicar que el juego había terminado.

El premio para quien lo encontrara antes de los 30 días de su partida era de U$S 5.000. Cualquiera podía participar de la cacería. Toda la idea, el dinero para llevarla adelante y parte del premio, fueron aportados por el mismo Evan.

Fue así como empezó su maratón de 27 días (como podrán adivinar, resultó capturado) este periodista de San Francisco. Huyendo de la ciudad donde tenía su vida entera, en auto, zigzagueando se fue camino a Las Vegas.

Pero antes de cualquier cosa, preparó cuidadosamente su huida: se dejó crecer el pelo y la barba para cortarlos a gusto; recolectó información acerca de software que le permita esconder los datos que deja por la red (ninguno es infalible); aprendió que usar gift cards, le permiten comprar por internet sin poder ser rastreadas; además, armó un sin fin de cuentas de correo electrónico y un perfil falso en Facebook y en Twitter.

Una vez en Las Vegas ya tenía alquilada una oficina, la cual le sirvió para instalar 2 notebooks. Éstas fueron controladas a distancia por Evan en el resto del viaje, la idea era despistar a sus seguidores. Además, también instaló una cámara web para monitorear cualquier actividad que puediera haber.

Como se podrán imaginar la idea de Evan no era permanecer en ese lugar. Se movilizó bastante. Para evitar dejar rastro (o para dejarlo lo menos posible) utilizó el bus de larga distancia. Un medio de transporte poco usado en EE.UU y que no tiene los controles que suelen tener los aeropuertos.

Cuando la gente se enteró del concurso, cientos de personas comenzaron a participar. Profesionales del rastreo de personas, aficionados, estudiantes, etc. Todo tipo de personas, todo tipo de métodos, todo tipo de afanes. Algunos deseosos de hallar a la inteligente presa, otros, seducidos por el premio.

En Twitter se nuclearon bajo la etiqueta #vanish (el nombre del espacio de Ratliff en la revista Wired), también se crearon sitios webs, blogs, flyers, e incluso una línea telefónica para colaborar con pistas. Un programador de St. Louis abrió un grupo en Facebook (La búsqueda de Evan Ratliff), él cual en una semana llegó casi a los seis mil miembros.

Por otro lado, desde las oficinas de Wired se empezó a divulgar información sobre las cuentas de Evan en un blog. Con esos datos y unas pocas llamadas legales, se obtuvo gran cantidad de información.

Además, sus perseguidores investigaron fotos de Evan en Flickr; utilizaron software para extraer información sobre la cámara utilizada y para buscar otras fotos tomadas como ésas.

Así fue como en pocos días se supo que Evan era un fanático del fútbol e hincha del Fulham inglés. Que era celíaco, que había comprado un departamento en Brooklyn con su novia (e incluso del contrato obtuvieron y difundieron una imagen de su firma).

Espontáneamente surgió una comunidad inmensa y organizada que, sin dejar un espacio por revisar, rastrearon a Evan hasta que pudieron encontrarlo.

Dos semanas después de que se inició el concurso, Jeff Reifman, un ex gerente de equipos de programación de Microsoft, creó VanishTeam, una aplicación de Facebook dedicada a reunir información y a discutir sobre Ratliff.

Al principio no tuvo mucho éxito, así que Reifman, la modificó agregándole algunas líneas de código, a fin de utilizarla para rastrear a Evan a través de su IP, pero ¿cómo podría dar esto resultado si Evan ocultaba su dirección con una aplicación para éstos fines?

Lo que Reifman buscaba era la dirección de IP de quiénes se conectaban a su aplicación. Así con mucha paciencia y sapiencia (y un poco de suerte), lograría encontrar a Evan si éste entraba a VanishTeam (Aclaro que Evan armó una cuenta de Facebook, la cual tendría muy pocos amigos, esto es lo que buscaba Reifman).
Evan mordió el anzuelo, había entrado a VanishTeam con su cuenta falsa de Facebook: James Donal Gatz. Reifman trató por todos los medios de ponerse en contacto con los amigos de Gatz para que le dieran información pero no obtuvo resultado.

Probó en Twitter diferentes seudónimos que Gatz podría usar, hasta que dió con @jdgatz. Reifman vió que Gatz seguía sólo a algunas cuentas de comercios, las cuales eran, obviamente, no más ni menos que robots.

Así fue como Reifman decidió crear un par de cuentas que dieran tal impresión y comenzó a seguir la cuenta de Gatz. Entretanto logró obtener una nueva IP de Ratliff, la cual supo más tarde era de Nueva Orleans. Cuando confirmó esto, notó que Gatz estaba siguiendo cuentas de comercios de ese lugar.

Una de las cuentas pertenecía a un comercio llamado “Naked Pizza”. Reifman les envió un correo electrónico para explicarles la situación. También compartió su información con el resto de los perseguidores y pasó la noche llamando a cincuenta hoteles de la zona para averiguar si en alguno se hospedaba James D. Gatz.

El jueves 8 de septiembre, Evan iría a una librería de Nueva Orleans a escuchar la lectura de un libro, como parte de un desafío al que Wired lo había retado por dinero. Él necesitaba el dinero, dado que la vida de fugitivo es dura y costosa.

Leach y Fillinger los fundadores y dueños de Naked Pizza, quienes había sido advertidos de la presencia de Evan en la zona por parte de Reifman, estuvieron merodeando la entrada a la librería a la cual había retado al reportero para que vaya.

La hora en que empezaba la lectura había llega y Evan no aparecía, al parecer todo había sido una pérdida de tiempo. Hasta que ven como un hombre ata su bicicleta en la calle y se dispone a caminar en dirección contraria a la librería previo haber visto a los dos hombres parados ante la puerta.

“Hey” gritó Leach acercándose dubitativamente a Evan y le dijo “Por casualidad, ¿no conoces a un tipo que se llama Fluke?“. El juego había terminado.

Leach y Reifman decidieron donar el dinero a Unity of Greater New Orleans, una organización benéfica que colabora con la reconstrucción de la ciudad luego del desastre del huracán Katrina.
La persecución de Evan por la red, se disolvió tan rápido como se formó.

Finalmente, volviendo al principio ¿se puede desaparecer de la vida propia e inventarse una nueva? La privacidad es una ficción moderna, no basta con crear una identidad nueva: mantenerla requiere una disciplina fuera de lo común. Un sólo error y el castillo de cartas se caerá en una fracción de segundo. Cualquier persona con algunos conocimientos técnicos y medios legales, puede obtener una gran cantidad de información sobre nosotros.


A Software Engineering Approach to LabVIEW

 Excelente libro para comenzar en Labview.