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.