miércoles 2010-03-10 13:45
Otro grano de arena: SCJP 1.6
Un resumen siempre ayuda. Si estás planteándote pasar el SCJP 1.6 (te lo recomiendo), este te puede venir muy bien.
Es un resumen del texto oficial (aunque algo así realmente no existe), pero si ya has comenzado a buscar a información y a formarte, verás que los objetivos son los oficiales y están bien cubiertos. He añadido algunos ejemplos interesantes de código hechos con mucho cuidado (sí, compilan y funcionan) y algunos recordatorios sacados de los test también oficiosos. Espero que te sea de utilidad.
¡Ah! Si necesitas alguna ayuda más, no dudes en contactar.
lunes 2007-05-21 22:36
Actualización a NanoBlogger 3.3
Por fin me he atrevido a actualizar el sitio a NanoBlogger 3.3, aunque lo he hecho sin querer
.
El resultado, ya estáis viendo, excelente. No solo ha mejorado en aspecto y en la calidad de las plantillas, si no que además incluye soporte multi-idioma, así que me he puesto como un loco a traducirlo y, si consigo traducir la ayuda, mandaré al señor Wood la traducción, ya que tiene francés, alemán e inglés, pero no la lengua de Cervantes...
domingo 05/11/2006 17:21:45
Soporte DRI en Xorg con Gentoo
Ya podeis mirar blogs (y los hay a millares) sobre como configurar con éxito
el soporte DRI (Direct Rendering Infraestructure) en vuestro servidor Xorg o
XF86 que no vais a encontrar ninguna referencia a 'xorg-server'.
¿Que de qué estoy hablando? Pues de que todos los esfuerzos de configuración se centran en los módulos a usar, en bajarse x11-drm etc y en la mayoría incluso te recomiendan exoticas opciones para el driver.
Luego esta la lucha entre le driver propietario fglrx y el de código abierto radeon, pero ninguno entra en lo más importante, a parte, claro está, de habilitar el soporte DRI en el kernel:
¡Hay que compilar xorg-server con soporte DRI! Pues eso, basta con añadir en make.defs la palabra clave dri para que, al compilar el xorg-server tenga el soporte, que se traduce en que ha de crear los módulos necesarios /usr/lib/xorg/modules/linux/libdrm.so y /usr/lib/xorg/modules/linux/libdri.so y otros más que en el directorio de extensiones que posibilitan la aceleración 3D.
Para otros detalles (no este, ya digo que no lo encontrarás) consulta, por ejemplo HOWTO direct rendering without proprietary drivers for ATI Radeon 9600 o HOWTO DRI with ATi Open-Source Drivers - Gentoo Linux Wiki y HOWTO ATI Drivers - Gentoo Linux Wiki si prefieres usar el driver propietario.
¡Uf!
¿Que de qué estoy hablando? Pues de que todos los esfuerzos de configuración se centran en los módulos a usar, en bajarse x11-drm etc y en la mayoría incluso te recomiendan exoticas opciones para el driver.
Luego esta la lucha entre le driver propietario fglrx y el de código abierto radeon, pero ninguno entra en lo más importante, a parte, claro está, de habilitar el soporte DRI en el kernel:
¡Hay que compilar xorg-server con soporte DRI! Pues eso, basta con añadir en make.defs la palabra clave dri para que, al compilar el xorg-server tenga el soporte, que se traduce en que ha de crear los módulos necesarios /usr/lib/xorg/modules/linux/libdrm.so y /usr/lib/xorg/modules/linux/libdri.so y otros más que en el directorio de extensiones que posibilitan la aceleración 3D.
Para otros detalles (no este, ya digo que no lo encontrarás) consulta, por ejemplo HOWTO direct rendering without proprietary drivers for ATI Radeon 9600 o HOWTO DRI with ATi Open-Source Drivers - Gentoo Linux Wiki y HOWTO ATI Drivers - Gentoo Linux Wiki si prefieres usar el driver propietario.
¡Uf!
sábado 21/10/2006 00:51:21
FuzzyCLIPS en Ubuntu 6.06
CLIPS (Sistema de Producción Integrada en Lenguaje C) es un entorno de
desarrollo de Sistemas Expertos. FuzzyCLIPS amplía
CLIPS proveyéndolo de capacidades de razonamiento difuso.
Lamentablemente, en la página de descargas de la National Research Council of Canada no existe una versión compilada de FuzzyCLIPS para GNU/Linux, si bien es posible compilarlo a partir de la versión disponible para M$ Güindous©, aunque requiere alguna adaptación nada complicada.
En primer lugar, se ha de descargar la versión para M$ Güindous© de la página http://www.nrc.ca. Se requerirá darse de alta con una dirección de correo válida ya que, una vez seleccionado el fichero a descargar, se enviará en enlace a esa dirección.
El fichero descargado se llama fzclp610dWin.zip (a día de hoy). Al descomprimirlo (p.e. con unzip), creará un directorio con el mismo nombre. Abriremos una sesión de terminal en el subdirectorio source dentro del anterior, donde habrá que editar dos ficheros:
Para compilar, podemos ejecutar:
o, para crear el ejecutable de línea de comandos:
y para crear el IDE bajo X
En mi caso no he tenido que tocar el Makefile.x porque las librerías y cabeceras para compilar con Athena Widgets (que son las librerías que usa FuzzyCLIPS para el IDE) están incluidas en las rutas por defecto del compilador. Puede que este no sea tu caso. Revísalo por si acaso.
Claro que, para que este proceso vaya bien, será necesario tener un sistema de compilación básico (compilador, ensamblador, etc) y las librerías de desarrollo de Xt y Athena Widgets que son libxt-dev, libxaw-headers, libxaw7-dev, libxpm-dev y xbitmaps (quizá falten algunas dependencias).
Suerte.
Lamentablemente, en la página de descargas de la National Research Council of Canada no existe una versión compilada de FuzzyCLIPS para GNU/Linux, si bien es posible compilarlo a partir de la versión disponible para M$ Güindous©, aunque requiere alguna adaptación nada complicada.
En primer lugar, se ha de descargar la versión para M$ Güindous© de la página http://www.nrc.ca. Se requerirá darse de alta con una dirección de correo válida ya que, una vez seleccionado el fichero a descargar, se enviará en enlace a esa dirección.
El fichero descargado se llama fzclp610dWin.zip (a día de hoy). Al descomprimirlo (p.e. con unzip), creará un directorio con el mismo nombre. Abriremos una sesión de terminal en el subdirectorio source dentro del anterior, donde habrá que editar dos ficheros:
- setup.h: habrá que cambiar el 1 que tiene definido el símbolo IBM_TBC por defecto a 0 y cambiar el 0 del símbolo UNIX_V por un 1. Esto se hace para que la parte dependiente del sistema operativo de la compilación entienda que estamos en un Unix System V o similar, que es lo más aproximado que vamos a encontrar.
- Makefile.cl: En mi caso (puede que en el tuyo no sea así), no tengo la librería libtermcap y en GNU/Linux no se usa, así que habrá que eliminar de esa línea la referencia a dicha librería.
Para compilar, podemos ejecutar:
$ make both
o, para crear el ejecutable de línea de comandos:
$ make -f Makefile.cl
y para crear el IDE bajo X
$ make -f Makefile.x
En mi caso no he tenido que tocar el Makefile.x porque las librerías y cabeceras para compilar con Athena Widgets (que son las librerías que usa FuzzyCLIPS para el IDE) están incluidas en las rutas por defecto del compilador. Puede que este no sea tu caso. Revísalo por si acaso.
Claro que, para que este proceso vaya bien, será necesario tener un sistema de compilación básico (compilador, ensamblador, etc) y las librerías de desarrollo de Xt y Athena Widgets que son libxt-dev, libxaw-headers, libxaw7-dev, libxpm-dev y xbitmaps (quizá falten algunas dependencias).
Suerte.
miércoles 08/03/2006 19:42:23
Oracle 10g en Gentoo: sí, es posible
Efectivamente. Gracias a una excelente página en Togaware
(en inglés), a un poco de paciencia y a algunos trucos no muy ortodoxos, he
conseguido instalar Oracle 10g (la última versión, 10.2.0.1.0 que puede descargarse desde
Oracle. Más concretamente, las versiones Windows y Linux
x86 pueden bajarse de aquí y
otras desde aquí.
La documentación de la versión está aquí. La guía explica como instalarlo en
Debian x86, pero casi todo es igual que en Gentoo, excepto, claro está, el
método de hacerse con el software de las dependencias de Oracle. También
existe otra guía para SuSE aquí, pero no he seguido
ésta, aunque puede ayudarte con alguna duda.
Poco que añadir al documento de Togaware; lo más cabal es seguirlo al pie de la letra salvo en algunas pequeñas cosas:
Poco que añadir al documento de Togaware; lo más cabal es seguirlo al pie de la letra salvo en algunas pequeñas cosas:
- Las versiones de libaio compatibles con Oracle son sólo las anteriores a la 0.3.15 (103, 104, 106).
- No he necesitado realizar los procedimientos relativos al servicio cssd que mencionan en Togaware
- He tenido problemas con los programas de arranque dbstart y
dbshut. Así que, en su lugar, he utilizado mi propio script de arranque y
parada que puedes ver aquí. Para que funcione,
déjalo en un directorio incluido en el PATH del usuario oracle y crea un
enlace dinámico a este con el nombre de la base de datos que creaste en la
instalación. Si, por ejemplo, llamaste a tu base de datos jul0,
necesitarás ejecutar las siguientes órdenes:
# su - oracle # cd ~/bin #Si tienes ~/bin en el PATH # ln -s orcl.sh jul0 # jul0 start #para arrancar la BD y... # jul0 stop #para pararla
Como ves, no recomiendo que sea el usuario root el que realice el arranque y la parada. Si no tienes más remedio, te recomiendo que uses el script anterior a través de la orden su - oracle, lo que da, casi siempre, menos quebraderos de cabeza. - Errores en la compilación: Al enlazar los ejecutables en la fase final
de la instalación (es parte de la instalación desde tiempos inmemoriales de
Oracle), encontré que faltaban dos bibliotecas de enlace dinámico que,
curiosamente, sí estaban en mi sistema pero que, sin embargo, buscaba en otra
ubicación. Mi solución fue crear enlaces simbólicos allí donde las buscaba;
las órdenes fueron:
# ln -s /usr/lib/gcc/x86_64-pc-linux-gnu/3.4.5/libgcc_s.so.1 /lib64/libgcc_s.so.1 # ln -s /usr/lib64/libstdc++-v3/libstdc++.so.5.0.6 /usr/lib64/libstd++.so.5
No sé si es posible eliminar después de la instalación estos enlaces, supongo que sí. - En cuanto a las dependencias, y sólo a título de referencia, las
versiones de los paquetes con los que pude instalar en Gentoo
correspondientes a los que en Togaware se indican como requisitos
preliminares son:
sys-devel/gcc-3.4.5 sys-devel/make-3.80-r3 sys-devel/binutils-2.16.1 x11-libs/openmotif-2.2.3-r8 dev-libs/libaio-0.3.106
Date cuenta de que no he necesitado ni lesstif ni rpm, claro. - Si te falla la creación de una base de datos e intentas volver a crearla con el mismo nombre, probablemente la herramienta te dirá que ya exista aunque borres los ficheros de la misma. Lo que hay que hacer es, simplemente, eliminar su entrada en el fichero $ORACLE_HOME/install/oratab
- Es difícil (o al menos a mí me lo pareció) encontrar cómo se arranca el
servicio de Oracle Web Enterprise Manager. La orden es:
oracle$ emctl start dbconsole
que es necesario para poder administrar las bases de datos de forma remota con esta herramienta.
martes 07/03/2006 09:51:11
Disculpas
Quiero pedir disculpas por tantos meses sin ocuparme de actualizar mi sitio.
Tampoco he estado tan ocupado, pero siempre tienes prioridades y a veces hay que elegir. La buena noticia es que espero tener tiempo para añadir en breve un montón de contenidos, así que, si estás leyendo esto, no te olvides pasar pronto por aquí de nuevo.
Gracias por visitarme.
Tampoco he estado tan ocupado, pero siempre tienes prioridades y a veces hay que elegir. La buena noticia es que espero tener tiempo para añadir en breve un montón de contenidos, así que, si estás leyendo esto, no te olvides pasar pronto por aquí de nuevo.
Gracias por visitarme.
sábado 09/04/2005 02:14:16
Nuevos drivers de sistema de archivos
Coincidiendo con la última actualización de kernel que he realizado
(2.6.10), me he dejado llevar por la euforia y me he puesto a investigar dos
drivers nuevos de sistema de archivos: pktcdvd y
squasfs.
El primero de ellos permite escribir en paquetes de 2K sobre discos ópticos regrabables, a saber, CD-RW, DVD-RW y DVD+RW. El segundo me interesó por la obvia preocupación de los que estamos acostumbrados a quedarnos, invariablemente, sin espacio en disco; este driver permite mantener un sistema de archivos (eso sí, de sólo lectura) en un dispositivo de bloques o en un fichero comprimido. De este modo podría comprimir selectivamente partes poco usadas, montarlas para lectura y así no desperdiciar tanto espacio.
Voilá: según el manual de mount, cuando se monte un disco udf se ejecutará el guión /sbin/mount.udf; este guión preparará el disposivo de bloques cdram0 a partir de /dev/dvd, de modo que mount pueda montarlo según la entrada de fstab anterior. De todos modos el método no es perfecto: si usas DVD+RW, puede que se copien datos, pero el disco no esté finalizado. Efectivamente, la primera vez que lo escribas debes esperar a que se copien todos los datos y, antes de desmontar el disco, para mayor seguridad, ejecutar pktsetup -d cdram0, ya que la finalización del disco puede estar pendiente. Como regla general siempre es bueno hacer ésto antes de desmontarlo.
Claro que todos estos pasos pueden simplificarse creando un guión para hacerlo todo de un tirón, lo que no supondría demasiada dificultad.
Algo curioso e interesante es que, si bien no es posible remplazar archivos (se añadirían con un número de versión) sí es posible añadir ficheros con mksquasfs y/o directorios al fichero comprimido incluso estando en línea, aunque, claro está, hasta que no se monta de nuevo el sistema no se verán los cambios.
Las pruebas aportadas para la versión 2.1 indican que es más rápido y comprime más que zisofs y cloop, pero pruébalo tú mismo.
El primero de ellos permite escribir en paquetes de 2K sobre discos ópticos regrabables, a saber, CD-RW, DVD-RW y DVD+RW. El segundo me interesó por la obvia preocupación de los que estamos acostumbrados a quedarnos, invariablemente, sin espacio en disco; este driver permite mantener un sistema de archivos (eso sí, de sólo lectura) en un dispositivo de bloques o en un fichero comprimido. De este modo podría comprimir selectivamente partes poco usadas, montarlas para lectura y así no desperdiciar tanto espacio.
Grabando directamente en discos +/-RW
Era algo que estaba esperando desde hace tiempo: usar los discos regrabables directamente, borrando y añadiendo a mi antojo, sin preocupación y sin abrir k3b u otros. Primero configuré el núcleo para compliar pktcdvd como módulo y después me bajé las, hasta ahora desconocidas, udftools. En el directorio /usr/src/linux/Documentation/cdrom encontré un simple pero suficiente manual de cómo hacerlo, packet-writing.txt. Allí cuenta que, una vez formateado el disco (los CD-RW con cdrwtool y con dvd+rw-format los DVD+/-RW) hay que ejecutar la órden pktsetup dev_name /dev/cdrom. Sin embargo, me parecía un poco tedioso tener que ejecutar dos órdenes cada vez que quisiese montar el disco para escritura, así que pensé en algún modo de hacerlo todo a la vez. Ahí va mi método:- Preparar puntos de montaje distintos para discos grabables y no grabables: en mi caso ya tenía cdrom, así que creé cdram.
- Preparar la entrada de fstab para un montaje rápido:
/dev/pktcdvd/cdram0 /mnt/cdram udf noatime,defaults,noauto 0 0
No hace falta especificar rw, ya que es por defecto, y el noatime está recomendado para minimizar las escrituras. - El super-truco: crear (como root) el fichero
/sbin/mount.udf con el siguiente contenido:
#!/bin/sh dev=${1/*\/} pktsetup $dev /dev/dvd mount -i $*
Voilá: según el manual de mount, cuando se monte un disco udf se ejecutará el guión /sbin/mount.udf; este guión preparará el disposivo de bloques cdram0 a partir de /dev/dvd, de modo que mount pueda montarlo según la entrada de fstab anterior. De todos modos el método no es perfecto: si usas DVD+RW, puede que se copien datos, pero el disco no esté finalizado. Efectivamente, la primera vez que lo escribas debes esperar a que se copien todos los datos y, antes de desmontar el disco, para mayor seguridad, ejecutar pktsetup -d cdram0, ya que la finalización del disco puede estar pendiente. Como regla general siempre es bueno hacer ésto antes de desmontarlo.
Comprimiendo directorios selectivamente
Aunque es una pena que squashfs no tenga soporte de escritura, sí que soluciona un problema de espacio, lo que es importante en el caso en que directorio a comprimir no se escribe casi nunca. Después de configurar el núcleo, compilar e instalar el módulo squasfs, me bajé el paquete squashfs-tools, que contiene el necesario mksquasfs. Es muy fácil de usar, pero se explica mejor con un ejemplo:- Crear un fichero comprimido: usando mksquasfs especificamos el
directorio que queremos comprimir y como destino un nombre de
archivo.
$ mksquasfs mimúsica mimusica.squashfs
- Cuando termine, renombramos el directorio recién comprimido.
$ mv mimúsica mimúsica.orig
- Creamos un directorio vacío, desde donde se montará el nuevo subsistema.
$ mkdir mimúsica
- Montamos el fichero comprimido bajo el directorio recién creado:
$ mount mimusica.squasfs mimúsica -t squasfs -o loop,ro
- Ahora, por precaución antes de eliminar el directorio original, podemos
comparar los contenidos a ver si todo fue bien:
$ diff -r mimúsica mimúsica.orig
- Si todo fue bien, ya podemos eliminar el directorio original
completamente, ya que lo tenemos comprimido y en línea:
$ rm -r mimúsica.orig
- Para que este directorio se monte al arrancar, habrá que incluir la
siguiente línea en fstab:
/home/miscosas/mimusica.squashfs /home/miscosas/mimúsica squasfs auto,defaults,ro 0 0
Por ejemplo.
Claro que todos estos pasos pueden simplificarse creando un guión para hacerlo todo de un tirón, lo que no supondría demasiada dificultad.
Algo curioso e interesante es que, si bien no es posible remplazar archivos (se añadirían con un número de versión) sí es posible añadir ficheros con mksquasfs y/o directorios al fichero comprimido incluso estando en línea, aunque, claro está, hasta que no se monta de nuevo el sistema no se verán los cambios.
Las pruebas aportadas para la versión 2.1 indican que es más rápido y comprime más que zisofs y cloop, pero pruébalo tú mismo.
lunes 14/03/2005 10:53:53
Videoconferencia en Linux
Efectivamente: después de muchos años usando GNU/Linux, ahora se me ocurre
probar la videoconferencia. No era algo que me produjese demasiado interés, ya
que no tenía con quien conversar. Creo que la utilidad viene cuando tienes
amigos o familiares con tarifa plana y que estén conectados muchas horas al
día. Si ésto es así, este método de comunicación es genial.
Mi segundo recelo fue: ¿será compatible GnomeMeeting con m$-netm3eting? Lamentablemente, soy el único linuxero (aunque sea de pastel) de la familia. Pues bien, me puse a la obra.
En un principio instalé la versión 1.00 que Gentoo me ofreció como estable, pero lejos de ser estable, cuando conectaba con GnomeMeeting 1.0.2 me daba un coredump magnífico
, así que decidí instalarme algo más
avanzado (digamos la 1.0.2), y ahí empezó mi pesadilla.
No sé a quién echar la culpa (creo que a mí mismo, por iluso) pero, ¿por qué narices se dice que una aplicación compila con una versión igual o superior de las librerías tal y cual si es imposible (y seguro que improbable) que lo haga con versiones superiores? Pues ahí está el problema. después de pegarme con librerías que no compilan, fallos de dependencias y demás (varias horas de compilación), me rindo a la evidencia: debo compilar GnomeMeeting exactamente con las versiones de librerías que me sugiere, no el famoso emerge, si no los propios ebuilds otra cosa no funciona.
Claro que aquí no terminan los problemas, ahora viene el bueno: abrir los puertos en el firewall (iptables) para que todo funcione. Después de sufrir desconexiones porque no había intercambio alguno de paquetes (ni de audio ni de vídeo), caigo en la cuenta: el protocolo usa UDP para envío y recepción, así que hay que abrir puertos UDP para transmisión y puertos TCP para inicio y finalización de la comunicación. Ahí no acaba la cosa: m$-netm3eting usa puertos diferentes de los de GnomeMeeting y además hay que abrir el regreso de LDAP para poder conectarse en el servidor de directorio de GnomeMeeting (ILS en Seconix). A ver, detallo las reglas:
Por supuesto, la salida se supone que está totalmente autorizada. Para la investigación de qué puertos se usan en la comunicación, os transmito un truco que aprendí de alguien el la red (lo siento, no recuerdo el nombre). Consiste en añadir una regla justo antes de la última, la que tira todos los paquetes (la de DROP) que registre todos los paquetes. Esta la mantendremos mientras hagamos pruebas solamente. Supongamos que la máquina con la que estás probando es la 124.23.39.71; entonces, si la regla DROP es la número 35, la regla de registro de paquetes sería:
Entonces, ejecuta un tail -f /var/log/messages y empieza a probar. Empezará a cantar el jilguero, así que apunta los puertos de origen (SPT) y de destino (DPT) de las entradas y saca tus conclusiones.
Otras órdenes útiles: para listar las reglas con número de regla (muy útil para eliminar reglas y para insertar reglas antes de las existentes)
Así, por ejemplo, para eliminar la regla 24 a partir de la información anterior por número (si lo haces por el contenido de la regla es más lioso):
Ahora sí puedo hacer videoconferencia, o al menos audioconferencia con quien no tenga una cámara, manteniendo el cortafuegos bien configurado. De todos modos mira en SanGoogle, ya que yo he sido muy cabezón y he querido probarlo por mí mismo, pero más o menos esas son las reglas.
¡Mucha suerte!
Mi segundo recelo fue: ¿será compatible GnomeMeeting con m$-netm3eting? Lamentablemente, soy el único linuxero (aunque sea de pastel) de la familia. Pues bien, me puse a la obra.
En un principio instalé la versión 1.00 que Gentoo me ofreció como estable, pero lejos de ser estable, cuando conectaba con GnomeMeeting 1.0.2 me daba un coredump magnífico
, así que decidí instalarme algo más
avanzado (digamos la 1.0.2), y ahí empezó mi pesadilla.
No sé a quién echar la culpa (creo que a mí mismo, por iluso) pero, ¿por qué narices se dice que una aplicación compila con una versión igual o superior de las librerías tal y cual si es imposible (y seguro que improbable) que lo haga con versiones superiores? Pues ahí está el problema. después de pegarme con librerías que no compilan, fallos de dependencias y demás (varias horas de compilación), me rindo a la evidencia: debo compilar GnomeMeeting exactamente con las versiones de librerías que me sugiere, no el famoso emerge, si no los propios ebuilds otra cosa no funciona.
Claro que aquí no terminan los problemas, ahora viene el bueno: abrir los puertos en el firewall (iptables) para que todo funcione. Después de sufrir desconexiones porque no había intercambio alguno de paquetes (ni de audio ni de vídeo), caigo en la cuenta: el protocolo usa UDP para envío y recepción, así que hay que abrir puertos UDP para transmisión y puertos TCP para inicio y finalización de la comunicación. Ahí no acaba la cosa: m$-netm3eting usa puertos diferentes de los de GnomeMeeting y además hay que abrir el regreso de LDAP para poder conectarse en el servidor de directorio de GnomeMeeting (ILS en Seconix). A ver, detallo las reglas:
############## # Gnomemeeting # # Devolución de la conexión: solo puertos altos y que tengan ya conexión saliente -A INPUT -p tcp -m tcp --sport 1720 --dport 1024: -m state --state ESTABLISHED -j ACCEPT # Intercambio de paquetes de A/V: bonito rango -A INPUT -p udp -m udp --sport 1024: --dport 5000:5005 -j ACCEPT
############ # m$-netm3eting # # Este va por libre -A INPUT -p tcp -m tcp --sport 1024: --dport 1503 -j ACCEPT # Probablemente sirva la vuelta del anterior, pero no me fío -A INPUT -p tcp -m tcp --sport 1024: --dport 30000:30005 -j ACCEPT # LDAP (ILS para Gnomemeeting): solo vuelta -A INPUT -p tcp -m tcp --sport ldap --dport 1024: -m state --state ESTABLISHED -j ACCEPT
Por supuesto, la salida se supone que está totalmente autorizada. Para la investigación de qué puertos se usan en la comunicación, os transmito un truco que aprendí de alguien el la red (lo siento, no recuerdo el nombre). Consiste en añadir una regla justo antes de la última, la que tira todos los paquetes (la de DROP) que registre todos los paquetes. Esta la mantendremos mientras hagamos pruebas solamente. Supongamos que la máquina con la que estás probando es la 124.23.39.71; entonces, si la regla DROP es la número 35, la regla de registro de paquetes sería:
$ iptables -I INPUT 35 -p all -s 128.23.39.71 -j LOG
Entonces, ejecuta un tail -f /var/log/messages y empieza a probar. Empezará a cantar el jilguero, así que apunta los puertos de origen (SPT) y de destino (DPT) de las entradas y saca tus conclusiones.
Otras órdenes útiles: para listar las reglas con número de regla (muy útil para eliminar reglas y para insertar reglas antes de las existentes)
$ iptables -nL --line-numbers | more
Así, por ejemplo, para eliminar la regla 24 a partir de la información anterior por número (si lo haces por el contenido de la regla es más lioso):
$ iptables -D INPUT 24
Ahora sí puedo hacer videoconferencia, o al menos audioconferencia con quien no tenga una cámara, manteniendo el cortafuegos bien configurado. De todos modos mira en SanGoogle, ya que yo he sido muy cabezón y he querido probarlo por mí mismo, pero más o menos esas son las reglas.
¡Mucha suerte!
viernes 04/03/2005 02:29:42
Fuente AWT por defecto
Por segunda vez, he estado a tiros con la fuente que AWT (para el JDK de sun)
usa por defecto. Pasa que usa un tamaño excesivamente grande y claro, la
pregunta es lógica: "¿dónde se cambia ésto?".
Bueno, pues después tenía una ligera idea del problema, pero nuevamente me puse a investigar. El problema es que usa un tamaño en puntos ("point size") de 140 debido a la resolución (puntos por pulgada) de mi monitor. Pues bien, eso me parece muy, muy grande, y no me gustaba.
Manos a la obra y a experimentar con el fichero font.properties. Después de tocarlo un poco, recibo un bonito mensaje del tipo:
Claro, mi respuesta fue: "¿mande?". Hasta que vi el "problema". Parece que (no sé si es sólo mi sistema) el doble guión después de "normal" no le hace mucha gracia. A estos campos de un selector de fuente se les llama "xfld", pues como falta el xfld de familia de fuente (o algo así), XWindow se queja. De acuerdo, meto un asterisco y... ¿qué ocurre? Que las fuentes siguen siendo enormes. Bueno, ahora viene la chapuza: si en lugar de "%d" en el octavo "xfld" (creo) fuerzo a 85, pues la fuente por defecto es buena. No me preguntéis por qué, pero funciona, aunque no sé hasta cuando y no sé si habré roto algo más. ¡Ah! A raíz de ésto he aprendido a usar la orden:
que sirve para probar un selector de fuente y, si funciona, para ver qué fuente selecciona.
Espero que la experiencia sirva a alguien. Hasta la próxima
.
Bueno, pues después tenía una ligera idea del problema, pero nuevamente me puse a investigar. El problema es que usa un tamaño en puntos ("point size") de 140 debido a la resolución (puntos por pulgada) de mi monitor. Pues bien, eso me parece muy, muy grande, y no me gustaba.
Manos a la obra y a experimentar con el fichero font.properties. Después de tocarlo un poco, recibo un bonito mensaje del tipo:
Warning: Cannot convert string "-b&h-lucidasans-medium-r-normal--*-140-*-*-p-*-iso8859-1" to type FontStruct"
Claro, mi respuesta fue: "¿mande?". Hasta que vi el "problema". Parece que (no sé si es sólo mi sistema) el doble guión después de "normal" no le hace mucha gracia. A estos campos de un selector de fuente se les llama "xfld", pues como falta el xfld de familia de fuente (o algo así), XWindow se queja. De acuerdo, meto un asterisco y... ¿qué ocurre? Que las fuentes siguen siendo enormes. Bueno, ahora viene la chapuza: si en lugar de "%d" en el octavo "xfld" (creo) fuerzo a 85, pues la fuente por defecto es buena. No me preguntéis por qué, pero funciona, aunque no sé hasta cuando y no sé si habré roto algo más. ¡Ah! A raíz de ésto he aprendido a usar la orden:
$ xfd -fn "nombre_de_fuente"
que sirve para probar un selector de fuente y, si funciona, para ver qué fuente selecciona.
Espero que la experiencia sirva a alguien. Hasta la próxima
.
miércoles 02/03/2005 01:13:53
WindowMaker
Me rindo
.
He vuelto a WindowMaker. Después de experimentar mucho con openbox, fluxbox y otros, ningún gestor de ventanas te da el control sobre las características de las ventanas y las recuerda como wmaker.
Lo que me gusta de WindowMaker
:
Lo que no me gusta: ¿cuándo se podrán usar temas para los controles de las ventanas? Supongo que nunca, aunque donde estén esos tan grandes... Imposible fallar al cerrar la ventana, ¿no?
Creo que lo primero que hay que aprender antes de hacer un gestor de ventanas (o cualquier cosa que hagas) es saber copiar al mejor para después, si puedes, mejorarlo. Todavía no he encontrado una copia de WindowMaker medianamente decente
.
.
He vuelto a WindowMaker. Después de experimentar mucho con openbox, fluxbox y otros, ningún gestor de ventanas te da el control sobre las características de las ventanas y las recuerda como wmaker.
Lo que me gusta de WindowMaker
:
- Recursos: ahorrativo, el más ligero de todos, requiere un único proceso si no usas ningún plugin
- Memoria: conserva todas las preferencias de las ventanas como escritorio en que mostrarla, si es omnipresente, si debe flotar encima o quedar debajo, y todo ello puedes hacerlo incluso en ventanas hijas de las ventanas principales
- Escritorios: me gusta cambiar de escritorios con la rueda del ratón y que se muestre el nombre de cada escritorio, de este modo sé dónde arranco cada ventana y llego al escritorio que quiero sin tener que usar ningún menú.
- Control de ventanas: ¿para qué necesito botones de maximizar y minimizar? Teniendo múltiples escritorios, jamás se me ocurre minimizar una ventana y maximizar me horroriza: ¿dónde está mi menú, mis carpetas y el monitor del sistema? Todo bajo control
Lo que no me gusta: ¿cuándo se podrán usar temas para los controles de las ventanas? Supongo que nunca, aunque donde estén esos tan grandes... Imposible fallar al cerrar la ventana, ¿no?
Creo que lo primero que hay que aprender antes de hacer un gestor de ventanas (o cualquier cosa que hagas) es saber copiar al mejor para después, si puedes, mejorarlo. Todavía no he encontrado una copia de WindowMaker medianamente decente
.
