La plaga Tux

Esta entrada la tengo escrita desde hace bastante tiempo pero entre unas cosas y otras se me había olvidado publicarla xD. Resulta que a partir de la versión 10.04 de Ubuntu la instalación de freewrl se ha complicado un poco por la nueva versión de xulrunner incluida en la distribución. Freewrl no se encuentra aún en los repositorios de Ubuntu y por este motivo tienes que compilar el programa a partir de las fuentes. El problema es que el dichoso programa depende de la versión 1.9.1 de xulrunner cuando en Ubuntu ya solo mantienen en los repositorios la 1.9.2. En esta entrada os explico la solución que he encontrado para poder compilar correctamente el programa a partir de dicha versión de la distribución.

Leer más…

Tras varios años usando C++ aún sigo sufriendo dolores de cabeza cuando me atasco con alguna cosilla como la que os comento a continuación. Estoy desarrollando una librería en la que estoy usando bastante las plantillas y la herencia para intentar abstraer las cosas lo máximo posible. Pues bien, al intentar crear una clase plantilla derivada que heredaba comportamiento de otra clase plantilla me he encontrado con la sorpresa de que el compilador me decía que la clase derivada no tenía visibilidad sobre los miembros de la clase base. La solución a este problema es muy sencilla y os la comento a continuación.

Leer más…

Editado/Edited: 25/06/10

Estoy probando unos scripts en Python que me han pasado (y que han sido desarrollados sobre Debian) y he tenido problemas a la hora de ejecutarlos. Cuando intentaba ejecutar estos scripts en mi ordenador me lanzaban el siguiente mensaje de error, entre otros:

/bin/sh: Syntax error: Bad fd number

El problema se encuentra en las llamadas que se hacen en el script a os.system() para ejecutar algunos comandos de consola. Como ya he dicho, los scripts han sido desarrollados sobre una plataforma Debian, pero en mi distribución Ubuntu no han funcionado. Esto se debe a que en ubuntu por defecto los comandos se ejecutan por sh y no por bash.

La solución que he visto ya propuesta en varios sitios es eliminar el comando sh de su sitio y hacer un enlace simbólico desde el comando bash a sh. Es una forma un poco bestia de hacerlo … pero no he visto ninguna otra solución. Si alguien conoce una forma más elegante de hacer esto que lo comente por favor.

sudo mv /bin/sh /bin/sh.bak
sudo ln -s /bin/bash /bin/sh

Visto aquí.

Otra solución mejor

En vez de tener que hacer este enlace simbólico mediante el módulo subprocess podemos especificar que terminar queremos usar mediante la opción executable. A continuación os dejo un método que me he creado para hacer llamadas a programas por la terminal usando /bin/bash en vez de la terminal por defecto (/bin/sh en ubuntu)

def run_shell_program (cmd):
  try:
    retcode = subprocess.call(cmd, shell=True, executable=&quot;/bin/bash&quot <img src='http://plagatux.es/wp-includes/images/smilies/icon_wink.gif' alt=';)' class='wp-smiley' />
    if retcode != 0:
      print &gt;&gt; sys.stderr, &quot;Error executing command: %s&quot; % cmd,\
      &quot;(return code: %s)&quot; % retcode
  except OSError, e:
    print &gt;&gt;sys.stderr, &quot;Execution failed: %s&quot; % cmd, e

See this page.

A better solution

Instead of making the symbolic link explained in the above post we can use the subprocess module in python in order to specify the shell executable we want to use. The next method written in python is used to run shell command using /bin/bash instead of the default shell command (/bin/sh in Ubuntu)

def run_shell_program (cmd):
  try:
    retcode = subprocess.call(cmd, shell=True, executable=&quot;/bin/bash&quot <img src='http://plagatux.es/wp-includes/images/smilies/icon_wink.gif' alt=';)' class='wp-smiley' />
    if retcode != 0:
      print &gt;&gt; sys.stderr, &quot;Error executing command: %s&quot; % cmd,\
      &quot;(return code: %s)&quot; % retcode
  except OSError, e:
    print &gt;&gt;sys.stderr, &quot;Execution failed: %s&quot; % cmd, e

Desde que me hice con mi última tarjeta gráfica ATI RADERON HD 5770 he sufrido problemas de rendimiento en diferentes distribuciones GNU/Linux a la hora de habilitar los efectos de escritorio (Compiz). En su día me estuve informando de cual era el problema que había, ya que con mi anterior tarjeta Nvidia de menores características iba todo super fluido. Si no recuerdo mal todo se debe a un problema que hay en el código del servidor gráfico X. Para que una parte del código sea compatible con las tarjetas gráficas Intel se tuvo que habilitar una característica que hizo que el redimensionamiento de ventanas con las tarjetas ATI fuese más lento. Siento no dar más detalles acerca de este hecho en concreto, pero no tengo tiempo y solo quería comentar la solución que he encontrado para solventar el problema en Ubuntu 10.04. La solución es bien sencilla, basta con agregar el repositorio que encontraréis en esta dirección, actualizar los repositorios mediante aptitude o apt-get y cuando actualicéis el sistema y reiniciéis el equipo todo debería funcionar sobre ruedas .

Since I bought mi last graphic card ATI RADEON HD5770 I’ve suffered performance problems in different GNU/Linux distros after enabling the desktop effects (Compiz). In its day I was searching information about the problem because of with my previous Nvidia graphics card all run like a charm. If I remember correctly this problem is caused by a problem in the X graphic server code. In order to make one part of the code compatible with Intel graphic cards one feature was enabled and this fact made slower the performance in ATI graphic cards. I’m sorry for not giving more details about this particular fact, but I have no time and I only want to tell you the solution found to solve the problem in Ubuntu 4.10. The solution is very easy, you only have to add the repository you can found in this page, update the repositories with aptitute or apt-get and upgrade the system. When you reboot the system all will run smoothly .

Después de un par de años usando Vim para todo en GNU/Linux, las pocas veces que accedo a Windows también lo necesito para editar cualquier tipo de fichero. Sin embargo, cuando intento editar algún fichero de los que ya tengo creados en mis particiones EXT3 tengo problemas con la codificación de los ficheros. En GNU/Linux utilizo siempre la codificación UTF-8, mientras que Windows utiliza su codificación por defecto (ISO-8859-1), y por lo tanto cuando abrimos archivos con Vim dentro de Windows observamos que algunos caracteres no se observan bien. La solución a este problema es bien sencilla, tan solo tenemos que editar nuestro fichero _vimrc y añadir la siguiente línea:

set enc=utf-8

Visto aquí.

After a couple of years using vim for everything in GNU/Linux, the few times that I use Windows I need it to edit any kind of file. However, when I try to edit some of the already created files in my EXT-3 partitions I have problems with the codification of the them. In GNU/Linux I always use the UTF-8 codification while Windows by default uses its codification (ISO-8859-1). Therefore, when I open these files in Windows some of the characters are not displayed correctly. The solution to this problem is easy, we only have to edit our _vimrc file and add the next line:

set enc=utf-8

Seen here.