El Demonio Negro

Con sólo hacer lo siguiente ya tendremos el teclado funcionando:

usuario@LOCAL:~$ hcitool scan
usuario@LOCAL:~$ hidd –connect < mac-addr-from-nokia-keyboard >

Claro esta que estas utilidades para bluetooth requieren de un receptor bluetooth en el ordenador además del respectivo software.
Los paquetes en que se incluyen las utilidades anteriores son bluez-utils y creo que también es necesario bluez-GNOME.

root@LOCAL:~$ apt-get install bluez-utils bluez-GNOME

Yo tengo instalados algunos paquetes más sobre bluetooth, si tenéis problemas, preguntad.

Puede que las teclas se ajusten a la configuración de teclado existente en el sistema. ¿Y esto que significa?
Esto puede causar que las teclas o símbolos escritos no coincidan con las teclas o símbolos pulsados. Creo que se debe a que el teclado viene configurado por alguna parte a lo inglés.

teclado Bluetooth Nokia SU 8W 01.png

teclado Bluetooth Nokia SU 8W 02.png

teclado Bluetooth Nokia SU 8W 03.png

teclado Bluetooth Nokia SU 8W 04.png

teclado Bluetooth Nokia SU 8W 05.png

teclado Bluetooth Nokia SU 8W 06.png

El problema de los aparatos inalámbricos es que algún bribón te puede estar monitorizando lo que haces. Asín que cuidadín.

He de comentar que el precio del teclado, para lo que es, es bastante caro.

Su uso principal está asociado a los terminales móviles de Nokia, no a un ordenador, mejorando la escritura de los teclados estilo móvil que incorporan.
A mí me viene bien para manejar el SSH para el móvil symbian que he comprado hace poco. Esto de necesitar Internet en cualquier sitio es lo que tiene.

Estoy abierto a comentarios y dudas.

Introducción

Vamos a ver como ejecutar aplicaciones con interfaz gráfico que están instaladas en una máquina remota pero que quieres verlas directamente en tu ordenador local.
Como prerequisito las máquinas remotas serán sistemas GNU/LINUX o UNIX.
En sistemas window$ también se tiene que poder hacer, probar suerte buscando información sobre seamless RDP.

Controlar las aplicaciones de una máquina remota sin tener que estar frente a ella no tiene mucho interés para un usuario normal, pero para aquel que hace cosas más avanzadas es el pan de cada día.
En sistemas LINUX/UNIX es siempre imprescindible SSH. Eso nos proporciona una consola en modo texto. Trabajar en modo texto siempre es muy cómodo, porque no hay sensación de lejanía en la respuesta del equipo remoto, es como trabajar directamente sobre él.
En cuanto pasamos a querer controlar aplicaciones en máquinas remotas de forma gráfica la cosa se torna incómoda. La comodidad a la hora de trabajar se reduce porque la información tarda mucho en ir y volver. Es como vivir en modo Matrix. Tu te mueves a una velocidad normal, pero lo que ves en la pantalla se mueve a la velocidad de un erizo.

Por eso hay que aligerar las cosas. No es lo mismo querer tener delante todo un escritorio que usar sólo una aplicación. Con sólo una aplicación la cosa se hace llevadera. Esto es lo que voy a explicar cómo hacer.
En el caso de querer usar una sesión completa la cosa depende de si la otra máquina esta en tu red local o una red a través de la red Internet.
En tu propia red te puede valer cualquier servidor VNC o XDMCP. Aunque siempre mejor NX.
A través de la Internet te queda NX. NX es un protocolo optimizado para conexiones X11/XDMCP.

Método Fetén

Para permitir que todo funciones de forma óptima y SSH realice automáticamente la parte responsable de securizar flujos de datos (gráficos y textuales) hay que modificar primero el servidor SSH de la máquina remota (fichero /etc/ssh/sshd_config). Activaremos las dos variables indicadas. Activar estas opciones conllevan ciertos riesgos de seguridad.

/etc/ssh/sshd_config
X11Forwarding yes
AllowTcpForwarding yes

Ahora basta con conectarnos usando la opción -X (X11 forwarding) y -Y (X11 trusted forwarding) del cliente SSH. En Debian -Y es una opción que funciona por defecto si no se especifica nada en otro sitio (~/.ssh/config, /etc/ssh/ssh_config).

usuario@LOCAL:~$ echo $DISPLAY
:0.0
usuario@LOCAL:~$ SSH -Y usuario@maquina-remota
Password:
LINUX maquina-remota 2.6.18-3-686 \#1 SMP Mon Dec 4 16:41:14 UTC 2006 i686
The programs included with the Debian GNU/Linux system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.
Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
No mail.
Last login: Mon Mar 5 03:55:53 2007 from XX.XX.XX.XX
usuario@maquina-remota:~$ echo $DISPLAY
localhost:10.0
usuario@maquina-remota:~$ xlogo
[Por pantalla se muestra una ventana con el logotipo X]
usuario@maquina-remota:~$ exit
logout
Connection to XY.XY.XY.XY closed.

Método algo falla (o, no te enteras capullo)

Este método se daba cuando aun no comprendía cómo funcionaba todo el tinglao este de redirecciones de SSH, etc. Pero lo considero útil de exponer. Porque se puede necesitar para una máquina a la que no tengas acceso de superusuario para modificar configuraciones. O porque tienes problemas con su en tu propia máquina.

Qué hacer en la máquina local

Para podernos conectar gráficamente nos valemos de la opción -X (X11 forwarding) y -Y (X11 trusted forwarding) del cliente SSH. Si usas estas opciones de conexión te debería dar igual si hay cortafuegos de por medio. En Debian -Y es una opción que funciona por defecto si no se especifica nada en otro sitio (~/.ssh/config, /etc/ssh/ssh_config).

Si estamos en window$ debemos tener un servidor X local para que se comunique con él la aplicación gráfica remota (que hace de cliente X remoto). Esto lo logramos instalando Cygwin. Cuando nos pidan las aplicaciones que va a instalar instalamos xorg/xfree86 y también el cliente SSH.

Una vez todo listo con el siguiente comando podremos ejecutar aplicaciones gráficas remotas

usuario@LOCAL:~$ SSH -X -Y usuario@maquina_remota

Si se muestra un error (lo normal) hay que editar la configuración del servidor X para permitir que acepte peticiones y conexiones TCP. Por defecto nuestro gestor de pantalla sólo maneja puertos tipo UNIX, que pecan de ser sólo de uso local.
Una opción es usar el programa de configuración del gestor de pantalla(gdm, kdm, …) para permitir conexiones TCP. Para gdm es gdmsetup.
Otra es modificar la variable DisallowTCP en el fichero de configuración del gestor de pantalla. Para gdm es /etc/gdm/gdm.conf.

/etc/gdm/gdm.conf
# If true this will basically append -nolisten TCP to every X command line,
# a good default to have (why is this a “negative” setting? because if
# it is false, you could still not allow it by setting command line of
# any particular server). It’s probably better to ship with this on
# since most users will not need this and it’s more of a security risk
# then anything else.
# Note: Anytime we find a -query or -indirect on the command line we do
# not add a “-nolisten TCP”, as then the query just wouldn’t work, so
# this setting only affects truly local sessions.
DisallowTCP=false

Además de permitir conexiones TCP hay que indicar quién las puede realizar.
Con xhost modificamos quien se puede conectar al servidor gráfico que se ejecuta actualmente. Permitimos que la máquina a la que nos vamos a conectar tenga acceso a nuestra sesión.

usuario@LOCAL:~$ xhost +maquina_remota

Qué hacer en la máquina remota

Puede que haya que retocar alguna regla del cortafuegos que tenga que ver con X11 o XDMCP. Depende de como se ejecute.

En teoría si hemos ejecutado SSH con -X -Y no habría que tocar nada de la variable DISPLAY, se haría automáticamente, pero por alguna razón yo en Debian tengo que modificarlo a mano (véis el porque de lo de que era un capullo).
Lo principal es indicar desde la línea de comandos remota dónde queremos que se vea la aplicación gráfica. Para ello hay que hacer uso de la variable de entorno DISPLAY que le indica a los programas cuál es su servidor X gráfico.

usuario@maquina-remota:~$ export DISPLAY=[maquina-local]:[display-servidor-X]

En caso de que tratemos de ejecutar alguna aplicación gráfica, por ejemplo xlogo, se debería mostrar el siguiente error.

usuario@maquina-remota:~$ xlogo
Xlib: connection to “[maquina-local]:[display-servidor-X]” refused by server
Xlib: No protocol specified
Error: Can’t open display: [maquina-local]:[display-servidor-X]
No se pudo abrir la pantalla porque el servidor X no se está ejecutando. [Mensaje en versión española]

Esto se debe a que tenemos que retocar el servidor X de nuestra máquina local. Hay que indicar a quién permitimos conectarse a nuestro servidor gráfico.
Si no se muestra el error es porque ya lo tenemos configurado de antemano. Si lo hemos modificado nosotros para que funcione así no hay problema, pero por defecto se debería mostrar el error anterior por cuestiones de seguridad.
El mensaje anterior puede resultar desconcertante para cualquier usuario de sistemas GNU/LINUX o UNIX que desconozca el uso y disfrute de la variable DISPLAY.
Puede que también se muestre este error en tu máquina local cuando te autenticas (logeas) como otro usuario mediante el comando su -

Ejemplo práctico

usuario@LOCAL:~$ SSH -X -Y usuario@maquina_remota
usuario@maquina-remota:~$ xlogo
Error: Can’t open display:
usuario@maquina-remota:~$ export DISPLAY=192.168.0.102
usuario@maquina-remota:~$ xlogo
Error: Can’t open display: 192.168.0.102
usuario@maquina-remota:~$ export DISPLAY=192.168.0.102:0
usuario@maquina-remota:~$ xlogo
Xlib: connection to “192.168.0.102:0.0″ refused by server
Xlib: No protocol specified
Error: Can’t open display: 192.168.0.102:0
usuario@maquina-remota:~$ exit
usuario@LOCAL:~$ xhost +192.168.0.1
192.168.0.1 being added to access control list
usuario@LOCAL:~$ SSH -X -Y usuario@maquina_remota
usuario@maquina-remota:~$ export DISPLAY=192.168.0.102:0
usuario@maquina-remota:~$ xlogo
[Por pantalla se muestra una ventana con el logotipo X]

Referencias interesantes:

• NX es un protocolo optimizado para conexiones x11/xdmcp
• Getting X11 forwarding through SSH working after running su
• SSH Users beware: The hazards of X11 forwarding
• Secure forwarding of services with SSH
• Problems forwarding X over SSH
• Cygwin

Yo recomendaría Debian, pero para empezar, cuanto más fácil, mejor.

Corre, ve, lee… descarga y prueba.

¿Alguien conoce algún sistema operativo que arranque desde el CD, aparte de LINUX?

Además, os presento a mí nueva mascota. Un Tux, de la familia Tux de toda la vida.

tux sobre la pantalla

un tux descanso en el sofa, pensando en Debian

otro tux descanso en el sofa

tux flasheado

Este sí que es un buen regalo.

Hoy, amigos, voy a publicar algo inacabado, para ver si entre los comentarios y el tiempo algún día consigo que funcione.

Se trata de poder manejar con los infrarrojos nuestro ordenador. Para ello necesitaremos las típicas tarjetas de televisión que llevan un receptor infrarrojos con su mando a distancia. Puede que existan más dispositivos, como en este caso, mi antigua y estropeada tarjeta de sonido.

La culpa de tener que realizar todas estas triquiñuelas la tiene Creative por no suministrar soporte a plataformas GNU/Linux. Todo se andará, por mis santos cojones, pero mientras…

El caso es que para que funcione hay que hacer que el kernel entienda de infrarrojos, configurar la aplicación que sabe que hacer con los aparatitos que manejan infrarrojos y por último adaptar los distintos programas que permiten ser manejados mediante infrarrojos.
Opcionalmente podremos crear nuestros propios programas o scripts para que pulsando un botón del mando nuestro ordenador actúe a nuestro antojo (para eso existen).

El meollo

El primer paso es configurar los módulos de infrarrojos para nuestro kernel LINUX en Debian.

Para configurar los módulos fácilmente necesitamos los paquetes

apt-get install lirc-modules-source modules-assistant build-essentials kernel-package

Ejecutando por ejemplo:

m-a auto-install lirc-modules-source

instalaremos un paquete con los drivers para que nuestro kernel maneje los infrarrojos.

El siguiente paso consistiría en copiar el archivo de configuración apropiado para nuestro receptor en el directorio de la aplicación/demonio que gestionará los dispositivos de infrarrojos:

root@masine:~$
cp -f /usr/share/doc/lirc/remotes/creative/lircd.conf.alsa_usb /etc/lirc/lircd.conf

Y aquí me quedé. No todo tiene un final.

Referencias:

LINUX Infrarred Remote Control
Creative supported remote controls

Me vinó bien leer sobre [changlonet.com] Cámaras de Vídeo DV para pensar y orientarme sobre la cámara de vídeo que me compré hace poco hace ya… y que aun no le he sacado el jugo. Pero en los sucesivos meses, según termine por fin la carrera, las tornas cambiarán. Y es que tengo muchos vídeos por montar.

Tardé del orden de… … … varios meses hasta que me decidí a comprar mi cámara. Estuve reflexionando y documentándome sobre cuál podría ser la mejor opción. Tampoco tenía prisa, esa es otra.

La calidad de las cámaras de la misma gama termina siendo más o menos la misma. Todos los modelos tienen prestaciones parecidas, por lo que al final para decidirte tienes que optar por los detalles que tú realmente buscas.

Desde el punto de vista de la calidad de imagen daba igual que el soporte de grabación fuese cinta o disco duro o DVD. Los formatos de grabación eran siempre los mismos.
Las cámaras DVD las descarte de inicio por lo mismo que comentaba changlonet. Por otro lado, al igual que las cintas, no tienen toda la capacidad de duración que yo buscaba. Añadiendo a esto que ninguno de los dos soportes son rápidos para grabar y regrabar (carecen de mucha flexibilidad debido a su naturaleza por diseño).
Es más, los fabricantes que optaban por poner DVD a una cámara de vídeo me incitaban al desprestigio. Me llevaban a pensar que era sólo una decisión de marketing, como querer vender “lo último” y no lo más útil. Aunque para quien no quiera editar ni nada es la mejor opción.

Hoy en día las cámaras que graban a DVD son lo mismo que las DV. Un DVD y una cinta tienen una duración de grabación similar. Y yo quería más. Por lo tanto, se convirtió en mi objetivo que la cámara tuviese un disco duro.

Otro punto importante es la autonomía que te permite la cámara. La duración de la batería es importante. Ya se que se pueden, y al final se tienen que tener ya aviso, poner más baterías, pero con cuantas menos tengas que llevar encima, preocuparte por ellas y cargarlas, mejor.

Calidad de grabación aceptable quería decir: Buena sensibilidad y del orden de 1-2 megapíxeles (no son totalmente equivalentes a las cámaras de fotos) más un zoom óptico potente.
Tenía preferencia porque tuviese 3 CCD (pieza clave en la calidad de la imagen), pero esta característica eleva mucho el precio para su uso real final.

También estuve buscando alguna que permitiera además de todo usarla como webcam pero eso lo podía lograr gracias a un truquito que ya comentaré. El truco se basa en la utilización de una tarjeta de televisión o artilugio similar que permita entrada de vídeo tipo RCA o S-Video para tener una webcam con cualquier cámara de vídeo o de fotos. Las cámaras deben tener salida de televisión. Ya lo detallaré.

Al final compré el modelo JVC GZ-MG50E. Que a día de hoy ya no se vende (es que tardo mucho en publicar algunas cosas).

No recomiendo cámaras Sony, a pesar de que tienen calidad luego la joden siempre queriendo usar sus propios inventos y no cumplir estándares. En general no compro nada de Sony, su avaricia al hacer ese tipo de jugadas me lleva a recomendar a cualquiera nunca comprar Sony. Que si nuestra propia memoria, nuestro propio tipo cable de no se que, anda y que se queden con su propio cliente. ¿Por que se creen que triunfó la Playstation 1 y 2?¿Porque no se podía piratear, es decir, hacer cada uno lo que quisiera con el aparato? Va fan culo.

Por supuesto para la compra tenía la visión puesta en GNU/Linux, dónde he ido encontrando las cámaras más apropiadas y a la vez los programas más usados y más útiles.
Hoy por hoy creo que no domino muy bien el arte del montaje y la edición. Aún estoy intentando hacerme con ellos. Yo pensé que podría editar todo un vídeo del tirón, pero estoy viendo que lo voy a tener que hacer por escenas.
No os toméis a broma los programas para GNU/Linux de edición de vídeo, porque son para ámbito profesional. Como anécdota, algunos de ellos se utilizan en los estudios de Hollywood, que no se si sabréis usa casi exclusivamente GNU/Linux en la producción de películas.

Para completar os voy a indicar las páginas que me sirvieron para formar una opinión y los programas.

• Una página de referencia para el vídeo y la edición.
• Cómo se hizo el corto Terroralia Esto lo descubrí al asistir a unas charlas por Lavapiés sobre cine y software libre. Realizaron un corto enteramente usando material GNU/Linux. Cuentan toda su experiencia. RECOMENDADO DE LEER.
• Hilo en barrapunto del año 2004 sobre Edición de vídeo en LINUX
• Hilo en barrapunto del año 2005 sobre Edición de vídeo en LINUX
• Componentes del Estudio de Producción en GNU/Linux. Una guía útil para ir tomando contacto.
• Edición de vídeo bajo GNU/Linux. Guía interesante para tomar contacto también.
• Video for GNU/Linux resources
• Getting Started With LINUX Video Editing
• Programa para la edición. Lives
• Programa para efectos. Effectv
• Programa para la edición y efectos. Jahshaka
• Celtx. Este no se exactamente todo lo que tiene, pero se que tiene que ver con scripting, planificación, guiones…

A quienes no sois seguidores del mundo linuxero el título de esta entrada, lo se, os suena a lo de siempre. Ya está el cansino (oiga) con sus chismes de linuxero.
Bueno, pues sí. Pero es que mola. Incluso me conformo con que del título os acordéis de Debian.

Pero lo que quiero hacer notar es el concepto que al finalizar este año 2007 será común (más que ahora) en los escritorios linuxeros. Los efectos gráficos molones en los escritorios.
Los conocedores de Apple los disfrutaron, creo, los primeros.
Los últimos serán los esclavos del planeta Window$. Bueno, los valientes que se atrevan con Window$ Vi$ta. Valientes, sí, y adinerados, porque … bueno que lo prueben.
(Pssst, A los no window$eros, ¡¡menudo ostión se van a dar colegas!!)

Aclaración: Para mí ostión no lleva h, no le pega.

Beryl on Debian testing

Debian Compiz

La chicha

A continuación vais a leer los nombres y siglas que en el mundo linuxero están detrás de los escritorios con efectos.

Debian ya hace semanas que introdujo en sus repositorios los paquetes del proyecto Compiz y como parte del servidor gráfico xorg la versión con soporte AIGLX. Suficientes para empezar a manejar los nuevos escritorios con efectos de lo más curiosos.
También están trabajando en empaquetar Beryl (ahora mismo esperando que salte a la palestra), un hijo de Compiz (informáticamente hablando) que tiene vida propia. Beryl por el momento tiene más desarrollo y más masa de usuarios que su padre.
A nivel de usuario está mejor Beryl porque aporta más variedad de efectos y mejor presentación. A nivel de desarrollo están aún verdes pero madurando con rapidez.
Pero no os confundáis ni seáis confundidos, ya son proyectos distintos.

Para explicar los fundamentos de AIGLX y de XGL, a la wikipedia.
Yo me decanto por AIGLX, el tiempo decidirá cuál es el que más gusta. Se nota la influencia del sombrero rojo.

El pasado y el futuro

Algunos intentos anteriores fueron xcompmgr y transset. También yo los he probado, y, bueno, hace varios años resultaban sorprendentes. Ahora no tienen nada que hacer frente a todo el desarrollo que existe hacia los escritorios con unos magníficos gráficos gracias a OpenGL.

Mis conclusiones derivan en que estamos ante un paso más hacia los escritorios en 3 dimensiones.
Pero yo hablo de las 3 dimensiones guays, en las que hay sensación de profundidad… porque hay profundidad. Paso el de la profundidad que se alcanzará cuando las imágenes, la interacción con los ordenadores no sea a través de monitores planos.
En este paso esta el proyecto Looking Glass, que he probado y aunque de momento le falta madurez tiene una pinta excelente. Los que hayan visto la película Minority Report pueden comparar lo que recuerden de ella con los vídeos que hay en la web. Sólo tienen que imaginar las imágenes en el aire, lo demás esta todo.
También pueden probarlo ellos mismos con el LiveCD que proporcionan.

Referencias:

• Debian
• Compiz
• Proyecto Beryl
• HOWTO Debian AIGLX y Compiz
• [wiki.debian.org] Compiz
• [wikipedia.org] AIGLX
• [wikipedia.org] Servidor gráfico XGL
• Configurar Composite y Render en Debian Sid

It’s really easy, there are many version control systems. Subversion has been widely adopted, not as wide as CVS, but.

Original URL (I’m only archiving it): subversion-quick-reference

Este “parche”, diseñado por Revolution LINUX, añade soporte para Esound y PulseAudio.

Con PulseAudio los vídeos en flash quedan sincronizados con el sonido. Con Esound a veces se perdía la sincronía.

http://pulseaudio.revolutionlinux.com/PulseAudio

Hay un paquete Debian ya preparado en http://pulseaudio.vdbonline.net/libflashsupport/

Con la vuelta al desarrollo de adobe para LINUX con flash player 9 beta (hay paquete en Debian) y con este parche parece que el mundo GNU/Linux queda algo menos lejos de la multitud de páginas web que hoy en día siguen usando flash.

Mientras llega la solución libre gnash, se puede ir tirando.

Ya no es versión Beta, hoy hay versión final de Flash 9 para GNU/Linux.