martes, 31 de enero de 2012

Fedora y QR en terminal

Esta entrada se debe, fundamentalmente, a que el otro día encontré un código QR en uno de mis directorios y no sabía como leerlo en el ordenador, así que saqué de teléfono móvil y lo leí. De repente me dio la sensación de ridículo, tener que recurrir a un móvil para leer un código en el ordenador, y me puse a indagar otra forma de hacerlo. En primer lugar, ¿que formas tenemos de hacerlos?
La más sencilla, que había usado hasta ahora cuando necesité uno, es el creador de códigos QR de Chromium


Una forma on-line podría ser, entre otras ZXing


Finalmente me decidí por un comando en terminal, que me parece más rápido y sin necesidad de ayuda externa. Lo encontré en LinuxHispano. En este caso se trata de qrencode, que está disponible en los repositorios de Fedora (pero no está instalado por defecto; tenemos que instalarlo).


Es muy sencillo de usar, como se puede ver


Sin embargo, realicé varios intentos hasta que salió a mi gusto. Es recomendable leer el man y aplicar algunas variaciones sobre las características estándar. A la orden básica
$ qrencode -o archivo.png 'texto_a_incluir'
conviene introducir la opción -s con un número entero, que supone el número de píxeles que llevará cada punto (el número estándar es de 3). A mi particularmente me ha gustado 7 (si no la imagen es muy pequeña) y -m, con otro número, para marcar el grosor del marco. Por defecto aplica 4, pero a mi me gusta más con 2. En total queda, por ejemplo,
$ qrencode -o qrblog3.png -s 7 -m 2 'http://www.clopezsandez.com'
que nos daría esto


Pero el origen de todo no era la generación de los códigos QR, si no su decodificación. De nuevo podemos decodificarlos de forma on-line, por ejemplo de nuevo a través de ZXing


y existen librerías que nos lo permiten hacer en Debian, Ubuntu y otros derivados de Debian, como es libdecodeqr-examples, como nos describe LinuxHispano. Sin embargo esa aplicación no está disponible para las distribuciones rpm. Después de hacer varias búsquedas, descubrí aquí zbar, disponible en Fedora


y que ya estaba instalada (no sé si por defecto o al instalar algún otro paquete). Con una simple orden
$ zbarimg archivo.png
lo decodifica, sin necesidad de tener que recurrir a aplicaciones on-line, extensiones de los navegadores ni tener que sacar el móvil del bolsillo para leerlo; más fácil y rápido, como se puede ver:






miércoles, 25 de enero de 2012

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.

lunes, 23 de enero de 2012

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)


jueves, 19 de enero de 2012

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.

miércoles, 18 de enero de 2012

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.

martes, 17 de enero de 2012

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.

lunes, 16 de enero de 2012

¿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.

Actualización: como respuesta al primer comentario hoy, 7 de junio de 2012 sigue llamándose oowriter, al menos en mi distribución (Fedora 17, con kernel 3.4.0.1)



viernes, 13 de enero de 2012

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.

jueves, 12 de enero de 2012

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.

martes, 10 de enero de 2012

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.

lunes, 9 de enero de 2012

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.

jueves, 5 de enero de 2012

De software propietario a libre. Lectura de ficheros de SPSS y R

SPSS es uno de los últimos pasos que me quedan en mi abandono progresivo de Windows y los programas propietarios. De hecho, mi último manuscrito lleva toda la estadística en R, sin ningún problema (regresiones logísticas paso a paso (el famoso anglicismo "stepwise"); uso del criterio de información Akaike; métodos Mantel-Haenszel para detección de variables confusoras con generación de figuras aclaratorias...). Sin embargo, hoy me he encontrado con un problema; tengo que hacer estadística con unos datos que solo tengo disponibles desde ficheros sav de SPSS. La función read.spss() del paquete foreign encontró un error en un punto determinado y era incapaz de recuperar para R el resto de los datos a partir del error. Para aquellos que tengan este mismo problema, la forma más sencilla es utilizar el propio SPSS y exportarlos en una formato legible por algún programa del que se disponga; por ejemplo, exportarlos con formato Excel y leerlos con Calc de LibreOffice. Con esta o cualquier otra aplicación de hoja de cálculo (por ejemplo gnumeric también vale) podemos convertir ese conjunto de datos en un fichero de texto tabulado. Nosotros, no anglosajones, como usamos comas para separar los decimales, no podemos exportar a un fichero csv, pero un fichero de texto plano, columnas separadas por tabulado, con comas como indicador de decimales y con primera línea con nombre de variables incluido se puede leer directamente en R con una función -read.delim2()- así

datos<-read.delim2("fichero")

En mi caso no tengo a mi disposición en casa un ordenador con SPSS; en los otros ordenadores de trabajo, todos con Fedora 16, no he conseguido aun hacer funcionar las máquinas virtuales de VirtualBox con Windows XP preparadas para el uso de SPSS, así que estaba en un problema. Por suerte, el software libre está siempre ahí para sacarnos de los problemas. He recurrido a PSPP, la aplicación libre alternativa a SPSS. con él he podido abrir perfectamente los ficheros para luego poder usarlos en R (o en el propio PSPP, llegado el caso).
Respecto a la pregunta del millón, ¿de donde viene el acrónimo de PSPP? No existe esa respuesta; mirar aquí.

miércoles, 4 de enero de 2012

Disco duro bloqueado

Otra entrada sobre hardware, pero esta vez hardware informático de verdad. Antes de vacaciones me entregaron un disco duro, para ser exactos un Western Digital Caviar Green de 1 TB y 64 MB de buffer, modelo WD10EARX-00N0YB0, que al conectarlo a un ordenador mostraba solamente 33MB, según el software con que lo manejamos (palimpsest). La intención era descubrir si era posible recuperar el tamaño original.


Tanto este como otro disco idéntico "sufrieron" esta llamemos alteración tras intentar utilizarlos como disco de sistema en un ordenador con una placa ASUS. Lo digo por que al documentarme en la red para manejar este "poltergeist" informático encontré en muchos sitios que es un caso documentado de determinadas placas Gigabyte, que reconocen un tamaño erróneo en determinados discos por un error en la BIOS (33MB para discos de 1 TB, 500 MB para los de 1,5TB y 1TB para los de 2; véase aquí). ¿Cómo es esto posible? Quizá lo comprendamos mejor si leemos qué es realmente la HPA (Host -a veces Hidden- Protected Area) de los discos duros.
Segundo, extraño que sean 33MB, ya que si hemos realizado alguna acción inconveniente que provoca el bloqueo del disco duro, lo normal es que muestre 64MB, que es el buffer. A pesar de ello, seguí investigando que posibilidades teníamos, y en alguna página señalan la posibilidad de recurrir a programas escritos para acceder y manipular a bajo nivel los discos duros. Fundamentalmente recomiendan el uso de MHDD y con él aplicar la orden de uncut (o NHPA) a la propia HPA para que recupere su tamaño original ("return to factory size").
Yo, que no tengo diskettes en mis ordenadores, y que no me gusta quemar CDs, instalé una ISO de Ultimate Boot CD a través de UNetbootin en un Flash USB Kingston DataTraveler ELITE de 1GB (el más caro que me he comprado jamás; en sus momentos, el mejor lápiz USB que había visto; ahora se me ha quedado algo pequeño y solo sirve para estas cosas. Pongo la foto solo para fardar de él).
Tras arrancar desde Ultimate Boot CD, en este caso en un Aspire One, con el disco conectado a través de una caja externa USB,


simplemente seguimos estos pasos:
- vamos a HDD
- seguidamente Diagnostics
- MHDD
y en el ejecutamos uncut (o NHPA)

Sin embargo, después de ver muchas páginas, fundamentalmente ésta, y haber llegado hasta ahí y ejecutado esa orden, quedaron bastante claras varias cosas:
1. Los discos están protegidos por una palabra clave
2. Dicha palabra puede ser extraída, aunque muchos señalan que puede ser ilegal (ver aquí "HPA can also be used to store data that is deemed illegal and is thus of interest to government and police computer forensics teams" y en otros lugares; leer con atención aquí desde la primera página a la última).

En resumen, en esta página que recomiendo se explica como se aplican unos scripts en MHDD para extraer en hexadecimal el contenido de la HPA y que parte contiene la palabra de protección de 32 bytes. Si no se dispone de la palabra no se puede aplicar la orden "uncut" y da un error.

Además, teníamos otras dos posibilidades. aplicar programas de desbloqueo, como HDAT2 o hdparm (ver aquí) o utilizar palabras maestras que podrían funcionar (tomadas de aquí). Como no tenía muchas ganas de traducir un hexadecimal y extraer una palabra, estuve aplicando estas cuatro para discos WD.


WDCWDCWDCWDCWDCWDCWDCWDCWDCWDCW
WDCWDCWDCWDCWDCWDCWDCWDCWDCWDCWD
&'()*.WDCWDCWDCWDCWDCWDCWDCWDCWDCWDCWD
h2oinsyde

pero parecía que no funcionaban. Un poco cansado lo dejé así. A la vuelta de las vacaciones, hoy por la tarde, al terminar de trabajar, he colocado el disco en una entrada SATA de un ordenador y arrancado con el mismo lápiz, y al ir a MHDD aplique directamente tanto NHPA (uncut) primero como HPA (cut, señalando el extremo final de 2TB, que el programa señalaba como 1,953,625,168) después y en ese momento me di cuenta de que el disco no tenía protección; además, no se encontraba la palabra PWD en la parte de arriba del programa. El disco había quedado desbloqueado.
Esto nos presenta algunos problemas. No sabemos qué es lo que ha funcionado; puede que haya quedado desprotegido el otro día con alguna de esas 4 palabras (en teoría hay un límite de 5, y luego hay que reiniciar el ordenador). Otra posibilidad es que la conexión por SATA haya permitido ejecutar la orden "cut" (HPA). Otro problema es que no he grabado imágenes decentes de cada acción. Por suerte tenemos otro disco y esta vez intentaré hacerlo de forma seriada, paso a paso y foto a foto. Como todos sabemos, lo mejor es siempre cazar el segundo león, y no empezar por el primero.

PD. Sigo sin tener clara la ilegalidad de esta acción. Si uno compra un disco, y por un bug de una BIOS hay que comprar otro ¿quien es el dueño del disco? Pongo un ejemplo. Te compras un coche de 24000€. Como arrancas en frío dando acelerones el sistema eléctrico se bloquea, y como tiene una palabra clave que es ilegal aplicar, te tienes que comprar otro. La gente no protesta por que cuestan 100€, pero si no fuera así...



martes, 3 de enero de 2012

Uso intensivo de hardware

Sí, ya estoy de vuelta. Estas vacaciones he estado usando intensivamente diferentes dispositivos hardware, como ya he indicado otras veces (uno de mis muchos off-topic). Esta semana he utilizado fundamentalmente una sierra curva de filo doble para podar árboles (fresnos, esta vez) y una sierra japonesa de bolsillo para cortar pequeñas ramitas. Cuando he acabado con las ramas pequeñas y medianas, a las más grandes les hemos aplicado una motosierra de podar ligera. El resultado ha sido este.


El fin, por supuesto, es mejorar el crecimiento de los troncos evitando ramas bajas o la duplicación del mismo tronco. Como hay que limpiar la tierra para evitar incendios, luego hemos preparado la madera para leña, dejando lo más fino para desbrozar posteriormente con cadenas y deshacer las ramas pequeñas como materia orgánica para enriquecer la tierra.


Eso nos lleva a un segundo objetivo de la poda, la misma leña, que termina así.


Y esto, en los días de Navidad, pleno invierno, se agradece mucho. Esta leña, por supuesto, es la de la poda de hace dos años, por que antes de quemarla, tiene que estar seca, o no produce calor y arde muy mal.
Es decir, vacaciones bajo puro uso de hardware, y un gran gasto de kernel (el cuerpo, para aquellos que no estamos acostumbrados, acaba molido).
Y, por supuesto, Feliz 2012 a todos.