¡¡Liberado!! Fedora 17

30 05 2012

Ayer, 29 de Mayo, ha sido lanzada la versión final de Fedora 17, y ya está disponible para su descarga por los diferentes medios de Fedora Project.

Algo que agradecerán los usuarios con equipos no muy potentes es que GNOME Shell es capaz de ejecutarse sin driver gráfico con soporte 3D. Otra novedad que ha levantado cierto revuelo en la comunidad vinculada a la distribución, es la reorganización de la estructura del sistema de ficheros.

Los directorios /lib/, /lib64/, /bin/ y /sbin/ desaparecen como tales, pasando a ocupar, junto con sus contenidos habituales, subdirectorios con el mismo nombre bajo /usr/. Se mantienen enlaces simbólicos por cuestiones de compatibilidad.

Entre los aspectos más destacados de Fedora 17 se pueden mencionar que cuenta con el Linux kernel 3.3, ademas incorpora GIMP 2.8, Firefox 12, LibreOffice 3.5.2.1 y una amplia selección de paquetes de software.

Principales características de Fedora 17:

· Linux kernel 3.3.4;
· Entorno de escritorio GNOME 3.4.1 (con GNOME Shell);
· KDE Software Compilation 4.8.3;
· Sistema de archivos simplificado, ya que ahora todo se mueve a /usr;
· EXT4 como sistema de archivos predeterminado;
· Integración de systemd;
· Soporte Multitouch;
· Software de renderizado para GNOME Shell;

Descarga directa

Para descargar Fedora 17 con cualquiera de los siguientes entornos de escritorio solo basta seguir el enlace correspondiente:

Gnome: i686, x86_64
KDE SC: i686, x86_64
LXDE: i686, x86_64
XFCE: i686, x86_64

o bien desde la pagina oficial :

Download / Descarga

Anuncios




¡Anunciado! FLISOL Monterrey 2012

26 05 2012

Así es amigos, lo leyeron bien, el FLISOL (Festival Latinoamericano de Instalacion de SoftwareLibre) es una realidad. El pasado miércoles 23 de Mayo el Grupo de Usuarios de Linux de la UR (GULUR) por medio de su espacio en Facebook a anunciado la fecha oficial para el evento que se llevara acabo en el CEDAE (Croquis) de la UR.

FLISOL MTY 2012

El evento tiene como fecha el sábado 30 de Junio de 2012 donde se contara con la presencia de diferentes expositores, installfest, conferencias, etc.

Por lo pronto seguiremos al pendiente de el desarrollo de este evento que se antoja que sea un éxito como en sus anteriores ediciones, espero encontrarlos por ahí.

Aquí encontraran más información

Pagina oficial: FLISOL Oficial

Croquis





XMPP & BOSH

6 01 2011

Si estás leyendo esto seguro que alguna vez has utilizado un “chat”. Los encontramos de las maneras más variadas, desde simples chats de dos personas (punto a punto se podría llamar), en páginas webs con decenas de personas, el ya bastante obsoletillo IRC, el malvado MSN Messenger…. alguno incluso habrá infectado a alguien con un troyano el cual trae una herramienta de chat para hablar con tu víctima. Como ves, existen infinidad de herramientas y cada una con sus normas y sus características. Hoy voy a hablar de un sistema potente, estándar y sobre todo libre. Hablo de XMPP.

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

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, lo que pasa es que no nos damos cuenta. Nosotros sólo vemos el resultado de toda esa “burocracia” entre máquinas. 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.

Ahora un símil entre protocolo cerrado y abierto con la realidad sería el siguiente. Quieres aprender un idioma, vas a una escuela donde te dan unas clases pero tienes la posibilidad de ir a la biblioteca pública y tomar libros para aprenderlo mejor. También puedes buscar por internet e incluso preguntar a gente que gustosamente te ayudará. 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 les 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 una guerra 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.

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 al caso 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 un wifi y sabíamos lo que hablaba por el messenger. Eso con xmpp no hubiera sido posible). 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 damos 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="mylatia@gmail.com" to="prueba@gmail.com">Hola, ¿que tal?</message>

Sobra explicarlo pero esto envía un mensaje de “mylatia@gmail.com” a “prueba@gmail.com” con el contenido “Hola, ¿que tal?”

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 de 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 dificultad. Si te interesa saber más hay un plugin jQuery (en javascript) y que en apenas 200 líneas es capaz de manejar ese protocolo y facilitar manejadores de eventos que hiso mi amigo Maxpowel.

Gracias a Maxpowel.