lunes, 16 de enero de 2017

RaspberryPi como herramienta docente. R y Calc. Episodio 2

Como ya habíamos comentado en alguna entrada anterior, en ratos libres estamos probando la posibilidad del uso de unidades RaspberryPi como sustituto posible en el hardware para las prácticas en la materias que impartimos en la Universidad. Las aplicaciones que utilizamos en estas materias son Calc, como hoja de cálculo para la introducción y presentación de datos y R para cálculos estadísticos.
Como hemos visto, una vez eliminada la posibilidad de utilizar unidades de RaspberryPi modelo 2b, hemos estado probando unidades 3B con Raspbian. Sin ninguna modificación disponemos de Calc y se puede instalar R, pero en una versión muy antigua —3.01—. Esta versión podría servir para docencia, pero genera problemas a la hora de instalar paquetes, ya que muchos servidores espejo no disponen de versiones de los paquetes para versiones antiguas. Para poder instalar las versiones más modernas de R tenemos que incluir repositorios debian testing (stretch). Es decir,

1. Actualizamos los repositorios ya activos en el sistema

sudo apt-get update

2. Accedemos a la lista de repositorios del sistema

sudo nano -$ /etc/apt/sources.list

3. Introducimos al final una línea como la siguiente para activar el repositorio de prueba —testing— de debian para raspberry; en este caso sería

deb http://archive.raspbian.org/raspbian/ stretch main

4. Guardamos y reiniciamos el sistema

5. Después deberemos actualizar el sistema entero, ya que se instalarán muchos paquetes nuevos, que incluyen también LibreOffice (ya sabemos que Debian tiende a ser bastante conservador para mantener la estabilidad en los repositorios estables).

sudo apt-get update
sudo apt-get upgrade

6. Instalaremos R

sudo apt-get install r-base r-core r-base-core r-base-dev

Y ya tenemos R instalado en una versión moderna

R version 3.3.2 (2016-10-31) -- "Sincere Pumpkin Patch"




Y la simulación de las prácticas ha sido perfecta, sin ningún contratiempo, pudiendo realizar todo sin problemas y con tiempo de respuesta adecuado, y sin problemas a la hora de instalar paquetes.




martes, 10 de enero de 2017

Wayland en Fedora; algunos inconvenientes

Llevo hasta este momento unos tres meses probando Wayland bajo diferentes circunstancias (portátil, sobremesa...) en Fedora 25. Teniendo en cuenta que solo soy un usuario normal, y no un desarrollador, hasta ahora he encontrado los siguientes problemas:
1. gparted, como indicamos aquí. No estoy completamente seguro de que se deba a Wayland, ya que me había pasado antes en X11. Aun así, como hemos visto, es fácilmente solucionable.
2. gnome-boxes, como habíamos indicado aquí. Solucionable con facilidad.
3. jdownloader. En ocasiones se cuelga y lanza una lista larga de errores (que desgraciadamente nunca he guardado). En las últimas actualizaciones no se ha producido, así que podemos darla por resuelta; además, era solo un pequeño problema que aparecía en ocasiones, al manipular la aplicación.
4. mkvtoolnix-gui. En terminal funciona perfectamente, pero la versión 9.40 de la máscara gráfica se colgaba (literalmente desparecía) al intentar realizar cualquier tipo de acción. Es un problema importante, ya que si bien en terminal se realizan fácilmente las extracciones, los montajes y añadidos de líneas de sonido o texto son complejos e incómodos en terminal. En la versión actual 9.60 funciona perfectamente, así que ya está solucionada.


5. vlc. Esta es la única alteración que me está afectando en mis ordenadores que aun no ha tenido solución. Al intentar visualizar cualquier fichero de vídeo el vlc simplemente no arranca. si se intenta por terminal da un mensaje de error como este:


A pesar de lo que dice, la reinstalación, incluido una previa desinstalación, no ha funcionado. Es el único problema que por ahora no he podido solucionar satisfactoriamente. Sí, hay otros programas, pero no me gustan tanto. Un pequeño fastidio.

ACTUALIZACIÓN:
No, jdownloader no está resuelta. De hecho, me ha vuelto a pasar. esta vez si he grabado el error. Para aclarar las cosas, esun error de Java, y empieza así (unas pocas líneas de unos cientos):
 

jueves, 15 de diciembre de 2016

sysqr no responde. ¿Dónde se activan las teclas mágicas?

Esta entrada tiene cierta relación con la anterior. En los tres ordenadores que tengo funcionando con Fedora 25, dos funcionan perfectamente con Wayland, descontando algunas alteraciones que iré explicando cuando las comprenda, pero un tercero, el más potente, el más moderno, muestra ciertas respuestas extrañas cuando está en el sistema gráfico Wayland. Fundamentalmente, el sistema muestra una granulación en el monitor y a partir de ese momento deja de responder a las órdenes gráficas y no deja llamar a un escritorio de texto (Ctrl+Alt+ F2 a F7, siendo F1 el que soporta el sistema gráfico). Este ordenador es el único que tiene una tarjeta gráfica externa, nVidia, por cierto; los demás llevan gráficas de Intel incorporadas en el procesador, y lo digo por si eso tiene que ver y alguno ve la relación. Además las primeras veces que se me bloqueó  el sistema no fui capaz de realizar una salida ordenada mediante sysrq (REISUB) y tuve que saltar el sistema con la tecla de reseteo.
Como había indicado en una entrada en la instalación de Fedora 18, la localización de los ficheros de configuración del sistema había cambiado de Fedora 17, /etc/sysctl.conf, al directorio /usr/lib/sysctl.d en Fedora 18, actuando desde  ese momento en el fichero /usr/lib/sysctl.d/00-system.conf. Y así apliqué tras la instalación de Fedora 25


y sin embargo no se ejecutaba la orden AltGr+ImpPant + REISUB.  Para comprender lo que supone, cada una de las letras ejecuta lo siguiente:

R pone el teclado en modo RAW (recobrar el control desde el entorno gráfico X al teclado)
E termina todos los procesos (end) (envía el comando Sigterm a todos los procesos, para finalizarlos ordenadamente)
I interrumpe todos los procesos (envía el comando Sigkill a todos los procesos, para forzar su terminación)
S sincroniza el disco duro (synchronize, descargar datos de la memoria a los ficheros en el disco duro)
U desmonta todos los sistemas de ficheros (unmount y volver a montar los sistemas de ficheros como de solo lectura)
B reinicia la máquina (reBoot)


Para evitar un tercer reseteo estuve evaluando los diferentes ficheros de configuración —/usr/lib/sysctl.d/— y en el fichero 50-default.conf aparece un mensaje así

#  This file is part of systemd.
#
#  systemd is free software; you can redistribute it and/or modify it
#  under the terms of the GNU Lesser General Public License as published by
#  the Free Software Foundation; either version 2.1 of the License, or
#  (at your option) any later version.

# See sysctl.d(5) and core(5) for documentation.

# To override settings in this file, create a local file in /etc
# (e.g. /etc/sysctl.d/90-override.conf), and put any assignments
# there.

# System Request functionality of the kernel (SYNC)
#
# Use kernel.sysrq = 1 to allow all keys.
# See http://fedoraproject.org/wiki/QA/Sysrq for a list of values and keys.
kernel.sysrq = 16

Para que veamos lo que supone cada número dentro del sysrq, el orden es:

0 - disable sysrq completely
1 - enable all functions of sysrq
>1 - bitmask of allowed sysrq functions (see below for detailed function description):
     2 - enable control of console logging level
     4 - enable control of keyboard (SAK, unraw)
     8 - enable debugging dumps of processes etc.
     16 - enable sync command
     32 - enable remount read-only
     64 - enable signalling of processes (term, kill, oom-kill)
     128 - allow reboot/poweroff
     256 - allow nicing of all RT tasks

Es decir, la el comando kernel.sysrq = 1 ejecutado en el primer fichero (00) de configuración es anulada por la kernel.sysrq = 16 colocado por systemd (50). Así que he sido obediente a systemd y he trasladado a un fichero /etc/sysctl.d/90-override.conf kernel.sysrq = 1, dejándolo fuera del directorio de configuración, y lo he eliminado del fichero 00. Algo exclusivo este systemd


Listo

miércoles, 14 de diciembre de 2016

Error en gnome-boxes bajo Wayland

He encontrado un problema en la ejecución de una máquina virtual en gnome-boxes en Fedora 25 utilizando Wayland. Más o menos resulta que tras la ejecución de gnome-boxes en terminal (si lo ejecutamos pinchando en el icono no se pueden leer los errores), al lanzar la máquina (en este caso Windows XP, para probar un programa), el sistema operativo comienza a cargarse y ahí se queda horas o días.


Podemos ver un error crítico en el terminal:

gnome-boxes:2361 Gtk-CRITICAL:gtk_gl_area_make_current: assertion 'gtk_widget_get_realized (widget)' failed

Debe ser un bug que viene de atrás, desde Fedora 22, y que está indicado aquí.
Tenemos dos soluciones:

La primera, recurrir a virt-manager, con el que la máquina virtual funciona como se esperaba,


o volver a X11 en gnome y boxes funciona adecuadamente (errores no críticos más o menos),


A Wayland aun le falta un pequeño empujón.

miércoles, 30 de noviembre de 2016

gparted Gtk-WARNING: cannot open display - root y xhost

No es la primera vez que me pasa esto; instalación de sistema, llamar a gparted y se obtiene un mensaje de

Gtk-WARNING **: cannot open display

Esto se debe a que gparted requiere privilegios de administrador para poder usarse

Root privileges are required for running gparted

y que es una máscara GRÁFICA. El administrador solicita la apertura de un nuevo sistema gráfico y ya está en posesión del usuario. En general muchas páginas recomiendan una orden como

xhost +

pero esto genera un problema de seguridad, ya que se abre el sistema gráfico a cualquiera (véase por ejemplo aquí). Es además matar moscas a cañonazos, ya que si lo único que necesitamos es que el administrador local tenga acceso al sistema gráfico, ¿por qué añadimos todos? Así que creo que es más lógico añadir al administrador local

xhost local:root

y listo. gparted en marcha


jueves, 24 de noviembre de 2016

Actualización a Firefox 50. Bloqueo del navegador por el mensaje de error de la extensión dragdropupload

Eso mismo; por cierto, un error repetido en el tiempo y especialmente molesto. En la última actualización de Fedora Firefox se actualizó a la versión 50 (y otras muchas cosas). Al lanzar el nuevo navegador apareció un mensaje de error que lo bloqueaba continuamente haciendo imposible su uso. No he guardado instantáneas, pero era un mensaje de un Java Script similar a

"...dragdropupload TypeError: can't access dead object..."

La única solución fue, tras tratar de cerrar el mensaje muchas veces, aceptar la posibilidad de eliminar todos las extensiones. Al arrancar empezará a cargar de nuevo todas las extensiones, ya que se sincroniza entre todas las máquinas, y hay que estar rápido de reflejos para eliminar la extensión en cuestión. De paso eliminé algunas que tenía desde hace tiempo y que ya no utilizo.

Las ventajas has sido claras; en primer lugar Firefox arranca antes (se ve que tenía demasiadas extensiones) y además sincronizan los cambios a las otras máquinas, con lo que al día siguiente ya estaban aplicadas en mi despacho, como se puede ver en la siguiente captura de pantalla.


Menos mal, por que estos 15 minutos de Chrome me habían generado un dolor de cabeza...

martes, 15 de noviembre de 2016

RaspberryPi como herramienta docente. R

El software que utilizo como herramienta de trabajo desde hace muchos años es completamente libre. No solo el que uso yo personalmente; también el que utilizo como herramienta de manejo de datos, gráficos y tratamiento estadístico. Eso quiere decir que la herramienta más importante en mis prácticas es R. La mitad de mi docencia se da delante de un ordenador, y debido al coste de mantenimiento de las aulas me he planteado, solo como duda teórica, si sería posible aplicar toda la docencia que explico utilizando RaspberryPi.


¿Qué ventajas ofrece? Fundamentalmente coste. Si una sala de informática de 21 ordenadores puede suponer unos 15.000€, la sustitución de una sala obsoleta por estos pequeños dispositivos puede salir por 1200€ (aprovechando monitores, teclados y ratones). El coste es el precio de un Raspberry (40€), una caja (10€) y una microSD (8€) multiplicado por 21.

¿Y los inconvenientes? Bastantes. Veamos; en primer lugar, los alumnos no están acostumbrados a nada que no sea Windows (o Mac). Las pruebas que he realizado han sido con Raspbian, que es una adaptación de Debian para esta máquina de arquitectura ARM. Por lo tanto, es una máquina limitada con fines de docencia para programadores, que no es este caso. He probado con RaspberryPi modelo 2B, de 512MB de RAM (tiempo de respuesta muy largo) y un RaspberryPi modelo 3B, con 1GB de RAM (tiempo de respuesta aceptable-bueno).

Las herramientas utilizadas son Calc —hoja de cálculo de LibreOffice, que ya está preinstalada en Raspbian—, y R; desde el repositorio de Debian disponemos de R v 3.1.1.

sudo apt-get install r-base

Al no ser una versión muy actualizada (hablamos una versión de 2014), la instalación de paquetes adicionales requiere que los espejos seleccionados sean http, y no https, que suelen tener paquetes solo para las últimas versiiones de R.

Realizada la instalación, el funcionamiento es fluido en el modelo 3 y prácticamente imposible de usar en una clase en el modelo 2, debido a la lentitud.

El modelo 3B lo he probado en un pitopCEED,


una pantalla formato tablet preparada para adaptar un Raspberry, con alimentador incluido y tecla de encendido. Este dispositivo se puede ajustar perfectamente a las clases.



El modelo 2B lo he probado en un monitor antiguo con conector DVI (el Raspberry tiene salida digital HDMI, pero con un adaptador HDMI-DVI funciona perfectamente). He posido instalar R pero el funcionamiento es a saltos y no permite un manejo fluido de las acciones.

En resumen, es factible el uso para docencia de R en dispositivos RaspberryPi 3. Para aquellos que estén utilizando RStudio como máscara gráfica, no me ha sido posible instalar RStudio, ya que no hay ningún binario con arquitectura ARM.

Planes siguientes:
- Realizar todas las pruebas utilizadas en las clases, medir los tiempo de desarrollo...
- Otras posibilidades de instalación de RStudio
- Instalación de la versión de Fedora para ARM y RaspberryPi

Estamos en ello...

martes, 8 de noviembre de 2016

Impresoras de tinta; érase una vez que la tinta era más cara que la sangre de unicornio

Desde hace bastantes  años tengo una impresora de tinta HP Officejet 8000 Pro.



Esta impresora tiene varias ventajas:
- Imprime muy bien
- Dual
- Rápida
- Drivers para Linux

Sin embargo me ha presentado bastantes problemas, alguno de los cuales ya los he señalado antes. En concreto ya se ha tenido que cambiar los dos cabezales (coste similar a una nueva) y ha sufrido un arreglo importante que solo fue posible con las piezas de otra similar que se había estropeado y el conjunto de piezas de las dos funcionaba. Además, el mayor inconveniente, común a todas las impresoras de tinta, es que un juego de cartuchos de alta capacidad cuestan como una impresora nueva.
Ahora se acerca el momento de comprar un nuevo juego de cartuchos, y la pregunta es, ¿compro un nuevo juego o cambio de impresora?
Desde mi punto de vista la impresora ideal es una multifunción láser con capacidad de escanear en color a dos caras, fotocopiar e imprimir a dos caras en blanco y negro. Personalmente no necesito impresión en color, pero en mi casa un pequeño porcentaje aun debe imprimirse en color. La decisión es complicada.

1. Como se necesita un cierto porcentaje de impresión a color, mis condiciones de multifunción láser con capacidad de escanear en color a dos caras, fotocopiar e imprimir a dos caras nos pone en impresoras muy caras y grandes, no adecuadas para casa.

2. Eso mismo en impresoras de tinta, si queremos evitar el gasto por los cartuchos nos lleva a impresoras profesionales muy caras que no se pueden justificar con mi uso habitual, un cartucho de cada color al año.

3. Si compro una multimedia habitual de tinta, he realizado un gasto para tener el mismo problema, solo por la capacidad de fotocopiador y escáner que solo lo utilizo en raras ocasiones en casa; es una decisión poco rentable.

4. Comprar una nueva similar a esta supone unos cartuchos de demostración, con lo que en dos meses pack nuevo y mismo problema sin haber mejorado nada.

5. Comprar tinta "barata" provocará que los cabezales de inyección se estropeen de nuevo. Mal asunto, 100€ de arreglo.

6. Comprar un pack de cartuchos de alta capacidad cuesta lo mismo que la impresora.

¿Qué hacer? Aquí planteo una duda existencial.

PD. Es solo una pregunta retórica. Tomaré la opción 6; pero llevo todo el día pensando que hacer... y discutiendo con el vendedor de la tienda, que opina también que la mejor opción es la 6. Eso sí, si deciden comprar nuevos cartuchos, nunca dejen que la impresora esté mucho tiempo avisando de que los cartuchos se están terminando, por que esa situción acaba siempre con cabezar estropeado.

lunes, 7 de noviembre de 2016

Cambio de équipo

Debido a los años acumulados, he cambiado mi ordenador de trabajo. Causas, diez años de uso, un disco duro de sistema con un sector erróneo y un arranque que fallaba cada vez más (¿condensadores?), lo que el último día supuso una pérdida de 29 minutos para lograr un arranque funcional. El nuevo equipo está muy bien:
- Placa madre ASUS X99-A II
- Procesador Intel Core i7 6850K
- 4 bancos de Memoria DDR4 PC2400 Kingston 16GB para un total de 64GB y asegurar el cálculo de datos
- Disco Duro SSD M2 256 GB Intel para el sistema
Asimismo, debido a que había que cambiar un monitor trajimos un Philips 272P4 de 27 pulgadas y con resolución 2560x1440 —para trabajar mejor con R al lado de otros programas— y con la capacidad de proyectar dos entradas simultáneamente  —para poder conectar un RaspBerryPi simultáneamente al ordenador principal—.


Como el equipo tiene cierto coste, se ahorró en la tarjeta gráfica, con una básica nVidia GeForce 210 montada por Asus, y ahí nacieron los problemas. La tarjeta en cuestión, que teóricamente puede cubrir 2560x1440, realmente solo puede alcanzar 1920x1200 a 60Hz, lo que hace imposible el funcionamiento del monitor en conexión DVI y solo se puede utilizar con un HDMI 2.0, con la merma de calidad debida al cambio de resolución en las pantallas planas. La única solución fue recurrir a una nVidia GeForce GT 730, también montada por ASUS.


Y así estamos; el nuevo equipo se comporta muy bien, con algunos problemas gráficos que pienso se deben a Fedora 25 beta con Wayland.
En resumen, esperando la versión estable de Fedora.

miércoles, 19 de octubre de 2016

Fedora 25 beta



En cuanto he podido disponer de unos minutos he instalado Fedora 25 beta de la manera más sencilla y rápida, actualizado a través de dnf, con los comandos ya habituales

su -c 'dnf -y update --refresh'

su -c 'dnf install dnf-plugin-system-upgrade' # (En mi caso no hizo falta, por que ya lo tengo instalado)

su -c 'dnf system-upgrade download --refresh --releasever=25'

su -c 'dnf system-upgrade reboot'

Sin problemas; algún mensaje de error que me ha obligado a arrancar primero en Xorg system pero luego ya he podido arrancar con Wayland.  Ahora a probarlo; si hay algún problema importante, lo pondremos en esta u otras entradas.

Ahora intentaré la instalación de Fedora 25 beta en RaspberryPi, a ver como va.