Ubicación de servicios (KDE Service Menu) para Dolphin en KDE 5

Muchas distribuciones Linux basadas en KDE están dando el salto o tienen previsto darlo en breve a KDE Plasma 5 (a partir de ahora, para abreviar, KDE5). En KDE4, si queríamos saber donde ubicar los archivos de servicios de Dolphin o Konqueror (los denominados KDE Service Menu), no teníamos más que ejecutar en una terminal:

kde4-config --path services

que acostumbra a devolver

/home/usuario/.kde4/share/kde4/services/:/usr/share/kde4/services/

Si ubicamos el servicio en la primera ruta (rutas separadas por dos puntos), solo estaría disponible para ese usuario en concreto (donde cambiamos usuario por el nombre del usuario que ejecuta el comando). Si lo ubicamos en la segunda, estaría disponible para todos los usuarios del sistema.

Normalmente el usuario no tiene que preocuparse de esto, sino que los scripts de instalación que suelen acompañar a los KDE Service Menu se encargan de todo. Pero no siempre todo funciona a la primera, ¿no es así?.

El problema que nos encontramos con KDE5, basado en Qt5, es que tiene establecidas rutas diferentes para los KDE service menu. Si tenemos instalada nuestra distro y actualizamos a KDE5, es probable que dejemos de tener disponibles nuestros servicios en Dolphin, porque éste los buscará en las nuevas rutas, y nuestros servicios se encontrán en las rutas preestablecidas por KDE4.

Para saber qué rutas se utilizan en KDE5, tenemos que ejecutar:

kf5-config --path services

(kf5 de KDE Framework 5) que devuelve

/home/usuario/.local/share/kservices5/:/usr/share/kservices5/

que si os fijáis son distintas a las que se usan en KDE4.

Algunas distribuciones han creado un alias a kf5-config, de manera que si probamos con kde5-config (que sería lo lógico) obtendremos las rutas igualmente.

Acceder a cámara de fotos desde KDE 4.8

Estoy usando desde la beta1, Kubuntu Precise 12.04 (muy satisfactoriamente dicho sea de paso). Una de las cosas que he notado (y no soy el único al que le pasa), es que el automontaje de nuestra cámara digital cuando la pinchamos al puerto USB (vía su cable correspondiente) no funciona (no aparece en la lista de dispositivos de Dolphin ni se muestra la notificación de dispositivo disponible en la bandeja de sistema). Por otra parte, sí que funciona sin ningún problema si pinchamos cualquier pendrive. Comentan en el siguiente enlace, que se trata de una regresión en la rama de KDE 4.8.x, que por lo visto soluciona la revisión 4.8.3 recientemente publicada (todavía no en los repositorios oficiales de Kubuntu). El problema de fondo es que KDE trata las cámaras digitales como dispositivos 'no removibles'. 

¿Y cómo hacer para acceder al contenido de la memoria de la cámara? Una opción sería retirar la tarjeta de memoria y usar un adaptador USB (del estilo de este) o bien un lector de tarjetas. ¿Pero qué ocurre si no disponemos ni de uno ni de otro?

Por suerte, el kio slave camera:/ funciona perfectamente, aunque falle lo comentado en el primer párrafo. De manera que si pinchamos nuestra cámara al puerto USB, la encendemos en modo reproducción/visualización, ejecutamos el administrador de archivos (Dolphin o Konqueror), pinchamos en la barra de direcciones, tecleamos

camera:/

y pulsamos intro, nos encontraremos algo parecido a esto:

Ahora solamente nos queda navegar por las distintas carpetas hasta dar con nuestras fotos. Un ejemplo para una Canon IXUS 860 IS:

Fuente:

http://ubuntuguide.org/wiki/Kubuntu_Precise_Photos_and_Graphics#Accessing_a_digital_camera_from_the_Dolphin_file_manager

Ejecutando Pinta sobre KDE

Como ya comenté en una entrada anterior, el software de dibujo y edición de imágenes Pinta, derivado del proyecto Paint.Net, presenta ciertas dificultades a la hora de ejecutarse correctamente en KDE. Sin embargo, la solución que ofrecí en dicha entrada, ya no resuelve el problema en las nuevas versiones de KDE/Kubuntu. Concretamente, estos días salió la versión 1.2 de Pinta, y al intentar ejecutarla en Kubuntu 12.04, obtenemos el siguiente error:

josea@kubuntu12:~$ pinta

Unhandled Exception: System.ArgumentException: 'gtk-close' is not a valid resource name of assembly 'Pinta.Resources, Version=1.2.0.0, Culture=neutral, PublicKeyToken=null'.
  at Gdk.PixbufLoader.InitFromAssemblyResource (System.Reflection.Assembly assembly, System.String resource) [0x00000] in :0 
  at Gdk.PixbufLoader..ctor (System.Reflection.Assembly assembly, System.String resource) [0x00000] in :0 
  at Gdk.Pixbuf..ctor (System.Reflection.Assembly assembly, System.String resource) [0x00000] in :0 
  at Gdk.Pixbuf.LoadFromResource (System.String resource) [0x00000] in :0 
  at Pinta.Resources.ResourceLoader.GetIcon (System.String name, Int32 size) [0x00000] in :0 
  at Pinta.ResourceManager.GetIcon (System.String name, Int32 size) [0x00000] in :0 
  at Pinta.ResourceManager.GetIcon (System.String name) [0x00000] in :0 
  at Pinta.Gui.Widgets.OpenImagesListWidget..ctor () [0x00000] in :0 
  at Pinta.OpenImagesPad.Initialize (MonoDevelop.Components.Docking.DockFrame workspace, Gtk.Menu padMenu) [0x00000] in :0 
  at Pinta.MainWindow.CreateDockAndPads (Gtk.HBox container) [0x00000] in :0 
  at Pinta.MainWindow.CreatePanels (Pinta.WindowShell shell) [0x00000] in :0 
  at Pinta.MainWindow.CreateWindow () [0x00000] in :0 
  at Pinta.MainWindow..ctor () [0x00000] in :0 
  at Pinta.MainClass.Main (System.String[] args) [0x00000] in :0 
[ERROR] FATAL UNHANDLED EXCEPTION: System.ArgumentException: 'gtk-close' is not a valid resource name of assembly 'Pinta.Resources, Version=1.2.0.0, Culture=neutral, PublicKeyToken=null'.
  at Gdk.PixbufLoader.InitFromAssemblyResource (System.Reflection.Assembly assembly, System.String resource) [0x00000] in :0 
  at Gdk.PixbufLoader..ctor (System.Reflection.Assembly assembly, System.String resource) [0x00000] in :0 
  at Gdk.Pixbuf..ctor (System.Reflection.Assembly assembly, System.String resource) [0x00000] in :0 
  at Gdk.Pixbuf.LoadFromResource (System.String resource) [0x00000] in :0 
  at Pinta.Resources.ResourceLoader.GetIcon (System.String name, Int32 size) [0x00000] in :0 
  at Pinta.ResourceManager.GetIcon (System.String name, Int32 size) [0x00000] in :0 
  at Pinta.ResourceManager.GetIcon (System.String name) [0x00000] in :0 
  at Pinta.Gui.Widgets.OpenImagesListWidget..ctor () [0x00000] in :0 
  at Pinta.OpenImagesPad.Initialize (MonoDevelop.Components.Docking.DockFrame workspace, Gtk.Menu padMenu) [0x00000] in :0 
  at Pinta.MainWindow.CreateDockAndPads (Gtk.HBox container) [0x00000] in :0 
  at Pinta.MainWindow.CreatePanels (Pinta.WindowShell shell) [0x00000] in :0 
  at Pinta.MainWindow.CreateWindow () [0x00000] in :0 
  at Pinta.MainWindow..ctor () [0x00000] in :0 
  at Pinta.MainClass.Main (System.String[] args) [0x00000] in :0 

Para solucionarlo, por suerte solo tenemos que instalar el paquete 'gnome-icon-theme-full', por ejemplo, de la siguiente manera:

sudo apt-get install gnome-icon-theme-full

Y aquí podemos verlo funcionando.

Pinta 1.0 no se ejecuta en Kubuntu 11.04

Si intento ejecutar la última versión de Pinta (1.0) desde Kubuntu 11.04, la aplicación no se lanza. Para obtener alguna pista de qué está pasando, lo intento desde un Terminal, encontrándome el siguiente mensaje:

jmunin@dell-kubuntu-natty:~$ pinta


GLib.GException: Icon 'gtk-dialog-error' not present in theme
 at Gtk.IconTheme.LoadIcon (System.String icon_name, Int32 size, IconLookupFlags flags) [0x00000] in :0 
 at Pinta.ErrorDialog.Build () [0x00000] in :0 
at Pinta.ErrorDialog..ctor (Gtk.Window parent) [0x00000] in :0 
at Pinta.MainClass.ExceptionManager_UnhandledException (GLib.UnhandledExceptionArgs args) [0x00000] in :0 
at GLib.ExceptionManager.RaiseUnhandledException (System.Exception e, Boolean is_terminal) [0x00000] in :0

Tal como comentan aquí, el problema es que no encuentra el icono gtk-dialog-error en la instalación de Kubuntu. La solución pasa por instalar el paquete gnome-icon-theme:

jmunin@dell-kubuntu-natty:~$ sudo apt-get install gnome-icon-theme

Y ahora ya sin problemas.

Esta versión de Pinta ha sido instalada a partir de este repositorio (dispone de actualizaciones de muchas otras aplicaciones; muy recomendable).

Gestión de paquetes bloqueados (hold) en Debian/Ubuntu desde Consola

Lista de comandos útiles de consola/terminal, referentes a bloquear/proteger una determinada versión de paquete instalada (como muy bien explica aquí):

• Bloquear paquete:
  echo 'NOMBRE_PAQUETE hold' | sudo dpkg --set-selections
  
• Desbloquear paquete:
  echo 'NOMBRE_PAQUETE install' | sudo dpkg --set-selections
  
• Para ver su estado:
  dpkg --get-selections | grep NOMBRE_PAQUETE
  
• Listar paquetes bloqueados:
  dpkg --get-selections | grep 'hold'

El siguiente ejemplo tiene que ver con la instalación y uso del DNIe en distribuciones Debian (incluyendo Ubuntu), en las que tenemos que evitar que 2 paquetes se actualicen a sus últimas versiones: opensc y libopensc2 (explicado aquí).

Para bloquearlos desde un terminal (una vez instalados los paquetes), ejecutamos:

echo 'opensc hold' | sudo dpkg --set-selections
echo 'libopensc2 hold' | sudo dpkg --set-selections

Para verificar que todo ha funcionado, comprobamos la salida del siguiente comando:

dpkg --get-selections | grep 'hold'

También podemos comprobarlo ejecutando:

~$ sudo apt-get update && sudo apt-get upgrade
...
Leyendo lista de paquetes... Hecho
Creando árbol de dependencias
Leyendo la información de estado... Hecho
Los siguientes paquetes se han retenido: libopensc2 opensc
0 actualizados, 0 se instalarán, 0 para eliminar y 2 no actualizados.

Para todo esto también puede resultar muy útil wajig.

¿Y porqué hacer todo esto desde consola? Una de las razones es que el gestor de paquetes de Kde para Kubuntu (KPackageKit) no soporta la gestión de esta característica (bloqueo de versiones de paquetes). Es precisamente una de las novedades de la futura versión de Muon (la actual, 1.1.x todavía carece de ello), que por lo visto va a ser el nuevo gestor de paquetes de Kubuntu Oneiric Ocelot 11.10.

Montar imagen ISO sin formato ISO 9660

El otro día me encontré con el problema de querer montar una imagen ISO que no cumplía el formato ISO 9660. Lo intenté pulsando el botón derecho sobre el archivo .iso dentro de Nautilus, Menú de contexto-> Abrir con -> Montador de archivos.

Como no hacía nada, probé desde un terminal con (ver aquí):

sudo mount -t iso9660 -o loop archivo.iso /directorio/de/montaje

pero siempre me lanzaba un error, estilo 'wrong fs type', o 'CD-ROM is NOT in ISO 9660 format'.

Después de probar con la aplicación gISOMount sin ningún resultado (se quedaba colgada),

definitivamente solucioné el problema gracias a AcetoneISO.

Aunque los repositorios oficiales de Ubuntu ya integran una versión, normalmente no será la última. Para asegurarnos, podemos tirar del siguiente repositorio PPA (para Lucid), ejecutando desde un terminal:

sudo add-apt-repository ppa:ferramroberto/linuxfreedomlucid
sudo apt-get update
sudo apt-get install acetoneiso

Encontraremos el acceso directo dentro de Aplicaciones -> Sonido y Vídeo.

Instalar versiones actualizadas de aplicaciones en Ubuntu y derivadas

Un compañero que se está iniciando en el mundillo de las distribuciones Linux, me preguntaba como instalar una aplicación en Ubuntu. De entrada se defiende con Synaptic, así como con el concepto de repositorios. Si no fuese el caso, los recursos que os enlazo anteriormente son de obligada lectura.

De cualquier forma, es muy útil http://packages.ubuntu.com para localizar una aplicación dentro de los repositorios oficiales de Ubuntu, para una versión concreta (Jauntu, Karmic, etc) o todas ellas.

Por ejemplo, hablemos de la aplicación ufraw. Si empleamos el buscador que facilita la anterior dirección (http://packages.ubuntu.com/search?keywords=ufraw) vemos el siguiente resultado:

Ahí podemos comprobar de qué versión disponemos en nuestra edición de Ubuntu. Para saber si es muy reciente o no, lo siguiente sería intentar localizar la página oficial de la aplicación (google es nuestro aliado), en nuestro caso http://ufraw.sourceforge.net/

Ahí comprobamos que hasta hace bien poco (01/04/2010) la última versión era la 0.16, justamente la versión que integra el repositorio Universe de Ubuntu Lucid 10.04. Así que no tendríamos más que usar Synaptic o desde consola apt-get para instalar dicha versión si disponemos de Lucid.

Pero si por ejemplo todavía tenemos Karmic, la versión disponible en el repositorio Universe es la 0.15. O justamente ahora ha salido la 0.17, de manera que ni Lucid viene con la última versión en los repositorios oficiales. ¿Cómo podemos hacer para instalar una nueva versión?.

Si la propia página de la aplicación no ofrece un repositorio con la versión más reciente para nuestra edición de Ubuntu, disponemos de varias alternativas. Yo voy a comentar las 2 que considero más sencillas.

La primera sería utilizar el servicio GetDeb: http://www.getdeb.net/welcome/

En la parte superior derecha, tiene un cuadro de search. Si buscamos nuestra aplicación de ejemplo: http://www.getdeb.net/updates/Ubuntu/9.10/?q=ufraw la versión es la misma que traen los repos de Lucid. GetDeb compila los paquetes para distintas ediciones de Ubuntu (Jaunty, Karmic, Lucid) así que si pulsamos en el resultado de la búsqueda: http://www.getdeb.net/software/UFRaw observamos que disponemos de la 0.16 (parte inferior de la pantalla) tanto para Jaunty como para Karmic (o sea, la misma versión que ya integra Lucid).

Nos descargamos la versión y la instalamos (al estilo Windows, vía Gdebi). Si usamos Firefox, éste nos ofrecerá descargar el .deb o instalarlo con Gdebi.

El inconveniente de este sistema es que si van saliendo nuevas versiones no estaremos al corriente, cosa que sí ocurre si trabajamos con repositorios, que siempre nos mantienen al día de las actualizaciones.

La otra posibilidad de la que os quería hablar es la de los repositorios PPA (Personal Package Archives). Podemos buscar dentro del servicio PPA si alguien mantiene un repositorio con las últimas versiones de la aplicación en cuestión. Ese alguien puede ser alguno de los desarrolladores, o algún colaborador/usuario de la aplicación. En este caso, si la propia página de la aplicación no hace referencia a ningún repositorio PPA, podemos usar alguno de los buscadores de paquetes dentro de los repositorios PPA, por ejemplo: https://launchpad.net/ubuntu/+ppas

Justamente el primer resultado es del repositorio de un usuario que mantiene las compilaciones diarias de la aplicación (ojo, pues las compilaciones diarias suelen ser una versión de la aplicación muy inestable).

El repositorio https://launchpad.net/~pmjdebruijn/+archive/ppa dispone de la última versión (la 0.17, a día 01/04/2010) tanto para Karmic como para Lucid.

Si nuestra edición es Karmic o superior, podemos añadir el repositorio a nuestro 'source.list' muy fácilmente, tal como explican aquí, o directamente pegando el nombre del repositorio, en este caso 'ppa:pmjdebruijn/ppa', dentro de la pantalla para añadir repositorios de terceros en Synaptic (o KPackageKit, si usamos Kubuntu) o bien desde consola:

sudo add-apt-repository ppa:pmjdebruijn/ppa
sudo apt-get update
sudo apt-get install ufraw

Obtener/Establecer UUID de partición de SWAP

El otro día estuve reparticionando el disco duro (reorganizando particiones, incluido borrar mi actual swap y crearla con otra posición y tamaño) y al arrancar el sistema operativo, me encontré un error de que no se había podido montar la partición swap o de intercambio. En mi /etc/fstab estaba utilizando el código UUID para identificar mis particiones, por la razón que expliqué en una anterior entrada.

El problema fue que al eliminar la partición de swap y volverla a crear, el UUID de la partición cambió. Al disponerme a averiguar el nuevo UUID de la partición de swap, para corregirlo en mi /etc/fstab, me encuentro que la orden:

ls -la /dev/disk/by-uuid

lrwxrwxrwx 1 root root  10 2010-03-17 01:52 2251c12d-0e7c-5d13-6c91-0a89f48e3986 -> ../../sdb7
lrwxrwxrwx 1 root root  10 2010-03-17 01:52 2ca25890-b8ad-478e-a4e7-b7d5400494d0 -> ../../sdd1
lrwxrwxrwx 1 root root  10 2010-03-17 01:52 45a8bef4-918a-4ddf-818e-8bb04e9b660f -> ../../sdb3
lrwxrwxrwx 1 root root  10 2010-03-17 01:52 46cdf0a3-3201-4820-bf67-a3c76acdbfe0 -> ../../sdc1
lrwxrwxrwx 1 root root   9 2010-03-17 01:52 5d482f91-66d6-4fb8-a525-a746e69ad914 -> ../../sda
lrwxrwxrwx 1 root root  10 2010-03-17 01:52 8c79355f-406d-451b-8995-36498944bba3 -> ../../sda1
lrwxrwxrwx 1 root root  10 2010-03-17 01:52 9b39e0d5-619e-b437-3a42-fc5206cd21ae -> ../../sdb8
lrwxrwxrwx 1 root root  10 2010-03-17 01:52 CE50FBB050FB9E01 -> ../../sdb1
lrwxrwxrwx 1 root root  10 2010-03-17 01:52 DE08B62608B5FE19 -> ../../sdb5

no muestra la partición de swap, así como:

blkid

/dev/sda1: LABEL="DISCO3" UUID="8c79355f-406d-451b-8995-36498944bba3" SEC_TYPE="ext2" TYPE="ext3" 
/dev/sdb1: UUID="CE50FBB050FB9E01" LABEL="wXP" TYPE="ntfs" 
/dev/sdb3: UUID="45a8bef4-918a-4ddf-818e-8bb04e9b660f" TYPE="ext4" 
/dev/sdb5: UUID="DE08B62608B5FE19" LABEL="DATOS" TYPE="ntfs" 
/dev/sdb6: TYPE="swap" 
/dev/sdb7: LABEL="temp" UUID="2251c12d-0e7c-5d13-6c91-0a89f48e3986" SEC_TYPE="ext2" TYPE="ext3" 

que sí la muestra, pero indica que carece de dicho uuid. El caso es que la partición de swap existe, tal como verifico ejecutando:

sudo fdisk -l

Disco /dev/sdb: 500.1 GB, 500107862016 bytes
255 cabezas, 63 sectores/pista, 60801 cilindros
Unidades = cilindros de 16065 * 512 = 8225280 bytes
Identificador de disco: 0x381e381d

Disposit. Inicio    Comienzo      Fin      Bloques  Id  Sistema
/dev/sdb1   *           1        2611    20972826    7  HPFS/NTFS
/dev/sdb2            4192       60801   454719825    5  Extendida
/dev/sdb3            2612        4191    12691350   83  Linux
/dev/sdb5            4192       26769   181357753+   7  HPFS/NTFS
/dev/sdb6           26770       27044     2208906   82  Linux swap / Solaris
/dev/sdb7           27045       46736   158175958+  83  Linux
/dev/sdb8           46737       60801   112977081   83  Linux

donde compruebo que la partición swap está en /dev/sdb6.

La manera de asignar un nuevo uuid a la partición consiste en ejecutar las siguientes órdenes. Primeramente, y por seguridad, desmontamos las particiones de swap (si acaso estuviesen montadas):

sudo swapoff -a

para luego establecer cual queremos que sea nuestra partición swap (en mi caso /dev/sdb6):

sudo mkswap /dev/sdb6

que como vemos nos devuelve el nuevo uuid de la partición:

Configurando la versión swapspace 1, tamaño = 2208900 KiB
sin etiqueta, UUID=d1a2d270-78d5-4a4b-9854-ccc2cd7db1ef

Para comprobar que todo está correcto, vuelvo a ejecutar:

josea@ubuntu-desktop:/dev/disk/by-uuid$ ls -la
total 0
drwxr-xr-x 2 root root 240 2010-03-17 01:13 .
drwxr-xr-x 6 root root 120 2010-03-17 01:52 ..
lrwxrwxrwx 1 root root  10 2010-03-17 01:52 2251c12d-0e7c-5d13-6c91-0a89f48e3986 -> ../../sdb7
lrwxrwxrwx 1 root root  10 2010-03-17 01:52 2ca25890-b8ad-478e-a4e7-b7d5400494d0 -> ../../sdd1
lrwxrwxrwx 1 root root  10 2010-03-17 01:52 45a8bef4-918a-4ddf-818e-8bb04e9b660f -> ../../sdb3
lrwxrwxrwx 1 root root  10 2010-03-17 01:52 46cdf0a3-3201-4820-bf67-a3c76acdbfe0 -> ../../sdc1
lrwxrwxrwx 1 root root   9 2010-03-17 01:52 5d482f91-66d6-4fb8-a525-a746e69ad914 -> ../../sda
lrwxrwxrwx 1 root root  10 2010-03-17 01:52 8c79355f-406d-451b-8995-36498944bba3 -> ../../sda1
lrwxrwxrwx 1 root root  10 2010-03-17 01:52 9b39e0d5-619e-b437-3a42-fc5206cd21ae -> ../../sdb8
lrwxrwxrwx 1 root root  10 2010-03-17 01:52 CE50FBB050FB9E01 -> ../../sdb1
lrwxrwxrwx 1 root root  10 2010-03-17 01:13 d1a2d270-78d5-4a4b-9854-ccc2cd7db1ef -> ../../sdb6
lrwxrwxrwx 1 root root  10 2010-03-17 01:52 DE08B62608B5FE19 -> ../../sdb5

donde ya podemos comprobar que sale la partición de swap con su correspondiente uuid.

Ahora solo nos queda editar el /etc/fstab, en mi caso quedando así:

UUID=d1a2d270-78d5-4a4b-9854-ccc2cd7db1ef none            swap    sw              0       0

Ahora podríamos ejecutar la orden:

sudo swapon -a

para empezar a utilizar la partición, o simplemente reiniciar el sistema, para comprobar que todo vuelve a estar en orden.

Acciones (comunes y/o de root) en menú de contexto

Hoy he añadido 3 nuevos imprescindibles en la categoría de Linux (margen derecho del Blog):

- Para escritorio KDE:

• Root Actions Servicemenu

- Para escritorio GNOME:

• NScripts
• G-Scripts (Nautilus Scripts)

Todos tienen la misma finalidad: permitir la ejecución de acciones habituales y/o de root (normalmente sobre archivos o carpetas) de manera simple, a través del menú de contexto de nuestro administrador de archivos (Nautilus en caso de GNOME; Konqueror o Dolphin en caso de KDE). Realmente más que de aplicaciones, se trata de recopilaciones de scripts de shell (scripts de Perl en el caso de Root Actions Servicemenu), aunque alguno requiera la presencia de software adicional.

La manera fácil de instalar Root Actions Servicemenu en Kubuntu (probado en Jaunty, Karmic, Lucid) es abrir una consola y ejecutar:

sudo add-apt-repository ppa:samrog131
sudo apt-get update
sudo apt-get install servicemenu-rootactions

Si queremos hacerlo manualmente descargamos el tar.gz de su sitio web, lo descomprimimos (por ejemplo en nuestro 'home' o carpeta de usuario), copiamos el archivo rootactions-servicemenu.pl a /usr/local/bin o /usr/bin

josea@linux-intb:~/Download/Root_Actions_2.4.8> sudo cp rootactions-servicemenu.pl /usr/local/bin

y comprobamos que tenga activado el atributo de ejecutable

josea@linux-intb:/usr/local/bin> ls -l
total 40
-rwxr-xr-x 1 root root 39078 ene 11 17:54 rootactions-servicemenu.pl

A continuación copiamos los archivos .desktop de dolphin-KDE4 a la carpeta service dentro de la configuración de nuestro KDE4, que (depende de la distro, en este caso openSUSE 11.2) podría ser ~/.kde4/share/kde4/services/:

josea@linux-intb:~/Download/Root_Actions_2.4.8/dolphin-KDE4> cp *.desktop ~/.kde4/share/kde4/services

Ahora ya podemos borrar el tar.gz y la carpeta donde lo hayamos descomprimido.

Para instalar g-scripts, descargamos el tar.gz, y lo descomprimimos dentro de ~/.gnome2. No hace falta hacerlo dentro de ~/.gnome2/nautilus-scripts/, pues la jerarquía de carpetas del tar.gz ya la incluye.

Si queremos instalar NScripts, descargamos el tar.gz, y en este caso sí que necesitaremos descomprimirlo dentro de ~/.gnome2/nautilus-scripts/

Ahora solo tenemos que abrir Nautilus o Dolphin, abrir el menú de contexto sobre un archivo o carpeta, y veremos un nuevo subconjunto de órdenes, dentro de la opción 'Scripts' en caso de Nautilus, y 'Opciones de root' en caso de Dolphin/Konqueror.

Sobre un archivo:

Sobre una carpeta:

Compilaciones diarias de Chromium

Si queréis estar al tanto del estado de desarrollo del navegador Chromium, proyecto de software libre detrás de Google Chrome, no tenéis más que comprobarlo vosotros mismos, simplemente ejecutando (en una distro derivada de Ubuntu Karmic 9.10):

sudo add-apt-repository ppa:chromium-daily/ppa
sudo apt-get update
sudo apt-get install chromium-browser

lo que os permitirá acceder a las compilaciones diarias de dicho navegador.

La verdad que actualmente es perfectamente utilizable, y aunque todavía no al nivel de funcionalidad de Firefox, es increíble lo que los desarrolladores de Google han conseguido en tan poco tiempo. Sin duda en cuestión de meses será un firme candidato a navegador 'predeterminado' en nuestro escritorio.

OpenShot Video Editor 1.0

Hoy ha sido publicada oficialmente la primera versión final de este magnífico editor de vídeo no lineal. Junto con Kdenlive, los 2 mejores editores de código abierto que existen actualmente. Así como Kdenlive ya es un proyecto veterano, es increíble lo que el equipo de desarrollo de OpenShot ha conseguido en tan poco tiempo (Agosto de 2008, tal como podemos leer en esta entrada sobre la historia del proyecto). Hoy en día casi no tiene nada que envidiar a soluciones propietarias (además que de pago) de edición no profesionales, como Pinaccle Studio, Nero Vision, Windows Movie Maker, etc.

Si queréis echarle un ojo, y usáis cualquier distro derivada de Ubuntu Karmic 9.10, simplemente:

sudo add-apt-repository ppa:jonoomph/openshot-edge
sudo apt-get update
sudo apt-get install openshot

Actualizando GRUB2

Recientemente instalé Ubuntu 9.10 Karmic Koala en mi portátil, machacando el gestor de arranque que tenía en el MBR (GRUB instalado por openSUSE) por el nuevo GRUB2 que incorpora Karmic.

La verdad que en principio todo funcionó, siendo capaz tanto de arrancar con Karmic, como con Windows 7 (las menos) y openSUSE (de calle la mejor en integrar el escritorio KDE).

El problema surgió en el último arranque que hice con openSUSE, pues YaST actualizó algunos paquetes, entre los que se encontraba una revisión del kernel. La siguiente vez que intenté arrancar openSUSE desde GRUB2, éste me lanzó un error de que no encontraba el kernel de openSUSE.

Así que después de arrancar con Karmic, y tirando de algunos recursos, concretamente éste (o este otro en castellano), la solución fue ejecutar update-grub (como root), tal como se muestra a continuación:

josea@ubuntu-dell:~$ sudo update-grub
[sudo] password for josea: 
Generating grub.cfg ...
Found linux image: /boot/vmlinuz-2.6.31-16-generic
Found initrd image: /boot/initrd.img-2.6.31-16-generic
Found linux image: /boot/vmlinuz-2.6.31-14-generic
Found initrd image: /boot/initrd.img-2.6.31-14-generic
Found memtest86+ image: /boot/memtest86+.bin
Found Dell Utility Partition on /dev/sda1
Found Windows 7 (loader) on /dev/sda2
Found openSUSE 11.2 RC 1 (i586) on /dev/sda6
done
josea@ubuntu-dell:~$ 

update-grub ejecuta unos scripts que se encuentran dentro de /etc/grub.d, que entre otras cosas, y dinámicamente, se encargan de encontrar los s.o. que tengamos en nuestra máquina, y almacenar toda esa información en el archivo grub.cfg, que se encuentra en /boot/grub (vendría a ser el menu.lst de GRUB) y que no deberíamos modificar manualmente, ya que de esto se encargan precisamente los scripts mencionados antes.

Si GRUB2 no estuviese correctamente instalado, ejecutaríamos a continuación (en mi caso no fue necesario):

sudo grub-install /dev/sda

que instalaría GRUB2 en el MBR de la unidad sda (usar sdb, etc si vuestra unidad es otra, o usar /dev/sdaX, sustituyendo sda por lo que corresponda, y X por el número de la partición en la que queramos instalar GRUB2, si no quisiésemos hacerlo en el MBR). Si lanzase algún error, podríamos intentarlo con:

sudo grub-install --recheck /dev/sda

Es hora de reiniciar y comprobar si nuestro trabajo ha resultado satisfactorio.

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