Problema con wxWidgets y última actualización de Xorg

Parece que en la última actualización de seguridad de X.org en openSuse 10.3 alguien ha metido la pata y se ha roto tanto Java como las aplicaciones que dependen de wxWidgets, entre ellas pgadmin3.

 El mensaje de error incluye mensajes ciertamente "preocupantes" como:

The error was 'BadAlloc (insufficient resources for operation)'.

Solución:

Modificar el xorg.conf con las siguientes lineas:

Section "Extensions"
    Option "Composite" "Enable"
    Option "MIT-SHM" "no"
EndSection

 

 

Cómo hacer que el Vigilante del Sistema de KDE se muestre completo

Si sois usuarios de KDE es posible que utiliceis la combinación de teclas Ctrl+Esc para lanzar el "Vigilante del Sistema" o lista de tareas.

La aplicación que se lanza es ksysguard pero se lanza de tal manera que sólo nos muestra la lista de procesos abiertos y no la ventana con los distintos sensores para monitorizar distintos parámetros de funcionamiento del equipo.
Si lanzamos ksysguard sin parámetros sí que nos aparece esa pestaña pero no si la lanzamos con la combinación de teclas. En este caso es como si escribiéramos ksysguard --showprocesses

Hay un pequeño truco para conseguir que al presionar Ctrl+Esc obtener el ksysguard "entero". Basta con hacer lo siguiente como root:
# cd /usr/bin
# vi ksysguard

y escribir:
#!/bin/bash
/opt/kde3/bin/ksysguard

#chmod +x ksysguard

Una vez que hemos hecho esto, podemos comprobar que si llamamos a ksysguard se llamará nuestro pequeño script:
#which ksysguard
/usr/bin/ksysguard

Bueno... pues ya lo tenemos funcionando ;)

Conectar a una base de datos DB400 desde Linux usando Python

De vez en cuando me toca hacer algún trabajo rutinario en bases de datos DB400, el DB/2 de los antiguos AS/400, ahora iSeries.

Normalmente usaba Client Access para Windows y el Navegador de Operaciones para llevar a cabo determinadas tareas en la base de datos. Desgraciadamente en Linux la versión de Client Access es muy limitada. Afortunadamente trae el driver ODBC que podemos instalar si problemas con unixODBC.

Una vez instalado el driver con el administrador ODBCConfig hay que ver como acceder desde nuestro lenguaje favorito, en mi caso Python. Hay algunas alternativas en cuanto a librerías de acceso a fuentes de datos ODBC pero o bien son privativas (egenix) o bien bastante limitadas (pyodbc)..

Existe sin embargo un proyecto muy interesante y que he conseguido utilizar con éxito: ceODBC.

Su desarrollador principal se muestra además completamente accesible y colaborativo, cosa de agradecer.

Supongamos que hemos creado un origen de datos ODBC con el nombre de "as400". El siguiente código muestra como acceder a nuestra base de datos y recuperar los 10 primeros valores recuperados de una tabla:

import ceODBC
con = ceODBC.connect('DSN=as400')
cur = con.cursor()
cur.execute("select * from biblioteca.tabla")
rows = cur.fetchmany(10)
print rows

(*)Importante fijarse en la cadena de conexión. Otros módulos permiten ignorar el DSN= y poner sólamente el nombre del origen de datos, pero con ceODBC no es así.

Acysos Tips....

Vamos a ver si reactivamos poco a poco la actividad en el blog.

Lo cierto es que el tiempo no es algo que nos sobre precisamente pero me he propuesto poco a poco ir retomando la costumbre de escribir algo. He decidido ir incorporando pequeños "tips" o trucos sobre cuestiones que me voy encontrando.

Aquí va el primero:
Cómo aumentar el tamaño del menú SuSE de KDE en openSUSE.

El menú de SuSE en KDE es francamente bonito, pero el tamaño de los iconos y el tamaño por defecto de su contenedor hacen que sea bastante incómodo. Por ello estuve mirando de qué manera podía modificarse su tamaño para adecuarse a mis necesidades.

Tras trastear un rato encontré el archivo:
.kde/share/config/kickerrc
en mi direcorio de usuario.
En la sección [General] del mismo hay dos entradas:
KMenuHeight y KMenuWidth para modificar los valores de altura y anchura del menú respectivamente.
Yo los tengo establecidos en 600 y 370 respectivamente, y ahora mi menú es ¡mucho más bonito!

Las ventanas son cosas del pasado

Web 2.0, blogosfera, redes colaborativas. Hace tiempo que estos conceptos vienen forjándose en la realidad de Internet. De alguna forma las personas hemos buscado métodos de evasión de la rigidez tecnológica existente buscando nuevas formas de obtener información, exponer nuestras ideas y en definitiva interactuar en un entorno informático.

Las limitaciones de la interfaz actual vienen determinadas por la metáfora del escritorio desarrollada hace más de 20 años en los laboratorios de Xerox PARC, en Palo Alto. Los investigadores de aquel centro estudiaron cómo era nuestra forma de interactuar con la información a través de un ordenador y surgieron ideas importantes como por ejemplo el ratón y la metáfora de las ventanas. Llegó el Mac, y OS/2, y Windows y un largo etc. de lo que no son más que visores de documentos.

Actualmente disponemos de hardware con unas prestaciones impensables hace años. Sin embargo, seguimos utilizando la misma metáfora del escritorio para tratar la información. El trabajo colaborativo se vuelve complicado. En general, colaborar en un entorno computerizado a día de hoy no deja de ser algo así como pasarnos documentos de un escritorio a otro, mientras hacemos nuestras observaciones. Existen algunos proyecto curiosos como Gobby, un editor colaborativo bastante ingenioso, pero que no deja de ser una muy hábil pirueta sobre un modelo que empieza a resultar caduco.

Si tuviéramos que rediseñar desde cero nuestra forma de trabajar con los ordenadores y con los demás... ¿seguiríamos utilizando la metáfora del escritorio?. ¿Dónde está la metáfora de la oficina?. ¿Y la metáfora del aula o la metáfora de mi comercio abierto al público?.

Hace años que pasé por la Universidad. He de decir que aprendí mucho más en los pasillos, hablando y discutiendo que en todos los libros. No basta con leer unos libros para asimilar todo aquello que la Universidad tiene que dar. La interacción social es fundamental.

Lo mismo ocurre con nuestro mundo virtual actual. Existe gran cantidad de contenido pero una escasa y mala interacción social entre quienes poblamos ese mundo. Necesitamos herramientas que nos permitan conseguir que Internet no sea un medio de entrega de contenidos sino un auténtico canal de colaboración entre personas.

Afortunadamente, ni soy original en esta linea de pensamiento, ni soy el primero. Hay un grupo de personas trabajando hace tiempo en esta línea en torno al proyecto de software libre OpenCroquet. OpenCroquet es un entorno tridimensional colaborativo, independiente del sistema operativo. En una próxima entrada en este blog comentaremos algo más al respecto. De momento, un link interesante para el que sepa inglés.

¿Por qué software libre?

Hay miles de páginas dedicadas al software libre. Dedicadas a explicar en qué consiste, porqué su modelo de desarrollo es más rápido y fiable, porqué es más seguro y en definitiva porqué surge este movimiento.

Existen multitud de enlaces a libros y opiniones de filósofos como Pekka Himanen, hackers como Stallman, Bruce Perens o Eric Raymond, ingenieros como Linus Torvalds. Incluso para los impacientes existen documentales como Revoution OS donde se explican muchas cuestiones relacionadas con el software libre.

Lo que es más dificil de explicar es porqué empresas como la nuestra apuestan en exclusiva a trabajar con soluciones de software libre. ¿Estamos locos? Tal vez sí, o tal vez no, pero dejenme que explique porqué creemos en lo que estamos haciendo.

Utilizaré un símil, tratando de no llevarlo demasiado lejos. Supongamos que los programas de ordenador son como los vehículos a motor. Existen motos, coches de diversos tamaños, marcas, modelos y colores, camiones, furgonetas y autobuses. Mucha gente conduce vehículos y los utilizan lo mismo para ir al cine a pasar la tarde (ej: reproducir MP3) como para llevar mercancías a sus clientes (ej: software de gestión de almacenes). No hace falta ser un ingeniero mecánico para conducir un vehículo (utilizar un programa), no hace falta que lo diseñemos, basta con adquirir uno que nos convenga. Tampoco hace falta tener conocimientos de mecánica(programación), basta con un carnet de conducir.

El problema es que en el mundo del software hace muchos años que la inmensa mayoría de los vehículos venían con el capot cerrado y sellado: el usuario no podía abrirlo ni siquiera para mirar el nivel de aceite (no puede verse el código fuente). No digamos ya para algo más serio: hay que llevarlo al concesionario oficial. No existen los pequeños talleres donde poder hacer revisiones o ajustes.

El software libre equivaldría a los vehículos en los que el capot se puede abrir. Así de sencillo. No es necesario saber diseñar el coche, ni siquiera saber de mecánica. Desde luego quién sabe algo de mecánica (programar) puede meter la mano debajo del capot y cambiar una correa o el aceite. Algunos incluso se atreven a ponerle un kit de óxido nitroso al coche para echar carreras.

No es una cuestión de buscar los méritos técnicos del software libre frente al propietario (que los tiene). Es que yo nunca me compraría un coche al que no se le puede levantar el capot.