sábado, 17 de octubre de 2015

Ordenadores para el tercer mundo

Hola a todos, el martes uno de los comerciales que había ido a un país sudamericano a ver qué vendía se me presentó con un OLPC OX 1.5 que había traído de allí para ver qué podíamos hacer con él.

  http://wiki.laptop.org/go/Hardware_specification_1.5


La iniciativa OLPC (One Laptop Per Child) pretendía crear un pequeño ordenador portátil barato orientado a niños que viven en países en vías de desarrollo. Es en sí un hardware barato, con un microprocesador compatible con la arquitectura X86 de Intel, y con un sistema operativo basado en Linux Fedora.

Hasta aquí todo bien, pero el proyecto recibió montones de críticas, y ahora sé por qué. Como se dice en mi tierra, el OLPC no es sólo un portátil, además es una mierda como una casa.



La primera impresión que da al verlo es que es un juguete. Un diseño que parece hecho "a prueba de niños", un teclado tosco e incómodo, una cruceta y unos botones para jugar a juegos, y una pantalla TFT  enana. Y tras encenderlo se confirma que es un juguete al ver un Linux que no parece un Linux.

Con un entorno gráfico extremadamente capado, casi monocromo, y en el que unas pocas aplicaciones y un par de juegos educativos en lo único que se tiene.

Tiene un navegador web ligero, de los que no sirven para nada. Admitamoslo, o tienes un Chrome o un Firefox, o no puedes acceder a la mitad de los contenidos de la web. Y tiene un procesador de textos que digamos simplemente que no es el Libreoffice.

Pero lo más sangrante es que no aprovecha los recursos de la máquina. Con una SD interna de 4GB de la que aprovecha sólo 2GB, ningún juego que use la cruceta, y una resolución de pantalla bastante mayor de la que se usa, tienes probablemente el sistema más desaprovechado del mundo.

Así que lo único que tienes al final es un juguete para los niños que ni siquiera es barato.

Frente a esta penosa iniciativa, hay otras más juiciosas. Un amigo me comentó la iniciativa "Play power" http://playpower.org/

Con un precio de tan sólo 10$, tienes algo parecido a lo que fue en su día un Spectrum o una NES de Nintendo. Con juegos educativos y un televisor donde conectarlo (y electricidad) puedes formar a muchos niños en la bases de la informática. Y esto en países donde el saber mecanografiar es la diferencia entre el duro trabajo del campo y el trabajo más cómodo (y normalmente mejor pagado) de una oficina, esto es algo que marca la diferencia.

RESUMIENDO: OLPC mierda, Play Power mola.

Salu2 a to2

lunes, 3 de agosto de 2015

El televisor Sony Bravia con Android

Hola a todos. Hace poco me he comprado una TV Sony Bravia con Android.



Me la compré con Android básicamente para poder ver las películas de Google Play. Me gusta Google Play sobre otras plataformas porque se pueden comprar películas (además de alquilarlas) y porque cada 3 meses o así hay ofertas de películas por 4€ en SD y 6€ en HD.

Pero al entrar en Google Play para ver las aplicaciones cual fue mi sorpresa que aparecían muy pocas aplicaciones.

Tras investigar un poco resulta que las aplicaciones están filtradas y solamente aparecen aquellas aplicaciones que se sabe que funcionan correctamente en esta TV y con el mando del televisor. Pero claro, uno quiere más (aunque tenga que conectar un ratón a uno de los USB).

La solución fue fácil, primero instalé desde el Google Play el "ES File Explorer". Luego descargue el APK del "Aptoide" en un pen drive y se lo conecté al televisor. Tras esto, con el "ES File Explorer" navegué hasta el pen drive y seleccioné el APK, entonces te aparece una advertencia diciendo que no puedes instalar aplicaciones desde "orígenes desconocidos".

En esta advertencia hay un botón que al pulsarlo te lleva a las opciones de configuración donde puedes habilitar la instalación desde "orígenes desconocidos". Tras habilitar la opción, volví al "ES File Explorer", vuelta a ejecutar el APK del "Aptoide" y ya pude instalarlo.

Así que a partir de ahora para instalar aplicaciones tengo dos formas: o bien las instalo desde Aptoide, o bien descargo el APK a un pen drive y lo instalo utilizando "ES File Explorer".

Salu2 a to2



lunes, 13 de julio de 2015

Instalar Python 2.6 en CentOS 7

Hola chavales, CentOS 7 viene con Python 2.7 instalado, mientras que CentOS 6 venía con Python 2.6.

Como no todas las aplicaciones de Python 2.6 funcionan bien en Python 2.7 (estas raras excepciones a veces ocurren), puede que necesitemos instalar Python 2.6.

Para ello lo que haremos será recompilar el Python 2.6 de CentOS 6 a partir del SRPM:

  yum groupinstall "Development Tools"
  yum install readline-devel openssl-devel gmp-devel  ncurses-devel  gdbm-devel zlib-devel  expat-devel libGL-devel tk tix libX11-devel  tcl-devel tk-devel tix-devel bzip2-devel sqlite-devel db4-devel libffi-devel  valgrind-devel systemtap-sdt-devel  tcl libffi-devel

 # Parcheamos libdb4
 yum install compat-db47
 ln -s /usr/include/db4.7.25/ /usr/include/db4

 # Parcheamos libffi
 mv /usr/include/ffi.h /usr/include/ffi.h.original
 ln -s /usr/include/ffi-x86_64.h /usr/include/ffi.h

 # Parcheamos /usr/lib/rpm/brp-python-bytecompile
 # edita el fichero /usr/lib/rpm/brp-python-bytecompile y en la
 # segunda línea reemplaza "errors_terminate=$2" por
 # "errors_terminate=0"


 adduser mockbuild

 # Como no es bueno construir paquetes con el root, crearemos un usuario llamado "compilar"
 adduser compilar
 su - compilar 
 wget ftp://ftp.redhat.com/pub/redhat/linux/enterprise/6Server/en/os/SRPMS/python-2.6.6-52.el6.src.rpm

 rpm -i python-2.6.6-52.el6.src.rpm
 cd ~/rpmbuild/SPECS

 # Edite el fichero "python.spec" y elimine las referencias a 
 # los ficheros: "dbm.so" y "ossaudiodev.so", y cambie la referencia
 # "plat-linux2" por  "plat-linux3". Luego añada la referencia a "%{dynload_dir}/dbm_failed.so"

 rpmbuild -ba python.spec



Encontrarás lo paquetes RPM generados en "../RPMS/x86_64/"
Y ahora vuelve a dejar el fichero "/usr/lib/rpm/brp-python-bytecompile" como estaba.

Puedes instalar los paquetes con "rpm -i" o añadirlos a tu repositorio.

Un saludo

jueves, 4 de junio de 2015

Alternativa a Active Directory bajo Linux

¿Qué haces cuando tienes un parque de equipos Linux y quieres gestionarlos como lo harías con Active Directory?

De cara al mecanismo de login, es relativamente sencillo. Casi desde siempre se ha podido utilizar un LDAP para tener una gestión centralizada de usuarios. Pero Active Directory ofrece más cosas.

Esas otras cosas que tiene Active Directory se llaman "políticas". Y permiten establecer el fondo de pantalla de un usuario, instalar software en un equipo o configurar una impresora.

Pues bien, ahora podemos tener eso mismo en Linux. Existe un proyecto de la Junta de Andalucía llamado GECOS que hace exactamente esto.

¿Cómo lo hace? Pues lo hace utilizando Opscode Chef (https://www.chef.io/chef/).

A "grosso modo" GECOS se puede dividir en 3 partes:
  • El Centro de Control GECOS: que ofrece una interfaz web para gestionar los usuarios, equipos y políticas de forma cómoda. Este Centro de Control lo que hace es meter valores en Chef por detrás.
  • Un servidor de Chef: que controla la configuración de los equipos en la sombra.
  • Una utilidad de configuración para distribuciones basadas en Ubuntu: que sirve para configurar el cliente de Chef de forma que tire contra el servidor de Chef, y para configurar el login de usuarios de forma que tire contra LDAP o Active Directory.
Este último punto, las utilidades de configuración, ya se encuentran integradas y preparadas en la distribución de Linux Guadalinex GECOS (basada en Linux Mint).

De forma que con GECOS se puede:
  • Cambiar el fondo de escritorio de un usuario
  • Instalar software en un equipo
  • Configurar una impresora en un equipo
  • Mostrar un mensaje de alerta al usuario
  • Etc

Por el lado malo, a fecha de hoy la versión de GECOS existente aún tiene muchos pequeños fallitos y detalles que pulir.

Además, recordemos que Active Directory tiene un esquema más o menos fijo, con lo que el script para importar usuarios de Active Directory dentro de GECOS  funciona más o menos bien.

Pero LDAP tiene un esquema que cada uno configura según su gusto, con lo que cada LDAP es de su padre y de su madre. Así que necesitarás conocimientos de programación para modificar el script base y realizar muchas importaciones de prueba hasta conseguir importar correctamente tu LDAP dentro de GECOS.

Salu2 a to2

lunes, 16 de marzo de 2015

Enviando datos en crudo a una impresora

Hola chavales, en el curro me he topado con un problema con unas viejas impresoras matriciales.
Resulta que el programa que envía los datos a imprimir, los manda "en crudo" ("raw" para los colegas).

Explico, nosotros tenemos un driver que suplanta una impresora Postscript y crea un PDF. Pues bien, la impresión "en crudo" lo que hace básicamente el saltarse el driver a la torera y enviar los datos directamente al puerto.

Para hacer las pruebas pertinentes, utilizamos un programita de Micro$oft:
 https://support.microsoft.com/es-es/kb/138594?wa=wsignin1.0

Gracias a las pruebas con este programita detectamos que el driver no se ejecutaba, y que los datos iban del tirón al puerto en cuestión.

Así que ya sabéis que si una impresora matricial no funciona, quizá la culpa no sea del driver.

Salu2 a to2

jueves, 5 de marzo de 2015

Trabajo con impresoras desde la línea de comandos en Windows

Hola a todos, hoy se ma ha planteado la necesidad de ver cómo se puede cambiar el nombre de una impresora desde la línea de comandos de Windows.

Pues bien, resulta que Microsoft incorpora una serie de Scripts VBS para trabajar con las impresoras.

https://technet.microsoft.com/es-es/library/cc771846%28v=ws.10%29.aspx

Lo primero es localizar estos scripts en el ordenador. En el servidor donde estaba trabajando se encontraban en la ruta C:\Windows\System32\Printing_Admin_Scripts\es-ES\

A partir de ahí puedes utilizar estos scripts para hacer cosas como listar las impresoras del sistema:

   cscript prnmngr.vbs -l 

O cambiar el nombre de una impresora:

  cscript prncnfg.vbs -x -p "Microsoft XPS Document Writer" -z XPS

Salu2 a to2

domingo, 1 de marzo de 2015

Comparando antes y después con Windows

Hola a todos. En un servidor con Windows Server 2012 tenemos una aplicación que cuando un usuario con privilegios de administrador instalaba, dicha aplicación funcionaba correctamente.

Pero si se borraba el perfil local de la máquina (teniendo "roaming profiles" en el Active Directory), tras iniciar sesión en el servidor la aplicación ya no funcionaba.

Dicha aplicación se instala en el perfil del usuario, algo nada recomendable pero por lo que se ve los programadores de esta aplicación lo hicieron así. Así que cuando ese "perfil movil" se movía, había algo de la aplicación que no se estaba moviendo correctamente.

Después de muchos quebraderos de cabeza y muuuuuuuchas horas de trabajo, conseguimos averiguar qué era y solucionar el problema. Para ello usamos el software "Process Monitor".

  https://technet.microsoft.com/es-es/sysinternals/bb896645.aspx

Partiendo de un perfil limpio, instalamos la aplicación y luego lanzamos el process monitor.

Aplicamos todos los filtros necesarios para excluir de la captura de eventos los procesos típicos del sistema (como el "task manager", o el "svchost"), y lanzamos la apliación que lógicamente funcionó correctamente. Luego guardamos la captura como CSV.


Tras esto, cerramos sesión, borramos el perfil local y a tras traerse el perfil móvil hicimos otra captura de eventos con el Process Monitor, pero esta vez sabíamos que la aplicación fallaría.

Una vez que teníamos 2 ficheros CSV (una con los eventos cuando la aplicación funciona y otra cuando no funciona). Los abrimos con Excel y quitamos las columnas de fecha y hora, y del ID de proceso. De esta forma los dos ficheros CSV son similares hasta el punto donde falla la aplicación.

Finalmente, comparando ambos ficheros CSV con Winmerge (que para algo son ficheros de texto), pudimos ver que nos faltaban algunas entradas del registro e incluso una librería DLL.

RESUMIENDO: Si queréis comparar un "antes" y un "después" del comportamiento de una aplicación, el "Process Monitor" es un buen aliado.

Salu2 a to2


martes, 17 de febrero de 2015

PnaclCoordinator: pexe load failed (pp_error=-2).

Hola a todos, hoy me he encontrado el siguiente error al intentar depurar el código PNaCL:

NaCl module load failed: PnaclCoordinator: pexe load failed (pp_error=-2).

Por lo visto, este código lo que indica es que no se ha podido descargar el PEXE. Así que le dí a F12, puse el navegador para ver los elementos que se descargan de la red, y vi que no tenía puesto el "*_unstripped.bc" en el servidor web.

Salu2 a to2

PNaCl ABI verification failed


Hola a todos, ayer estuve todo el día depurando en NaCL y cuando compilé la versión final con PNaCL me encontré el siguiente mensaje de error:

ERROR [NaCl module load failed: PnaclCoordinator: PNaCl Translator Error: PNaCl ABI verification failed]

Tras mucho investigar resulta que tenía definida la variable del entorno NACL_SDK_ROOT apuntando a "pepper_canary" mientras que estaba intentando compilar con "pepper_39".

Así que la causa del problema es que estaba mezclando código de dos NaCL SDK distintos.

Cambié la variable para que apuntara a "pepper_39", recompilé todo y ya funciona.

Salu2  a to2

miércoles, 28 de enero de 2015

Construyendo los naclports

Hola a todos, estoy estudiando el uso de PNaCL para crear un cliente nativo de Chrome para los Chrome books.

Esta es sólo una de las opciones a estudio para ver con cuál de las opciones tendremos en menor tiempo y con menor esfuerzo una versión del cliente de nuestro software para Chromium.

Como parte de las dependencias de nuestro software está OpenSSL, así que viendo por la web encontré que lo mejor es tirar de los "naclports".

Para construir los "naclports" necesitarás:

  • Ubuntu 14 de 64 bits (no uses Debian porque encontrarás problemas con las versiones)
  • Descargar el "nacl_sdk" (debes descargar "pepper_canary") 
  • Descargar los "naclports". 

Como hay partes del "nacl_sdk" compilado para amd64 y partes compiladas para i386, necesitas la versión de 64 bits y obtener las librerías de 32 bits y las herramientas necesarias para la compilación mediante:


sudo apt-get install git curl lib32stdc++6 g++ lib32z1 lib32ncurses5 lib32bz2-1.0


Una vez hecho esto descaga el "nacl_sdk" y los "naclports" siguiendo los pasos indicados en:

Cuando ya has obtenido todo el software podrás construir la librería "openssl" mediante:

  cd naclports/src
  export NACL_SDK_ROOT=/home/usuario/chrome/nacl_sdk/pepper_canary

  export BUILDBOT_BUILDERNAME=true
  NACL_ARCH=pnacl TOOLCHAIN=pnacl make openssl

Si todo va bien deberá construirse la librería sin dar ningún error.

Un saludo