Mantención de imágenes virtuales de virtualbox

Luego de muchos meses sin escribir, vuelvo para dar un truco corto, pero muy útil.
Hoy noté que me quedaba sin espacio libre en la partición home, tanto en mi laptop como mi escritorio. no entendía porqué, pues no había instalado nada particularmente grande. Luego, investigando un poco me nació un sospechoso: El disco duro de la máquina virtual (VirtualBox) estaba usando mucho más espacio que el indicado por el sistema operativo invitado.
¿porqué ocurre ésto?
Lo que sucede es que cuando se borra un archivo en el sistema operativo windows, éste "marca" el espacio utilizado como libre, pero físicamente los datos permanecen ahí. Perjudicando enormemente a los entornos virtuales.
¿como solucionarlo?
Existen herramientas para windows, como sdelete, la cual "limpia" el espacio no utilizado marcándolos con ceros. Su utilidad es para asegurarse de tener entornos donde no se puedan recuperar archivos una vez borrados, sin embargo la utilidad para el caso de las máquinas virtuales es que existen programas que encogen el espacio utilizado por una unidad de tamaño variable, permitiendo recuperar espacio mal utilizado.
El método que expongo a continuación es para virtualbox, y utilizándolo el tamaño de mis imágenes bajó de 15G a sólo 4G!

- En un sistema operativo invitado, descargar sdelete (el enlace se encuentra al final de la entrada), y ejecutar:
sdelete -c c:

luego cerrar la máquina virtual, y desde una línea de comandos ejecutar:
VBoxManage modifyvdi /ruta/imagenwin.vdi compact

es necesario especificar la ruta completa del archivo, o la misma que está registrada en el archivo de configuración de VirtualBox.

Enlaces útiles
sdelete: Utilidad de Microsoft para borrar completamente los archivos.

Xorg 7.4, hotplugging, synaptics y más

Xorg input hotplugging

Recientemente Archlinux optó por pasarse a xserver 1.5. La nueva versión del servidor gráfico incluye diversas novedades, pero la que más destaca, y genera dolores de cabeza, es input hotpluggin.

La motivación tras el nuevo sistema de manejo de entrada, es la capacidad de xorg de manejar dinámicamente los dispositivos. En el pasado era necesario especificar la configuración de forma manual en el archivo xorg.conf. Esto resultaba incomodo, debido a la necesidad de reiniciar el servidor X para aplicar nuevos cambios importantes. Sin embargo, la obligación del archivo no era tan estricta, pues el servidor gráfico tenía rutinas de autodetección, donde configuraba los dispositivos al iniciarse. Ésto parecía una buena solución, sin embargo poseía un defecto: Si un dispositivo era removido, se perdía la conexión, y por lo tanto el manejo del driver. Y aunque reconectara, no era posible volver a utilizarlo. Para los usuarios de laptops ésta última afirmación puede parecer una falacia, pues es frecuente que los ratones y teclados usb funcionaran apenas conectados. Lo que quizás desconocían, es que había un truco para lograr ésto: El Kernel mantenía un dispositivo genérico (por ejemplo: /dev/input/mice). Para la mayoría de los usuarios, éste dispositivo genérico parece ideal, sin embargo, con la evolución de la tecnología, los dispositivos cada vez incluyen mas funciones. ¿que pasaba con un teclado que tuviera funciones de scrolling, teclas especiales, etc. o siendo más fantasioso.. ¿Que pasaría con el soporte para ratones con acelerómetros u otras gracias que quizás inventen en el futuro?

la respuesta es tan simple como obvia, con el sistema mencionado, no se hubieran podido manejar inmediatamente, hasta reiniciar el servidor gráfico y cargar los controladores adecuados para dichos dispositivos.

Para solucionar ésto, se invento el sistema X input event driver (evdev), el cual utilizando las ventajas de hal y dbus, monitorea los dispositivos conectados, y aplica reglas definidas en sus políticas (reglas basadas en la base de datos de hardware) asignando automáticamente configuraciones e indicando con que controlador manejar cierto dispositivo.

Las reglas se configuran en archivos XML con extensión fdi. Los cuales, si bien en un inicio pueden parecer complicados, al entender su funcionamiento, son una herramienta poderosa para personalizar la configuración del hardware.

Como ejemplo, al actualizar mi laptop, no funcionaba el touchpad como debía, pues aunque utilizaba el driver Synaptics, no configuraba opciones personalidas que me gustan (scroll con 2 dedos, botón derecho al presionar la esquina inferior derecha, desplazamiento horizontal y vertical en los bordes derecho e inferior respectivamente, tercer botón al presionar con 2 dedos, etc. Para configurarlo, antes era necesario recurrir al archivo xorg.conf, pero con ésta nueva versión que incluye hotpluggin, el servidor X ignora las configuraciones establecidas en dicho lugar. Ahora, en su lugar es necesario definir una politica de hal para el dispositivo.

política para manejar el touchpad Synaptics

El controlador de synaptics puede causar un par de problemas. Existe un controlador específico (en archlinux, el paquete se llama xf86-input-synaptics) el cual provee el driver. La política de Hal para configurarlo (en mi caso la defini en el archivo /etc/hal/fdi/policy/11-x11-synaptics.fdi) es la siguiente:

<?xml version="1.0" encoding="ISO-8859-1"?>
<deviceinfo version="0.2">
<device>
<match key="info.capabilities" contains="input.touchpad">
<match key="info.product" contains="Synaptics TouchPad">
<merge key="input.x11_driver"  type="string">synaptics</merge>
<merge key="input.x11_options.AlwaysCore" type="string">true</merge>
<merge key="input.x11_options.Protocol" type="string">auto-dev</merge>
<merge key="input.x11_options.Emulate3Buttons" type="string">true</merge>
<merge key="input.x11_options.SHMConfig" type="string">true</merge>
<merge key="input.x11_options.LeftEdge" type="string">1700</merge>
<merge key="input.x11_options.RightEdge" type="string">5300</merge>
<merge key="input.x11_options.TopEdge" type="string">1700</merge>
<merge key="input.x11_options.BottomEdge" type="string">4200</merge>
<merge key="input.x11_options.FingerLow" type="string">25</merge>
<merge key="input.x11_options.FingerHigh" type="string">30</merge>
<merge key="input.x11_options.MaxTapTime" type="string">180</merge>
<merge key="input.x11_options.VertEdgeScroll" type="string">true</merge>
<merge key="input.x11_options.HorizEdgeScroll" type="string">true</merge>
<merge key="input.x11_options.CornerCoasting" type="string">true</merge>
<merge key="input.x11_options.CoastingSpeed" type="string">0.30</merge>
<merge key="input.x11_options.VertScrollDelta" type="string">100</merge>
<merge key="input.x11_options.HorizScrollDelta" type="string">100</merge>
<merge key="input.x11_options.MinSpeed" type="string">0.10</merge>
<merge key="input.x11_options.MaxSpeed" type="string">0.60</merge>
<merge key="input.x11_options.AccelFactor" type="string">0.0020</merge>
<merge key="input.x11_options.VertTwoFingerScroll" type="string">true</merge>
<merge key="input.x11_options.HorizTwoFingerScroll" type="string">true</merge>
<merge key="input.x11_options.TapButton1" type="string">1</merge>
<merge key="input.x11_options.TapButton2" type="string">2</merge>
<merge key="input.x11_options.TapButton3" type="string">3</merge>
<merge key="input.x11_options.RBCornerButton" type="string">3</merge>
</match>
<match key="info.product" contains="AlpsPS/2 ALPS">
</match>
<match key="info.product" contains="appletouch">
</match>
<match key="info.product" contains="bcm5974">
</match>
</match>
</device>
</deviceinfo>

Teclado con rueda
Otro problema que tuve, fue para que el sistema reconociera la rueda de desplazamiento incorporada en mi teclado, aunque intenté de todas maneras que configurara el dispositivo leyendo desde /dev/input/event2, no fue posible, e incluso pensé en crear un nuevo driver, sin embargo, compilando la última versión del driver disponible (xf86-input-evdev-2.1.0), el sistema reconoció nuevamente mi rueda, y puedo utilizar mi teclado tranquilo. Luego de ésto, puedo decir que me encuentro satisfecho con Xorg 7.4, pues funciona perfecto tanto en mi portatil, como en mi escritorio.

Links útiles
Código fuente de controladores de xorg
Wiki de archlinux de hotplugging

PKGBUILD para xf86-input-evdev-2.1.0

Sincronizar Google calendar con Kontact (korganizer)

Querámoslo o no, desde que Google empezó a crecer, se ha hecho parte de nuestras vidas. No nos basta con realizar nuestras búsquedas en el popular sitio, sino que confiamos nuestra correspondencia al servicio que puso de moda las casillas gigantes, y además habemos algunos que registramos parte de nuestra vida mediante su gran aplicación Google Calendar.

Sin embargo, habemos personas a quienes no nos gusta visitar constantemente un sitio web para tareas que podemos realizar utilizando nuestro programa PIM (administrador de información personal) favorito. La presente entrada es para hablar acerca de como sincronizar el servicio de google con Kontact, sin embargo, las instrucciones sirven para otros programas, como evolution, Apple icalc, e incluso Outlook Express! pues, como ya debieron notar, la aplicación de la cual hablaré es multiplataforma, gracias a que está escrita en java.

La versión de Kontact de kde4, además de perder estabilidad desde la versión anterior, también perdió la característica de manejar multiples calendarios, incluyendo los calendarios externos. En kde 3 era posible leer fácilmente los calendarios de google reader, pero jamás se pudo escribir en éstos. Esa característica la extrañaba desde que pasé a la nueva versión del escritorio de la K, debido a que suelo utilizar indistintamente mi equipo portatil, mi escritorio, y mi perfil móvil en la universidad. Esta mañana descubrí la solución a mis necesidades de sincronización: GCALDaemon.

GCALDaemon es un programa que actúa como servicio, el cual trabaja como middleware entre las aplicaciones locales con Google Calendar, ya sea de forma local (mediante un archivo de ical) o mediante un servidor (http o ldap) que se ejecuta en la maquina cliente, el cual permite otros tipos de conexión para la sincronización de los calendarios. Además, el programa provee opciones para la notificación de correos de Gmail, entre otras funciones vinculadas a Google.

Su instalación es relativamente simple, pero para mi lo fue más, pues como siempre, en archlinux bastó un yaourt -S gcaldaemon, luego agregar mi usuario al grupo gcal, y ejecutar el programa de configuración

/opt/gcaldaemon/bin/config-editor.sh

Luego, para configurarlo, fue necesario habilitar la sincronización de archivos, la cual se habilita en la casilla indicada en la imagen. En ella, es necesario asociar nuestra cuenta de correo google, con el correo de google calendar, y un archivo ical.
La cuenta de google no es necesario indicar donde conseguirla.
El calendario de google se obtiene en el sitio de Google calendar, copiando el enlace asociado al icono ICAL indicado en la imagen. Dicha opción se encuentra en los detalles del calendario al cual se desea sincronizar.

El secreto de la sincronización local, es indicar cual es el archivo donde el software guarda los calendarios, en el caso de Korganizer, dicho archivo se encuentra en ~/.kde4/share/apps/korganizer/std.ics, es en este paso donde es posible seleccionar otros archivos ics, según cual sea nuestra aplicación.

Una vez indicado, y con el programa cerrado, basta ejecutar el daemon. icql, aunque una buena manera, es de forma manual. En el caso de archlinux es /opt/gcaldaemon/bin/standalone-start.sh

Una vez ejecutado, ya se podrán ver los cambios en Kontact, y serán bidireccionales las modificaciones!
Referencias:
GCALDaemon, sitio con documentación y manuales para el programa.

KDE 4.1: Parte II - Teclas de acceso rápido

En todo el tiempo que llevo utilizando la nueva versión del escritorio de la gran K, algo que me ha resultado tremendamente molesto son las teclas de acceso rápido. Si bien KDE incorpora esa opción (preferencias del sistema / introducir acciones), estas sencillamente no funcionan.

El tip que deseo compartir esta vez, consiste en crear nuestros accesos rápidos, sin utilizar el asistente de la gran K. Con ellos, es posible lanzar programas de una manera rápida, y con la destreza suficiente, también es posible pasar parámetros a programas en ejecución.

Ingredientes:
xbindkeys

Preparación:
- Agregue a su sistema 1 paquete completo de xbindkeys
- En una terminal bien limpia, prepare los códigos de acceso rápido utilizando
xbindkeys -k
- Al abrirse la ventana, presione su acceso de tecla rápido favorito. xbindkeys le devolverá un código similar a esto:

Press combination of keys or/and click under the window.
You can use one of the two lines after "NoCommand"
in $HOME/.xbindkeysrc to bind a key.
"(Scheme function)"
m:0x10 + c:38
Mod2 + a

- Copie el valor devuelto, y reemplaze el contenido de las comillas por su comando favorito. Usted puede realizar cadenas separándolas con ";" (punto y coma)
- Pegue el contenido dentro del archivo .xbinkeys
- Ejecute xbindkeys, en caso que ya se encuentre en ejecución, ya debiera estar funcionando su acceso rápido.

Para los lectores flojos, dejo mi configuración actual. bastante minimalista por cierto, pero efectiva. Con ella es posible abrir dolphin al estilo windows (logo + e), subir y bajar el volumen.

"dolphin"
m:0x50 + c:26
Mod2+Mod4 + e

"ksnapshot"
m:0x10 + c:111
Mod2 + Print

"dbus-send --type=method_call --dest=org.kde.kmix /Mixer0 org.kde.KMix.increaseVolume string:"Master:0""
m:0x0 + c:176
XF86AudioRaiseVolume

"dbus-send --type=method_call --dest=org.kde.kmix /Mixer0 org.kde.KMix.decreaseVolume string:"Master:0""
m:0x0 + c:174
XF86AudioLowerVolume

"dbus-send --type=method_call --dest=org.kde.kmix /Mixer0 org.kde.KMix.toggleMute string:"Master:0""
m:0x0 + c:160
XF86AudioMute

# opcionalmente, usted puede agregar un acceso rápido para visualizar el resto de accesos rápidos activos.
"xbindkeys_show"
control+shift + q

Con ésto, podrá utilizar sus accesos de teclado rápido sin tener que esperar a las próximas versiones de KDE 4, donde el error "debiera" estar resuelto.

Diccionarios en Openoffice.org 3

Esta mañana actualicé mi sistema, y me encontré con una actualización importante: Openoffice.org 3.0. Inmediatamente pensé! wow! estos desarrolladores de Archlinux si que son veloces. Al rato note que cometí el error de no leer los mensajes que arrojó Pacman, motivo por el cual ignoré ciertos detalles importantes. El motivo de la entrada de hoy, es explicar como solucionar los aparentes cuelgues que ocurren en entornos KDE, además de proveer mi extensión con el diccionario para Chile.

El primer motivo, y probablemente el que mas disgustos causará es la eliminación del soporte gráfico "kde". Lo que implica que es necesario forzar el "look and feel" al utilizado por Gnome. Si no hacemos ésto, es muy probable que el programa "se cuelgue".

Para solucionarlo, es necesario definir la variable de entorno OOO_FORCE_DESKTOP con el valor gnome. Sin embargo, en equipos compartidos esto es molesto. Entonces, una buena solución es hacerla global. Para hacerlo, es necesario crear el archivo /etc/profile.d/soffice.sh, asignarle permisos de ejecución, y como contenido, agregar

export OOO_FORCE_DESKTOP=gnome

Otra molestia de la nueva versión es la ausencia de los diccionarios por defecto. Si bien es relativamente simple instalarlos, Archlinux viene sólo con algunos. Entre ellos el español, pero localizado al español de españa (es-ES)

Diccionario para es-CL

Dicho diccionario puede ser instalado desde el administrador de extensiones (herramientas/Administrador de extensiones). Sin embargo, en equipos compartidos ésto puede ser molesto.
Para instalarlo de forma global, es necesario ejecutar como administrador

/opt/openoffice/program/unopkg add --shared dict-cl.oxt

Y para desinstalarlo, basta con ejectuar

/opt/openoffice/program/unopkg remove --shared org.openoffice.cl.hunspell.dictionaries

Y ya que estamos jugando con unopk, es posible visualizar las extensiones globales instaladas ejecutando

/opt/openoffice/program/unopkg list --shared

Direcciones útiles
Sitio que contiene extensiones y diccionarios para openoffice.org
Origen del diccionario de sinónimos