Conociendo el terminal #9: Instalar paquetes .deb con dpkg

Voy a ir retomando la serie sobre el terminal, que tenía un poco abandonada con tanta vídeo-distro y demás historias. Y para empezar, un capítulo (grabado hace tiempo ya) sobre el comando dpkg. 

Trucos Ubuntu: Recuperar la conexión a Internet después de suspender

Para abrir boca esta semana os traigo un truco para solucionar un problema bastante desquiciante, al menos en mi caso. Si soléis usar la función de suspender y habéis actualizado Ubuntu a su última versión, probablemente habréis sufrido un bug bastante gordo, que rompía la conexión a Internet después de recuperar el equipo de la suspensión. No sé vosotros, pero a mi me entraron ganas de cometer atroces crímenes al comprobar que el error ocurría de una forma más o menos masiva, y lo que es peor, es algo que viene ocurriendo de forma "aleatoria" desde hace bastantes versiones. No me digáis que no es para ponerse a afilar las bayonetas, en fin...

Conociendo el terminal #8: Limpieza de paquetes

Con este vídeo retomo una serie que había dejado un poco de lado en los últimos tiempos, y que espero ir completando poquito a poco. No en vano los linuxeros somos fieles defensores de esta herramienta con aspecto arcaico pero tan cómoda que es el bendito terminal.

Software Linux: Undistract-Me

Atención: este programa lleva años sin soporte, id al final del artículo para obtener más información.

Para abrir la semana con buen sabor de boca os traigo un pequeño programa que añade una funcionalidad curiosa al terminal: un sistema de notificaciones para comandos de larga duración.

Lo cierto es que la aplicación es tan simple y la idea tan estúpidamente brillante que no me extrañaría que terminase convirtiéndose en una función por defecto en las versiones futuras de los terminales básicos de la familia ubuntera. Eso si lo vemos desde el lado optimista, desde el punto de vista negativo resulta increíble que algo como esto no exista desde tiempos inmemoriales.
Como menciono en el vídeo, las condiciones para que esta aplicación funcione son las siguientes:

• El comando tiene que durar más de diez segundos. Si fuese menos las notificaciones resultarían invasivas.
• El terminal tiene que encontrarse en segundo plano o minimizado; una notificación cuando se supone que estás mirando el terminal es una tontería
• Tenemos que activar la opción "ejecutar el comando como un intérprete de conexión" que se encuentra en la pestaña "título y comando" de las preferencias del perfil:

Y poco más hay que añadir; yo uso este sistema de notificaciones desde hace un buen tiempo y lo cierto es que se agradece no tener que andar comprobando que los comandos largos han concluido. Le debemos este inteligente detalle a Johnathan Lange, quien pone a disposición de todos nosotros el programa a través de su espacio de Launchpad, su página web y la ppa correspondiente:

sudo add-apt-repository ppa:undistract-me-packagers/daily 

sudo apt-get update 

sudo apt-get install undistract-me

En resumen, una aplicación humilde, que representa un simple complemento para nuestros terminales, pero que aporta una conveniente dosis de comodidad y, sobre todo, de sensación de integración con nuestros flamantes entornos gráficos. O sea, un "must have" con toda la barba.

ACTUALIZACIÓN MAYO 2016:

Tras un montón de años, por casualidad he revisado este programa y he visto que lleva sin ser actualizado desde hace el mismo montón de años. Por ello, os recomiendo encarecidamente que ignoréis estas instrucciones y que, si os sentís con ánimos suficientes, os paséis por el github del programa, os descarguéis el código fuente y compiléis vosotros mismos. Una pena...

Conociendo el Terminal #7: Tareas básicas de supervisión del sistema

Pues a no ser que se os ocurra alguna cosa importante, esta serie ha terminado... La verdad es que esto del terminal daría para una telenovela infinita, en definitiva se trata de un sistema operativo en sí mismo y hay miles de secretos para conocer. Así que esta serie, más que terminar, se va a tomar un descanso mientras preparo nuevos capítulos para más adelante. Bueno, en realidad esta última frase está encriptada y en realidad donde digo "para más adelante" quiere decir "para cuando aprenda más cosas y sepa explicarlas adecuadamente".
Este que nos ocupa hoy es un batiburrillo de comandos que he englobado en el genérico de "supervisión del sistema", más que nada porque no se me ocurría otro nombre que darle. En realidad se trata de una lista de órdenes sencilla que sirven para diversas tareas, y si tienen algo en común es que sirven para tenerlo todo bajo control.
En principio los puntos que más pueden interesar tener en control son los siguientes:

• Procesos en funcionamiento y procesadores: comandos top, htop, killall
• Memoria RAM comando free
• Discos duros comando iostat
• Red y conexión a internet comando netstat

Y teniendo en cuenta este listado, mi tarea ha consistido en seleccionar uno o dos comandos importantes para cada uno de ellos. En realidad el objetivo, como de costumbre, es acercar a los usuarios inexpertos a principios básicos de manejo de ordenadores desde la "filosofía GNU", que más allá del software libre propiamente dicho, defiende que los usuarios de aparatos tecnológicos deben adquirir conciencia y autonomía para poder utilizar sus máquinas de una manera eficiente. En este sentido, estoy seguro de que mucha de la gente que conocéis y que accede a las computadoras lo hace de una forma inconsciente, desconociendo qué es lo que pasa realmente dentro de esa caja que de vez en cuando pita y ronronea como un gato. Como de costumbre, el terminal es una herramienta ideal para llevar a cabo este tipo de pedagogía.
Por supuesto, para la mayoría de estos comandos existen alternativas gráficas que se pueden utilizar en prácticamente todos los entornos de escritorio. No obstante, creo que, de nuevo, la intervención del terminal es recomendable, pues aligera mucho todas estas tareas a poco que nos aprendamos de memoria los comandos correspondientes a cada cosa. Órdenes como top, free o netstat deberían ser de obligado conocimiento. 
En cuanto a las herramientas que no vienen por defecto en distros de la familia Ubuntu (desconozco si en otras estarán disponibles), recomiendo por su vistosidad htop, que muestra de una manera más clara la información sobre procesos, y que tiene funciones realmente potentes.

me gustaría terminal este artículo, que marca una pausa en la serie sobre la venerable línea de comandos, con una reflexión sobre el terminal. De la mano de mi contacto googleplusero Mathias Mckeenan he conocido este meme, cuyo contenido es bastante interesante:

Desde mi punto de vista este mensaje debe ser "de consumo interno" para los linuxeros más veteranos, me explico: estoy completamente de acuerdo en lo que dice sobre el terminal, pero yo no trataría de convencer a nadie de que Linux mola por la consola. Linux "debe" ser "vendido" (cuántas comillas) a los ventaneros tirando de los argumentos conocidos: seguridad, gratuidad... y en menor medida de otros argumentos no menos famosos: libertad, solidaridad, independencia, principios, etc. Separo todas estas razones en dos grupos porque las segundas, y todos deberíamos ser conscientes de ello, no son importantes para los usuarios ajenos al Software Libre. Son principios que se van adquiriendo con el tiempo, que te terminan convenciendo y enamorando o que, sencillamente, te dan lo mismo. Pero los primeros sí pueden ser convincentes.
Es tras un proceso de "conversión" casi religiosa, cuando te das cuenta de que, en efecto, el terminal es una pasada. Cuando te das cuenta de lo práctico que resulta, del tiempo que ahorras, y de los descubrimiento que vas haciendo con cada investigación que haces sobre una nueva funcionalidad en la red de redes. ¿Por qué recomiendo usar estos comandos en lugar de sus correlatos en modo gráfico? Por una sencilla razón, que se resume en una máxima: ten siempre un terminal abierto, siempre a mano.  En seguida te darás cuenta del tiempo que estabas perdiendo buscando aplicaciones tontas.

Conociendo el terminal #6: Compilación Básica

Nos acercamos al final de la serie dedicada al terminal, y después de cinco capítulos de contenido bastante asequible, por fin nos metemos en harina. Así y todo, estoy convencido de que muchos de vosotros le perderéis el miedo al tema de la compilación tras ver el tutorial de hoy. Bueno, en realidad perderíais ese miedo al ver cualquier tutorial o entrada de blog o cualquier fuente de información donde aclaren los pasos de la compilación en Linux, que en realidad es un acto bastante sencillo de hacer a poco que nos organicemos y, sobre todo, recordemos que hay unas cuantas variantes en este asunto. La que os presento en el vídeo, aderezada con algunas alternativas, es la que se considera clásica, y representa un gran porcentaje de las posibilidades que os encontraréis por esos pagos de internet.

Por qué la compilación mola

En realidad la compilación ni mola ni deja de molar. Lo que de verdad está bien y resulta emocionante es lo que está en el fondo de este proceso: la posibilidad de instalar un programa en cualquier sistema que atienda a unos estándares, da igual cómo esté construido. Si tenemos las herramientas y conocimientos adecuados, contar con el código fuente garantiza que podremos ejecutar un programa. Esto que parece algo anodino en realidad constituye la magia y el milagro del Software Libre. Por que estos códigos fuentes almacenados en un simple tarball son libremente modificables si están, eso sí, bajo la correspondiente licencia que lo permita legalmente. El código fuente liberado significa progreso porque nos involucra a todos en el trabajo de mejora y desarrollo de los programas. Y encima poder utilizar de manera práctica el código fuente de un programa es una tarea sencilla. Son tres pasos, como indico en el vídeo. Que algo en realidad tan complejo se pueda hacer con un puñado de comandos es lo que hace que Linux sea, se pongan como se pongan, el sistema operativo más potente que existe. Más que nada porque el propio sistema operativo también es libre. El que opine lo contrario es idiota.

Algunos consejos

No soy quién para dar consejos, que para algo tengo muy a gala no tener ni pajolera idea de programación, pero sí que puedo aportar algo de mi corta experiencia con estas cosas. Una idea que conviene tener en cuenta es echarle un vistazo al tarball que nos hayamos descargado. Examinando los archivos que contiene el fichero comprimido podremos hacernos una idea de las posibilidades y estrategias de compilación/instalación que deberemos seguir:

Los archivos que veis en la imagen superior son los típicos que nos encontraremos. Básicamente todos suelen tener el mismo tipo de información:

• Readme: este es de los importantes; es el que nos informa de cuáles son los pasos que tendremos que hacer, las dependencias necesarias y la estrategia concreta de compilación o instalación. también lo podréis encontrar con el nombre de LÉEME, en castellano. 
• Manifest: Suele contener una descripción del programa, con sus funciones, historia de la aplicación, autores... A veces también aparece con el nombre de Authors. 
• Copying: La licencia de uso. Es importante conservarla, por si algún pesado no toca las narices en algún caso improbable. 
• Todo: "cosas por hacer"; nos cuenta en qué están trabajando los desarrolladores de cara a la próxima versión del programa.
• License: Parecido a Copying. Guardadlo, es lo más parecido a una factura que existe en el mundo GNU. 
• Configure: Este es el más importante de todos. Si existe este fichero, es que efectivamente podemos compilar mediante el procedimiento típico. Y si no existe, entonces ya sabemos que no se compila de la misma manera. Toca localizar otros archivos: ejecutables (se distinguen por un icono característico), scripts de ejecución (con diferentes extensiones: .sh, .py, .run...), etc. En cualquier caso, el readme es nuestro amigo, nos indicará cuál es el camino que debemos de seguir.  

Otro tema que os puede llamar la atención es el asunto de la forma que utilizo para descomprimir los archivos del código fuente. Uso el procedimiento gráfico, mediante un clic secundario sobre el tarball y "descomprimir aquí". Generalmente en los tutoriales que circulan por internet se usa un procedimiento basado en comandos para realizar la misma tarea. El comando en cuestión es uno de los siguientes:

tar xvf nombre_del_archivo.tar
tar xvfz nombre_del_archivo.tar.gz
tar xvfj nombre_del_archivo.tar.bz2

Cuál debemos elegir de los tres dependerá de la extensión del archivo comprimido. Y para ser transparentes, vamos a examinar qué significan esas letras que van detrás de la orden tar:

• x: (extract) le decimos a tar que se ponga a extraer archivos como si no hubiese un mañana.
• v: (verbose) le ordenamos a tar que nos vaya enseñando un listado de los archivos que va descomprimiendo. Esta orden es opcional, si no la ponemos tar descomprimirá "en silencio" y no tendremos información en pantalla sobre los archivos que se van descomprimiendo. No obstante su uso es obligatorio si hay alguien mirando que no tenga conocimientos de Linux: las líneas moviéndose a la velocidad de la luz en una pantalla de terminal siempre quedan muy bien y pensarán que somos unos hackers de quinto dan.
• f: (following) le decimos a tar que descomprima el archivo siguiente. 
• z / j: (la z viene de zip, y la j supongo que de Jen0f0nte, agradezco el homenaje tardío pero merecido) El uso de una de estas dos letras dependerá de la extensión del archivo. z es para el método de compresión llamado gzip, con extensión .tar.gz, y j es para el método de compresión bzip2, con extensión .tar.bz2; si el .tar no tiene más extensiones, no ponemos nada, que tar (el programa, no la extensión) ya sabrá de qué va el asunto. 

Vamos, un follón. Al final lo único que importa es que la carpeta resultante tenga sus correspondientes permisos de lectura y escritura (porque otra cosa no, pero la compilación es una orden que implica lecturas y escrituras de archivo a punta pala). Si hacéis la extracción en un directorio que tenga permisos para vuestro usuario, no habrá problema. No obstante podéis verificar esto haciendo clic derecho sobre la carpeta descomprimida y comprobando en la sección permisos que todo tiene esta pinta:

Por si acaso queréis estar completamente seguros, podéis hacer clic sobre el botón inferior que pone "aplicar permisos a los archivos contenidos". Toda precaución es poca...
No obstante con el método gráfico tenemos el mismo resultado sin tener que aprendernos de memoria los códigos, así que lo dejo a vuestra elección (y quizá usáis una distro muy rara que no incluye la opción de descomprimir al hacer clic derecho, ya sabéis que hay más distros que longanizas). Por cierto, en este enlace tenéis una buena guía sobre muchas de las posibilidades del programa tar en línea de comandos. Realmente potente, oiga.

El problema de las dependencias

Quizá sea este el único defecto de la instalación mediante código compilado. Según los casos, compilar un programa puede ser tan fácil como ejecutar los consabidos ./configure, make y make install, o tan agotador como construir un árbol de dependencias lleno de ramificaciones inextricables. En este sentido, conviene tomárselo con paciencia y con un poco sentido común.

¡Ajá! Si hay ./configure, la compilación es de las típicas

Recuerdo que cuando empecé con esto de Linux, hace menos años de los que pensáis, una de mis primeras hazañas fue intentar compilar un programa de edición gráfica basado en Gimp llamado Cinepaint. Animado sobre todo por mi desconocimiento, comencé la tarea tirando de intuición, y leyendo el README del archivo comprimido (tardé en darme cuenta de que un archivo tar.gz es un archivo comprimido) fui haciendo paso por paso. Os lo creáis o no, lo conseguí. Eso sí, al no tener ni idea de que compilar un programa puede llevar tiempo de procesamiento, lo hice en mi fiel netbook, que por aquel entonces sufrió (y mucho) el proceso de aprendizaje sobre esta plataforma; la compilación duró alrededor de cuatro horas, sin contar el tiempo que tardé en instalar todos los paquetes de dependencias. Pero lo conseguí. Esta fue una de las cosas que creo me convencieron de que Linux molaba. Si yo podía hacerlo, es que Linux estaba bien pensado. Eso sí, debo confesar que jamás he conseguido volver a instalar Cinepaint, supongo que por alguna dependencia obsoleta. En cualquiera de los dos casos, son claras muestras de las dos condiciones que ponía al principio. Paciencia: si hay muchas dependencias y el programa es grande, la cosa puede llevar horas. Sentido común: cuanto más raro o antiguo sea un programa, más probabilidades hay de que la compilación sea o muy difícil o directamente imposible.
Hay otro problema colateral que puede dificultar la compilación: el hecho de que, nos guste o no, el lenguaje de la informática es el inglés. Aquí la solución es obvia: un cursillo acelerado si no conocéis el idioma previamente. En muy raras ocasiones me he encontrado con programas cuyas instrucciones estén escritas en la hispánica lengua. De hecho, en el vídeo os muestro el ejemplo de turpial, pulcramente explicado en castellano, pero que os prometo fue algo fruto de la más pura casualidad. No creo que en el fondo esto sea algo criticable; el inglés, nos guste o no, es la lengua franca planetaria y hay que aceptarlo como un hecho. Pero hay que reconocer que la cosa se vuelve más difícil si no nos manejamos mínimamente con el idioma  de Shakespeare.

¿Merece la pena compilar aplicaciones?

Sí y no. La mayoría de las veces no va a ser necesario hacerlo. Los programas precompilados, esto es, aquellos programas que ya han sido compilados por sus desarrolladores y comprimidos en paquetes autoinstalables (.deb, .rpm) son en la actualidad la manera más sencilla, cómoda y limpia de instalar un programa en nuestro sistema. Sólo en algunos casos podría ser conveniente la instalación desde el código fuente, sobre todo en algunos muy determinados en los que será beneficioso compilar con alguna opción "extra". En la siguiente imagen, por ejemplo, nos encontramos con estas opciones especiales para el programa Ufraw:

Opciones extra de compilación para Ufraw

En algunas ocasiones estas opciones nos brindan nuevas o mejores funcionalidades que no vienen "por defecto" en el programa precompilado; en otras, y estas son las más importantes, una compilación adaptada puede ayudarnos a que un programa que nos daba problemas pueda funcionar correctamente en nuestra distribución. ¿Cómo sabremos cuándo es conveniente una cosa o la otra? He aquí otra de las cosas buenas que tiene Linux: tendréis que estudiar para averiguarlo. Los usuarios de Linux, que somos libres, tenemos en nuestra mano que todo funcione como debe. Para ello contamos con la, en general, buena y completa documentación de cada programa, con páginas y páginas web que dan la información que necesitamos... incluso hay algunos locos que se dedican a hacer tutoriales grabados en vídeo con el fin de echar una mano a los demás. Y esto, lejos de ser un defecto de Linux, es su principal virtud. Al convertirnos en corresponsables, nos da la oportunidad de aprender. Y conforme aprendemos, nos volvemos más autónomos, y podemos pasar a ayudar a otros. En otros sistemas la máxima es un poco diferente:

Si no funciona, te jodes fastidias. Tu paga y ya veremos.

Conociendo el Terminal #5: Creación de alias

El capítulo de hoy de la serie sobre el terminal se adentra un poquito más en los misterios de nuestra consola y estoy convencido de que a lo más novatos les va a hacer sentir como verdaderos hackers. En el fondo los alias son un instrumento sencillo y, sobre todo, muy cómodo, pero como todo en este mundo del pingüino, tiene sus secretos.
En el vídeo que os presento la cosa queda bastante bien explicada, o eso creo; para añadir alias nuevos sólo tenemos que editar un archivo que se encuentra en nuestra carpeta de usuario, pero oculto, el muy cabroncete: .bashrc.

Otro día os explico cómo hacer para que todo esto salga en el terminal

Voy a aprovechar este artículo para añadir algunos detalles más sobre el funcionamiento de los alias y el contenido del susodicho archivo .bashrc, aunque naturalmente las posiblidades son prácticamente infinitas.
En primer lugar, el archivo .bashrc contiene unos cuantos alias por defecto, alguno de los cuales está desactivado mediante el símbolo "#" y por lo tanto podemos activar a voluntad; por ejemplo, vamos a ver estas líneas, que he sacado de mi archivo .bashrc, y que estarán en el vuestro también si andáis por Ubuntu (los alias por defecto pueden variar de una distro a otra):

alias ls='ls --color=auto'
#alias dir='dir --color=auto'
#alias vdir='vdir --color=auto'
alias grep='grep --color=auto'
alias fgrep='fgrep --color=auto'
alias egrep='egrep --color=auto'

Vemos que las líneas 2 y 3 de los comandos anteriores están desactivadas; este párrafo corresponde con algunos alias relacionados con los comandos ls, dir y grep. Los dos primeros ya los conocemos, sirven para examinar el árbol de directorios y archivos. Por su parte, grep es un comando que sirve para realizar búsquedas de cadenas en archivos... ya, ya sé que eso es como no decir nada, para conocer grep y otras herramientas de búsqueda de datos tendréis que esperar a otro capítulo... El caso es que todos estos comandos están ahí juntitos por que este apartado de .bashrc controla el aspecto de esos comandos, básicamente los lindos colores que vemos cuando ejecutamos la orden "ls" en el terminal. Si echáis de menos esos colores al hacer un dir, ya sabéis, borráis el signo "#", volvéis a abrir el terminal, y listo. Por cierto, que si os fijáis, cuando ejecutamos el comando "ls", lo que estamos haciendo en realidad es invocar el comando "ls --color=auto" bajo el alias "ls". Las implicaciones lógico-filosóficas de un alias que parece un comando pero que invoca a ese mismo comando las dejo para vuestras propias pajas mentales.
Otra chorrada que está incluida en este archivo es la posibilidad de darle una nota de color al "prompt" (es decir, el encabezamiento de nuestra terminal: usuario@nombredelequipo:~$):

¡Orgía de color! ¡Quién puede concentrarse con esta hemorragia de estímulos sensoriales!

 Para conseguir esto, tenemos que localizar en el archivo las siguientes líneas:

# uncomment for a colored prompt, if the terminal has the capability; turned
# off by default to not distract the user: the focus in a terminal window
# should be on the output of commands, not on the prompt
#force_color_prompt=yes

...y quitar la almohadilla de la última. Reseteamos el terminal, y ya tenemos el prompt de colores. Los muy cachondos ya nos avisan de que esto lo dejan desactivado porque lo de poner el prompt de colores sólo sirve para distraer y es propio de perroflautas u horteras. Nos han jodido, que no nos lo pongan delante...
En el archivo .bashrc hay algunas sorpresas más, pero os recomiendo que le echéis un vistazo vosotros mismos. Es una delicia meterse en estos archivos de configuración y comprobar lo bien explicado que está todo, eso sí, en inglés.
Las capacidades de creación de alias sólo tienen como límites las de la sintaxis del terminal y nuestra propia imaginación. Podemos hacer alias complejos para tareas que requieren un montón de pasos, como por ejemplo tareas recurrentes del tipo: "me meto en esta carpeta, luego en esta otra y ejecuto el programa X con permisos de superusuario". Este tipo de tareas se abrevian escandalosamente con alias, y la forma de crearlos es tan sencilla como editar una línea que una los diferentes comandos mediante el símbolo "&&".
Para terminar el artículo, me permito dejaros a continuación unas cuantas sugerencias, que podéis añadir a vuestros archivos .bashrc y probar a ver qué tal os encontráis en este nuevo mundo de atajos:

#actualiza repositorios
#y aplica actualización al sistema

alias actualizar='sudo apt-get update && sudo apt-get upgrade'

#apaga el ordenador
alias apagar='sudo shutdown -h now'
#resetea

alias reset='sudo shutdown -r now' 

#instala una aplicación 
#(hay que añadir el nombre del paquete 
#después de "instalar")

alias instalar='sudo apt-get remove'
#borra un paquete

alias borrar='sudo apt-get remove'
#examina los procesos que están en ejecución

alias procesos='ps aux'

#elimina y purga un paquete 
#(es decir, lo borra y elimina las dependencias 
#que se instalaron para hacerlo funcionar 
#y que no formaban parte del sistema con anterioridad)
alias purgar='sudo apt-get --purge remove'
#comprueba espacio en los discos

alias espacio='df -h -x tmpfs -x devpts -x usbfs' 
#ver estado de memoria ram
alias memoria='free -m'
#tienes más años que Matusalén 
#y recuerdas que hace mil años 
#usabas el MS-DOS 
#y en lugar de cd .. se escribía cd.. 
#para subir directorio
#y lo echas de menos
alias cd..='cd ..'

Si sois capaces de entender todas las líneas que acabo de escribir, enhorabuena, vais por buen camino y empezáis a entender cómo funciona nuestro querido Bash. Podéis copiar y pegar directamente el párrafo anterior en vuestro archivo, y así os ahorráis más trabajo todavía. Por supuesto, se trata sólo de una plantilla que podéis modificar a vuestro gusto: podéis cambiar el nombre del alias si no os parece adecuado el que os propongo. Ojo, si estabais pensando en renombrar el alias "borrar" por "mandar a freír espárragos", conviene saber que no se aceptan alias con varias palabras separadas por espacios, así que tendréis que utilizar los típicos guiones bajos "_" o escribir todo junto. También podéis bloquear el uso de alguno de los alias añadiendo la almohadilla al principio de la línea que más rabia os dé, o sencillamente borrándola. 
Con este regalito termino el artículo de hoy; sólo me queda agradecerle a RafaGCG la sugerencia para la elaboración de este capítulo, e invitaros a los que conozcáis más alias útiles que me los hagáis saber para completar nuestra colección.  

Conociendo el terminal #4: Gestión de paquetes (en Ubuntu)

El capítulo de hoy va a ser de especial utilidad, sobre todo para mi... con él me voy a ahorrar que algún despistado me pregunte qué es eso del "sudo apt-get update", etc. que añado en cada análisis de una aplicación... Les enlazo a este tuto, y listo.
Aunque este es uno de los capítulos más sencillos de la serie, encierra algunos de los elementos que convierten a Linux en un sistema especial. Por un lado, el concepto de "paquete" que, lejos de referirse a un mal jugador de fútbol, que también, en este caso alude a los ficheros de programas del sistema. Estos paquetes tienen varios papeles en el funcionamiento de Linux. Pueden funcionar como "controladores" para los programas propiamante dichos, intermediando entre estos y el sistema y dotando de funcionalidades a las aplicaciones, o haciendo que estas se comuniquen entre sí. Son las denominadas "librerías". Estas librerías son compartidas entre las aplicaciones, de forma que todas recurren a las mismas si necesitan hacer la misma función. Las aplicaciones, por su parte, requieren de estas librerías para instalarse, y el sistema nos avisará si carecemos de algunas de ellas. En estos casos hablamos de las librerías como "dependencias" de una aplicación. Es decir, las librerías de las que depende un programa para funcionar. Pues bien, en lo que al terminal se refiere, tanto librerías como aplicaciones son paquetes exactamente iguales a la hora de instalarse y eliminarse. Así, todo el funcionamiento del sistema se vuelve absolutamente transparente en la medida en que conozcamos la función de las librerías implicadas, y podremos tomar decisiones sobre la conveniencia de una instalación basándonos en el conocimiento que tengamos sobre la estabilidad o rendimiento de una librería en concreto.
Esto que suena tan técnico y tan complicado se vuelve bastante sencillo y mecánico con la práctica. Basta con conocer el funcionamiento de nuestros gestores de paquetes, bien sean gráficos o por terminal. En este sentido, creo que ningún gestor gráfico suplantará al 100% al terminal para este tipo de trabajos, así que es más que conveniente conocer cómo hacerlo funcionar.
La mayor parte de comandos básicos ya los explico en el vídeo, así que permitidme que aporte algún truco más que quizá os sea de utilidad. Un procedimiento que ahorra bastante tecla es el de enlazar comandos mediante el símbolo &&, como en el siguiente ejemplo:

sudo apt-get update && sudo apt-get upgrade

Parece una chorrada pero ahorra tiempo; eso sí, recordad que cada comando necesitará su correspondiente "sudo", al menos en el ejemplo que os indico. La lista de comandos que podemos enlazar mediante este procedimiento es ilimitada.
Otro "atajo" muy interesante es la capacidad de un comando de añadir cuantos parámetros deseemos. Por ejemplo, podemos instalar programa tras programa mediante un solo comando:

Un viejo comando que usé unas cuantas veces en la época de Maverick Meerkat. Fuente del comando: ubuntulife

Si sumamos ambos trucos podemos ahorrar un montón de tiempo si somos de los que tenemos que reinstalar el sistema habitualmente. Basta con ir coleccionando los repositorios y programas que necesitamos en un archivo de texto, y luego pegar el contenido en un terminal tras la reinstalación. El único problema de este método es que hay que escribirlo todo correctamente; un error y el trabajo del terminal se detendrá. Por supuesto, daré la bienvenida a otros truquitos y consejos que sobre esta materia tengáis a bien aportar, así que no os cortéis.
Por último, y en prueba de mi respeto por otras distribuciones, sobre las que no hago tutoriales en profundidad no por manía o desidia, sino por puro desconocimiento, me gustaría compartir con vosotros una pequeña tabla comparativa en la que se despliegan los comandos más importantes para diferentes gestores de paquetes bajo terminal. Aunque hay unos cuantos más de los que hay en la imagen, creo que están los más importantes: apt (Debian y derivados), yum (Red Hat y familiares), pacman (Arch y allegados) urpmi (Mandriva y acólitos), slaptget (Slackware y... eso, Slackware), emerge (Gentoo y sus amiguetes) y zypper (Suse y colegotas). No están todos los que son, pero...

Clic para ampliar

Conociendo el terminal #3: Gestión básica de archivos y carpetas

Este es otro capítulo sencillo y simple en el que tratamos de rascar la superficie del terminal; las capacidades de este programa son mucho mayores, y conforme vayamos avanzando iremos repasando algunas de ellas. Pero como conviene ir poco a poco, para no asustar al personal recién llegado, hoy repasamos algunas opciones básicas para jugar con archivos y carpetas.
Como vimos en anteriores entregas, el terminal se comporta como un emulador del sistema completo, pero en modo texto. Por lo tanto, todo lo que podemos hacer en nuestro escritorio gráfico podemos hacerlo en la consola mediante comandos.

En el caso de la gestión de archivos, he decidido repasar las tareas más simples que llevamos a cabo con nuestros navegadores de ficheros habituales: copiar y mover archivos, crear y borrar carpetas y navegar por nuestro árbol de directorios.
El vídeo deja la mayoría de comandos más o menos claros, y como podéis comprobar el movimiento entre archivos y carpetas es bastante sencillo, teniendo en cuenta algunas cosas un tanto especiales:

• Cuidado con las mayúsculas y las minúsculas. Aunque en el vídeo digo que Linux distingue entre unas y otras, esto es falso. Dependerá del formato de disco de vuestras particiones. Si estáis en una partición formateada en FAT, por ejemplo, el sistema no las distinguirá. En formatos tipo Ext, sí las distingue.
• Atención también con los nombres separados por espacios: como indico en el vídeo, la forma correcta de escribir un nombre de archivo que conste de dos partes separadas por un espacio es la siguiente: "primeraparte\ segundaparte", es decir, las dos palabras separadas por un espacio, pero con el símbolo \ inmediatamente después de la primera palabra. 
• Ojito si andamos piruleando por el directorio "/". Sí, es otra barra, pero esta vez inclinada hacia el otro lado. El directorio que se representa sólo mediante la barra es el directorio de sistema, y si tocáis cosas por esos territorios ignotos sin saber muy bien qué hacéis, destruiréis el sistema y se os llenará la habitación de orcos furibundos. 
• Cada comando en el terminal se puede modificar mediante opciones. Para saber las opciones de que disponemos basta con escribir "man + nombre del comando". Las más comunes en este terreno de la gestión de archivos son "-a" (viene de "all" y suele servir para ampliar la capacidad de un comando), -R (significa "recursivo" y generalmente suele servir para que la acción afecte también a subcarpetas y archivos que estén incluidos en ellas). Hay un montón más, aunque afortunadamente su conocimiento no es imprescindible. Están para ayudar a hacer las tareas más rápido, no para asustar al personal.
• Y un guiño a los veteranos del MS-DOS: para subir al nivel superior en un árbol de directorios se escribe "cd ..", con un espacio entre el cd y los puntos.Los más viejunos sabéis de qué hablo.

Y como de costumbre, os dejo la "chuleta" para tener la colección de comandos a mano en cualquier momento. Y además con algunos más de los que digo en el vídeo, para que nadie se queje.

Clic derecho y "guardar archivo como..." para descargar

Supongo que me habré dejado unos cuantos, así que se abre la veda para que los que sabéis de esto completéis el artículo con más comandos. Aviso: ¡en este capítulo sólo valen los que tengan utilidad para el manejo de archivos y carpetas!

Conociendo el terminal #2: Atajos de teclado

Será que ya tengo más años que Matusalén (para los estándares actuales) y tengo cogida la manía desde los tiempos de MS-DOS, el caso es que uno es más que aficionado a los atajos de teclado. Por eso suelo insistir en este asunto en casi todas las series dedicadas a analizar programas de mi canal de Youtube. Conocer los atajos de teclado tiene dos ventajas importantes:

• Te convierte en una especie de gurú informático entre tus allegados, aunque en realidad no tengas ni pajolera idea de ordenadores. Cuando un colega te pide ayuda con alguna chorrada, tu te acercas a su ordenador, rechazas con gesto displicente el ofrecimiento del ratón y haces un par de pases mágicos, sin darle tiempo a comprobar la combinación de teclas que has usado, alcanzas un pequeño nirvana sólo al alcance de taumaturgos, alquimistas y demás conocedores de arcanos no aptos para la plebe. 
• Es práctico.

Atendiendo sobre todo al segundo punto, más aún en el caso del programa que nos ocupa, se hace especialmente interesante memorizar algunos de los atajos que os propongo en este vídeo. Sobre todo aquellos que están dirigidos a las correcciones de comandos y a la localización de estos, ambas tareas tediosas y de las que más incómodo hacen el trabajo con la consola.
De todas formas, debo confesar que esta pequeña guía está especialmente orientada a los terminales propios de terminales Debian - Ubuntu, que son los que conozco. Creo, pero no estoy muy seguro de ello, que determinadas combinaciones son diferentes en escritorios KDE u otros. Lo mejor, como siempre, es ir probando a ver qué funciona y qué no. Por mucho miedo que dé el terminal, no os cargaréis nada probando combinaciones de teclas.
Eso sí, para completar el vídeo-artículo de hoy y de la misma manera que hice en su día con el tutorial dedicado a los atajos de Nautilus, os dejo una plantilla con una lista ampliada y ordenada, para que la podáis guardar por ahí en una carpeta perdida de vuestro sistema. Está bajo licencia Creative Commons, lo que os da carta blanca para hacer con ella lo que gustéis, así que compartidla, seguro que hay gente que lo agradece.

Clic derecho y "guardar destino como..." para descargar

Tras estos dos capítulos más o menos introductorios, a partir del siguiente nos empezaremos a meter en profundidades... pero estad tranquilos, entre que yo no tengo conocimientos suficientes y que no considero necesario el uso del terminal "para todo", tengo planeado un repaso a las funciones que considero verdaderamente importantes. Según "mi verdad", como dicen las folclóricas.  

Conociendo el Terminal #1: Introducción

Pues aquí tenemos una de las sorpresas que prometí el sábado pasado: una serie dedicada a nuestro humilde compañero en Linux, el terminal.
Debo advertir a los lectores que esta serie está orientada a neófitos en esto de Linux, labor que ya sabéis ocupa la mayor parte de los contenidos que están bajo mi responsabilidad en este blog. Encontraremos en ella, por lo tanto, un guía de iniciación al uso de este intérprete de comandos que es al mismo tiempo uno de los programas más potentes y útiles de todo el sistema, y una de las principales causas de repulsa entre los desconocedores de su funcionamiento.
Conforme avanza el mundo de la tecnología y de la informática, y se desarrollan entornos de escritorio cada vez más potentes y coloristas, la sensación de que el terminal es un vestigio del pasado se hace cada vez más patente. En ese sentido, quizá los más veteranos nos sintamos "sentimentalmente unidos" a esta sencilla línea de comandos; quien más, quien menos, los aficionados a la informática que superen la treintena se habrán encontrado en alguna ocasión con esta pantalla negra y su cursor parpadeante, reclamando atención, orgullosamente dispuesto a desafiar nuestro conocimiento de las palabras mágicas que lo pueden poner a trabajar. Y en el caso opuesto, los más jóvenes, que sólo conocerán de oídas términos como "MS-DOS" o "cmd", fruncirán el ceño ante las antediluvianas líneas bidimensionales y en 16 colores de la consola.

El terminal, ese incomprendido

Por eso creo que es muy recomendable que aquellos de vosotros que conocéis a fondo el funcionamiento y la filosofía que se esconde detrás de los sistemas Linux enfoquemos el asunto del Bash de la manera más natural y sencilla posible. Lejos de ocultar su presencia mediante interfaces gráficas pesadas y redundantes, desde un principio conviene familiarizar a los más nuevos con este programa, y conseguir convencerles de que, con un par de comandos, se pueden hacer las mismas cosas y de manera más cómoda. Naturalmente, esto no es así en el cien por cien de las ocasiones, así que también es importante distinguir aquellos usos para los que el uso del terminal es más eficiente que el de sus homólogas aplicaciones gráficas, y al revés.
Este primer capítulo supone la introducción al conocimiento de las funciones del terminal, y como con el resto de vídeo-manuales, lo dedico enteramente a su interfaz, amén de algunos datos históricos para los más curiosos. Evidentemente, explicar la interfaz del terminal no resulta demasiado complicado, pero todo tiene su intríngulis. Como se puede apreciar en el vídeo, en el terminal todo tiene su porqué y su explicación, no hay ningún símbolo o carácter que no tenga significado.
Este capítulo además sugiere (sin profundizar en ello, que es un lío) el verdadero follón que hay en torno al nombre que le damos a este programa. ¿Consola, terminal, bash, línea de comandos? En realidad todos ellos se utilizan en la actualidad casi como si fueran sinónimos, pero la cosa puede complicarse un poco si somos exigentes con la nomenclatura de las cosas. De los términos citados anteriormente, los que más me gustan son los dos primeros. Tanto "terminal" como "consola" aluden a la más primitiva forma de interacción con una computadora. Como su propio nombre indica, el terminal en origen era el punto en el que el usuario de una red de computadoras (importante lo de la red) podía gestionar la comunicación con otros puntos de esa red. Básicamente se trataba de una pantalla conectada a un ordenador, y un teclado mediante el que introducir datos. Estos elementos hardware, por su carácter de punto de comunicación entre la máquina y el usuario, se denominaron terminales o consolas. Nos encontramos en los primerísimos inicios de la informática actual, estamos hablando de aquellas computadoras del tamaño de una habitación y sus inmediatos sucesores. La cosa se complica históricamente con la aparición de los ordenadores de escritorio; durante los primeros tiempos los usuarios de estas máquinas tenían que convivir con dos máquinas simultáneamente: además del ordenador de escritorio propiamente dicho, un terminal con el que establecer contacto con la red de ordenadores.

Un terminal de texto de principios de los 80. Fuente: Wikipedia

La evidente falta de eficiencia de estos sistemas hizo necesaria la aparición de los emuladores de terminal, que permitían realizar las mismas funciones de comunicación que un terminal físico, pero desde un programa que se podía ejecutar en el ordenador de escritorio; más aún: además de poder funcionar como el antiguo terminal, tratándose de un emulador, se podía hacer funcionar como consola "virtual" para cualquier ordenador de la red que estuviese conectado, mediante normas de autenticación y de obtención de privilegios de administrador de sistema. Así que si hablamos propiamente, lo que tenemos ahora mismo en Linux son emuladores de terminal y no terminales verdaderos. Aunque esta explicación pueda ser innecesaria, creo que sirve para comprender la extraña línea de comandos que nos saluda cada vez que abrimos el terminal: como explico en el vídeo, lo que tenemos es una "frase" en la que básicamente se describe la posición del emulador con respecto a una red: el usuario propietario de ese terminal, la red a la que está conectada la máquina, y la ubicación del cursor en el árbol de directorios. Una frase que, si sabemos interpretarla, funciona como un "mapa" con el que entender a qué partes de nuestro sistema (o de la red en el que esté el sistema) van a afectar las acciones que emprendamos con nuestros comandos.
Con el paso del tiempo, los viejos terminales que eran capaces de mostrar sólo texto dejaron su sitio a los actuales ordenadores personales, que no son más que un terminal más moderno, y capaz de mostrar imágenes y texto. En los sistemas Unix y Linux, bajo el protocolo gráfico X Window System, también conocido como X11. la pervivencia de los emuladores de terminal basados en texto en los sistemas Linux (y en los demás) se debe principalmente a su eficiencia, comodidad de uso (si conocemos los comandos) y fiabilidad. Donde falla un sistema de ventanas siempre funcionará una línea de comandos, y mediante las palabras mágicas adecuadas podemos ahorrarnos incómodos paseos por menús, listados de aplicaciones, clics y más clics de ratón...
Las ventajas del uso del terminal aumentan conforme se compliquen las actividades que queramos realizar, sobre todo aquellas en las que entren en juego diferentes tipos de permisos para interactuar con el sistema. Aquí es donde, en los sistemas Linux, entran en juego los términos "root" y "sudo", con los que finaliza el capítulo.
No tengo demasiado definido el "índice" de contenidos de esta serie (como casi siempre, vaya), pero probablemente contenga los siguientes elementos principales:

• Atajos de teclado del terminal
• El terminal como gestor de archivos
• El terminal como interfaz de ejecución de programas
• El terminal como administrador del sistema
• El terminal como herramienta de programación
• Pijadas sobre el terminal: tuneo, colorines y fuegos de artificio variados 

Insisto en que todavía no tengo claro ni los contenidos ni mucho menos el orden en que aparecerán, pero creo que estos elementos que he citado son de obligado repaso; conforme avance la serie seguramente haré adaptaciones, cambios, adiciones y ampliaciones a estos asuntos. Por lo pronto, el siguiente capítulo seguro que tratará sobre los atajos de teclado (más que nada, porque ya lo he grabado). Eso sí, dudo mucho que me meta en asuntos de nivel demasiado complejo, más que nada porque creo que no son de uso inmediato para el usuario promedio, y además la mayoría de ellos escapan a mis conocimientos. Con lo cual creo que quedan bien definidos, si bien no el contenido, al menos el continente y los límites que lo definen. Como de costumbre, espero que esta serie sea de utilidad, y ahora más que nunca reclamo la ayuda de los que sabéis más que yo para avisarme de meteduras de pata, falta de datos cruciales y esas cosas. ¡A ver si entre todos nos sale algo chulo!

Miniaturas de archivos RAW en Nautilus

Hoy toca vídeo corto y post corto, que aunque no cobremos, de alguna manera tenemos que solidarizarnos con quienes, en la calle o desde las redes sociales, o desde donde sea, manifiestan pacífica y solidariamente su disconformidad con la serie de calamidades políticas, económicas y financieras que nos están llevando a los que menos lo merecemos (la clase obrera) a una situación cada vez más desesperada.
Yendo al tema que nos ocupa, os dejo un vídeo-artículo para solucionar una pequeña pero molesta carencia de las distribuciones de Linux con entorno gnome o similares, la previsualización de miniaturas de archivos RAW en el navegador de archivos por defecto.
Por suerte, y como de costumbre, estas pequeñas dificultades son mucho más fáciles de solucionar en entornos libres que en "los otros". Todavía recuerdo las aventuras buscando información, bajándome códecs de vete tu a saber dónde, y un largo etcétera de vicisitudes para poder ver las miniaturas RAW en el explorador del Windows... Por suerte, en Linux son un par de pasos:

Instalación de Gnome-Raw-Thumbnailer

El primer paso es instalar el programa que facilita la codificación de las imágenes raw en Nautilus, el navegador por defecto de distribuciones Gnome y también de Ubuntu (que con Unity ya no se sabe si es Gnome o no, pero que básicamente funciona con la estructura, dependencias y programas de Gnome). Ojo, hay dos versiones del programa, la de los sistemas de 64 bits y la de los de 32; esta última lleva en su nombre el indicador "i:386" para diferenciarla de la otra. En la mayoría de los casos con este sencillo paso la visualización debería funcionar incluso sin necesidad de cerrar la sesión o reiniciar Nautilus. Si de primeras no funciona, podemos probar esas dos posibles soluciones; y si seguimos sin ver nuestros archivos correctamente, podemos pasar al siguiente punto.

El susodicho programa

Un poquito de código

¿Preparados? ¿Os habéis puesto vuestras gafas de pasta reparadas con esparadrapo? ¿Tenéis a mano una buena bolsa de ganchitos? ¿Habéis colgado en la pared un cartel con un OVNI con el lema "la verdad está ahí fuera"? Bien, en realidad estos pasos previos no son necesarios, pero siempre viene bien ponerse en situación "geek" cuando se trata de abrir el terminal y empezar a "picar código". Aunque, como veréis, la cosa es mucho más fácil de lo que parece o quiero aparentar, para dármelas de entendido.
Abrimos el terminal con Ctrl+Alt+t. También podríamos buscar el programa entre el resto de aplicaciones, pero ya que estamos en este plan, mejor vamos aprendiendo que Linux se maneja mucho mejor si usamos el teclado. Windows también, pero te deja hacer menos cosas.
escribimos lo siguiente:

sudo gedit /usr/share/thumbnailers/raw.thumbnailer

Precioso terminal con horrible logo al fondo

por si no lo conocéis, Gedit es el equivalente en Linux de la "libreta de notas" de Windows, aunque, por supuesto, bastante más potente y útil, dado que nos permite modificar archivos de sistema sin demasiadas dificultades. Por esa razón necesitamos abrirlo mediante la orden "sudo" del terminal, con la que accedemos al programa con credenciales de administrador (sudo: "super user do" o "haz esto como super usuario"). También, al igual que con el terminal, podemos usar gedit como editor simple de textos accediendo a el por la ruta normal de buscar el programa, pero si no lo abrimos como sudo no podremos editar archivos de sistema. Recordad, siempre que hagamos un sudo en el terminal, nos pedirá la contraseña de usuario. Esta es una de las razones por las que Linux es mucho más seguro que Windows. Aunque no lo parezca con tanto control de seguridad, Windows funciona en modo administrador todo el tiempo (aunque podemos modificar este comportamiento, pero ya hay que saber algo de informática para enterarse de qué implica ir por la vida de administrador), y eso significa que los ficheros de sistema son vulnerables a cualquier modificación o acceso no permitido. En Linux no tenemos acceso a los archivos del sistema a no ser que voluntariamente accedamos a ellos mediante nuestra contraseña. Simple y efectivo, como a mi me gusta.
Lo que hemos hecho con el comando es crear un archivo que proporciona información a Gnome-raw-thumbnailer para reconocer qué archivos y con qué extensiones deberán ser tratados como archivos fotográficos RAW. Es decir, editamos los tipos MIME asociados con Gnome-raw-thumbnailer. Por si no lo sabéis, los tipos MIME son la forma que tienen los sistemas operativos de reconocer qué tienen que hacer con los diferentes tipos de archivo. Por ejemplo, el tipo MIME "vídeo MPEG-4 (vídeo/mp4)" es un archivo con extensión .mp4 que Linux reconoce como vídeo, y abre con Totem (o el programa por defecto que seleccione para abrirlo al hacer doble clic). Tenemos tipos MIME para vídeo, audio, texto, fotos...

Si hacemos clic derecho sobre cualquier archivo y seleccionamos "propiedades", podemos comprobar su tipo MIME

Es importante recordar que los archivos RAW difieren en nombre (y en contenido) entre las diferentes marcas de cámaras fotográficas, por lo que conviene hacerle saber a Linux qué archivos son esos. Con lo que acabo de comentar, ya sabemos que el objetivo es indicar a Gnome-raw-thumbnailer con qué tipos MIME debe asociarse. El archivo por defecto nos aparece en blanco (porque no existía y lo hemos creado nosotros). Lo rellenamos de contenido con lo siguiente (copiad y pegad lo que viene ahora en Gedit):

[Thumbnailer Entry]
Exec=/usr/bin/gnome-raw-thumbnailer -s %s %u %o
MimeType=image/x-3fr;image/x-adobe-dng;image/x-arw;image/x-bay;image/x-canon-cr2;image/x-canon-crw;image/x-cap;image/x-cr2;image/x-crw;image/x-dcr;image/x-dcraw;image/x-dcs;image/x-dng;image/x-drf;image/x-eip;image/x-erf;image/x-fff;image/x-fuji-raf;image/x-iiq;image/x-k25;image/x-kdc;image/x-mef;image/x-minolta-mrw;image/x-mos;image/x-mrw;image/x-nef;image/x-nikon-nef;image/x-nrw;image/x-olympus-orf;image/x-orf;image/x-panasonic-raw;image/x-pef;image/x-pentax-pef;image/x-ptx;image/x-pxn;image/x-r3d;image/x-raf;image/x-raw;image/x-rw2;image/x-rwl;image/x-rwz;image/x-sigma-x3f;image/x-sony-arw;image/x-sony-sr2;image/x-sony-srf;image/x-sr2;image/x-srf;image/x-x3f;

Una vez hecho esto, debería funcionar, aunque por mi experiencia y con el tipo de cámara que tengo (una venerable Nikon D60, indestructible la pobre), debo añadir un cambio a este código. Si estáis en el mismo caso que yo, añadid lo siguiente:

 image/x-NEF;image/x-nikon-NEF;

Esto es así porque los archivos que genera mi cámara tienen la extensión NEF (propia de Nikon) en mayúsculas, y Linux es bastante quisquilloso con las mayúsculas y minúsculas. Verificad la extensión de vuestra cámara y, si también produce archivos con extensión en mayúsculas, haced lo propio. Aunque la lista es bastante completa y cubre una gran parte de extensiones, podéis probar a introducir otras a ver si funciona.

Gedit con el código mágico

Y eso es todo; salvo algún extraño accidente, vuestros archivos RAW se verán perfectamente en Nautilus. Y como ya sabéis cómo funciona, podéis acceder a este archivo y modificarlo a discreción mediante el comando del terminal que os indiqué arriba. Por cierto, quizá esta entrada no os sirva de nada porque vuestra distro ya previsualiza los RAW sin problemas. La verdad es que desconozco si en otras distros el Gnome-raw-thumbnailer viene instalado por defecto o no; de hecho, y aunque ahora mismo estoy trabajando sobre el, no sé si Ubuntu 12.10 ha solucionado esta pequeña carencia... cada vez que reinstalo el sistema llevo a cabo este procedimiento y lo tengo tan automatizado que lo hago sin comprobar primero si los RAW se ven sin más... animal de costumbres que es uno. En 12.04 juraría que no se veían de primeras, eso sí.
En cualquier caso, espero que os sirva de ayuda, y ya de paso que os vayáis acostumbrando al manejo del terminal, y conociendo algunas cuestiones básicas sobre el funcionamiento y las características de nuestro querido sistema operativo libre.
Ah, y las fuentes que no falten; todo esto no lo he descubierto tras horas de investigación profunda. Encontré la información en esta página y desde aquí les agradezco que lo hayan hecho y de paso recomiendo que la visitéis para estar enterados de estos truquillos y más cosas. Este vídeo-artículo no es más que una traducción ampliada a nuestro idioma, que no todo el mundo conoce la lengua de Shakerpeare, ¿no?

Actualización: Como indica Rafa en los comentarios de este artículo, también disponemos de un programa específico para los entornos XFCe, como Xubuntu:

sudo apt-get install tumbler-plugins-extra

Gracias a Rafa por la información, como siempre; y a los que leéis el blog, os  invito a compartir vuestros conocimientos para complementar los artículos, ¡es la mejor manera de aprender!