Lo hice y lo entendí

De la época que estuve usando Gentoo recuerdo con especial cariño dos cosas: la flexibilidad y la posibilidad de personalización durante el compilado de los parámetros USE, y las herramientas de gestión de paquetes de Portage: el emerge y el equery del Gentoolkit.

El emerge viene a ser una unión de los comandos de Debian dpkg, apt-get, apt-cache y apt-build. Nigún misterio por esa parte…

Sin embargo, el equery que, como su propio nombre indica, se usa para hacer queries a la base de datos de paquetes, resulta muy útil. Por ejemplo, se puede obtener la lista de paquetes que dependen de uno dado (ejemplo copiado de Gentoolkit):

# equery depends pygtk
[ Searching for packages depending on pygtk... ]
app-office/dia-0.93
dev-python/gnome-python-2.0.0-r1
gnome-extra/gdesklets-core-0.26.2
media-gfx/gimp-2.0.4
x11-libs/vte-0.11.11-r1

También nos permite obtener un árbol de dependencias de un paquete dado, pero en este caso no se trata de los paquetes de los que depende el paquete, sino de sus dependencias:

# equery depgraph cdrtools
Displaying dependencies for app-cdr/cdrtools-2.01_alpha37
`-- app-cdr/cdrtools-2.01_alpha37
 `-- sys-libs/glibc-2.3.4.20040808 (virtual/libc)
  `-- sys-kernel/linux-headers-2.4.22 (virtual/os-headers)
   `-- sys-apps/baselayout-1.10.4
    `-- sys-apps/sysvinit-2.85-r1
     `-- sys-apps/gawk-3.1.3-r1
      `-- sys-apps/util-linux-2.12-r4
          `-- sys-apps/sed-4.0.9
        `-- sys-libs/ncurses-5.4-r4
            `-- sys-apps/pam-login-3.14
            `-- sys-libs/pam-0.77-r1
                 `-- sys-libs/cracklib-2.7-r10
               `-- sys-apps/miscfiles-1.3-r1
              `-- app-arch/gzip-1.3.5-r1
              `-- sys-apps/portage-2.0.50-r10

En Debian, a menudo quiero eliminar un paquete y las dependencias no me lo permiten:

 # dpkg -P libxine1
dpkg: dependency problems prevent removal of libxine1:
 totem-xine depends on libxine1 (>= 1.1.2-5).
dpkg: error processing libxine1 (--purge):
 dependency problems - not removing
Errors were encountered while processing:
 libxine1

Es posible que esté tan convencido de querer eliminar el paquete que me decida incluso a eliminar sus dependencias:

# dpkg -P totem
dpkg: dependency problems prevent removal of totem:
 gnome-desktop-environment depends on totem (>= 1.4.3).
dpkg: error processing totem (–purge):
 dependency problems - not removing
Errors were encountered while processing:
 totem

Pero claro, llegados a este punto, me temo que el gnome-desktop-environment no lo quiero eliminar. De momento, los paquetes ya me los ha dejado marcados como que no los quiero instalados para aprovechar la mínima ocasión para eliminarlos:

# dpkg -l | egrep -v ^ii
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Installed/Config-files/Unpacked/Failed-config/Half-installed
|/ Err?=(none)/Hold/Reinst-required/X=both-problems (Status,Err: uppercase=bad)
||/ Name             Version              Description
+++-================-====================-============================================
pi  libxine1         1.1.2+dfsg-4         the xine video/media player library, binary
pi  totem            2.16.5-3             A simple media player for the Gnome desktop

Como a mí me da manía dejarlos así, pues en este punto haría un “apt-get --reinstall install libxine1 totem” para que vuelvan a estar en estado ii.

La forma elegante de prever y al mismo tiempo tantear si podríamos borrar el paquete sería haber usado el “dpkg -P” con una de las tres opciones que evitan que la acción se haga en realidad:

       –no-act | –dry-run | –simulate
              Do everything which is supposed to be done, but  don’t  write  any  changes.
              This  is  used  to  see what would happen with the specified action, without
              actually modifying anything.

              Be sure to give –no-act before the action-parameter, or you  might  end  up
              with  undesirable  results. (e.g. dpkg –purge foo –no-act will first purge
              package foo and then try to purge package –no-act, even though you probably
              expected it to actually do nothing)

Pero bueno, esta forma de trabajar por tanteo me parece un atraso tras haber visto lo que puede hacer el equery.

Sigue leyendo »

Siempre he tenido la idea de que la shell de Windows era terriblemente limitada, no sólo por las funcionalidades propias del CMD (algo mayores que las del viejo COMMAND.COM, en cualquier caso) sino también por la ausencia de esos viejos amigos del intérprete de comandos que tanto facilitan la vida en UNIX: grep, awk, sed, etc. Por eso, entre otras cosas, me gusta tanto el Cygwin, porque me permite tener toda la potencia de la shell de UNIX en Windows.

Pero para ser sincero, hablando de scripting en Windows, he de reconocer que he visto hacer cosas muy interesantes con VBScript e incluso de vez en cuando ves algún script de CMD que te llama mucho la atención, como me pasó hace unos días.

Tenía una aplicación en Windows que iba escribiendo en un fichero de log de esos que van rotando. Lo típico, la aplicación va escribiendo en un fichero logfile.log que cuando llega a un tamaño es renombrado a logfile.log.old reemplazando al anterior con ese mismo nombre y genera un nuevo logfile.log.

Pues bien, yo necesitaba recoger esos .old durante varios días apuntando la hora exacta a la que se había guardado, una tarea trivial en UNIX: Pones un script como el siguiente en el cron para que se ejecute cada minuto y un logfile.log.old se convierte en un logfile.log.200709141929 en un santiamén:

#!/bin/sh
if [ -f logfile.log.old ]
then
   mv logfile.log.old logfile.log.$(date +%Y%m%e%k%M)
fi

En el CMD de Windows esto no es tan sencillo, para empezar porque los comandos date y time de Windows no se puede decir que sean lo más versátil del mundo: ¡Sólo aceptan el parámetro /t!

C:\>date /t
14/09/2007

C:\>time /t
19:51

Sigue leyendo »

Es posible que alguna vez os hayáis visto con la necesidad de probar una placa base con su memoria y su procesador y tal vez disco duro, unidad óptica, etc., fuera de una caja. En servicios técnicos y tiendas como la del tendero digital seguro que tienen que hacerlo de vez en cuando para probar tal placa base o tal componente. En nuestras casas es más raro, aunque puede presentarse alguna vez el caso.

Suponiendo que tenemos una fuente de alimentación ATX disponible, esto no supone mayor problema, de forma que podamos montar fácilmente un entorno de pruebas similar al de estas fotos (encontradas aquí y aquí):

No tiene mayor complicación…. excepto por un elemento clave… ¡El interruptor!

Sí, porque a diferencia de las viejas fuentes AT que llevaban un interruptor conectado a la propia fuente, las fuentes ATX necesitan que les llegue la señal de encendido de la placa base. Esto permite cosas tan interesantes como arrancar el ordenador con el teclado, a una hora determinada, después de perder la alimentación o por Wake on LAN… El interruptor de la caja ahora es un sencillo pulsador con retorno que le da la señal de encendido a la placa base. Como muchos ya sabréis, si lo dejas pulsado varios segundos, el ordenador se apaga.

Sigue leyendo »

Pocos se acordarán ya de la que fue una de las primeras entradas de este blog, La pesadilla de compartir partición entre Linux y Windows. En ella, contaba cómo hacía poco había empezado a usar el driver NTFS-3G para compartir particiones entre Linux y Windows y que justo ese día había salido el NTFS-3G 1.0.

Pues bien, desde entonces vengo usando el NTFS-3G continuamente, habiendo visto cómo el driver cada vez funciona mejor y más rápido. Szabolcs Szakacsits, el principal desarrollador del proyecto, tiene todos mis agradecimientos por haber conseguido algo que se había hecho esperar tanto (soporte seguro de lectura y escritura de NTFS en Linux) y con tanta calidad.

En fin, el caso es que desde el principio me venía fijando en que cuando hacía según qué operaciones de escritura en la partición NTFS usando un usuario distinto de root me encontraba con el error:

cp: preserving times for 'foo': Operation not permitted

Y los ficheros se creaban con la fecha actual en lugar de la suya. Por ejemplo:

$ ll torvalds-says-linux.au
-rw-r--r-- 1 supercoco users 41493 2006-10-27 21:24 torvalds-says-linux.au
$ cp -p torvalds-says-linux.au /mnt/e/
cp: preserving times for `/mnt/e/torvalds-says-linux.au’: Operation not permitted
$ ll /mnt/e/torvalds-says-linux.au
-rwxrwxrwx 1 root root 41493 2007-09-10 22:31 /mnt/e/torvalds-says-linux.au

Esto no ocurre con root:

# ll torvalds-says-linux.au
-rw-r--r-- 1 supercoco users 41493 2006-10-27 21:24 torvalds-says-linux.au
# cp -p torvalds-says-linux.au /mnt/e/
# ll /mnt/e/torvalds-says-linux.au
-rwxrwxrwx 1 root root 41493 2006-10-27 21:24 /mnt/e/torvalds-says-linux.au

Tenía pendiente investigar la causa pero no le estaba dando mucha importancia. Hasta que hace unos días pasé todas las fotos de la tarjeta de memoria de la cámara de fotos y a continuación me di cuenta de que los ficheros habían perdido la fecha y hora correctas, algo que me molestó mucho. No es una pérdida irreparable, porque dichos datos siguen estando en la cabecera Exif de las fotos, pero sí fue muy molesta.

En realidad la solución estaba a tiro de Google en forma de hilo de los foros de NTFS-3G y con contestación del propio szaka (Szabolcs Szakacsits): cp: preserving times for ‘file’: Operation not permitted.

El problema estaba en que yo montaba la partición poniendo lo siguiente en el /etc/fstab:

/dev/sdb6  /mnt/e ntfs-3g rw,defaults,umask=000,locale=en_US.ISO-8859-15    0       0

y resulta que si se especifica una de las opciones uid, gid o [udf]mask, es el propio FUSE el que verifica dichas opciones y gestiona los permisos.

Teniendo en cuenta que ntfs-3g funciona con el setuid de root:

# ll /usr/bin/ntfs-3g
-rwsr-xr– 1 root fuse 40440 2007-08-08 19:50 /usr/bin/ntfs-3g

Extracto del man de ntfs-3g:

If ntfs-3g is set setuid-root then non-root users will be also able to mount block devices
or via /etc/fstab if the 'user' or 'users' mount(8) option is specified. The ntfs-3g  pro-
cess drops the root privilege after successful mount and runs unprivileged afterwards.

FUSE hace lo correcto según el estándar POSIX al rechazar la operación, como nos cuenta Szabolcs:

I have the result of the investigation. FUSE is right. Things worked
as they should. The operation indeed mustn't be permitted in such cases
according to the POSIX standard.

Namely utimes(2) doesn't permit changing the time stamps because the
effective uid of the cp process doesn't equal the uid of the file
__AND__ the new time stamps are not the current time, __EVEN_IF__
the user has write permission to the file. This is how POSIX wants.

Por tanto, si quitamos el umask=000 que, en cualquier caso, es el valor que se toma por defecto, FUSE no hará las comprobaciones y las horas y fechas se escribirán correctamente, aunque no estemos con el usuario root.

Esta es la línea de mi /etc/fstab ahora:

/dev/sdb6  /mnt/e ntfs-3g rw,defaults,locale=en_US.ISO-8859-15    0       0

Por cierto, ¿a alguien le ha llamado la atención el fichero que he usado de prueba? El fichero de audio (formato au) torvalds-says-linux.au es muy antiguo y al reproducirlo oímos a Linus Torvalds pronunciar Linux. Pronunciación que se usa de referencia desde entonces. Se puede reproducir en un sistema Linux con OSS simplemente haciendo:

cat torvalds-says-linux.au > /dev/audio

Supuso una enorme alegría para mí la primera vez que conseguí configurar una tarjeta de sonido en Linux y oír a Linus. Yo encontré el fichero en uno de mis viejos CDs de InfoMagick. Hoy en día está en múltiples sitios y formatos. Por ejemplo, en la página de Paul Slanden.

En la entrada anterior, Iniciar una instalación de Debian por red, introducíamos los sistemas diskless. Basándonos en la infraestructura detallada en dicha entrada, el arrancar una Debian completa desde la red sólo supone unos sencillos pasos más.

En concreto, si ya somos capaces de arrancar la instalación de Debian por la red, alterando el fichero de configuración del PXELINUX podemos lograr que el sistema que arranca de la red use el kernel que nos interese y, a continuación, montar por NFS el sistema de ficheros que tendremos preparado en otra máquina.

El primer paso es crear una instalación de Debian dentro de un directorio del servidor de arranque (en mi caso /exports/peggy, donde peggy es el nombre del sistema que arrancará Debian de la red) usando el útil comando debootstrap

# mkdir -p /exports/peggy
# debootstrap --arch i386 etch /exports/peggy http://ftp.es.debian.org/debian/

El debootstrap no instala un kernel por defecto, así que entramos en la nueva instalación con chroot para instalar uno:

# chroot /exports/peggy
# apt-get install linux-image-686 libc6-i686
# exit

Ahora vamos a crear un nuevo fichero de configuración para el PXELINUX. Como podemos leer en la documentación del PXELINUX, el fichero default, que es el que ya tenemos, es el último que se intenta cargar. Antes de eso, el gestor de arranque por red trata de usar un fichero con un nombre como 01-<direccion MAC en minúsculas y con guiones como separadores de bytes>. Por ejemplo, si la dirección de nuestro sistema es 00:41:64:ED:29:D3, necesitaremos un fichero con el nombre 01-00-41-64-ed-29-d3 en /var/lib/tftpboot/pxelinux.cfg/.

Sigue leyendo »

El conjunto de piezas de PC más pequeño que sirva para hacer algo es: CPU, placa base con procesador de vídeo integrado (opcionalmente con una CPU integrada también, como en el caso de las VIA EPIA) y fuente de alimentación.

Con esta configuración necesitaríamos arrancar de la red para poder hacer algo y estaríamos hablando de un sistema diskless.

Si queremos que el sistema sea autónomo, además de las piezas anteriores, necesita un sistema de almacenamiento propio (disco duro, memoria USB, unidad óptica, disquetera) del que arrancar, que normalmente será un disco duro. Supongamos que tenemos un sistema mínimo sólo con un disco duro, queremos instalarle Debian y no tenermos una unidad óptica externa ni nada que podamos usar para hacer la instalación estándar. En ese caso, necesitaremos arrancar la instalación por red.

Es un proceso bastante sencillo, aunque necesitaremos una cierta infraestructura en otro sistema ya instalado del que el sistema a instalar obtendrá todo lo necesario. La máquina a instalar ha de soportar arrancar desde la red por PXE, una combinación de DHCP y TFTP que permite asignar una dirección IP al sistema cliente y a continuación pasarle los ficheros necesarios para que lo haga.

En mi caso, como el router ADSL que uso ya es servidor de DHCP, es deseable evitar posibles interferencias al montar un nuevo servidor DHCP a pesar de que, según la Wikipedia, esto en teoría se podría evitar:

The PXE Client/Server Protocol was designed so it can be used in the same network as an existing DHCP environment without interference

Por ello, y como el PC destinado a servidor de arranque tiene dos interfaces de red, uno normalmente sin usar (eth0) y otro conectado al router (eth1), yo prefiero independizar ambas redes, de tal forma que si conectamos con un cable cruzado la toma de red del sistema a instalar con el interfaz sin usar, estamos listos para comenzar la configuración del sistema.

Sigue leyendo »

¿Te sentiste melancólico al leer la entrada Los Linux de mi vida? ¿Te llenó de nostalgia ver la captura de pantalla que tomé de las X Windows con FVWM en Slackware 1.1.2?

A mí, desde luego, sí, y por eso me puse a ver cómo poner un FVWM con el sabor de aquél en una Debian moderna. Y lo digo porque el FVWM puede tomar más aspectos diferentes que un camaleón, como podemos ver en la página de capturas de pantalla de FVWM. Por tanto, voy a proponer, con unos pocos y sencillos pasos una forma para disfrutar un ratito de un FVWM “retro” con una Debian actual. En este viaje al pasado no vamos a romper nada ni vamos a cambiar nada de la configuración actual que podamos tener para arrancar KDE, Gnome, o lo que sea que estemos usando, ya que entiendo que nadie quiera usar esta configuración para siempre…

1) Instalamos el paquete fvwm1:

# apt-get install fvwm1
Reading package lists... Done
Building dependency tree
Reading state information... Done
Suggested packages:
  librplay3
The following NEW packages will be installed:
  fvwm1
0 upgraded, 1 newly installed, 0 to remove and 0 not upgraded.
Need to get 0B/297kB of archives.
After unpacking 831kB of additional disk space will be used.
Selecting previously deselected package fvwm1.
(Reading database ... 146100 files and directories currently installed.)
Unpacking fvwm1 (from .../fvwm1_1.24r-51.2_amd64.deb) ...
Setting up fvwm1 (1.24r-51.2) ...

2) Copiamos este fichero system.fvwmrc-menu a /etc/X11/fvwm/. Opcionalmente, antes de hacerlo, podemos querer hacer un backup del archivo system.fvwmrc-menu que pone Debian por defecto.

3) Ejecutamos “update-menus” para añadir todos los programas instalados en el sistema al menú de FVWM. En Debian, el fichero system.fvwmrc-menu es una plantilla a partir de la cual el update-menus crea un system.fvwmrc con un menú con todos los programas. Igual que hace con cualquier gestor de ventanas instalado en el sistema.

4a) Si estamos usando un Display Manager o Login Manager como kdm, gdm o xdm, lo paramos con /etc/init.d/kdm stop, /etc/init.d/gdm stop o /etc/init.d/xdm stop. Si estábamos en una sesión gráfica se cerrará y volveremos a la consola de texto.

4b) Si solemos entrar en las X Windows con startx, salimos.

5) Si existe el fichero ~/.xinitrc en el $HOME de nuestro usuario, podemos hacer una copia de seguridad o renombrarlo temporalmente. En cualquier caso, editamos el fichero ~/.xinitrc y en la primera línea ponemos “fvwm“.

6) Ejecutamos startx y ¡volvemos 12 años atrás!

¿Qué cambios lleva el fichero system.fvwmrc-menu que propongo sobre el de por defecto de fvwm1?

Sigue leyendo »

En algunos casos puede interesar que la base de datos de WordPress no cambie durante algún tiempo para cualquier tarea de mantenimiento. Nuevas entradas, si tú eres el único que escribe el blog, no va a haber, claro. Pero te puede interesar que nadie haga el esfuerzo de escribir nuevos comentarios si luego podría ocurrir que se fueran a perder.

Para ello, puedes cerrar los comentarios y los pings en todas las entradas fácilmente entrando en mysql:

mysql -u usuario_mysql_wordpress -p nombre_base_de_datos_wordpress

y ejecutando la siguiente sentencia SQL:

UPDATE wp_posts SET comment_status = 'closed', ping_status = 'closed' WHERE comment_status = 'open';

Para volver a permitir los comentarios después:

UPDATE wp_posts SET comment_status = 'open', ping_status ='open' WHERE comment_status = 'closed';

Encontrado en: Enable or Disable WordPress Comments on all posts in one step

Hace un rato os contaba cómo configurar el Epson 2480 en Linux. Ha sido muy fácil, ¿verdad? Bueno, pues era más bien una excusa para entrar caliente en un tema que quería abordar hace tiempo…

Siendo el caso del Epson Perfection 2480 uno de los casos más fáciles que podemos encontrar para configurar un dispositivo hardware que no esté directamente soportado por el kernel, nos toca reconocer que a Linux aún le queda un buen camino que recorrer en el área del reconocimiento automático del hardware, algo que sin el apoyo real de los fabricantes nunca será posible del todo. Este dispositivo está bien soportado en Linux, pero como el firmware es cerrado, no puede ser incluido en distribuciones que tengan un mínimo reparo a las licencias del software que incluyen.

En la época de Windows 95 anterior a la llegada del 98 teníamos otro escáner, un Mustek Paragon 6000p de puerto paralelo. Estábamos contentos con aquel escáner, aunque como el 486 no tenía EPP/ECP la velocidad de transmisión de imágenes al PC era lamentable. Pero bueno, el caso es que cuando salió Windows 98, Mustek no sacó drivers para este nuevo sistema operativo. Incluso hoy en día, si vamos a la página de drivers del 600 III EP Plus (¡el 6000p no está!) vemos que sólo hay drivers para Windows 95. ¿Qué pasó? Pues que si migraba no tenía escáner. Ahí me di cuenta de que si el escáner estaba soportado en Linux con un driver abierto (sí que lo está, aunque no sé desde cuándo), jamás me tendría que preocupar en adelante porque un dispositivo hardware dejara de estar soportado. Desafortunadamente, aquel escáner tuvo una muerte temprana, pero si aún estuviera funcionando, yo, en 2007, más de 10 años más tarde, podría poneros capturas obtenidas con él con mi Debian, pero desde luego no podría hacer lo mismo con Windows XP ni con Vista.

Estos problemas le ocurrieron a mucha gente cuando Windows 98 no aceptaba los drivers de Windows 95 y el fabricante no hacía drivers para dispositivos de un año o dos de antiguedad para Windows 98. Volvió a ocurrir cuando muchos dispositivos quedaron en la cuneta en el paso a Windows 2000. Ahora, como los drivers de Windows 2000 sirven para Windows XP, llevámos mucho tiempo sin vivir estos problemas y se nos habían olvidado, pero con la salida de Vista, de nuevo está ocurriendo que ante la ausencia de drivers para Vista, muchos tienen que elegir entre su hardware o Vista (que yo lo tendría claro, pero en fin, para gustos están los colores).

Es el paraíso de los fabricantes. No me extrañaría que desearan con todas sus fuerzas que con cada nueva versión Microsoft cambiara el formato de sus drivers para que todos los usuarios tiraran a la basura sus dispositivos totalmente funcionales y compraran nuevos compatibles con el nuevo Windows Tuerto de turno.

Y es que comprar hardware para el que exista un driver en Linux te garantiza que tu hardware morirá cuando tú quieras, no cuando quiera el fabricante dejar de soportar el dispositivo porque con dos años ya está obsoleto.

Pero no sólo eso: Hay esforzadísimos programadores de drivers de Linux que se lo curran muchísimo para, contra el viento y la marea de los fabricantes que no proporcionan las especificaciones de sus dispositivos, crear drivers usando ingeniería inversa de los drivers de Windows. Su labor es altamente loable, pero no hemos de conformarmos con eso. Un driver obtenido por ingeniería inversa normalmente será de peor calidad que uno hecho a partir de las especificaciones. Así que, como dicen los americanos, tenemos que votar con nuestros euros y favorecer a los fabricantes que proporcionan las especificaciones de su hardware o, incluso mejor, que favorecen e impulsan la creación de drivers abiertos.

El poder está en nuestras manos si lo usamos bien. Si te vas a comprar una tarjeta WiFi fíjate en que Ralink hace un esfuerzo grande para que tengamos buenos drivers para sus chips, fíjate en que Intel proporciona los mejores drivers abiertos de procesadores gráficos de hoy en día, fíjate en que con la ayuda para hacer drivers para Linux que proporciona VIA a los desarrolladores y los que ella misma distribuye, las placas VIA EPIA van mejor en Linux que en Windows…

…y fíjate en que si ahora mismo NVidia y ATI cerraran sus puertas, nos quedaríamos con tarjetas gráficas compradas por entre 100 y 600€ que en pocos meses no servirían para nada que no fuera 2D.

Por tanto, por favor, antes de comprar cualquier hardware nuevo, comprueba previamente si está soportado en Linux. Estarás favoreciendo a los fabricantes que colaboran con la comunidad de código abierto, estarás perjudicando a los que no lo hacen y, sobre todo, saldrás ganando tú. Es posible que no uses Linux ni quieras usarlo en el futuro, pero haciéndolo así sabes que dentro de 10 años, si quieres volver a usar ese dispositivo que tienes en el armario, podrás hacerlo, aunque tenga que ser con Linux.

Hace unos años compramos en casa un escáner Epson Perfection 2480 para un tema muy concreto que tuvimos que hacer en Windows. Es un buen escáner. Como llevábamos tiempo buscando uno que diera una calidad razonable sin llegar al precio de un escáner profesional, cuando dimos con él por fin pudimos respirar, ya que habíamos tenido que devolver varios anteriormente porque de verdad no llegaban al límite de lo aceptable.

Ya no lo habíamos vuelto a usar desde entonces, pero hace unos días lo recuperé para escanear los CDs de la entrada Los Linux de mi vida. Como no podía ser de otra forma, lo hice en mi Debian, así que os voy a contar los pasos que hay que seguir para ello.

1) Instalar el SANE (Scanner Access Now Easy), si no lo está ya:

apt-get install libsane

El paquete libsane-extras contiene soporte para algunos escáneres adicionales.

2) Desde la página lista de escáneres soportados por SANE vamos a la página del driver SnapScan, que es el que hace falta para este dispositivo, que nos informa de que necesitamos obtener el fichero de firmware esfw41.bin de los drivers de Windows.

2a) Descargamos el driver del Epson Perfection 2480 para Windows, que es un fichero zip autodescomprimible. Lo descomprimimos con unzip y obtenemos varios ficheros, uno de los cuales es el ModUsd.cab. Si lo descomprimimos con cabextract encontraremos finalmente el esfw41.bin.

O también:

2b) Si tenemos el driver instalado en Windows, copiamos el fichero de c:\windows\system32

3) Copiamos el fichero esfw41.bin al sitio que deseemos del sistema de ficheros

4) Editamos el fichero /etc/sane.d/snapscan.conf y especificamos el sitio donde hemos dejado nuestro fichero de firmware:

# Change to the fully qualified filename of your firmware file, if
# firmware upload is needed by the scanner
firmware /mi/path/esfw41.bin

5) Editamos el fichero /etc/group y añadimos el usuario que vaya a hacer uso del escáner (no se debe usar root para esto) al grupo scanner.

scanner:x:110:supercoco

6) Usamos unos de los frontends de SANE para escanear, como por ejemplo el XSane, casi tan bueno o más que el software oficial Epson para Windows.

¡Ya está! Como veis, no tiene ninguna complicación. Al final, si no fuera por el fichero de firmware y por tener que darle permisos al usuario para escanear, no habría que hacer nada, sólo pinchar y usar (plug & play).