Archivo

Archivo para agosto, 2007

Ultimos capitulos de la teleserie SCO

Lunes, 13 de agosto de 2007 4 comentarios

Actualización (14/Sep): SCO se acoge al famoso “Chapter 11″ del codigo de Bancarrota yankee. En pocas palabras es una medida de protección para empresas que se acercan a la quiebra, con el fin de darle algo de respiro para que intenten recuperarse.


El año 2003 SCO se intentó aprovechar del sistema legal de yankeelandia para recolectar dinero sin producir nada. La idea era anunciar que Linux contenia código de ellos (SCO Unix) para intimidar y cobrar por supuestas indemnizaciones debido a un uso no legítimo del código de su propiedad. Iniciaron un pleito contra IBM pero nunca pudieron demostrar cual era el famoso codigo.

(esta introduccion es para los desinformados de siempre)

De paso hubo un pleito con Novell quien aseguraba tener los derechos sobre el codigo de Unix, lo que invalidaria la posición de SCO.

El pasado viernes 10, Dale A. Kimball no solo determinó que Novell tenía los derechos y no SCO, sino que ademas SCO le debe a Novell el 95% de los royalties que SCO ha cobrado por licencias de Unix, principalmente a Microsoft y a Sun.

La situacion de SCO es complicada, su plan de conquistar al mundo al estilo Pinky y Cerebro no les ha traido mayores beneficios, y en estos ultimos 5 dias sus acciones bajaron de USD$1.5 a menos de USD$0.5 (hagan el calculo). Esta en duda si ahora son capaces de pagar lo que deben a Novell.

Cierro con las palabras de Ars Technica:

Few options remain open for SCO, and a bankruptcy could be imminent.

Cómo mejorar conexion lenta de ssh en Ubuntu Feisty

Sábado, 11 de agosto de 2007 9 comentarios

Cuando trato de conectarme a un servidor ssh usando Ubuntu Feisty se queda unos segundos “pensando” y después de eso se establece la conexión normalmente. Habilitando el “verbose” de ssh encontré lo siguiente:

fcatrin@desktop:~$ ssh -v serverdeprueba.com
OpenSSH_4.3p2 Debian-8ubuntu1, OpenSSL 0.9.8c 05 Sep 2006
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug1: Connecting to serverdeprueba.com [ipdeprueba] port 22.
debug1: Connection established.
debug1: identity file /home/fcatrin/.ssh/identity type -1
debug1: identity file /home/fcatrin/.ssh/id_rsa type -1
debug1: identity file /home/fcatrin/.ssh/id_dsa type 2
debug1: Remote protocol version 1.99, remote software version OpenSSH_3.6.1p2
debug1: match: OpenSSH_3.6.1p2 pat OpenSSH_3.*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_4.3p2 Debian-8ubuntu1
debug1: Miscellaneous failure
No credentials cache found
debug1: Miscellaneous failure
No credentials cache found

Las ultimas cuatro lineas se demoraron bastante en aparecer, una rápida búsqueda en google me indica que esos mensajes los arroja la autenticación con kerberos, y además encuentro que esa autenticación se demora si no hay un servidor kerberos disponible. Como yo no uso kerberos, y además creo que soy parte de la mayoría, simplemente deshabilité ese modulo en /etc/ssh/ssh_config.

Donde dice:

GSSAPIAuthentication yes

Lo cambié por:

GSSAPIAuthentication no

Y ahora el ssh se conecta inmediatamente, como siempre debió haber sido.

Tags: , ,

Java 1.3 en Ubuntu Feisty

Lunes, 6 de agosto de 2007 4 comentarios

Esta semana he estado trabajando con unas aplicaciones antiguas que requieren Java 1.3 por la versión del Application Server que están utilizando. Java 1.3 es bastante antiguo y depende de algunas bibliotecas igual de antiguas, piensen en esos tiempos en que no se usaba UTF-8 por omisión en Linux.

Tal como esperaba, no lo pude ejecutar directamente en Ubuntu Feisty, trate de darle algunas pistas al sistema, como el clásico LD_ASSUME_KERNEL pero tampoco tuve éxito. Al final, el procedimiento era bastante sencillo, pero bien podría haber perdido mucho más tiempo en esto. Estoy seguro de que alguien más agradecerá este tip (Hi Aldrin!)

Se necesitan 4 sencillos pasos:

Paso 1: Descargar Java 1.3 desde el sitio de Sun

  • Ir a http://java.sun.com/products/archive/
  • Seleccionar J2SDK 1.3 o J2RE 1.3 segun se necesite. Yo me fui por J2SDK 1.3.1_20

Paso 2: Cambiar los permisos y ejecutar el archivo .BIN para aceptar la licencia y descomprimir el archivo. Recomiendo hacer esto en el directorio /opt

cd /opt
chmod 755 ELARCHIVO.BIN
./ELARCHIVO.BIN

En mi caso, esto generó el directorio /opt/jdk1.3.1_20

Paso 3: Instalar libstdc++ compatible con esta version de Java. Ojo que el numero de version podria cambiar, lo importante es que sea 2.x

apt-get install libstdc++2.10-glibc2.2

Paso 4: Crear un link simbólico para que el binario de java pueda encontrar la biblioteca libstdc++ que espera. Ojo que las versiones pueden cambiar

cd /usr/lib
sudo ln -s /usr/lib/libstdc++-3-libc6.2-2-2.10.0.so libstdc++-libc6.1-1.so.2

Con eso ya podrán ejecutar java, pero seguramente tendrán problemas por el soporte multilenguaje, entonces antes de ejecutar java asegurense de ejecutar

export LANG=en_US

Resultado final:

fcatrin@shaman:~$ /opt/jdk_1.3.1_20/bin/java -version
java version "1.3.1_20"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.3.1_20-b03)
Java HotSpot(TM) Client VM (build 1.3.1_20-b03, mixed mode)

Pasos opcionales pero convenientes
Con esos pasos podrán ejecutar java directamente con /opt/jdk_1.3.1_20/bin/java, pero es muy engorroso. Personalmente uso un método que me simplifica el problema de rutas y versiones de java. Todas las versiones de java instaladas las hago vivir en /opt. En ese directorio creo un enlace simbólico apuntando al nombre real del java instalado. Tengo algo asi:

java13 -> jdk1.3.1_20
java14 -> j2sdk1.4.2_02
java -> java14

Para crear uno de esos enlaces aplico:

cd /opt
ln -s jdk1.3.1_20 java13

De esta forma, java13 siempre sera /opt/java13 independiente del java instalado, y el java por omisión siempre sera /opt/java, y si lo deseo lo puedo cambiar para que apunte a java14 o java 13 depende de qué java quiero tener por omisión. En mi .bashrc dice :

export JAVA_HOME=/opt/java
export PATH=$JAVA_HOME/bin:$PATH

Con eso tengo lo suficiente para que cualquier aplicación java que ejecute utilice el java por omisión (1.4 en este caso). Para el caso de java13 me cree un script /usr/local/bin/java13 que dice:

export JAVA_HOME=/opt/java13
export PATH=$JAVA_HOME/bin:$PATH
export LANG=en_US

Entonces cuando requiero java 1.3 simplemente ejecuto source java13 y listo. De esta forma:

fcatrin@shaman:~$ java -version
java version "1.4.2_02"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_02-b03)
Java HotSpot(TM) Client VM (build 1.4.2_02-b03, mixed mode)
fcatrin@shaman:~$ source java13
fcatrin@shaman:~$ java -version
java version "1.3.1_20"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.3.1_20-b03)
Java HotSpot(TM) Client VM (build 1.3.1_20-b03, mixed mode)

Tags: , , ,

AbiWord en La Tercera

Viernes, 3 de agosto de 2007 9 comentarios

Es grato a veces encontrarse con este tipo de noticias en un medio masivo “tradicional”.

Equipo boliviano traduce al aymara procesador de texto de software libre (La Tercera)