Instalación y configuración de Easy Peasy (Ubuntu) en Asus eee PC

El ASUS Eee PC es uno de los netbook más populares del mercado. Su procesador intel Atom, su sistema de almacenamiento SSD (en lugar de un disco duro convencional), su pequeño peso y tamaño, conectividad WiFi, Bluetooth y varios conectores USB, unido al hecho de que es posible comprarlo con Linux preinstalado, hacen de este mini portátil una maravilla de producto.

El «sabor» de Linux con el que se comercializa el Eee es una versión modificada para ASUS de Xandros, ejecutando KDE y IceWM como gestor de escritorio y de ventanas. El escritorio se organiza porr pestañas Internet, Work (trabajar), Learn (aprender), Play (jugar), Settings (preferencias) y Favorites (favoritos). Al pulsar sobre cada una de ellas, se mostrarán los iconos de acceso directo a las aplicaciones de cada categoría.

Existe software con entorno gráfico para la instalación de nuevos paquetes pero también se puede usar la consola y el conocido apt-get. Aunque Xandros esté basada en Debian, los repositorios de paquetes, no obstante, han de ser -en general- los oficiales de Xandros, pues hay paquetes y drivers que sólo funcionarán en el Eee si se usa la versión a medida del paquete que ofrece Xandros. Sin embargo, la comunidad, como siempre, se ha puesto manos a la obra para intentar la compatibilidad total con el hardware del Eee independientemente de la distribución Linux. Tal es el tirón de esta máquina en la comunidad del software libre que se ha creado una versión especial de Ubuntu, totalmente «tuneada» para sacar el máximo provecho del Eee. Esa distro, originalmente conocida como UbuntuEEE tuvo que cambiar su nombre por Easy Peasy, debido a problemas de derechos de uso del nombre y logos de Ubuntu (Canonical se quejó por email al responsable del proyecto UbuntuEEE y éste le cambió el nombre por EasyPeasy en enero de 2009).

Sigue leyendo Instalación y configuración de Easy Peasy (Ubuntu) en Asus eee PC

Diario Android

Bueno, un grupo de compañeros de Proyelia, junto con la gente de i2map, hemos puesto en marcha una web para ir informando diariamente sobre las novedades de Android que nos lleguen. El nombre del blog : diarioandroid.com (diariolinux.com hace escuela 😉 Si no quieres teclear tanto, también puedes escribir diariog1.com que es más cortito y te lleva al mismo sitio 🙂

Yo mismo he colaborado con un post donde explico cómo configurar Android en el G1 ( ó ADP1) para acceder a Eduroam, (red wifi WPA 2 Enterprise).

Si trabajas con un G1, ADP1 u otro dispositivo Android pásate de vez en cuando por nuestro blog, seguro que encontrarás cosas interesantes.

Ah! Y recuerda que en breve (acaba de anunciarlo Telefónica), podrás comprar un HTC Dream al lado de tu casa 😉

Abrir 2 perfiles de Firefox simultáneamente

Firefox admite el uso de perfiles. Basta con lanzarlo con la opción «-P» :

$ firefox -P

Este comando abrirá el asistente de creación y selección de perfiles.

Por ejemplo, yo tengo dos : uno el de uso habitual, con las extensiones habituales instaladas (Euskalbar, Delicious, Pronounce, LiveHTTPHeaders, Flash Tracer, Google Gears, BugmeNot y WordReference Translator… vaya, no sabía que tuviera tantas 🙂

El otro perfil de Firefox no tiene ninguna extensión instalada. Lo llamo de «desarrollo», y es precisamente por eso para lo que lo uso: para hacer experimentos de programación con las extensiones Firefox, de tal forma que si meto la pata, no pasa nada, sólo he roto el perfil de desarrollo. Si no consigo arreglar el problema, o si rompo algo «de verdad», borro el perfil, y vuelvo a crearlo. Fin del problema.

Ahora bien, cuando estoy en modo «desarrollo», hecho en falta todas mis extensiones habituales. Me gustaría poder trabajar con ambos perfiles a la vez: el habitual y el de desarrollo, uno en cada ventana. Pero hasta ahora, no lo había conseguido: si lanzas otra sesión Firefox desde la línea de comandos, se abre en una pestaña aparte y no vuelve a saltar el asistente. Si pones «firefox -P default» ocurre lo mismo.

Pues bien, hoy he descubierto que SÍ que es posible abrir 2 ventanas Firefox a la vez, una con cada perfil. Para ello, hay que indicar la opción -no-remote, así:

$ firefox -no-remote -P default

Ya estoy contento 🙂

Ver los módulos que tenemos cargados en Apache2

Receta rápida:

/usr/sbin/apache2ctl -t -D DUMP_MODULES

using 127.0.1.1 for ServerName Loaded Modules: core_module (static) log_config_module (static) logio_module (static) mpm_prefork_module (static) http_module (static) so_module (static) alias_module (shared) auth_basic_module (shared) authn_file_module (shared) authz_default_module (shared) authz_groupfile_module (shared) authz_host_module (shared) authz_user_module (shared) autoindex_module (shared) cgi_module (shared) deflate_module (shared) dir_module (shared) env_module (shared) mime_module (shared) negotiation_module (shared) php5_module (shared) setenvif_module (shared) status_module (shared) Syntax OK

Ingeniería del software y OpenOffice.org

La creación de una nueva funcionalidad en cualquier proyecto software no trivial requiere seguir una serie de pautas y métodos que aseguren que lo que se va a crear se hace según lo especificado, en el tiempo acordado y con el coste previsto. Para conseguirlo, es necesario pasar por una serie de trámites que harán además que lo creado pueda ser revisado, modificado o reutilizado en el futuro sin dejarse la salud en el intento. Crear una nueva funcionalidad en OpenOffice.org, aunque sea pequeña, requiere también pasar por un proceso de documentación ingenieril que aunque pueda asustar al principio, se ve como algo imprescindible si se quiere que OOo sea una suite ofimática de calidad. Un ejemplo de todas estas abstracciones lo podemos encontrar en la nueva funcionalidad «overline» prevista para OpenOffice 3.1.

Para que esa nueva funcionalidad se aceptara en OOo Writer, lo primero que tuvo que hacer su autor es redactar una completa especificación siguiendo la plantilla que el equipo de revisión de OOo (iTeam) ha preparado al efecto. Alguien podría decir, bueno, no hace falta todo esto para poner un efecto de subrayado superior a las fuentes… hasta que se da cuenta de que ese efecto requiere un cambio/añadido en la especificación del estándar OpenDocument… vaya, pues sí, habrá que hacerlo. Luego se da cuenta de que ese cambio incluye nuevas cadenas de texto en el interfaz, que por supuesto habrá que traducir. «Ah… pues también es verdad». Cuando ha terminado, observa que el API UNO de OOo también debería de ofrecer la posibilidad de cambiar por programación el efecto de subrayado superior… etc., etc. El redactar una especificación requiere pensar y hacer frente a todos esos problemas (y más) por escrito. ¿Hemos terminado? No. El equipo iTeam de OpenOffice requiere también, para el control de calidad, la redacción de una serie de «pruebas unitarias» para el interfaz gráfico. Una serie de pasos muy detallados con un final esperado. Algo del estilo: «Pulsa en Nuevo documento writer, elige Formato/Carácter en el menú. Pulsa la pestaña Efectos de Fuente. Selecciona «Overline» en la lista, la primera opción debería de ser «Sin subrayado», comprueba que en el desplegable Color, la opción por defecto es «Sin color»…» Son especificaciones de casos de prueba (Testcase specifications)

Si queréis saber más al respecto, podéis echarle un vistazo a esta presentación bajo el título «The OpenOffice.org specification process demystified»