Estación de Tránsito

Instalación y configuración de un Proxy/Web Caché

En una red local que permita el acceso a Internet, la mayoría de los equipos se conecta a los mismos sitios en forma reiterada. El Sistema Operativo y algunas aplicaciones (como los antivirus) bajan actualizaciones cotidianamente. Es decir, se descargan múltiples veces los mismos archivos, y cuantos más equipos se tengan en la red, peor es la redundancia en las descargas. Ni hablar del tiempo desperdiciado en bajar de Internet archivos que ya fueron descargados por otro equipo de la red. Si, además, contamos con una conexión a Internet con escaso ancho de banda, o alta latencia, el problema se agrava todavía más. La solución es incorporar a la red un Web Proxy que centralice la navegación en un servidor y que, también, permita cachear los archivos, para evitar su redescarga, de modo similar al caché de un navegador web. En esta ocasión, explicaremos cómo trabajar con Squid, un Proxy/Web Caché de código abierto (Open Source) extremadamente configurable y poderoso.

DESCARGANDO SQUID
Si Linux es nuestra plataforma, para descargar e instalar Squid lo haremos a través del administrador de paquetes de nuestra distribución (en Debian o Ubuntu es posible realizarlo desde la línea de comandos con sudo apt-get install squid). En el desafortunado caso de que no cuenten con uno (¿qué esperan para actualizarse a una distribución moderna?) deberán recurrir al sitio oficial de Squid, del que se podrán bajar varias versiones de binarios, o los fuentes si prefieren compilarlo ustedes mismos. Si son usuarios de Windows, tendrán que descargar el port de Windows que mantiene la empresa italiana Acme Consulting. Hay distintas versiones, pero aconsejamos trabajar con la “Standard”, cuya última versión se baja de aquí. Una vez descargado, recomendamos extraerlo en la raíz de la unidad C para que quede instalado en C:\squid, que es la ruta usada por defecto en el archivo de configuración.

A EDITAR LA CONFIGURACIÓN
Nos dirigimos a nuestro editor de textos preferido y modificamos el archivo de configuración, que en el caso de Linux se encuentra en /etc/squid/squid.conf, y en el de Windows en C:\squid\etc\squid.conf.default (en este último, conviene hacer “guardar como” squid.conf y dejamos el squid.conf.default como backup; lo mismo hay que realizar con los archivos mime.conf.default y cachemgr.conf.default). Al trabajar con este archivo es preferible tener en cuenta algunas cosas. Todas las líneas comenzadas con el signo # son “comentarios” y, por ende, son ignoradas por Squid. Es buena idea que hagamos un uso extensivo de los comentarios al llevar a cabo modificaciones en la configuración, ya que, en variadas ocasiones, deberemos retocarla mucho tiempo después y, si no hemos formulado comentarios informativos adecuados, será menos sencillo encontrar las directivas correspondientes. También es necesario considerar que es relevante el orden en que declaramos las directivas en este archivo, sobre todo a la hora de trabajar con las ACL, o listas de control de acceso, que son las que permitirán o denegarán el acceso a los clientes a los sitios web que hayamos configurado. Por cierto, esto ya nos da una idea de que, además, es posible utilizar Squid para restringir la navegación sólo a un grupo de sitios determinados, en lugar de darle “salida libre” a los clientes para que naveguen adonde deseen. En la mayoría de las versiones de Squid, prácticamente todas las directivas vienen comentadas con “#”, tomando, de esta manera, cada una de ellas su valor por defecto. Si queremos modificarlo, debemos quitar el # o, mejor aún, copiar la línea debajo, eliminando el comentario, para tener a mano los default como referencia. Dicho sea de paso, cada una de las directivas en el archivo de configuración viene acompañada por un extenso comentario que explica cada uno de sus valores posibles y las distintas opciones correspondientes a esa directiva, por lo que el archivo de configuración es muy largo (¡4400 líneas!) y cuesta encontrar las líneas que indicamos controlar o modificar. Por lo tanto, es aconsejable que hagan uso de la función de búsqueda del editor para localizar la ubicación de cada directiva a medida que la vamos mencionando.

La primera línea a la que tenemos que prestar atención es a la que contiene la directiva http_port 3128. Esto indica que Squid recibe las peticiones de los clientes en el puerto 3128, pero lo podemos cambiar por el puerto que deseemos, o agregar varias directivas http_port para que escuche en múltiples puertos simultáneamente.

Luego, buscamos la directiva cache_mem. Esta orden indica la cantidad de memoria RAM que se usará para guardar archivos cacheados, cuyo valor, por lo común, es de 8 MB. Según la cantidad de memoria RAM de la que dispongamos, es preferible dejarlo entre 8 y 32 MB (vale la pena mencionar que, en todas las directivas en las que se especifica tamaño de archivos, es posible hacerlo en KB, MB o GB). Algunas líneas más abajo, encontraremos maximum_object_size_in_memory, que refiere al tamaño máximo de los archivos a ser cacheados en memoria (los que superen dicho tamaño no serán cacheados en memoria). Su valor por defecto es de 8 KB, aunque, en general, no conviene mantenerlo. También debemos tener en cuenta maximum_object_size, que trabaja de la misma forma, pero respecto de los archivos cacheado en disco. En este caso, si nuestra prioridad es ahorrar ancho de banda, es deseable poner valores altos (32 o 64 MB), y si, por lo contrario, queremos acelerar la velocidad de descarga de las páginas, dejamos un valor bajo como el que viene por defecto (4 MB).

A continuación, buscamos la directiva cache_dir. Esta es una de las líneas más importantes del archivo, ya que aquí se define el sistema de archivos con el que trabajará el caché de disco, y la estructura y el tamaño del mismo. Utilizando el sistema de archivos nativo de Squid, llamado ufs, el formato de la directiva es cache_dir ufs NombreDirectorio TamañoMáximo L1 L2, en donde NombreDirectorio es el directorio en el que reside el caché, TamañoMáximo el tamaño límite del caché (en este caso, expresado exclusivamente en MB) y L1 y L2 la cantidad máxima de subdirectorios de primer y segundo nivel, respectivamente, a crear bajo NombreDirectorio. Por defecto los valores son cache_dir ufs c:/squid/var/cache 100 16 256; por consiguiente, el tamaño límite del caché de disco es de 100 MB. Es imprescindible modificar este valor y poner el más alto que nos sea posible, considerando el espacio en disco que deseemos destinar al uso del caché. Un mínimo de 1000 MB es aconsejable, pudiendo llegar a especificar 5000 o 10000 MB si nos sobra el espacio en disco, o de allí para arriba si estamos preparando un equipo dedicado a la función de Proxy/Caché.

En la versión de Windows, necesitaremos configurar la directiva visible_hostname, que sirve para personalizar el nombre de host que aparece en los mensajes de error, con el nombre que deseemos, pero esta directiva debe tener un valor, de lo contrario Squid se negará a ejecutarse.

CONTROL DE ACCESO
Squid ofrece una enorme flexibilidad a la hora de administrar el acceso a Internet. Sus listas de control de acceso (ACL) posibilitan especificar redes, subredes y equipos a los que permitiremos o negaremos el acceso. En realidad, esta operación tiene lugar en dos pasos: en primer lugar, se define un segmento de la red al que se le quiere dar acceso, y se le otorga un nombre o “alias”. Luego, se permite o se impide el acceso a los distintos alias. Veamos un ejemplo: localicen en el archivo de configuración la línea acl localhost src 127.0.0.1/255.255.255.255. En dicha línea, se está declarando una lista de alias “localhost” que corresponde a la IP 127.0.0.1 (es decir, la del loopback, el equipo local en donde corre Squid). Por defecto, muchas versiones de Squid impiden todo acceso al proxy hasta que el administrador no configure deliberadamente las ACL. Así que comencemos por permitir el acceso desde el equipo que hostea Squid. Si no existe en algún lugar de la sección “ACCESS CONTROLS” una línea que diga http_access allow localhost debemos agregarla, pues, de lo contrario, ni siquiera tendremos acceso desde el anfitrión. Luego, agreguemos nuestra red local para habilitar el acceso al resto de las estaciones de trabajo. Para ello, creamos una línea que exprese acl miredlocal src 192.168.10.0/24 justo debajo de la línea que da acceso al localhost. Noten que todavía no le dimos acceso a la red; simplemente, estamos declarando que contamos con una red de nombre “miredlocal”, cuyo segmento de red es 192.168.10.x y su máscara de red es 24 (255.255.255.0). Para posibilitar efectivamente el acceso, agregamos debajo: http_access allow miredlocal. Es factible permitir el acceso sólo a determinados equipos de la red, o, por el contrario, negar el acceso únicamente a algunas máquinas; también se puede especificar el acceso en base a distintos días y horarios. Estos filtros más avanzados se configuran uno a uno, a través de rangos o de expresiones regulares. Está todo muy bien explicado en el mismo archivo de configuración, aunque, lamentablemente, el texto se encuentra en inglés, por lo que, tal vez, necesiten recurrir un par de veces a un buen diccionario (recomiendo especialmente WordReference) para comprender totalmente las diferentes opciones de administración que posibilitan las ACL.
Concluyamos la configuración del control de acceso notando que, al final de esta sección, hay una línea que dice http_access deny all. Es muy importante tenerla en cuenta, ya que significa que sólo serán capaces de acceder al proxy aquellos equipos o subredes que hayamos habilitado explícitamente.

PASOS FINALES
Con estas modificaciones en el archivo de configuración poseemos lo suficiente como para tener un Proxy/Web Caché totalmente funcional. Ni hace falta mencionar que las opciones y posibilidades de Squid son realmente muchas, y quedará en cada uno de ustedes seguir indagando tanto en el explicativo presente en el mismo archivo de configuración, como en la documentación que se halla en el sitio web oficial, para lograr que Squid trabaje de acuerdo a sus necesidades. Pero, primero que nada, lo mejor es probar que todo lo hecho hasta el momento funciona correctamente. Por lo general, los usuarios de Linux sólo deben reiniciar el servicio para que Squid se desempeñe (en Debian o Ubuntu, lo hacemos desde el shell con sudo /etc/init.d/squid restart). En cambio, en Windows, primero debemos crear el sistema de archivos del caché desde la línea de comandos, con la orden c:\squid\sbin\squid.exe -z que, además, verificará la correcta sintaxis en el archivo de configuración y nos avisará si existe algún error. Pero, si todo va bien, sólo resta instalar Squid como servicio de Windows, ejecutando c:\squid\sbin\squid.exe -i. Esto instalará Squid como servicio automático, pero para levantar el servicio, tendremos que hacerlo con net start squid (o si lo prefieren, por supuesto, desde el panel de control/herramientas administrativas). El servicio se instala como Automático, es decir que arrancará cuando se inicie Windows, pero puede ser configurado como Manual si es necesario.

PROBANDO EL PROXY
Es el momento de configurar la conexión al proxy en el navegador web. En Firefox para Linux, vamos a Editar/Preferencias. En la versión de Windows, nos dirigimos a Herramientas/Opciones (¿alguien me puede explicar a qué se debe esta diferencia en ambas versiones de Firefox?). Luego, hacemos clic en “Avanzadas”, en la solapa “Red” pulsamos el botón “Opciones” y elegimos “Configuración manual de proxy”. A continuación, en “Proxy HTTP” ingresamos la IP del equipo anfitrión de Squid (127.0.0.1 si estamos realizando la prueba desde el mismo anfitrión) y el puerto 3128 (o el que hayamos puesto en el archivo de configuración). Como siguiente paso, tildamos “usar el mismo proxy para todos los protocolos” y salimos aceptando. Para concluir, apuntemos el navegador hacia cualquier sitio web (apuesto a que el 90% de ustedes teclearán “www.google.com” y, si funciona, Squid ya está acelerando nuestra navegación y ahorrándonos valioso ancho de banda. Si trabaja bien desde el mismo anfitrión, pero no desde otros equipos de nuestra red local, pese a que configuramos correctamente los accesos en Squid, muy probablemente se deba al Firewall del anfitrión bloqueando las conexiones. En Windows, tendrán que dirigirse a panel de control/Firewall de Windows y crear una excepción que habilite el puerto de Squid.

Y EL RESTO DEPENDE DE USTEDES
Pocas veces es tan cierto como en este caso que apenas hemos raspado la superficie de lo que este sorprendente software es capaz de hacer. Además de ser un completo proxy-cache, puede usarse para habilitar o impedir el acceso a determinados websites, para restringir el tipo de archivos que se descargan y para configurar como bloqueador de popups. También está pensado para trabajar en tándem con el Servidor Web Apache con el objetivo de acelerar la entrega de páginas en un sitio web y para realizar control y auditoría sobre el uso de la navegación que hacen los usuarios de nuestra red. Y, seguramente, existen muchas posibilidades que no hemos mencionado. Queda por cuenta de ustedes, como siempre, seguir investigando. ¡Hasta la próxima!

Si no le damos permisos de acceso a “localhost”, el proxy no podrá ser accedido desde la máquina donde se ejecuta. (Click para agrandar)

Aquí editamos el archivo de configuración para agregar una lista de control de acceso (acl) para permitir operar con Squid desde nuestra red local. (Click para agrandar)

En la web oficial de Squid tenemos varias herramientas para realizar un análisis de los logs, lo que permite tener una idea más acabada de lo que sucede con el tráfico web de la LAN. (Click para agrandar)

Aclaración: Este post fue publicado originalmente en la revista POWERUSR #46. TODOS LOS DERECHOS RESERVADOS. PROHIBIDA SU REPRODUCCIÓN TOTAL O PARCIAL SIN EL CONSENTIMIENTO EXPRESO DEL AUTOR. SE PERMITE EL ENLACE O LINKEO A ESTE POST SIN NINGÚN TIPO DE RESTRICCIONES.

La percepción más común es que Linux es un Sistema Operativo para servidores, estable y potente, aunque muy difícil de aprender y usar, y poco atractivo gráficamente; en cambio, Windows es más limitado e inestable, pero intuitivo y bonito. En los últimos tiempos, estos preconceptos comenzaron a resquebrajarse con la aparición de Compiz. Aunque todavía está en etapa de desarrollo, este software le demostró al mundo que un Desktop Linux también puede superar en presentación visual y productividad a un equipo con Windows.

TODO ENTRA POR LOS OJOS
Una vieja frase que circula entre los programadores, al referirse a un producto de software, es la siguiente: “Si no podemos hacerlo bien, hagamos que se vea bien”. Algunas empresas de desarrollo de software propietario han hecho de este concepto un mantra (¿alguien dijo Microsoft?). Algunas veces, basan en la “cosmética” líneas enteras de productos, que tienen múltiples deficiencias, pero que se ven “lindos” y, de esta forma, logran ganar mercado, sobre todo entre los usuarios de menos conocimientos informáticos. Otras veces, las mejoras cosméticas alcanzan para justificar el lanzamiento de una nueva versión de una aplicación o de un Sistema Operativo, cuando los verdaderos cambios esperados por los usuarios, esos que solucionan problemas o agregan funcionalidad, siguen brillando por su ausencia. Mientras tanto, en el mundo del software libre, hasta hace muy poco, a menudo se tomaba el camino opuesto: se hacía tanto hincapié en la funcionalidad y en la potencia del Sistema Operativo y sus aplicaciones que se dejaba completamente de lado la estética visual y la facilidad de uso.

NO HAY MAL QUE DURE CIEN AÑOS
Pero hay una nueva tendencia entre los partidarios del Open Source, cuya punta de lanza es la distribución Ubuntu y su desarrolladora Canonical, quienes prestan especial cuidado a la cosmética y a la amigabilidad de todos los componentes de la distribución. Afortunadamente, notaron que estos aspectos son críticos para muchos usuarios, y comenzaron a tenerlos en cuenta. La consecuencia de esta tendencia es que Linux, hoy en día, ya está lo suficientemente maduro en este sentido como para representar una alternativa respecto de otros Sistemas Operativos de escritorio, como los de MS. Es por eso que en Redmond redoblaron la apuesta “estética” con el lanzamiento de Windows Vista, incluyendo, junto a las versiones más costosas del mismo, “Windows Aero”, un administrador de ventanas preparado para aprovechar el poder de los modernos procesadores gráficos. Esto permite al administrador de ventanas diversas mejoras apuntadas a incrementar la productividad (como el nuevo “task switcher” del ALT-TAB), y otras pensadas como simples “regalos para la vista”.

COMIENZA EL DESARROLLO DE XGL
En la industria informática,‭ ‬pocas veces los primeros en lanzar al mercado en forma masiva un producto innovador son los creadores de la tecnología que respalda ese producto.‭ ‬Cuando MS anuncia,‭ ‬en julio de‭ ‬2005,‭ ‬que ha comenzado el desarrollo de Vista,‭ ‬el programador de David Reveman,‭ ‬contratado ese mismo año por Novell‭ (‬dueña de SUSE Linux‭) ‬ya lleva un tiempo trabajando en Xgl,‭ ‬un nuevo servidor X‭ (‬el motor gráfico de Unix/Linux‭) ‬que hace uso,‭ ‬a través de OpenGL,‭ ‬del motor‭ ‬3D del GPU.‭ ‬El‭ ‬2‭ ‬de enero de‭ ‬2006‭ ‬el código fuente de Xgl es publicado en http://www.freedesktop.org e,‭ ‬inmediatamente,‭ ‬se forma una comunidad de desarrolladores interesados en contribuir al proyecto.‭ ‬Unos meses después,‭ ‬se hace evidente que,‭ ‬para aprovechar todos los efectos visuales que permiten los nuevos y poderosos chips gráficos,‭ ‬es necesaria una mayor integración entre el gestor de ventanas‭ (‬encargado de dibujar y administrar las ventanas en el escritorio‭) ‬y el gestor de composición‭ (‬responsable de los efectos visuales‭)‬.‭ ‬Nace entonces Compiz,‭ ‬que integra ambas funciones en una única aplicación.‭ ‬Como es costumbre en la comunidad Open Source,‭ ‬Compiz fue concebido,‭ ‬desde un principio,‭ ‬como un sistema abierto,‭ ‬modular y extensible,‭ ‬que permitía a sus usuarios diseñar sus propios efectos visuales o modificaciones a la manera de‭ “‬plugins‭”‬,‭ ‬muy sencillos de programar e implementar.‭ ‬Poco tiempo después,‭ ‬decenas de nuevos plugins inundaban los foros de http://forum.compiz.org/,‭ ‬muchos de los cuales pasaron a ser parte de la rama oficial.‭ ‬También,‭ ‬pronto aparecieron‭ ‬forks‭ ‬de Compiz,‭ ‬como el proyecto Beryl,‭ ‬que prefirieron hacer hincapié en agregar soporte para una mayor cantidad de chips gráficos,‭ ‬en detrimento de una mayor estabilidad lograda por la rama oficial.
‭
CARACTERÍSTICAS DE COMPIZ
El corazón de Compiz es un cubo en‭ ‬3D,‭ ‬en el que cuatro de sus caras‭ (‬todas menos la superior e inferior‭) ‬representan distintas vistas del escritorio,‭ ‬similar a los workspaces a los cuales los usuarios de Linux ya están habituados.‭ ‬Puede ser rotado a gusto y placer por el usuario para acceder a ventanas de aplicación que se hayan‭ “‬repartido‭” ‬por las diferentes caras del cubo,‭ ‬permitiendo la visualización,‭ ‬en forma cómoda,‭ ‬de una gran cantidad de aplicaciones que estén abiertas de manera simultánea.‭ ‬Otra característica muy importante es la transparencia en las ventanas,‭ ‬que puede ser parcial‭ (‬por ejemplo,‭ ‬sólo en la barra de título‭) ‬o total.‭ ‬Por supuesto,‭ ‬es configurable el grado de transparencia,‭ ‬y,‭ ‬también,‭ ‬podemos aplicar la transparencia sólo al mover una ventana por el escritorio,‭ ‬para visualizar las ventanas que se hallen debajo.‭ ‬Agregando algunos de los plugins que mencionábamos anteriormente,‭ ‬se obtienen espectaculares efectos visuales al maximizar o minimizar las ventanas:‭ ‬por ejemplo,‭ ‬al minimizar una ventana,‭ ‬esta se‭ “‬prende fuego‭” ‬hasta desaparecer,‭ ‬o se hace añicos,‭ ‬o se pliega como una hoja de papel.‭ ‬Al tomar una ventana maximizada de una‭ “‬esquina‭” ‬y doblarla como si se tratara de un pañuelo,‭ ‬se ve lo que se encuentra detrás sin aplicar transparencias.‭ ‬En resumen,‭ ‬las posibilidades son miles,‭ ‬tantas como caben en la imaginación de la multitud de desarrolladores que han liberado plugins para Compiz.

HECHOS,‭ ‬NO PALABRAS
A esta altura,‭ ‬nuestros lectores deben estar ansiosos por ver con sus propios ojos tantas virtudes.‭ ‬Para‭ ‬correrlo sin problemas,‭ ‬necesitamos un procesador gráfico que esté soportado por XGL.‭ ‬El tema es que determinar esto no es sencillo,‭ ‬ya que el soporte varía según el driver‭ (‬libre o propietario‭) ‬y la distribución GNU/Linux que se elija en cada caso.‭ Una buena ‬guía es la lista elaborada por los usuarios de Gentoo Linux‭,‭ ‬aunque la información allí contenida no es concluyente,‭ ‬y no es raro obtener buenos resultados con un chip gráfico que figura como‭ “‬no soportado‭”‬.‭ ‬En principio,‭ ‬podemos afirmar sin temor a equivocarnos que la inmensa mayoría de las placas de gama media y alta,‭ ‬tanto de ATI como de Nvidia,‭ ‬que hayan sido fabricadas en los últimos tres años,‭ no ‬deberían‭ tener ‬problemas.‭ ‬Pero allí no terminan las dificultades.‭ ‬Las versiones más nuevas de las distribuciones Linux más importantes‭ (‬Debian,‭ ‬Fedora,‭ ‬Gentoo,‭ ‬Mandriva,‭ ‬Slackware,‭ ‬SUSE y Ubuntu‭) ‬ya incluyen a Compiz en sus respectivos repositorios.‭ Luego ‬se instala fácilmente mediante el administrador de paquetes que corresponda a nuestra distro.‭ ‬Pero para versiones anteriores,‭ ‬o si somos usuarios de otras distros,‭ es posible‬ bajar directamente de http://compiz.org/‭ ‬los binarios‭ (‬y rezar para que‭ ‬funcionen en nuestro entorno‭)‬,‭ ‬o descargar el código fuente y compilarlo,‭ ‬tarea no exenta de inconvenientes,‭ ‬pero que,‭ ‬de tener éxito,‭ ‬nos brindará mayor estabilidad y velocidad de ejecución.‭ ‬En‭ ‬caso de emergencia,‭ ‬encontraremos en la web una multitud de guías que nos asistirán,‭ ‬paso por paso,‭ ‬con el procedimiento de instalación,‭ ‬en varios idiomas y para un amplio abanico de distribuciones.‭ ‬Pueden comprobarlo buscando en Google la expresión‭ ‬+compiz‭ ‬+howto y eligiendo los resultados que correspondan a nuestra distro.

PARA NO QUEDARSE CON LAS GANAS
Seguramente,‭ ‬en este instante,‭ ‬los lectores que‭ tengan ‬equipos algo vetustos,‭ ‬o que carezcan de procesadores gráficos con aceleración‭ ‬3D,‭ ‬estarán insultando en varios idiomas.‭ ‬Sin dudas,‭ ‬serán secundados por los‭ ‬poseedores de motherboards con chips gráficos‭ “‬onboard‭” ‬económicos‭ (‬como los fabricados por SiS‭)‬,‭ ‬que son más que adecuados para tareas de oficina o para correr juegos sencillos,‭ ‬pero que,‭ ‬al no implementar OpenGL,‭ ‬no‭ ‬pueden ejecutar Compiz.‭ ‬Mientras ahorran moneda tras moneda para comprar una placa de video con todas las de la ley,‭ si quieren‬ enterarse de qué se trata esto de Compiz pueden recurrir a YouTube.‭ ‬Múltiples usuarios han subido al popular portal decenas de videos en los que muestran sus escritorios animados,‭ ‬en una pintoresca competencia por lograr efectos más espectaculares que los de los demás.‭ O‬btendremos un rápido panorama de los videos más populares de esta temática ingresando a‭ ‬Youtube y‭ ‬apreciaremos escritorios que dejarán boquiabierto a más de un usuario de Windows Vista.‭ ‬Y a no perder de vista que Compiz es software que se encuentra en sus fases iniciales de desarrollo,‭ ‬y todavía‭ ‬esperamos de este‭ ‬proyecto para el Desktop GNU/Linux muchas sorpresas más.‭ ¡‬Hasta la próxima‭!

Aquí vemos al cubo de Compiz corriendo en KDE, con distintas aplicaciones abiertas en cada una de sus caras. La imagen de fondo que se observa detrás del cubo es conocida como “Skydome”. (Click para agrandar)	Otro cubo pero corriendo sobre GNOME, sin Skydome. Podemos apreciar también el uso de transparencias en la ventana del reproductor multimedia. (Click para agrandar)	Vemos aquí como se puede tomar una ventana desde uno de sus bordes o esquinas, y arrastrar el puntero “plegando” la ventana, para poder observar lo que se encuentra debajo. (Click para agrandar)
Con el plugin “Scale”, al dirigir el puntero del mouse a la esquina superior derecha del monitor, miniaturas de todas las ventanas abiertas se desplegarán en pantalla, para que podamos seleccionar rápidamente la que deseamos.	El Task Switcher del ALT-TAB usa transparencias y muestra miniaturas de las ventanas. Además, estas miniaturas son “vivas” y se actualizan en simultáneo con la ventana, es decir que si teníamos un video reproduciéndose, en la miniatura lo veremos correr normalmente. (Click para agrandar)	Observamos aquí distintos “temas” de Compiz. La mayoría hace uso de transparencias para las barras de título, y algunos “iluminan” los botones de maximizar/minimizar/cerrar al ubicarles el puntero encima. (Click para agrandar)

ALGUNOS PLUGINS DISPONIBLES PARA COMPIZ

Plugins nativos

Plugins de la comunidad (paquete compiz-extra)

Aclaración: Este post fue publicado originalmente en la revista POWERUSR #45. TODOS LOS DERECHOS RESERVADOS. PROHIBIDA SU REPRODUCCIÓN TOTAL O PARCIAL SIN EL CONSENTIMIENTO EXPRESO DEL AUTOR. SE PERMITE EL ENLACE O LINKEO A ESTE POST SIN NINGÚN TIPO DE RESTRICCIONES.