openSUSE y R. Compilar o infierno de dependencias

Ya tenemos solución para el problema que presenta openSUSE en la instalación del paquete estadístico R. La solución encontrada por hckorootx (véase su comentario en esta entrada) es, como no debe ser menos en una distribución de Linux, la compilación desde código fuente. Después de ver su comentario hice un segundo intento de instalación desde binarios. Siguiendo las instrucciones que aparecen en la página de R para openSUSE, apliqué sobre una máquina virtual de 32bits la técnica de un solo click,

donde se me advirtió de nuevo, al igual que me había pasado en la instalada a 64 bits, de que no se disponía de la glibc_2.15, imprescindible para el funcionamiento de R (y, si leemos aquí, para todo el funcionamiento de Linux).

Luego, al intentar en terminal llamar a R, la respuesta es la esperada ya que NO APARECE LA LIBRERÍA

Así que, a aquellos que no puedan vivir sin YaST y openSUSE, pero que también, como yo, no puedan trabajar sin R, hckorootx nos ha dado la solución mediante compilación y que voy a pegar aquí


hckorootx dijo...
R funcionando en openSUSE 12.1 64 bits:
1) Bajamos R-2.14.1.tar.gz (http://cran.es.r-project.org) y lo movemos a nuestro directorio $HOME
2) tar xvzf R-2.14.1.tar.gz
3) cd R-2.14.1
4) ./configure
configure: error: no acceptable C compiler found in $PATH
See `config.log' for more details

* Instalamos gcc (y, de paso, make)

5) ./configure
configure: error: No F77 compiler found

* Instalamos gcc-fortran

6) ./configure
configure: error: --with-readline=yes (default) and headers/libs are not available

* Instalamos readline-devel

7) ./configure
configure: error: --with-x=yes (default) and X11 headers/libs are not available

* Instalamos xorg-x11-devel

8) ./configure (saldrán algunos warnings, pero el proceso se completará)
9) make (al finalizar, el ejecutable de R será $HOME/R-2.14.1/bin/R)
10) Opcionalmente, si queremos que R esté disponible para todos los usuarios, nos identificaremos como root y ejecutaremos:

make install

Lo que de paso puede refrescar a los que en general no compilamos desde código fuente como se hace (de forma general, particularidades aparte). Como ya he dicho, también debemos instalarlo así en la distribución de 32 bits.

Gracias, hckorootx.

Disco duro bloqueado: segunda parte

Como decía en la entrada anterior sobre discos duros bloqueados, disponía de un segundo disco duro en el mismo estado, con 1 TB reducido a 33MB. Es un disco idéntico al anterior, misma marca, modelo y hasta lote. Para realizar la restauración del tamaño original se siguieron los mismos pasos que la otra vez:
1. Detección de su estado, después de un arranque defectuoso en una placa GigaByte. A través de palimpsest detectamos que realmente solo se reconocen 33MB.

2. Arranque con Ultimate Boot CD, repitiendo con un Aspire One, con el disco conectado a través de la misma caja externa USB, y Ultimate Boot CD en el mismo lápiz Kingston. El disco solo se puede poner en la unidad USB de la derecha, posición más retrasada de las dos, ya que en caso contrario no es detectado por MHDD (tal como se ve en la foto).

3. Una vez detectado el dispositivo, se ve la protección por password y se intenta romper (passwords genéricas de Western Digital indicadas en la otra entrada), y aunque parece que en cada segundo intento parece valer (no pone fail), eso no es cierto y el dispositivo sigue protegido y no es posible hacer aplicar ningún comando de recuperacion (HPA=cut o NHPA=uncut)

4. Se realiza la misma acción en un ordenador sobremesa nuevo, que permite también arranque desde USB (el mismo lápiz USB con Ultimate Boot CD). Se desconecta todos los discos duros de la máquina y se coloca el disco bloqueado en S-ATA 1. MHDD detecta a la primera, sin necesidad de escanear, el dispositivo, al contrario que en el intento a través de una conexión por USB:

5. Al acceder a él, no aparece marca de protección alguna ni la de password (PWD con fondo rojo en la línea superior). Aplico directamente NHPA (uncut) y funciona.

6. Para asegurarnos, lo pasamos por el palimsest. Perfecto.

Conclusiones:

- El desbloqueo de la HPA debe realizarse en una conexión S-ATA y no USB. De esta manera no aparece la protección.
Podemos encontrar dos dudas:

- ¿Es preciso hacerlo en un ordenador moderno? Probablemente no, ya que podemos generar un Ultimate Boot CD en un CD, como su propio nombre indica. Sin embargo sigo pensando que existe la posibilidad de que la protección no se muestre por algunas características modernas del ordenador. La protección existe y en muchos blogs se da por supuesto que no es fácil romperla. Deberíamos terner un tercer disco similar y aplicar directamente el uso del S-ATA 1 de un sobremesa directamente para estar seguros de cual ha sido el paso definitivo.

- ¿Sería posible que en la conexión USB hubieramos roto la protección mediante alguna de las palabras genéricas, y que debido a esa misma conexión USB no pudieramos aplicar NHPA, a pesar de haber roto la protección? Aun tengo esta duda, pero no creo, ya que lo repetí muchas veces. Al principio aplique todas las palabras juntas, hasta que no aparecía "fail", pero luego lo hice una a una y reiniciaba, y en todas aparecía el mensaje "fail".

Por si son interesantes las características del ordenador donde se solucionaron los dos bloqueos, aquí va el hardware tras un
lshw -short
Dos consideraciones.
Una. Sí, como usuario normal, ya que así sale más corta y comparando no se pierde información.
Dos, lshw no se instala con Fedora; tuve que instalarlo para esto (su -, y luego yum install lshw)

NTFS, MKV y totem

He detectado un nuevo problema en el uso de discos externos. Coincide además con discos NTFS. La copia es la siguiente, de un disco NTFS a otro NTFS, con un ordenador con Fedora 16 64bits como "ejecutor" de la acción, y siendo los ficheros multimedia contenedores matroska de vídeo. La orden de copia se hace desde un nautilus como administrador llamado desde un terminal

$ su -
palabra
# nautilus

A lo largo de la larga copia aparece en el terminal un mensaje cada minuto diciendo que totem-video-thumbnailer era incapaz de leer la imagen, lo que contribuye al consumo de recursos (no grabé ninguna imagen por que el ordenador estaba muy "ocupado"). Para terminar, al intentar desmontar de forma gráfica, aparece este bloqueo.

Tuve que desmontar en terminal. Este error solo aparece en discos con ficheros matroska (MKV). Quizá totem sea una de las causas de este gran consumo de CPU.

Unidades externas NTFS. Lentitud y consumo de recursos

Hoy he intentado terminar con mis problemas de copias a unidades externas NTFS y he visto el verdadero problema - la lentitud (ver también aquí). He dado la orden de copia de 386 GB de material multimedia de una unidad conectada en un S-ATA interno formateado en NTFS a un disco externo también formateado en NTFS y conectado por un USB externo. El sistema no se bloquea completamente, simplemente copia muy lentamente y consume la mayor parte del sistema. El resultado han sido 9 horas de copia, a una velocidad de 12MB/s y con un sistema en el que no se podía hacer nada. No se podía llamar a ninguna aplicación gráfica y en terminal tardaban 10 minutos en ejecutarse ordenes tan simples como cd .. o ls. Lo mejor de todo es que he realizado la misma orden en un ordenador con Windows 7 y copia a la misma velocidad (12MB/s); eso si, el sistema está disponible para hacer otras cosas.
Soluciones:
- No usar discos NTFS, lo que es difícil si queremos mantener compatibilidad con otros ordenadores no Windows y con aparatos multimedia que solo entienden FAT y NTFS.
- Si hay que usarlos, copiar en un ordenador libre y con mucha paciencia. Además, si se dispone de él, usar un ordenador con Windows.
- Si se dispone de un solo ordenador, evitar el bloqueo de pantalla, ya que de lo contrario tendremos un ordenador con una pantalla en negro un tiempo muy largo y que no se sabe cuanto va a durar. Evitar mal carácter y nunca reiniciar por las malas, ya que no se desmontan bien las unidades y nos montamos un lío, perdemos ficheros y acabaremos reparando el ordenador en las fstab.

Acortando direcciones

En vista de lo largas que son las URLs de mis entradas, he probado a acortarlas (en Google, por costumbre). El resultado es interesante, sobre todo para poner en twitter.
De http://www.clopezsandez.com/2012/01/donde-y-como-se-llama-el-ejecutable-de.html pasa a http://goo.gl/5x2Gf.

¿Dónde está y como se llama el ejecutable de Writer-LibreOffice?

A lo largo de todos estos meses en los que he estado usando LibreOffice nunca me he preguntado ni dónde estaban los ejecutables ni como se llamaban. Sin embargo, hoy he necesitado saber donde estaban (para que un determinado tipo de ficheros se abriera con writer) y he descubierto que aun se llama oowriter. Estuve buscando en /usr/bin y /usr/sbin pero no lo encontraba. Con whereis no funciona poner *writer, hay que poner el nombre completo, con lo que lo detecté con find (me fui al directorio raíz y lancé la búsqueda). Salió un montón de cosas, pero después lo he filtrado con grep para que se vea fácilmente en esta imagen.

En resumen, no lo encontraba por que no lo buscaba con oo por delante. Ahora que lo sé, simplemente whereis oowriter, y listo:

Así que, sí, librewriter se llama -aun- oowriter.

VirtualBox en Fedora

La instalación es bien sencilla. En vez de instalar la versión OSE disponible en repositorios

es preferible instalar la versión bajada de Oracle, como podemos ver en yumex. Bajaremos 3 ficheros: el binario correspondiente a nuestra distribución, bien la versión para 32 o 64 bits, según corresponda, el vbox extpack y la iso de las guest additions, para luego actualizarlas en los sistemas internos de la máquina virtual.
Una vez instalada, por supuesto nos aparece un error, debido a que VirtualBox no ha sido introducido en el kernel (Linux no está construido como Windows)

Por suerte Linux nos dice lo que debemos hacer, y ejecutamos la orden que nos indica

/etc/init.d/vboxdrv setup

pero nos aparece otro error.

Se debe, como se puede ver, a que DKMS, encargado de generar módulos para el kernel, no está instalado en Fedora 16. Debemos instalarlo primero.

Puede aparecer un tercer error, debido a no disponer de gcc instalado (compilador de varios lenguajes para Linux). Al intentar generar el módulo de VirtualBox en el kernel y llegar a make, comando encargado de decidir que compilar, sin gcc no se puede compilar. Tendríamos en ese caso que instalar gcc también. Ese error, si aparece tras la instalación de dkms, lo tenemos que leer en el log resultante (que nos indica el propio error donde está).

Una vez superados todos estos problemas, ya se genera un módulo para VirtualBox en el kernel

Y así ya podemos instalar el extpack en VirtualBox, arrancar las máquinas y actualizar los guest additions en los sistemas operativos invitados. Perfecto. Ya podemos usar los programas de Windows. Ahora viene la pregunta del millón, ¿para qué?
Por costumbre, aun uso VirtualDub, pero a través de wine y rar en el terminal. Simplemente me queda el uso del escáner, un Canoscan 8000 que Linux no reconoce.

Convertir música

Personalmente, no estoy muy interesado en la conversión de los diferentes formatos de audio. Algún día tendré que pasar todos mis CDs a ficheros digitales, ya que considero que la vida de los discos está acabada, pero no es algo que me preocupe actualmente. Sin embargo, un compañero me ha pedido que transforme unos ficheros m4a (contenedor de audio favorito de Apple) a mp3 para poder escucharlos con Windows Media Player. Por supuesto, la conversión de formatos con pérdida a otros con pérdida es un error, ya que se pierde información dos veces, pero he abandonado Windows hace mucho y no sabría decirle como puede incluir codecs adecuados. En resumen, las posibilidades a mi alcance en Fedora eran:
1. Soundconverter: muy sencillo y disponible en los repositorios. Para mi gusto demasiado sencillo. Podemos ver aquí sus propiedades

La conversión ma4 a mp3 es posible, siempre que tengamos librerías faad instaladas, ya que no deja de ser una GUI de gstreamer en gnome.

En general, a pesar de ser usuario de siempre de gnome, para la transformación de sonido en Ubuntu he usado soundKonverter, un front-end mucho más completo. Por supuesto, debido a su K de KDE, precisa la instalación de las librerías qt, pero en Ubuntu las instalaba previamente con k3b. Sin embargo, no he encontrado soundkonverter en ningún repositorio de Fedora 16 con gnome.

2. gnormalize. Front-end similar a SoundKonverter, y también más completo que soundconverter. Está disponible en los repositorios atrpms, como podemos ver en yumex. Si no tenemos activado ese repositorio, en la pestaña de repositorios podemos activarlo o introducirlo como decíamos aquí.

Hace una conversión previa a wav y luego al formato deseado con la configuración que se haya pedido con borrado del wav (si así se le ha pedido). Rápido y útil.

3. audio-convert-mod. Un front-end que debe estar instalado automáticamente en Fedora, ya que no lo conocía antes. Es muy simple, pero muy efectivo. Las posibilidades de entrada dependen, naturalmente, de las librerías disponibles

y las salidas son muy limitadas (aac, wc, mp3, flac, wav, ogg), con menos posibilidades que con soundkonverter y gnormalize.


Desde mi punto de vista, cualquiera nos puede servir. En general, los usuarios ocasionales solo necesitamos una librería con el decodificador del formato del fichero de sonido que queramos oír/convertir y un front-end gráfico para poder convertir esa música si la queremos para algún aparato externo al ordenador sin complicaciones.

En resumen:
1. Si escuchamos la música desde el ordenador, no es necesario convertirla, solo instalar la librería con el decodificador adecuado para poder leerla.
2. No es conveniente transformar de nuevo la música codificada con pérdida (mp3, m4a, ogg...) por que provocaremos una segunda pérdida de calidad. De nada sirve darle más bprs; lo perdido en la primera codificación, perdido esta, y no aparece de nuevo por magia, y el segundo algoritmo, al utilizar diferentes patrones, provocará una segunda pérdida. Es mejor conseguirla de nuevo con el otro formato o extraerla de los CDs en flac (sound-juicer lo hace automáticamente si lo configuramos así).
3. Si conseguimos música sin pérdida (wav, mac/ape, flac), lo mejor es convertirla a un formato sin pérdida y libre. Por ejemplo, guardo mis CDs en flac, que es una compresión (queda como a la mitad de un wav). Si es música con formato ape sin pérdida (mac - monkey's audio codec) la transformo a flac; comprime algo menos, pero se distribuye bajo licencia BSD y GPL.
4. No comprar música (ni nada) que traiga DRM.
5. Si queremos comprimir, me gustaría recomendar ogg, pero dependerá de en que aparatos queramos escuchar los ficheros. Por desgracia, la mayor parte lee mp3, e incluso aac, pero muy pocos ogg. Asi que si quieren comprimir, compriman en mp3, y servirá para cualquier aparato; y podemos hacerlo gracias a lame.

Para mi me llega con sound-juicer para pasar CDs a flac y una GUI sencilla que convierta mac a flac, con la librería adecuada para la decodificación de los ficheros ape de mac (monkey's audio codec; no confundir con Apple). Con eso es suficiente para mi. Para los usuarios de Windows, con EAC -el mejor ripeador-, que se puede asociar con lame para transformar a mp3 con pérdida y flac para compresión sin pérdida, suficiente también.

Yumex, ya que no tenemos YaST

Una vez rescatados por Fedora, sí puedo afirmar que me gustaria tener YaST. Sin embargo, podemos utilizar una aplicación similar, aunque menos completa; se trata de yumex (YUM EXtender - he conocido su existencia gracias a Usemos Linux). Nos permite usar de forma gráfica yum, facilitando nuestra tarea diaria, ver los paquetes instalados y las actualizaciones disponibles, controlar los repositorios activos e instalar nuevos paquetes (similar a Synaptic en Debian/Ubuntu). Es más útil y rápido que el terrible (es solo una opinión) packagekit.
YumEx está disponible en las aplicaciones

o lo llamamos desde el terminal ($ yumex). Si no estuviera instalado, directamente

$ su -
     palabra del administrador
# yum install yumex


Su apariencia es limpia, fácil de usar; véase, por ejemplo, la pestaña de repositorios,

No es YaST, pero no está mal.

Otra de tarjeta gráfica

La tarjeta gráfica se ha muerto. Eso me pasó el otro día, para ser exactos el viernes 6 de enero, o quizás el 7, ya que como todas estas cosas pasan en los ratos de ocio (entre las 22:00 y las 3:00), nunca se sabe en que día estamos. ¡Viva la nueva tarjeta!
Pero es algo más complejo. El primer síntoma que apareció fue unos saltos raros entre páginas en Chromium, así que fue el primer culpable al que achacar todo el problema. Sin embargo, eliminado Chromium por las malas (diferentes tipos de kill) el sistema se comportaba de forma aun más extraña, hasta que no pude hacer nada. Debido a mi impaciencia, ejecuté de la peor forma posible, con RESET. A partir de ahí ya no arrancó, ya que al no haber cerrado correctamente, los ficheros de configuración eran inconsistentes y el sistema quedaba en una pantalla inmóvil en negro tras varios errores. Decidí echarle la culpa a Fedora, con lo cual instalé OpenSUSE 12.1. Había leído que era la distribución con más novedades y muy estable (por ejemplo, está muy interesante esta entrada). Sin embargo, en cada instalación, solo se leía el inicio, y al cambiar a cualquier resolución la pantalla se quedaba en negro. Definitivamente la culpable era la tarjeta gráfica, nVidia antigua con la que había sustituido otra ATI que me había generado problemas de drivers en Fedora. Bien, pues estamos de nuevo con esa ATI (por ahora, unas 9 horas de uso intensivo, no me ha dado ningún dolor de cabeza más).
Mi experiencia sobre OpenSUSE ha sido educativa, pero algo dolorosa. Cambiada la tarjeta, y una vez que estaba con OpenSUSE, acabé de instalarlo. Lo que voy a explicar son solo mis opiniones, por si pueden ser útiles para algún lector:
- OpenSUSE es estable, funciona bien. Los puntos más positivo que he observado son:
1. YaST - ¿Cómo es posible que las demás distribuciones no tengan YaST? Esta aplicación-suma de aplicaciones es lo más cómodo y útil que he visto en mis 6 años de uso d eLinux. De Reyes -falta un año- quiero un YaST. Mágnífico el control de los repositorios, la configuración del cortafuegos... Da la sensación de que con YaST todo es posible.
2. Zypper - mágnífico. Muy rápido. Quizás algo menos explicativo que yum, pero mucho más rápido, así que no está mal.
3. Instalación desde DVD 64 bits muy completa; prácticamente no faltaba nada (incluido en la Linux Magazine nº 78).
4. Versión 2.31 de aMule -es preciso añadir el repositorio packman- frente a la 2.26 de Fedora. Muy buena esta nueva versión. Rar 4.01, frente al 3.96 de Fedora.
5. Lo siento, pero no he podido descubrir si Snapper es tan interesante como parece ser, por que instalé en ext4, y no en btrfs.

Puntos NEGATIVOS:
1. Kernel 3.10, frente al 3.17.1 de Fedora.
2. Imposible el funcionamiento de Chromium, debido a que faltaba una librería en 64bits que no pude encontrar forma de instalar.
3. Instalación de R versión 2.13 (en Fedora ya estaba con la 2.14.1), teniendo que buscar un repositorio especial, sin que pudiera funcionar, ya que también faltaba una librería (libc.so.6 - GLIBC-2.15, nada menos) de 64bits. Como este programa para mi es muy importante, busque muchas formas de instalarla y al hacerlo, rompí la consistencia de esta librería fundamental, con lo que el sistema no arrancó más (solo unas pocas horas de prueba). Da la sensación de que debemos probar la versión de 32bits para evitar este pequeño infierno de dependencias.

Como es natural, lo he resulto volviendo a Fedora 16 (gracias, Fedora). En 50 minutos, todo preparado. Esperemos ahora que la tarjeta gráfica no me de más disgustos.