Este es el comunicado oficial del que se puede obtener la última información sobre la fiesta que se realizará en Córdoba:

“Feliz año nuevo a todos los kdeeros \o/.

A fines de este mes, como ya es costumbre cada 6 meses, sale la nueva versión de KDE SC, concretamente la 4.6. Y, como también es costumbre ya, KDE-AR va a estar festejando su lanzamiento.

Contando con las exitosas experiencias de fiestas pasadas y con ganas de pasarla bien, esta vez se nos ocurrió hacer una fiesta común en la ciudad de Córdoba. Vamos a juntarnos gente de distintos puntos del país —como Rosario, Buenos Aires y la propia Córdoba— para socializar, conocernos mejor IRL, hablar de KDE y otras cosas nerdas y disfrutar de tan amena ciudad.

KDE SC 4.6 sale el 26 de enero. La fecha de la fiesta es el fin de semana del 22 y el 23, la hacemos unos días antes porque nos queda mejor a todos actualmente. El lugar, algún bar a confirmar, que los oriundos de Córdoba nos pueden conseguir.

Están todos invitados, los esperamos para hacer de esta una fiesta grosa. En unos días va a estar accesible la web de inscripciones para que vayan anotando sus asistencias.

Vamos a ir subiendo información actualizada a la respectiva página en nuestra wiki.”

Se espera una asistencia multitudinaria y de todas partes del país para esta nueva fiesta ¿quizás adelantando lo que será la Akademy-la próxima a realizarse en algún futuro no tan distante?

Basándome en el artículo de IT World se me ocurrió refrasear el título y el contenido.

1. Soporte de Hardware: Windows XP es arcaico, y fue diseñado para correr en hardware ya antiguo. A medida que nuevas tecnologías son introducidas, se vuelve menos probable que Windows XP sea compatible o pueda tomar ventaja de ellas. GNU Linux provee soporte para pantallas multitouch, y también ha mejorado mucho la administración de memoria y energía.

2. Drivers de instalación mejorados: Linux posee un sistema de detección e instalación de drivers (módulos) superior. Windows XP en casi todos los casos cumple con esta característica, pero bastante seguido la búsqueda de drivers no devuelve ningún resultado y pide el ingreso del disco de drivers del proveedor del hardware. Instala un hardware nuevo en Linux, y la mayor parte del tiempo va a agregarlo automaticamente junto con los drivers correctos sin ninguna interacción adicional del usuario.

3. Seguridad: Windows XP carece de muchos de los controles de seguridad que han sido introducidos en Linux. Observando las vunerabilidades que se descubrieron desde el lanzamiento de Linux, el sistema operativo Linux no es afectado por los virus programados para Windows XP, y en cuanto a los virus destinados a Linux (muy pocos) los efectos son casi nulos en comparación a los problemas que ocasionan sus contrapartidas a Windows XP.

4. Rendimiento: Una de las quejas contra cada nueva generación de Windows es que parece volverse más lento y sobrecargado con cada iteración. Linux ciertamente incluye nuevas características–las cuales suelen ser extremadamente útiles–consiguiendo un booteo rápido y un desenvolvimiento más veloz que el de WIndows XP.

Quien se descargue el millennia archive se preguntará cómo funciona (principalmente porque al ver la ayuda -h no muestra todas las opciones que debería, porque me olvidé de agregarle eso). La respuesta es simple, y en este mini-tutorial les voy a mostrar un caso de uso.

Explicándolo brevemente, Millennia Archive es un sistema de administración de datos al estilo repositorios/administrador de paquetes.

Un repositorio puede estar alojado en cualquier servidor http, que contiene un archivo .xml que guarda los links a cada ítem (puede ser un libro, un gráfico, un video o un archivo de música) y una interfaz web en php para poder editar dicho xml, es decir, agregar/modificar/quitar ítems.

Por el lado del cliente, hasta el momento sólo estoy desarrollando una versión en python para consola. La misma lo que hace es conectarse al/a los repositorio/s configurado/s en el archivo sources.conf (que en futuras versiones se llamará millennia.conf) para buscar/descargar un ítem deseado. Este archivo descargado se guarda en un directorio que también se parametriza desde ese archivo de configuración.

Configuración:

1. Editar con cualquier editor de textos el archivo sources.conf.

2. Modificar la opción books_dir=/home/alex/Books/ , ingresando el directorio ya existente en el que deseamos se descarguen los libros. En caso de Windows debería ser algo así como “C:\millennia\Books\”.

Ejemplo de uso:

1. Quiero descargar el libro The Flayed Hand de Guy de Maupassant.

2. Ejecuto Millennia Archive con el parámetro -s para buscar: python millennia.py -s Guy

3. Millennia Archive me imprime un mensaje con el resultado de la búsqueda del libro en todos los repositorios, asignándole a cada uno un “Millennia ID”, es decir, un número identificador del resultado de dicha búsqueda.

4. Ejecuto Millennia Archive con el parámetro -S para descargar añadiendo el ID: python millennia.py -S Guy 00.

5. Disfruto de mi libro en HTML con el visor/navegador de mi preferencia.

Así de sencillo. Hay que tener en cuenta que el número de identificación se corresponde con resultado de búsqueda, por eso se debe ingresar exactamente la misma cadena de texto que se utilizó en la búsqueda al descargar.

Es case-sensitive (diferencia mayúsculas y minúsculas), y busca por el título de los libros, que incluye autor y título separados por un guión. La búsqueda en el paso 2 podría haberse hecho con “Flayed” en lugar de “Guy” y hubiera encontrado el mismo resultado.

Se aceptan sugerencias para mejorar tanto el sistema en sí, como el cliente de consola. Saludos!

Para poder usar Millennia Archive Client se requieren las librerías de Python 2.6 y PyCurl. Recuerden que es para la consola!

A continuación el paquete:

millennia-alpha0.tar.gz

Uno corresponde al diagrama de flujo de la aplicación cliente y otro a las interfaces de los repositorios de Millennia Archive.

A continuación están los .jpg en versiones en español e inglés. Que los disfruten! Pronto estaré subiendo acá una versión alfa del cliente.

Millennia Archive Client Flow Chart EN.jpg

Millennia Archive Client Flow Chart ES.jpg

Millennia Archive Interfaces EN.jpg

Millennia Archive Interfaces ES.jpg

KDE SC, antes llamado K Desktop Environment, es una plataforma completa de aplicaciones, que consta de un gestor de ventanas (kwin), un completo administrador de escritorios (plasma), y una gama muy variada de utilitarios.

También se lo denomina genéricamente GUI, o interfaz gráfica.

¿Qué es una interfaz gráfica?

Es el entorno visual que nos permite interactuar utilizando el tecaldo y el mouse con el sistema operativo y los distintos programas, con representaciones gráficas intuitivas, es decir, de una forma amigable. Al GUI se lo puede diferenciar de la terminal/consola de comandos, en la que uno se desenvuelve escribiendo lineas de comandos con el teclado.

Además de KDE SC, existen otras, como pueden ser Gnome, XFCE, FluxBox, BlackBox, Aero (Windows Vista/7), Aqua (MacOS X), etc. Algunos incluyen simplemente manejo de ventanas sin administrador de escritorio.

¿Bajo qué Sistema Operativo corre?

KDE SC es multiplataforma. Se puede utilizar como GUI tanto en distribuciones Linux, en varios sistemas UNIX (FreeBSD, OpenSolaris, entre otros),  así como también en Mac OS X y Windows. Esto último es muy interesante, ya que nos permite modificar la apariencia de este sistema desde sus versiones XP en adelante, además de la ventaja de contar con miles de aplicaciones libres desarrolladas para KDE SC. También se comenzó un proyecto de portarlo a Google Native Client.

¿Cómo es KDE SC por dentro?

Está construido con el framework Qt3 para el antiguo KDE 3 y Qt4 como base para KDE4.

El framework Qt es desarrollado por Nokia, tanto por programadores pagos como por voluntarios de todo el mundo. Esto es posible gracias a que existen 3 versiones con distintas licencias: Licencia Comercial Qt, Licencia Qt GNU LGPL y Licencia Qt GNU GPL.

Qt se encarga de facilitar la interacción de las aplicaciones que utilizan las API de este framework con cada uno de los sistemas operativos. Gracias a los bindings se puede desarrollar con la API de Qt utilizando los lenguajes C++, Python y Ruby. Maneja acceso a bases de datos SQL, XML parsing, manejo de hilos/threads, soporte de red y una API multiplataforma para el manejo de archivos.

Las aplicaciones que funcionan en KDE SC se desarrollan también a través del framework Qt.

¿Qué se necesita para programar aplicaciones Qt/KDE?

A la configuración básica que nos permitirá desarrollar estos programas no le debe faltar:

1. Librerías del lenguaje que vamos a usar para programar(C++, Python, Ruby).
2. El framework Qt para C++, PyQT (para Python) o RubyQt (para Ruby).
3. Un editor de texto para escribir nuestro código.

En Windows quizás necesitemos además descargar un complemento especial de MS Visual C++ (ver los links útiles abajo de todo).

Adicionalmente, podemos diseñar la parte visual de nuestros programas usando Qt Designer (muy parecido a las herramientas de MS Visual Studio) en el cual arrastramos controles en la pantalla de nuestra aplicación.

Si bien podemos programar utilizando un editor de texto simple, existen alternativas más completas que nos ofrecen otras funcionalidades (marcas de syntaxis, diccionario, etc.) como emacs, geditor ó notepad++. Y hay para todos los gustos, los que quieran usar algo más complejo como un entorno de desarrollo en el que tambien se pueda hacer debugging, unit testing y demás. podemos usar un IDE como Eclipse (con los plugins necesarios), Qdevelop ó Eric.

Links útiles

Python: http://www.python.org/download/

Complemento MS Visual C++: http://www.microsoft.com/downloads/en/confirmation.aspx?familyId=9b2da534-3e03-4391-8a4d-074b9f2bc1bf&displayLang=en

PyQT4: http://www.riverbankcomputing.co.uk/software/pyqt/download

En la primera parte nos habíamos quedado en la difícil decisión que debió tomar Google, si utilizar un GUI tradicional sobre el sistema de las X, o uno propio en Native Client. Vamos a analizarlo:

¿Por qué un GUI tradicional?

La principal ventaja de utilizar un GUI tradicional es que ya está hecho. Algunos usuarios de GNU/Linux prefieren la confiabilidad de Gnome, otros la innovación de KDE, y otros más la agilidad y sencillez de Blackbox. En mi opinión personal, si hubiera que elegir alguno de estos tres para implementar el GUI de Google Chrome OS, la elección más acertada sería KDE. Ya que aunque aún está en sus inicios (pero ya ha superado los problemas que tenía de estabilidad en su primerísimas versiones), es muy prometedor, la estructura con que se ha desarrollado es muy OOP y elegante, soporta imágenes vectorizadas y permite animaciones 2D fluidas, así como también efectos 3D.

Se preguntarán entonces: pero… ¿no iba a ser totalmente orientado a la web? ¿no era tan sencillo desarrollar aplicaciones .nexe? ¿no iban a ser todos los programas Native Cliente en el futuro Google Chrome OS?.

Yendo por partes, como diría Jack el Destripador. Cómo será el nuevo Google Chrome OS no lo sé, ya que no trabajo para Google, ni conozco a nadie que lo haga. Sólo puedo imaginarme cómo será, y cómo podríamos crear nuestro propio Chrome OS si así lo quisiéramos…

El GUI basado en KDE, por ej., se encargaría de mostrarnos la ventana de bienvenida y login, un bonito fondo de pantalla, una elegante barra de tareas, una simpática decoración de ventanas, efectos de transición entre ventanas y escritorios en 2D y 3D, animaciones, widgets, etc. Todo el contenido de las ventanas, o las aplicaciones en sí, serían Native Client. Tanto las aplicaciones visuales como las no visuales, para generalizar: aplicaciones .nexe.

Pasando en limpio, algunas de las ventajas serían:

• Ahorro de tiempo: la mayoría ya está hecho, sólo haría falta adicionar cuestiones de Branding Google (logos, imágenes personalizadas, etc.)
• Trabajo en conjunto con comunidades OpenSource: las mejoras en KDE se verían reflejadas en Chrome OS, y viceversa, y así con todos los componentes opensource que se utilicen. Esta es la ventaja filantrópica y a mi entender el aporte más valioso.
• Plataforma Multi-platafórmica: a lo que me refiero usando esta conjunción de palabras poco feliz es que se podrán utilizar no sólo aplicaciones desarrolladas para Native Client, sino también las desarrolladas para Gnome y Kde, simplemente instalando los paquetes correspondientes a cada una.

¿Por qué un GUI totalmente Native Client?

Si bien requerirá mayores tiempos y esfuerzos, un GUI desarrollado totalmente en Native Client (corriendo sobre Xorg), permitiría levantar entornos gráficos no solo de manera local, sino también remotos. La clave está en la conjugación de qué será unívocamente ejecutado de forma local y qué podrá ser también ejecutado de manera remota. No olvidemos que el entorno visual es una de las partes más pesadas, hablando en términos de disco duro, de las distribuciones de GNU/Linux de hoy en día.

Además, cuanto más haya desarrollado Google a su antojo, mayor poder y control tendrá sobre el Sistema Operativo.

Si, en teoría, con Native Client se pueden realizar aplicaciones de todo tipo con un amplio acceso a las funciones del sistema, no debería tener mayores complicaciones desarrollar un GUI en esta plataforma.

¿Chrome OS = Kernel Linux + (GNU + Xorg + Servidor Web + Motor Chrome) + Native Client Apps << GUI >> Native Client Apps?

Esta podría ser la fórmula que tienen en mente. Como podemos ver, algo que tendrían en común las dos variantes analizadas anteriormente en referencia al entorno gráfico, sería un servicio corriendo sobre el kernel del motor Native Client, que se encargaría de hacer la ejecución del código recibido desde un servidor.

La parte pintada de rojo corresponde a todo lo que indefectiblemente debe estar instalado en la pc local, una Netbook por ej. La parte verde es una zona libre que puede ser tanto offline (local) como online (remota). ¿De que sirve un GUI remoto? Algunos GUI podrían ser personalizables, y tendríamos el mismo GUI en cualquier PC que utilicemos, en algunos se podría limitar el uso de ciertas aplicaciones, etc.

Native Client se encarga de ejecutar código no-seguro de páginas de internet alojadas en un servidor HTTP. Pero este servidor puede estar tanto en Internet, o en otra PC de la WAN o LAN, o en nuestra misma Netbook.

Me animo a vaticinar que si lo especulado hasta ahora es relativamente correcto, Chrome OS traerá implementado un servidor web donde se almacenarán todas las aplicaciones que podremos ejecutar en nuestra PC sin necesidad de una conexión a Internet. La posibilidad de ejecutar programas sin estar conectados 24×7 es clave para la aceptación del público en general, ya que no todo el mundo tiene los medios económicos para contratar una banda ancha ilimitada y portatil.

Hasta aquí llegó mi humilde y teórica opinión, vagas especulaciones, y demás. A continuación invito a todos los que quieran ponerse manos a la obra para desarrollar su propio sistema operativo al estilo Google Chrome OS.

Siguiente >>

Si querés seguir leyendo el tutorial para hacer tu propio Google Chrome OS, hacé clic acá.

Los ingenieros de Google están ingeniándoselas (y copy/pasteando) para desarrollar un Sistema Operativo, posiblemente con el objetivo de competir de manera directa con Microsoft Windows.

Con la premisa de proporcionar un Sistema Operativo gratuito, libre, veloz, simple y seguro (libre de virus, spyware, etc.) para las netbooks (en principio) y posteriormente para las pc de escritorio, decidieron utilizar el kernel Linux como base, y desarrollar una nueva interfaz de usuario, principalmente orientada a la navegación y el uso de aplicaciones web.

Mucho énfasis le han puesto a esto último de la orientación al web. Y la primera pregunta que se nos viene a la mente es: ¿Voy a necesitar conexión a internet constante para poder utilizar las aplicaciones? Y la respuesta aún no la sabemos, pero lo más probable es que no. Es de dudar que Google sólo se enfoque a satisfacer las necesidades de aquellos usuarios con conexión constante e ilimitada a Internet.

A mi entender, y de ahí viene el título de este post, lo que Google intentará ofrecer en su Chrome OS es un sistema operativo análogo al WebOS desarrollado por Palm. Este sistema que lleva consigo el nuevo Palm Pre, se caracteriza por la facilidad de desarrollar aplicaciones compatibles, utilizando los lenguajes y técnicas usadas actualmente para el diseño web. Lo cual no significaría que uno deba estar conectado a Internet para que funcione, sino que la tecnología con la cual se crean las aplicaciones es la misma, o similar, a la que se utiliza para crear las páginas web.

También, desde su blog, Google invita a la comunidad línux a participar de este proyecto.

Hace pocos días publiqué un artículo sobre lo que me parecía a mi sería el futuro, y al mismo tiempo el camino correcto, de los Sistemas Operativos.

Esta mañana MSI ha anunciado su MSI Winki, un sistema conectado directamente al hardware del motherboard, y basado en Linux. En principio este chip vendrá junto con algunos modelos de motherboard de MSI, aunque la empresa afirma que en el futuro lo distribuirán en todos sus productos.

Por lo que se puede apreciar, las aplicaciones que incluye son las básicas: Skype para VoIP, Pidgin para mensajería instantanea (compatible con protocolos MSN, ICQ, AOL, Google Talk, MySpace, etc…),  Firefox para navegación de internet.

Resta ver en el futuro si esto se establecerá simplemente como un mini S.O. intermedio, o en base a estos chips se empezará a embeber mediante hardware un completamente funcional Sistema Operativo, la robustes y portabilidad de linux lo permitiría, la evolución tecnológica de las memorias también.

¿Microsoft pondrá el grito en el cielo o Windows 8 vendrá en formato “chip” y basado en Linux?

Se viene la revolución del software, y debemos estar preparados para adaptarnos. Nunca es tarde para descargar una distribución de linux y ponerse al día.

Saludos! Espero sus comentarios…