Activar Kickoff en Mandriva 2010

Aquí seguimos, buscando la mejor distro KDE del momento. Con la avalancha de lanzamientos de las últimas fechas (Ubuntu, Mandriva, openSUSE y Fedora, por orden de publicación) uno no da abasto.

En esta ocasión estaba probando Mandriva 2010, y choca a estas alturas encontrarse con el menú clásico de KDE activado por defecto,

en lugar de Kickoff.


Cambiar de uno a otro es muy sencillo, pero ojo, que antes de poder hacerlo con el menú de contexto en el icono del lanzador, tenemos que comprobar que los elementos gráficos de escritorio no están desactivados (en cuyo caso dicho menú de contexto no nos mostrará esa posibilidad). Es el comportamiento predeterminado en Mandriva. Así que mientras no me di cuenta del detalle, estuve un buen rato maldiciendo mi torpeza.

Así que tal como decía antes, la configuración de los elementos gráficos está desactivada, por defecto.

Y así es como se nos muestra el menú de contexto del lanzador de KDE (ni rastro de la opción de activar Kickoff).

Tras activar la configuración de elementos gráficos de escritorio, ahora el menú presenta este aspecto.

p.d. Por cierto, en la carrera a la mejor distro KDE del año, destaca en primer lugar openSUSE (lástima de administración de paquetes), seguida muy de cerca por Mandriva, y más rezagada Kubuntu (fundamentalmente no acaba de cuajar KPackageKit, todavía muy verde). Estoy pendiente de probar Fedora (el liveCD se ha negado a cargar al inicio parte de los elementos del escritorio KDE, en mi sobremesa, así que mal comienzo).

Usar UUID o ID en lugar de nombres de dispositivos

El otro día compré una tarjeta expresscard eSata para poder conectar mi recién adquirida base (docking station) Sharkoon al portátil.

Al margen de las asombrosas velocidades de transferencia que se consiguen usando eSata en comparación con UBS, me encontré con el problema de que tanto al conectar el disco duro en caliente como al iniciar el sistema con él conectado, los nombres (o el orden) de los nombres de dispositivos pueden variar. Me explico...

Si arranco el sistema operativo sin el disco duro eSata conectado, el disco interno del portátil es /dev/sda, y las distintas particiones /dev/sda1, /dev/sda2, etc. Si conecto el disco eSata (el disco al docking, y el docking al puerto eSata de la expresscard), el sistema le asigna nombre de dispositivo /dev/sdb, y sus distintas particiones /dev/sdb1, /dev/sdb2, etc. En este estado de cosas, tendremos archivos de configuración, elinks, etc que hacen referencia a estas particiones y/o nombres de dispositivos. Pero si yo ahora arranco el sistema con el disco duro externo ya conectado al puerto eSata, puede pasar (de hecho en mi caso es lo que pasa) que el sistema le asigne a dicha unidad el nombre de dispositivo /dev/sda, y al disco duro interno /dev/sdb, con el consiguiente reordenado en las particiones.... y a partir de ahí ya os podéis imaginar la que se lía (en mi caso, del gestor de arranque ya no pasa).

Para evitar esta situación, podemos usar UUID (Identificador Universal Único) en lugar de nombres de dispositivos (/dev/sdx#). Los UUID se asignan unívocamente a cada unidad, independientemente de su orden de arranque, cambios en hardware, etc.
¿Y como podemos averiguar dichos UUID?. Una forma sencilla de hacerlo es a través de la utilidad de linea de comandos blkid. Tenemos que ejecutarla como superusuario (root), y el resultado puede ser parecido a éste:

linux-intb:~ # blkid
/dev/sda1: SEC_TYPE="msdos" LABEL="DellUtility" UUID="07D7-031C" TYPE="vfat"
/dev/sda2: UUID="A4C4FAA5C4FA78BE" TYPE="ntfs"
/dev/sda3: UUID="7688E5C284F748B5" TYPE="ntfs"
/dev/sda5: UUID="c57fbee4-4540-1d9a-7296-f108f9bb5959" TYPE="swap"
/dev/sda6: LABEL="kubuntu_9.04" UUID="c64c8686-4549-4b42-90f5-1db009068089" TYPE="ext4"
/dev/sda7: LABEL="openSUSE_11.2" UUID="42622030-05ab-44b0-a967-748d276fe753" TYPE="ext4"

pudiendo usar estos UUID tranquilamente en todas aquellas partes donde hasta ahora empleábamos los nombres de dispositivos y/o particiones (como en los archivos fstab, menu.lst y grub.conf). Por ejemplo, en el fstab, podemos añadir UUID=xxx.yyy.zzz (sin las comillas dobles) en sustitución de /dev/sdx#, es decir:

UUID=xxx.yyy.zzz  /media/eSATA     ext3 auto,user      0       2

en lugar de

/dev/sdb1  /media/eSATA     ext3 auto,user      0       2

De esta manera, nos ahorramos los quebraderos de cabeza ocasionados por cambios en el hardware.

Además de la especificación by-uuid, el administrador de dispositivos udev utiliza alternativamente otro tipo de alias denominado by-id. Una forma sencilla de averiguar estos id (así como uuid, etiquetas, etc) es sabiendo que udev establece estos alias al arranque sobre /dev/disk. Si ejecutamos:

ls /dev/disk -l

vemos 4 resultados:

josea@linux-intb:~> ls /dev/disk/ -l
drwxr-xr-x 2 root root 380 2009-10-25 14:00 by-id
drwxr-xr-x 2 root root 100 2009-10-25 15:00 by-label
drwxr-xr-x 2 root root 220 2009-10-25 14:00 by-path
drwxr-xr-x 2 root root 160 2009-10-25 15:00 by-uuid

Si a continuación ejecutamos:

ls /dev/disk/by-id -l

obtenemos

josea@linux-intb:~> ls /dev/disk/by-id/ -l
total 0
lrwxrwxrwx 1 root root  9 2009-10-25 15:00 ata-TOSHIBA_MK1234GSX_27LMTPXAT -> ../../sda
lrwxrwxrwx 1 root root 10 2009-10-25 15:00 ata-TOSHIBA_MK1234GSX_27LMTPXAT-part1 -> ../../sda1
lrwxrwxrwx 1 root root 10 2009-10-25 15:00 ata-TOSHIBA_MK1234GSX_27LMTPXAT-part2 -> ../../sda2
lrwxrwxrwx 1 root root 10 2009-10-25 15:00 ata-TOSHIBA_MK1234GSX_27LMTPXAT-part3 -> ../../sda3
lrwxrwxrwx 1 root root 10 2009-10-25 15:00 ata-TOSHIBA_MK1234GSX_27LMTPXAT-part4 -> ../../sda4
lrwxrwxrwx 1 root root 10 2009-10-25 15:00 ata-TOSHIBA_MK1234GSX_27LMTPXAT-part5 -> ../../sda5
lrwxrwxrwx 1 root root 10 2009-10-25 15:00 ata-TOSHIBA_MK1234GSX_27LMTPXAT-part6 -> ../../sda6
lrwxrwxrwx 1 root root 10 2009-10-25 15:00 ata-TOSHIBA_MK1234GSX_27LMTPXAT-part7 -> ../../sda7
lrwxrwxrwx 1 root root  9 2009-10-25 14:00 edd-int13_dev80 -> ../../sda
lrwxrwxrwx 1 root root  9 2009-10-25 15:00 scsi-SATA_TOSHIBA_MK1234G_27LMTPXAT -> ../../sda
lrwxrwxrwx 1 root root 10 2009-10-25 15:00 scsi-SATA_TOSHIBA_MK1234G_27LMTPXAT-part1 -> ../../sda1
lrwxrwxrwx 1 root root 10 2009-10-25 15:00 scsi-SATA_TOSHIBA_MK1234G_27LMTPXAT-part2 -> ../../sda2
lrwxrwxrwx 1 root root 10 2009-10-25 15:00 scsi-SATA_TOSHIBA_MK1234G_27LMTPXAT-part3 -> ../../sda3
lrwxrwxrwx 1 root root 10 2009-10-25 15:00 scsi-SATA_TOSHIBA_MK1234G_27LMTPXAT-part4 -> ../../sda4
lrwxrwxrwx 1 root root 10 2009-10-25 15:00 scsi-SATA_TOSHIBA_MK1234G_27LMTPXAT-part5 -> ../../sda5
lrwxrwxrwx 1 root root 10 2009-10-25 15:00 scsi-SATA_TOSHIBA_MK1234G_27LMTPXAT-part6 -> ../../sda6
lrwxrwxrwx 1 root root 10 2009-10-25 15:00 scsi-SATA_TOSHIBA_MK1234G_27LMTPXAT-part7 -> ../../sda7

Vamos con otro ejemplo: en menu.lst podemos utilizar la nomenclatura by-id en lugar de los nombres de dispositivos. En lugar de:

title openSUSE 11.2
    root (hd0,6)
    kernel /boot/vmlinuz-2.6.31.3-1-default root=/dev/sda7 resume=/dev/sda5 splash=silent quiet showopts vga=0x317
    initrd /boot/initrd-2.6.31.3-1-default

podríamos poner:

title openSUSE 11.2
    root (hd0,6)
    kernel /boot/vmlinuz-2.6.31.3-1-default root=/dev/disk/by-id/ata-TOSHIBA_MK1234GSX_27LMTPXAT-part7 resume=/dev/disk/by-id/ata-TOSHIBA_MK1234GSX_27LMTPXAT-part5 splash=silent quiet showopts vga=0x317
    initrd /boot/initrd-2.6.31.3-1-default

En el ejemplo que veíamos antes con fstab, si usásemos by-id en lugar de nombres de dispositivos o by-uuid, quedaría:

/dev/disk/by-id/scsi-3500000e01632b7d0-part2   /media/eSATA     ext3 auto,user      0       2

Ojo porque si creamos la partición durante la sesión en curso, udev no montará en /dev/disk los alias by-id o by-uuid hasta que reiniciemos.

Kubuntu 9.10 Karmic Koala con KDE 4.3.2

En mi última entrada, ponía en duda si al futuro Kubuntu Karmic le daría tiempo de integrar la recientemente publicada revisión 2 del escritorio KDE 4.3. Sin embargo, y para nuestro regocijo, se confirma tal circunstancia.

Tengo depositadas grandes expectativas en Karmic, y dicha noticia no deja de ser otro indicador más de ello. Animo a quienes no hayan probado KDE 4.x, o lo hayan hecho en alguna de sus versiones más tempranas (y les dejara mal sabor de boca), a darle una oportunidad. El lanzamiento de Karmic el 29 de Octubre sería un buen momento.

KDE 4.2.4 en Kubuntu Jaunty 9.04 (oficialmente)

Sorprendentemente (la primera vez que ocurre, que yo recuerde) los señores de Kubuntu incorporan una revisión del escritorio KDE, como actualización en un repositorio 'oficial' (y me refiero en una versión de Kubuntu ya publicada; durante el ciclo de desarrollo de la misma, sucede habitualmente).

Lo habitual hasta ahora era lo siguiente. Me explico:

Sale Kubuntu 8.10; oficialmente, con la versión de KDE 4.1, revisión 2. Durante el período de soporte de esa versión de Kubuntu, Canonical hace correcciones en dicha revisión, recompilaciones, etc que se publican en sus repositorios oficiales. Pero si los señores de KDE sacan revisiones de esa versión (4.1.3, 4.1.4, etc) Kubuntu no las incorpora en dichos repositorios, tal como comento en el segundo punto de esta entrada. Como mucho y hasta ahora, algún colaborador las recompilaba y las compartía con la comunidad (oficiosamente, por lo tanto) publicándolas en algún repositorio personal PPA (es de esa manera que ahora mismo tengo mi Kubuntu Jaunty con KDE 4.3.1).

Entiendo que no es posible ni factible incorporar como actualización de una versión de Kubuntu ya publicada, una nueva versión de KDE. Para eso tenemos los ciclos de publicación de Ubuntu/Kubuntu cada 6 meses (o los repositorios PPA, para los que gusten de hacer experimentos; eso sí, en casa y con gaseosa). De manera que si queremos disfrutar 'oficialmente' del nuevo KDE 4.3.x, es comprensible que tengamos que esperar a Kubuntu Karmic 9.10 (veremos si KDE 4.3.1, o la todavía no publicada 4.3.2, que saldrá entorno al 6 de Octubre, 3 semanas antes que la publicación final de Karmic, esperada para el 28 de Octubre).

Pero no me parece tan razonable que si (por ejemplo) Kubuntu Jaunty integra KDE 4.2.x, no se vayan publicando, aunque sea en los repositorios Backports (no activados por defecto) las sucesivas revisiones de dicho escritorio, que con un ciclo de publicación mensual, únicamente incorporan soluciones de errores o problemas de rendimiento detectadas, y no cambios en API's o interfaces de programación.

Pero como un síntoma de que las cosas en Kubuntu parecen estar cambiando (y para bien) finalmente lo que comento en el párrafo anterior ha sucedido.

Configuración y uso de Ext2Fsd

En una entrada anterior os hablé de Ext2Fsd, un controlador para acceder a particiones ext2/ext3 desde Windows. Yo siempre había utilizado Ext2IFS, pero recientemente me encontré que no es compatible con inodes mayores de 128 bytes, de manera que no tenía acceso a particiones ext2/ext3 con dicha característica. Así que me he cambiado a Ext2Fsd, y aunque llevo poco tiempo, los resultados de momento son satisfactorios. La puesta en marcha y administración son sustancialmente diferentes a como se hacía en ExtIFS, de modo que me gustaría comentar como funciona.

De entrada, debemos distinguir entre el servicio que nos da acceso propiamente a las particiones ext2/ext3, y la utilidad que nos permite administrar todo lo relativo a su configuración y a las particiones (volúmenes, como le llama Ext2Fsd).

Una vez instalado, nos encontramos con el administrador en la bandeja del sistema.

Pulsando el botón derecho del ratón obtenemos el siguiente menú contextual:

y si escogemos 'Show Main Window' o igualmente con el botón izquierdo del ratón en lugar de con el derecho, vemos:

y

si seleccionamos 'Service Management' en el menú de contexto anterior.

En principio, no tenemos acceso a ninguna partición, así que desde el administrador tendremos que seleccionar la partición que queramos tener acceso, y asignarle una letra de unidad. Hacemos doble clic sobre la partición en cuestión, y en la pantalla que se abre:

pulsamos en el botón 'Mount Points' y asociamos una letra de unidad. Si aplicamos y volvemos a hacer doble clic sobre la partición, veremos una pantalla como ésta:

Es importante que establezcamos el juego de caracteres usado en la partición, pues predeterminadamente se usa el valor 'default'.

Si la distribución Linux que usamos (y casi todas hoy en día) utiliza el juego de caracteres UTF8, comprobaremos que no vemos correctamente acentos, eñes, etc.

Así que nada más asignarle una letra de unidad, el siguiente paso será establecer el codepage correspondiente (UTF8 en mi caso)

Aplicamos y a partir de ese momento, la partición aparecerá en Mi PC, y trabajaremos con ella como si de una partición Fat/Ntfs se tratase. Si no es así, es que el servicio está detenido, así que en la pantalla de 'Ext2Fsd Service Management', pulsamos el botón 'Start' si el servicio no está iniciado. Ahora sí, debemos ver las particiones en Mi PC.

Como vemos en la captura de la pantalla de administración de servicio (Ext2Fsd service management), podemos establecer que el servicio siempre arranque al inicio, de manera que a partir de ese instante, y si las unidades no son extraibles, siempre que reiniciemos, nos encontraremos accesibles las particiones, sin tener que hacer nada de nada. De hecho, la herramienta de administración puede cerrarse cuando queramos, lo importante es que tengamos el servicio en marcha.

También si vamos a usar particiones ext2/ext3 en unidades extraibles, pueda interesarnos activar la opción 'Assign drive letter automatically', de forma que nos evitamos el engorro de tener que asignar las letras de unidad manualmente cada vez que pinchemos una unidad.

La administración del servicio también podemos hacerla desde el menú 'File' del gestor de volúmenes:

KRename 4.0.0

Buenas noticias, pues tal como anuncian aquí, por fin se ha publicado la versión 4.0.0 de KRename, la primera versión final para el escritorio KDE4. Tal como comentaba en una anterior entrada, hasta ahora a los usuarios de KRename no nos quedaba otra que usar la anterior versión estable 3.0.x (enfocada a KDE3, aunque funcionase en KDE4), o tirar de repositorios no oficiales y usar alguna versión en desarrollo de la rama 4.0.x. Se supone que ahora que tenemos versión estable, todas las distros integrarán en sus repositorios oficiales esta versión, en detrimento de la 3.0.x.

KRename es una utilidad de renombrado de ficheros extremadamente potente que incorpora una gran cantidad de funcionalidades.

En mi opinión, y con la llegada oficial de KRename a KDE4, la única aplicación pendiente de migrar a Qt4 y con la que completaríamos la funcionalidad de la que disfrutábamos en KDE3, es K3b. De momento, tenemos que conformarnos con una alpha2.

Acceso desde Windows a particiones ext2/ext3 con tamaño de inode mayor a 128 bytes

Como ya comenté en una anterior entrada, gracias a Ext2 IFS, tenemos acceso (lectura/escritura) a particiones ext2 o ext3 desde Windows. Por lo menos hasta ahora.

Hace unos días compré un disco duro de 1Tb Seagate LP 5900rpm: ideal para hacer copias de seguridad usando eSata, silencioso, apenas se calienta, y muy económico (60€). Le di formato ext3 con el GParted de los repositorios de Ubuntu Jaunty, y como de costumbre, intenté acceder a la partición desde Windows, pero no hubo forma. Así que investigando un poco, me encuentro con esto:

Large inode
The current version of Ext2 IFS only mounts volumes with an inode size of 128 like old Linux kernels have. Some very new Linux distributions create an Ext3 file systems with inodes of 256 bytes. Ext2 IFS 1.11 is not able to access them. Currently there is only one workaround: Please back up the files and create the Ext3 file system again. Give the mkfs.ext3 tool the -I 128 switch. Finally, restore all files with the backup.

que viene a decir que particiones ext2/ext3 con tamaño de inode superior a 128 bytes no están soportadas por Ext2 IFS. ¿Cómo podemos solucionarlo? Ahora comento 2 alternativas.

Todos los pasos que siguen deberán de ejecutarse con la partición desmontada.
Además debemos tener instalado el paquete e2fsprogs (por defecto habitualmente), de lo contrario, ejecutamos

sudo apt-get install e2fsprogs

Si no sabemos de que partición se trata, podemos averiguarlo ejecutando:

sudo fdisk -l

Para averiguar el tamaño de los inodes de nuestra partición ext2/ext3, podemos ejecutar:

sudo tune2fs -l /dev/sdb1

que nos devolverá información relativa a nuestra partición (sdb1 en mi caso) resultando:

Filesystem volume name:   DISCO2
Last mounted on:          
Filesystem UUID:          4d78dc72-191c-4411-97c6-1f3500f02224
Filesystem magic number:  0xEF53
Filesystem revision #:    1 (dynamic)
Filesystem features:      has_journal ext_attr resize_inode dir_index filetype sparse_super large_file
Filesystem flags:         signed_directory_hash
Default mount options:    (none)
Filesystem state:         clean
Errors behavior:          Continue
Filesystem OS type:       Linux
Inode count:              61054976
Block count:              244190000
Reserved block count:     12209500
Free blocks:              230114068
Free inodes:              61054916
First block:              0
Block size:               4096
Fragment size:            4096
Reserved GDT blocks:      965
Blocks per group:         32768
Fragments per group:      32768
Inodes per group:         8192
Inode blocks per group:   512
Filesystem created:       Thu Sep 17 23:16:52 2009
Last mount time:          Tue Sep 22 03:15:18 2009
Last write time:          Tue Sep 22 03:15:26 2009
Mount count:              9
Maximum mount count:      32
Last checked:             Thu Sep 17 23:16:52 2009
Check interval:           15552000 (6 months)
Next check after:         Tue Mar 16 22:16:52 2010
Reserved blocks uid:      0 (user root)
Reserved blocks gid:      0 (group root)
First inode:              11
Inode size:              256
Required extra isize:     28
Desired extra isize:      28
Journal inode:            8
Default directory hash:   half_md4
Directory Hash Seed:      c1bd76dd-d5df-4fca-b2a8-38b6967de2be
Journal backup:           inode blocks

Si queremos filtrar únicamente los datos relativos a inodes, podemos ejecutar lo siguiente:

sudo tune2fs -l /dev/sdb1 | grep Inode

que devuelve:

Inode count:              61054976
Inodes per group:         8192
Inode blocks per group:   512
Inode size:              256

Como vemos, efectivamente GParted ha dado formato a mi partición con un tamaño de inode de 256 bytes.

La primera alternativa sería volver a formatear nuestra partición desde consola (dado que GParted no permite establecer dicho parámetro), estableciendo el tamaño de inode a 128 bytes, quedando para una partición ext3 como sigue:

mke2fs -v -I 128 -j -L "etiqueta_volumen" /dev/sdb1

o si queremos como ext2, quitamos el parámetro -j (este parámetro es el que activa el journaling, característica diferenciadora entre ext2 y ext3), quedando:

mke2fs -v -I 128 -L "etiqueta_volumen" /dev/sdb1

Vemos que el tamaño de inode se establece con el parámetro -I tamaño_bytes. Por supuesto, perderíamos todos los datos de nuestra partición al formatear.

Otra alternativa, si queremos utilizar el tamaño de inode de 256 bytes (que pronto se convertirá en el valor por defecto) u otro mayor, sería acceder a dichas particiones desde Windows con Ext2Fsd, que recientemente dio soporte a tamaños de inode mayores de 128 bytes, tal como comentan aquí.

p.d. Si únicamente vamos a utilizar la partición del disco para copias de seguridad nos podría interesar, para maximizar el espacio, ejecutar mke2fs con los parámetros -m 0 y -N 20000, tal como:

mke2fs -v -I 128 -j -N 20000 -m 0 -L "etiqueta_volumen" /dev/sdb1

Aunque establezcamos el número de inodes a 20000, éste es un valor de referencia usado por mke2fs; por ejemplo, si la partición es de 250Gb, y usamos dicho parámetro, el valor real será de 59.648 inodes, y sin él, el número de inodes será 61.049.000. Esto determinará el número de archivos que se pueden almacenar en la partición (a mayor número de inodes, mayor número de archivos, pero si lo que vamos a almacenar son archivos grandes, es una manera de maximizar el espacio disponible). De la misma manera, si no espeficicamos un valor para -m, se reservará un 5% del espacio de la partición al superusuario. Para una partición de 1TB, estamos hablando de casi 50Gb que recuperamos, estableciendo -m 0.

KRename (o cómo arreglar un desaguisado)

Tal como comento en una entrada anterior dedicada a ese magnífico programa llamado Rapid Photo Downloader, por un despiste me encontré con una barbaridad de archivos (concretamente 528) sin extensión (menos mal que todos tenían la misma: jpg) en una unidad de red (un NAS, para ser más exacto) y sin posibilidad de repertir nuevamente la operación. ¿Cómo solucionar este desaguisado?

Vamos a tirar de aplicación de renombrado de archivos por lotes (batch renamer); y tratándose de KDE, qué mejor que KRename.

Kubuntu Jaunty integra en los repositorios oficiales la última versión estable que, desgraciadamente, todavía es una versión nativa para el escritorio KDE 3.5.x (no significa ésto que no podamos usarla en KDE 4.x). El problema de esta versión estable es que no soporta unidades de red (o yo no he visto manera, ni tan siquiera usando KIO slaves). Así que la alternativa es usar la versión en desarrollo, ésta sí nativa KDE 4. La ventaja fundamental es su integración con la arquitectura subyacente bajo KDE 4, incluyendo soporte de recursos compartidos de red, como se puede apreciar en la siguiente captura.

Para instalar dicha versión lo mejor es buscar un repositorio PPA que la empaquete para nuestra versión de Ubuntu/Kubuntu, de manera que nos evitemos tener que compilar, problemas de dependencias, etc. Nos será de mucha utilidad un buscador de paquetes en repositorios PPA, que nos permita localizar la aplicación que estamos buscando. Podemos usar el buscador oficial, aunque yo concretamente estoy usando PPA Search, ya no solamente vía web, si no también integrado en las búsquedas rápidas de Firefox, gracias a Mycroft Project.

Después de la búsqueda, obtenemos 2 repositorios, pero el que contiene la versión más reciente (hoy día la 3.9.3) es éste de Sam Rog. Para agregarlo a nuestro gestor de paquetes:

• Seleccionamos nuestra versión de Kubuntu
  

• e introducimos las 2 entradas correspondientes en nuestro gestor de paquetes (Synaptic, KPackageKit, etc)
  

• y añadimos el certificado.

Esto último se puede hacer de varias maneras, pero la que estoy usando últimamente evita completamente el uso de la consola:

• hacemos clic en el identificador de la clave, dentro de la página principal del repositorio
  

• en la nueva página nuevamente clic en el identificador
  

• y por último ya podemos ver la clave. Seleccionamos su contenido, tal como nos muestra la captura
  

• que pegamos en un archivo de texto, lo guardamos en local, para luego importarlo desde el propio gestor de paquetes.

Recargamos los repositorios, y al hacer la búsqueda, nos encontramos disponibles las 2 versiones. Instalamos la más reciente.

A partir de aquí, todo es 'coser y cantar'. KRename ofrece grandes ventajas, como añadir los archivos de directorios completos, trabajar con archivos/carpetas locales o en unidades de red, como se puede ver.

No solamente permite renombrar, si no copiar o mover.

Y además, integra funcionalidad avanzada a la hora de obtener etiquetas para el renombrado, con información obtenida de distintos orígenes, gracias al uso de plugins.


En mi caso concreto, el renombrado es muy sencillo, no necesito de ningún plugin, ya que tal como se puede apreciar, solamente necesito añadir la extensión.

Pulsamos 'Finish y el proceso tarda unos segundos

Rapid Photo Downloader (actualizado)

Después de 23 días de viaje, más de 4.600km recorridos, visitados pueblos y ciudades (Palencia, Lerma, Soria, Tarazona, Tarragona, Sitges, Barcelona, Pals, Cadaqués, Bilbao, Lekeitio, Zarautz, San Sebastián, etc), decenas de playas y paisajes encantadores... Es normal llegar a casa y encontrarse con 531 fotos en la memoria de la cámara. ¿Y cómo volcar tantos archivos al disco duro del ordenador, con la organización deseada (no nos sirve copiar/pegar), sin utilizar los programas que acompañan a la cámara fotográfica (es un engorro instalarlos únicamente para dicho fin, y para todo lo demás seguramente usemos otras aplicaciones que nos resulten más familiares), cuando además solamente funcionan bajo Windows?

Pues en esta situación es donde nos encontramos con una joya de programa: Rapid Photo Downloader. Instalarlo para cualquier edición de Ubuntu/Kubuntu/etc es muy sencillo, solamente hay que seguir los pasos que nos detallan en su propia web, además que nos serán de mucha utilidad para saber como añadir cualquier otro repositorio PPA (Personal Package Archive), así como gestionar su clave de autenticación (la parte más engorrosa).

Una vez instalado, el programa es muy sencillo. Basta conectar la cámara a través de su correpondiente cable a un puerto USB, o pinchar la memoria de la misma en un lector de tarjetas, y pulsar el botón Descargar. Pero antes de ello, deberíamos de proceder previamente a configurar la aplicación, si no queremos montar un desaguisado. Para ello, nos vamos al menú 'Fotos', orden 'Preferencias'. En el cuadro de diálogo que se nos presenta, 2 opciones son fundamentales: 'Carpeta de descarga' y 'Renombrar imagen'. Los siguientes son los valores por defecto de ambas opciones de configuración.

Aquí os dejo tal como yo las he configurado. Para entender un poco de qué va todo ésto, no tenemos más que fijarnos en los ejemplos que nos muestra el propio programa en la parte inferior de cada cuadro de diálogo.

Actualización

Si os fijáis bien, en la pantalla anterior he cometido un error: he omitido la extensión de los archivos, de manera que me he encontrado con 531 archivos perfectamente clasificados y renombrados, pero todos ellos sin extension (.jpg en este caso). Lo correcto sería hacerlo tal como se ve en la captura siguiente.

Una vez configurado, ya podemos pulsar el botón Descargar. En mi caso lo hice con la cámara conectada al puerto USB a través del cable que la acompaña. Pero normalmente será mucho más rápido si lo hacemos directamente desde la memoria SD de la cámara conectada a un lector de tarjetas.



Y aquí un ejemplo del resultado final, una vez descargadas todas las fotos, y accediendo a una carpeta al azar. Fijaros en la ruta de la barra de direcciones, y en el nombre de los archivos.

Actualización

En la pantalla anterior se observa perfectamente el error que cometí y que os comento líneas arriba, pues los archivos no tienen extensión (aunque Nautilus muestre la vista preliminar igualmente, lo que hizo que tardase en darme cuenta de la metedura de pata).

Aspecto de KDE 4.3

Estos días estoy usando la beta 2 del futuro KDE 4.3.0, en Kubuntu 9.04. Es sorprendentemente estable para ser una beta 2, así que supongo cumplirán lo establecido en el roadmap y será publicada la versión final el 28 de Julio. ¿Cuál será la primera distro en integrarlo como escritorio KDE por defecto?

Pero ahora al caso, ya parece confirmado el nuevo tema predeterminado de escritorio, un rediseñado, muy 'transparente' y (a mi gusto) atractivo Air, en detrimento de Oxygen (que por supuesto seguirá ahí, para los que gusten de un aspecto más 'oscuro').

UNetbootin

Acabo de añadir a mi lista de 'imprescindibles' Linux (margen derecho del blog) la aplicación UNetbootin. Las últimas versiones de las distribuciones más conocidas (Ubuntu, Fedora, etc) ya integran una herramienta para poder instalar la distro y arrancarla desde un pendrive. Pero tienen la paradoja de que para poder ejecutar dicha herramienta, primeramente tendremos que poner en marcha la distribución, lo que implica necesariamente grabar el cd/dvd (aunque sea en un regrabable) de la imagen de la distro que nos descarguemos, iniciarla y ejecutar la utilidad que nos permite instalar la distribución en la memoria USB. Todo este proceso es el que nos permite evitar UNetbootin.

Las ventajas de usar UNetbootin:

• Es multiplataforma (se ejecuta tanto en Windows como en Linux).
• Independiente de una distribución en particular.
• Soporta la práctica totalidad de distrubuciones Linux (es capaz de instalarlas y hacerlas arrancables desde un pendrive).
• No necesitamos grabar, en ningún soporte óptico, la imagen iso que queramos instalar en el pendrive (incluso se la descarga de internet si no lo hemos hecho previamente).

Kubuntu 9.04 Jaunty

Sin duda el mejor Kubuntu hasta la fecha. Por muchas razones, siendo las tres más reseñables:

- Aunque lentamente, va madurando en cada nueva versión, acercándose cada vez más al hasta ahora mucho más trabajado (Canonical invierte claramente más recursos) Ubuntu. ¿Noticias como ésta serán la confirmación de un cambio de tendencia?.

- La conjunción en el mapa de ruta (roadmap) de una buena versión de KDE (en esta caso, la versión 4.2.2) con el lanzamiento de Kubuntu (cosa que anteriormente no había pasado). Es curioso como casi todas las 'grandes' ajustan sus lanzamientos sincronizándose con cada nueva versión de GNOME, lo que no siempre deja en buen lugar a la edición KDE correspondiente. Es curioso lo que va a ocurrir con la recién lanzada KDE 4.2.4, la mejor versión KDE hasta la fecha, que probablemente no se incluya como escritorio por defecto en ninguna de estas distribuciones. ¿Cuándo una distro importante apostará decididamente por KDE, o al menos ajustará su roadmap al de este entorno de escritorio?.

- La adopción de un gestor de paquetes (realmente frontend del sistema de gestión de paquetes base de Debian y derivadas: Dpkg) prometedor y ojalá futuro estándar entre distribuciones. Me refiero a PackageKit, y más concretamente su 'frontend' KPackageKit, sustituto del denostado por muchos Adept (la verdad que siempre me pareció mejor Synaptic, el gestor de paquetes de Ubuntu). Y digo prometedor pues aunque resulta realmente atractivo, todavía carece de cierta funcionalidad.

Un ejemplo de lo comentado en el punto anterior, es lo que me ha ocurrido al intentar actualizar la versión de KDE incluida en Jaunty.
Desgraciadamente, Kubuntu no soporta 'oficial' ni 'oficiosamente' (si exceptuamos los repositorios PPA, aunque como su nombre indica, son repositorios 'personales') las actualizaciones dentro de la misma rama de KDE, en este caso la 4.2.x (ya lanzadas la 4.2.3 y 4.2.4 y a la espera de la nueva rama 4.3.x para finales de Julio). Y no lo entiendo muy bien, pues como bien señalan las listas de cambios (changelogs) de dichas revisiones 4.2.x, simplemente se limitan a solucionar errores, no a implementar nuevas funcionalidades. Aún así, podemos añadir el siguiente repositorio si queremos tener la última revisión de la rama 4.2.x en Jaunty:

deb http://ppa.launchpad.net/kubuntu-ppa/ppa/ubuntu jaunty main

y hacer una actualización completa. El problema es que si usamos KPackageKit para todo el proceso, nos encontraremos que la cosa no va, y tampoco nos informará de cual es la causa.
Un mensajito debería informarnos que nos falta la clave pública asociada al repositorio que hemos añadido, pero por desgracia no ocurre así.
De manera que pasamos de KPackageKit, y recurrimos directamente a la consola. Ahí nos damos cuenta de cual es el problema (última linea), al ejecutar sudo apt-get update:

josea@dell-kubuntu:~$ sudo apt-get update                 
Obj http://es.archive.ubuntu.com jaunty Release.gpg       
Obj http://es.archive.ubuntu.com jaunty/main Translation-es

...

Obj http://security.ubuntu.com jaunty-security/multiverse Packages
Obj http://ppa.launchpad.net jaunty/main Packages
Obj http://ppa.launchpad.net jaunty/main Sources
Descargados 308B en 0s (509B/s)
Leyendo lista de paquetes... Hecho
W: Error de GPG: http://ppa.launchpad.net jaunty Release Las firmas siguientes no se pudieron verificar porque su llave pública no está disponible: NO_PUBKEY 2836CB0A8AC93F7A

Así que ejecutamos en una consola (cuidado con el guión al final de la linea):

gpg --keyserver keyserver.ubuntu.com --recv-keys 2836CB0A8AC93F7A && gpg --export -a 2836CB0A8AC93F7A | sudo apt-key add -

o mejor todavía (más fácil):

sudo apt-key adv --keyserver keyserver.ubuntu.com --recv-keys 2836CB0A8AC93F7A

y obtenemos:

gpg: solicitando clave 8AC93F7A de hkp servidor keyserver.ubuntu.com
gpg: clave 8AC93F7A: clave pública "Launchpad Kubuntu Updates" importada
gpg: Cantidad total procesada: 1
gpg:               importadas: 1  (RSA: 1)
OK

Parece que la cosa marcha. Así que volvemos a intentar la actualización desde la consola (primero un sudo apt-get update) con sudo apt-get upgrade:

josea@dell-kubuntu:~$ sudo apt-get upgrade
Leyendo lista de paquetes... Hecho
Creando árbol de dependencias
Leyendo la información de estado... Hecho
Se actualizarán los siguientes paquetes:
akonadi-kde akonadi-server akregator ark dolphin dragonplayer gwenview kaddressbook kamera kate kde-icons-oxygen
kde-printer-applet kde-window-manager kde-zeroconf kdebase-bin kdebase-data kdebase-plasma kdebase-runtime
kdebase-runtime-bin-kde4 kdebase-runtime-data kdebase-runtime-data-common kdebase-workspace-bin kdebase-workspace-data
kdebase-workspace-libs4+5 kdegraphics-strigi-plugins kdelibs-bin kdelibs5 kdelibs5-data kdemultimedia-kio-plugins
kdepasswd kdepim-kresources kdepim-strigi-plugins kdepim-wizards kdepimlibs-data kdepimlibs5 kdeplasma-addons
kdeplasma-addons-data kdm kfind khelpcenter4 klipper kmag kmail kmix kmousetool knotes kompare konqueror
konqueror-nsplugins konsole kontact kopete korganizer krdc krfb ksnapshot ksysguard ksysguardd ksystemlog ktimetracker
kuser kwalletmanager libakonadiprivate1 libkcddb4 libkdecorations4 libkdepim4 libkexiv2-7 libkholidays4 libkipi6
libkleo4 libkonq5 libkonq5-templates libkpgp4 libksieve4 libkwineffects1 libmaildir4 libmimelib4 libokularcore1
libplasma3 okular okular-extra-backends python-kde4 system-config-printer-kde systemsettings
84 actualizados, 0 se instalarán, 0 para eliminar y 0 no actualizados.
Necesito descargar 96,1MB de archivos.
Se utilizarán 242kB de espacio de disco adicional después de esta operación.
¿Desea continuar [S/n]?

o bien desde el propio KPackageKit, que ahora sí que es capaz de cargar el contenido del nuevo repositorio y mostrarnos las actualizaciones:

Otro detalle que tienen que pulir es que mientras está realizando alguna operación (descargando, instalando, etc) el botón 'Detalles' de la pantalla de estado de proceso permanece desactivado.

Free Software Pact y Elecciones Europeas 2009 (actualizado)

Como usuario de software libre y defensor del código abierto, me parecen interesantes iniciativas como la Free Software Pact (aquí en castellano), donde nuestros políticos se pueden comprometer (por escrito, ahí está la gracia) a apoyar en Europa políticas activas a favor del software libre, y oponerse a toda discriminación en su contra, defendiendo los derechos tanto de los autores como de los usuarios de software libre. Porque el software libre es un 'bien común', que debe ser protegido y fomentado.

En España, esta iniciativa está contando con la promoción y apoyo de Hispalinux.

De momento, únicamente cuenta con el compromiso firme de UPyD, y más tímidamente de algunos representantes de BNG / Europa de los pueblos - verdes (concurren juntos a estas elecciones). Digo tímidamente pues aunque presuman de ello, de momento no parecen haber cumplido todos los trámites (aunque figuren aquí, no aparecen en el listado definitivo).
Actualización: Ahora sí aparecen, no sólo los cabezas de lista del BNG, si no también los del CHA (al igual que el BNG, integrados con Europa de los pueblos - verdes). En un sprint final, la lista ha engordado repentinamente, de lo cuál debemos congratularnos: Los Verdes-Grupo Verde Europeo, Izquierda anticapitalista - Revolta Global, Iniciativa per Catalunya Verds - Esquerra unida i alternativa. Curiosamente, aparece la candidata del PSOE Francisca Pleguezuelos Aguilar, lástima que ocupe la posición 27 de la lista. Bien por ella, pero dice poco de los 26 compañeros que la preceden (lo cuál deja claro cuan anecdótico es el apoyo al software libre de su partido, y una excepcionalidad lo que ocurre en Extremadura y Andalucía).

Es curioso como IU ha desperdiciado (aunque aún estén a tiempo, quedan todavía unos días) la oportunidad de suscribir dicha iniciativa, cuando en su programa electoral para estas elecciones figura su compromiso firme (o eso, ingenuo de mi, deduzco de su lectura) con (extracto del apartado POR UNA SOCIEDAD DE LA INFORMACIÓN JUSTA Y SOLIDARIA):

• Fomento del Software Libre, estableciendo el uso preferente de programas de código fuente abierto en las Administraciones Públicas, superando situaciones monopolistas de dependencia tecnológica.
• Oposición a la implantación de las patentes de software, por favorecer a las grandes multinacionales del ramo y a los grandes bufetes multinacionales, causando además un perjuicio al movimiento del software libre, tanto a los programadores individuales como a las pequeñas empresas que producen este tipo de programas.
  

Aunque nada tiene que ver con el tema, también me parece interesante destacar los siguientes puntos de su programa:

• Modificación del sistema de defensa de la propiedad intelectual que actualmente se realiza a través de la implantación del llamado canon digital, buscando alternativas más justas en beneficio del interés general, compatible con el respeto de los derechos de los creadores, los de la industria tecnológica y los de los consumidores.
• Cambio profundo del modelo vigente propiedad intelectual, priorizando los aspectos sociales y colectivos de toda obra, pues el vigente, concebido en un principio para proteger el trabajo del creador individual, se ha convertido principalmente en un instrumento de maximalización del beneficio de grandes empresas de carácter multinacional.
• No penalización del libre intercambio de archivos siempre que no tenga un fin lucrativo, de acuerdo con la actual doctrina jurisdiccional, y apoyo al derecho a la copia privada.
• Digitalización de los fondos culturales e históricos propios de la Administración General del Estado y su puesta a disposición de manera libre y gratuita de los ciudadanos en la Web, permitiendo además la descarga digital de los fondos de las bibliotecas estatales. La publicación de estos fondos se realizará mediante licencias libres que aseguren una difusión de los mismos sin las restricciones que impone el actual modelo de propiedad intelectual.

Después de todo el 'chorreo' de noticias relativas a Internet y al mundo del software que han ido cayendo en los últimos tiempos, todas ellas debatidas en el Parlamento Europeo (patentes de software, los llamados 'paquete Telecom' y 'modelo Sarkozy', uso de estándares abiertos, etc), creo de nuestro interés tener claro cual es la postura de nuestros representantes en dicho parlamento, y dicho sea de paso, que ellos también lo tengan claro (hay mucho desconocimiento por su parte de todos estos temas, y los lobbys del sector se aprovechan de dicho desconocimiento para influenciar su voto en la defensa de sus intereses).

Así como también es injustificable que el gobierno socialista apruebe la compra de nosecuantos miles de portátiles para los chavales de 5º de primaria, y eche balones fuera delegando en cada comunidad autónoma qué software debe instalarse en dichos ordenadores. Y luego está, nos encontramos con noticias como que el nuevo gobierno de Galicia ha decidido instalar Windows y aplicaciones Microsoft en dichos portátiles, tal como afirma Ana Miranda, candidata del BNG:

Pon como exemplo a recente decisión do PP que dende a Xunta de Galiza decidiu colocar Windows nos portátiles do alumnado de 5º de primaria, “unha adxudicación moi polémica que fará que a Xunta de Galiza pague cada ano 2 millóns de euros a Microsoft, só polo uso do seu sistema operativo”.

Y ojo, que tampoco estoy de acuerdo con el arranque dual que plantean algunos, pues eso implica el tener que pagar las licencias igualmente. El que quiera usar Windows u Office, que lo pague de su bolsillo, así de claro. Hay alternativas tecnológicas de código abierto, usando estándares abiertos, y aún por encima, gratuitas. Estamos hablando del erario público, no de la empresa privada, que pueden comprar/utilizar el software que mejor se adapte a sus intereses (solo faltaría).

Yo tengo claro que las elecciones al parlamento europeo son clave en la defensa de todos estas cuestiones (y muchas otras que no viene a cuento comentar aquí), y por consiguiente, pienso ir a votar. Y tú, ¿también lo tienes claro? ;-)