Esta laptop Samsung RF511 es una laptop muy linda, y bastante potente. Según sus especificaciones cuenta con un procesador Intel i5, 4 gigas de RAM y una placa de video NVIDIA GT540M. Esta adquisición fue influenciada principalmente por ser de las pocas laptops que se podían adquirir que tenían una placa de gráfica NVIDIA.

En windows aún no experimenté demasiado, más allá de estar varias horas desinstalando toda la basura que Samsung instala de fábrica (programas, demos, pésimos antivirus, programas que no tengo idea qué hacen, controladores que descontrolan, etc… lo cual no es solo de Samsung, todas las empresas hacen este tipo de estupideces) pero no he tenido ningún problema por ahora. Todo parece funcionar correctamente.

En linux, que es mi principal sistema operativo, específicamente la distribución Ubuntu 11.04 es donde comencé a llevarme algunas sorpresas, varias por falta de investigación y desconocimiento a la hora de decidir la compra de este equipo.

La primera sorpresa fue intentar bootear desde USB. Mi pregunta fue ¿Como bootear desde USB con una laptop Samsung RF511? LLegué a pensar era imposible, pero milagrosamente descubrí que si se puede bajo una incómoda condición, solo reconoce los USB cuando la computadora es prendida con el USB conectado.

Si rebooteamos la computadora, no detecta que hay un USB, y por lo tanto no bootea desde éste. Debe ser apagada y prendida nuevamente para lograr bootear. Supongo que esto lo hacen para conseguir que la pc reinicie realmente rápido.

Resuelto el problema del booteo, logré entrar con un LiveUSB e instalar el sistema operativo Ubuntu Linux/GNU.

Al iniciar por primera vez, para mi sorpresa,  salió un mensaje que decía que mi equipo no tenía el hardware necesario para ejecutar Unity, la nueva interfaz gráfica de Ubuntu Natty que necesita para funcionar una aceleradora gráfica.

Se imaginan mi sorpresa, al ver este mensaje, cuando había comprado esta computadora precisamente por su placa NVIDIA que debería ser más que suficiente para soportar Unity.

Investigando un poco descubrí que había sucedido. Esta laptop, y varias otras nuevas, tienen un sistema llamado NVIDIA Optimus, que en efecto significa que no tienen una placa gráfica.. sinó que tienen dos ! Efectivamente tiene un GPU NVIDIA pero además tiene otra Intel, que es menor calidad, pero con un consumo mucho menor. Entonces esta tecnología solo activa la placa NVIDIA cuando se la necesita, y para todo lo demás utiliza la placa Intel.

Lamentablemente, esto solo funciona bien en Windows, en linux no hay mucho soporte aún. Existe un proyecto llamado Bumblebee (ehhhh.. mucho Transformers estos chicos) que pareciera dar soporte a esta tecnología, pero aún no lo he probado.

Pero como había detectado la placa NVIDIA, pero no podía usarla, era como si no hubiera placa directamente.. y no usaba siquiera la Intel. La solución fue manualmente desinstalar el divers de NVIDIA (desde la configuración de restricted drivers) y al reiniciar la pc, ya me funciona Unity como siempre.

Luego el siguiente problema fue el mousepad. Si bien funcionaba, no andaba el Scrooll vertical (ni el horizontal, pero me hubiera molestado menos) y tampoco había forma de desactivarlo cuando conectaba el mouse o escribía (no se imaginan cuantas veces toqué con la palama de mi mano el pad y se me fue el cursor a cualquier lado mientras escribía este artículo).

Buscando entre los dispositivos que detectaba… ¡parecia que no existía ningún touchpad! Pero como era posible que no lo detectara pero funcionara…. aun no lo se.. pero lo que descubrí es que sí era detectado, ¡pero como cualquier otra cosa! Según el comando xinput list es detectado como PS/2 Logitech Wheel Mouse.

Investigando un poco en internet, resulta que el Kernel de linux que estoy utilizando tiene problemas para detectar los nuevos touchpad elantech y ya estaba reportado el bug en las listas de Ubuntu y del kernel de linux pero aún no fue solucionado en upstream, por lo que hay varios parches, para el que quiera intentar resolverlo por su cuenta (aun no lo intenté y no se si lo intentaré o viviré con este bug hasta que sea resuelto). Pareciera estar bastante avanzado el tema por lo que espero que pronto sea solucionado.

Investigando todo esto descubrí también que el modelo que me vendieron tiene un bug en un chip de Intel Cougar Point HM65 que trae problemas con los dispositivos SATA2 que conecte en la computadora. Este chip fue retirado del mercado por Intel en Febrero y se aconseja que se reemplace en todos los equipos por una versión (revision 6 o superior) que no tenga este defecto. (el cual no se puede arreglar con un parche porque es un problema de hardware) que evaluaré que hacer y en el peor de los casos.. esperar no tener dispositivos SATA2 en los tres o cuatro años que espero me dure esta computadora.

Por ahora eso fue todo lo que estuve experimentando, el resto anda en verdad muy bien. Por lo que estoy bastante conforme. (aunque sigo llorando por no haber podido comprar una Dell con características similares snif snif snif)

Por defecto, no tiene soporte para el lenguaje Groovy, pero es fácilmente configurable, e incluso sin necesidad de permisos de adminsitrador, permitiéndonos configurar nuestor ambiente de trabajo, sin modificar la configuración de los demás usuarios.

Para esto debemos descargar el bundle con el coloreo de sintaxis, tipos mime y otras cosas del sitio http://www.grails.org/Gedit

En esa misma página podremos encontrar instrucciones para instalarlo, que requieren de permisos de administrador. Pero combinando un post anterior en este mismo blog, sobre como hacer que gedit abra archivos tpl como si fueran archivos php y algunos otros tips más, podremos instalarlo sin necesidad de permisos especiales.

Luego de descompactar el archivo descargado, copiamos los directorios plugins, snippets y styles a la carpeta ~/.gnome2/gedit

Para arreglar el coloreo de sintaxis y enseñarle a gedit la existencia de groovy debemos crear la carpeta (si no existe) ~/.local/share/gtksourceview-2.0/language-specs y copiar en ella los dos archivos terminados en .lang que descompactamos.

Despues creamos el archivo ~/.local/share/mime/packages/Overrides.xml (y las carpetas necesarias, si no existen) y agregamos en ese archivo el contenido de los dos archivos xml que se encuentran en el bundle.

El contenido final del archivo será similar a

<?xml version="1.0" encoding="UTF-8"?>
<mime-info xmlns="http://www.freedesktop.org/standards/shared-mime-info">
	<mime-type type="text/x-groovy">
		<sub-class-of type="text/x-java"/>
		<comment>Groovy Source File</comment>
		<glob pattern="*.groovy"/>
	</mime-type>
	<mime-type type="text/x-groovy++">
		<sub-class-of type="text/x-groovy"/>
		<comment>Groovy++ Source File</comment>
		<glob pattern="*.gpp;*.g++"/>
	</mime-type>
	<mime-type type="text/x-gsp">
		<sub-class-of type="text/html"/>
		<comment>Grails GSP File</comment>
		<glob pattern="*.gsp"/>
	</mime-type>
</mime-info>

Finalmente, para que el sistema reconozca nuestros cambios, debemos actualizar la base de datos de tipos mime, ejecutando el comando update-mime-database ~/.local/share/mime

Con esto, al abrir el próximo archivo de groovy, deberíamos tener coloreo de sintaxis funcionando correctamente.

Se pueden seguir haciendo otras cosas como habilitar bash completion, pero lo dejaremos para otra oportunidad.

Como a varios les pasa, me aburro muy seguido de mi fondo de pantalla, y me gusta que se cambie periódicamente de forma automática, de tal manera que vaya rotando entre varios fondos que previamente elegí.

Para hacer esto usaba Desktop Drapes. Un pequeño programita que hacía justo lo que yo quería que hiciera.

Sin embargo, revisando la lista de wallpapers por default de la nueva versión de Ubuntu, encontré uno llamado Cosmo que ya es un slideshow y sin instalar ningún programa adicional.

Lo que descubrí fue que los wallpapers que están disponibles para todos los usuarios se encuentran enumerados en arcihvos XML en el directorio /usr/share/gnome-background-properties. En la instalación por default de Ubuntu hay dos archivos, uno que contiene todos los fondos estáticos, y uno llamado Cosmo.xml para el slideshow, que en lugar de apuntar a una imagen, señala a oto archivo xml.

El archivo al que apunta es /usr/share/gnome-background-properties/ubuntu-wallpapers.xml

En este archivo se listan todas las imágenes que conformarán el slideshow, cuanto tiempo permanece cada una y como son las transiciones entre ellas. Evidentemente no las va rotando al azar, lo cual me hubiera gustado poder especificar, pero algo es algo

En todo caso, hasta ahí llegó mi investigación por el momento. Los formatos de los XML son bastantes simples y creo que cualquiera con un poco de experiencia en xml y paciencia podría crear los suyos propios, pero me encantaría ver alguna aplicación que permita configurarlos fácilmente, ya que no encontré otra forma, que no sea manualmente para modificarlos, al menos por ahora.

Por ser algo que me interesa seguiré investigando el tema un poco más, pero si alguien sabe como configurar los fondos de escritorios fácilmente para hacer slideshow o descubre algún otro dato interesante, está más que bienvenido a compartir su conocimiento y experiencia con nosotros en este blog.

En linux es ampliamente usado un programa muy similar, pero que se llama, y no por casualidad, Midnight  Commander

El uso del teclado en MC (Midnight Commander) es igual a como era en DOS, incluso el hecho de que para salir se debe presionar F10, pero esta tecla tiene un significado especial en la terminal de gnome, que es abrir el menú File, entonces no nos queda forma fácil, desde teclado, de cerrar el programa.

Hoy encontré el blog Diario Linux en donde explican como desactivar la asociación del F10 con el menú File, pero en uno comentario, se menciona que para salir del programa era suficiente presionar ESC-0 (presionar y soltar escape,  y luego el numero 0, no es necesario mantener presionado nada)

Admito que me sorprendió lo fácil que era y que además funcionara bien !

En ese mismo blog se explican, en los comentarios, formas más fáciles de darle al F10 el comportamiento esperado en la termina de gnome.

Hoy me sucedió que quería ver un archivo que estaba en la papelera de reciclaje desde la linea de comando. Como era mi costumbre traté de buscarlo en el directorio ~/.trash pero para mi sorpresa, ese directorio no existía más.

En este artículo comentaré el nuevo funcionamiento de la papelera de reciclaje, donde se la puede encontrar, y demás cosas que vaya descubriendo.

En un post anterior, comenté al pasar que no había un estandar para la papelera de recicjale entre diferentes sistemas de escritorio como kde o gnome, por lo que cada uno manejaba este tema como creía mejor.

Pero ahora existe la Freedesktop.org Trash Specification que precisamente dice el formato común que deben seguir las papeleras de reciclaje. (Técnicamente ya existía pero yo no la conocía y al menos gnome no la usaba, y siendo aun mas puntillosos aun es un Draft)

Ubicación de la papelera

La especificación prevee varias papeleras de reciclaje. Al igual que lo hacía anteriormente gnome, puede haber una papelera en el mountpoint de cada partición y una papelera en el home de cada usuario. Según la especificación solo la papelera en el home es obligatoria.

A grandes razgos, la ubicacion que se usa para la papelera se determina de la siguiente manera:

• Si se borra un archivo que esta en la misma partición que el home del usuario se utiliza la papelera que se encuentra en ~/.local/share/Trash
• Si el archivo no esta en la misma partición, pero existe en el root de esa particion (el mountpoint) un directorio llamado .Trash, dentro de ese directorio se crea otro directorio cuyo nombre será el UID del usuario y ese directorio ser usará como Trash
• Si el archivo no es de la misma particion que el home, y no existe un directorio .Trash (o no se tienen permisos) se crea en el mounpoint un directorio llamado .Trash-<UID>, donde UID es el numero que identifica al usuario que esta borrando el arcihvo.

Como se ve, hay varios lugares posibles para una papelera de reciclaje y a todos hay que tenerlos en cuenta. Además, los progrmas viejos, que no siguen esta especificación tal vez esten moviendo los archivos que borran al viejo directorio ~./Trash por lo que hay aún mas lugares que revisar.

Estructura interna

Antes la papelera de gnome solo contenía arcivos borrados, pero no habia forma de saber cual habia sido el directorio desde el que fueron borrados, ni cuando habian sido borrados. (creo que la papelera de kde hace rato posee esta clase de información). La papelera era, básicamente, un directorio en donde simplemente se movian los archivos que eran eliminados. Y si había dos archivos eliminados, con el mismo nombre, sin importar si fueron elimindos desde lugares o fechas distintas, el ultimo pisaba al primero. Simplemente no podian ir a la papelera dos archivos que se llamaran igual

Ahora esto fue mejorado, pero a su vez se complicó un poco la estructura interna de la papelera. La papelera cuenta ahora con dos directorios. Uno llamado files y otro llamado info. En el primero se mueven los archivos eliminados (o copian segun la implementación). El nombre con que se mueven no tiene por qué ser el mismo nombre que tenían anteriormente (aunque es recomendado que sean similares almenos) . Esto es así para poder permitir que se borren archivos con el mismo nombre, o en diferentes momentos, sin que se pierda el anterior. La idea de mantener un nombre similar al orignal es para ayudar, si es necesario, a una recuperación manual del archivo.

En el segundo directorio, info, se crea un archivo que debe tener exactamente el mismo nombre que el archivo que se está borrando, pero debe agregarsela al final .trashinfo. Si borro, por ejemplo el archivo “malid-0006.jpg” en mi home, y este se mueve a la papelera con el nombre “~/.local/share/Trash/files/malid-0006.jpg“, se debe crear un archivo llamado “~/.local/share/Trash/info/malid-0006.jpg.trashinfo”.

Este archivo .trashinfo tiene un formato similar a los archivos .desktop (para hablar en forma clara, es como un archivo .ini de windows). Debe contener una sección llamada [Tras Info] y dentro de esta dos atributos, uno llamado Path y otro llamado DeletionDate.

Por ejemplo e archivo trashinfo que se genera cuando borro una imagen llamada malid-0006.jpg es el siguiente:

[Trash Info]
Path=/home/fernando/malid-0006.jpg
DeletionDate=2008-05-01T16:00:15

Y este archivo se encuentra en /home/fernando/.local/share/Trash/files/malid-006.jpg.trashinfo.

Gracias a este archivo .trashinfo se puede saber desde donde y cuando fue borrado un archivo. Información muy valiosa para poder luego recuperarlo.

Comentarios personales

Si bien complicaron un poquito como era el tema de borrar un archivo, me parece que era algo necesario de hacer, al menos en gnome, y tambien muy bueno que todos los grandes proyectos lo adopten así se puede tener una papelera unificada y predecible.

Lamentablmente, en gnome, aún falta madurar esta nueva papelera. Si bien se pueden borrar archivos y va al lugar correcto, al applet de la papelera sigue siendo igual que siempre. No se puede verla fecha de eliminación de un archivo, ni su directorio original (al menos si muestra su nombre original. gnome usa para los nombre de los archivos en el trash el mismo nombre del archivo, y si ya existe le agrega al final un contador. por ejemplo, mi archivo malid borrado dos veces quedaría malid-0006.2.jpg.

Otra crítica que yo le hago a gnome, es que no mantiene automaticamente la papelera. si yo borro algo, este algo queda en la papelera para siempre o hasta que yo me acuerdo de borrarlo. Si ademas tenemos un sistema con muchos usuarios y uno borra cosas pero jamas borra la papelera, esta quedará por siempre ocupando espacio que los otros pobres usuarios no sabrán en que está siendo consumido. (obviamente un administrador de sistema puede detectar este tipo de cosas, pero es mas trabajo para el administrador que sería yo y soy muy vago)

Fuer ade esas criticas, me parece un excelente paso adelante y seguramente veremos florecer en poco tiempo una plétora de aplicaciones y herramientas que harán uso de este nuevo estandar de maneras que escapan a nuestra imaginación.