El proveedor de red que me permite e-comunicarme con matrix ofrecía la posibilidad de doblar la velocidad de red por un euro. Debido a nuestro afan de ser tan matrix como el que más decidí aceptar. Sin embargo la condición era cambiar a un nuevo router N, un Hitron BVW-3653 (el modelo lo supe después).
Llegan los técnicos, se llevan el modem que tanto servicio le ha dado... al router que ponía después y me ponen esa ... cosa.
El resultado ha sido una red más rápida y completamente abierta sin protección alguna (ni siquiera una simple encriptación WEP). Además, mientras no descubra otras posibilidades, este cablerouter se configura de forma totalmente gráfica, casi sin posibilidades. Además, mirando en la red se puede ver que presenta errores en el enrutado, y que su potencia de emisión inalámbrica es escasa.
Por lo tanto he decidido aplicar una solución drástica; me he comprometido a mantener esta "cosa" 6 meses, pero a cambio he ganado una red de 30 Mbits. Para poder convivir con esa situación, he anulado la emisión WIFI de este router y cambiado el usuario y las palabras de entrada; he cableado directamente el ordenador principal al que he puesto en zona desmilitarizada, y sí, hay 30Mbits -o más, por que en ocasiones la red pasaba de 4MB/s (4*8=32). Tres, en la segunda salida de cable (y aun le quedan dos) he conectado mi antiguo linksys, con lo cual no he tenido que configurar una nueva red inalámbrica, ya que sigo aplicando la configuración anterior. Además, tengo una segunda ventaja. Cuando no se usan los equipos adicionales (otros ordenadores, WD TV Live y Play Station), se puede apagar el router. ¡Fantástico!, no hay Hitron que por bien no venga.
Habrá que buscar en la red si existen firmwares libres para este router.
PD. No sé por que el que es considerado como el mejor proveedor de red de España reparte dispositivos tan malos.
jueves, 16 de febrero de 2012
miércoles, 15 de febrero de 2012
Discos de más de 2TB. Posibilidades de uso
El día que me enteré de las inundaciones en Tailandia fui corriendo a mi tienda habitual de material informático a comprar discos duros, y solo me vendieron uno, con lo que hice un recorrido "amplio" por la ciudad y me compré 3, por si tenía luego problemas de suministro. Apresuradamente compré dos unidades de más de 2 TB, que eran inútiles en mi antigua unidad WDTV. Después de haber comprobado que el firmware no se ha cambiado en mucho tiempo, y que por tanto es un dispositivo sin futuro, lo he transferido a otra televisión y en la que se usaba habitualmente he instalado un nuevo WD TV Live. Este nuevo dispositivo sí lee los discos de más de 2TB, así que ahora solo nos queda decidir la forma en la que se van a usar.
Como es sabido, las tablas de partición basadas en MBR (Master Boot Record), la famosa partición msdos que llevamos haciendo desde ya no se sabe cuando, no permiten particiones mayores de 2TB, por diferentes razones que en vez de explicar aquí serán más fácil de entender si las miramos aquí. El resultado final es que tenemos dos discos de 2,5 TB (WD Elements) y 3TB (WD My Book) al que tenemos que darle uso.
El uso de estos discos como arranque genera un problema en la BIOS, que tiene que ser capaz de arrancar en formato EFI (Extensible Firmware Interface), en vez de MBR, ya que así podemos utilizar tablas de partición GPT (GUID Partition Table). Es decir, debemos poder cambiar el tipo de arranque en la BIOS. En mi caso no me preocupa. Primero, uso discos de sistema de 30GB y 34GB en mis ordenadores principales. En los demás no uso nunca discos muy grandes (trabajo, pasó el resultado a Dropbox y punto). Mi principal objetivo para estos discos es almacenamiento. Para ello he probado diferentes formas de distribuir los discos:
1. Lo más sencillo es hacer dos particiones, de tal manera que ninguna tenga más de 2TB. Me surge la duda de si eso es posible si la partición se realiza en sectores de 512 bytes, ya que en ese caso chocaríamos con el límite de número de sectores (ver de nuevo aquí). De todas maneras, ahora la partición estándar en gparted es ahora en sectores de 4096 bytes, así que no tenemos ese problema. En este caso el disco de 2,5TB fue particionado tipo msdos (MBR), con dos particiones inferiores a 2TB
El dispositivo WD TV Live como se ve lee perfectamente las dos particiones y sus ficheros. Por supuesto, no es posible ni ext3, ni ext4. El dispositivo solo lee fat, fat32 y NTFS.
Es decir, una forma de usarlos para simple almacenamiento sería particionarlo "tradicionalmente" con dos particiones (o más) inferiores a 2TB. Para asegurar, formatearemos con sectores de 4096 bytes o más.
2. Por supuesto, lo más adecuado -o quizás no- sería particionarlo una sola vez en una tabla GPT. Lo he aplicado sobre el disco de 3TB y por curiosidad he aplicado inicialmente un formateo en ext4. El dispositivo detectaba el disco,
pero era incapaz de encontrar los ficheros.
Sin embargo, con la tabla de partición GPT, pero formateado a NTFS, el dispositivo lo lee perfectamente
Esto nos da una segunda opción; una tabla de partición GPT con una sola partición (o varias si se prefiere). La decisión depende de varios factores. Sin embargo, por comodidad, seguridad y compatibilidad, quizás lo más adecuado en este momento sea hacer dos particiones o más del disco, ya que un fallo en una partición podría no afectar a la otra y se podrían salvar al menos la mitad de las copias priv..., quiero decir de las manzanas (más de una cesta) y en una tabla MBR.
El uso de las particiones GPT para arranque no es, por ahora, algo que me preocupe, ya que tiendo a utilizar el disco más pequeño que encuentro para el sistema. En estos momentos uso discos sólidos para eso, ya que ahora mismo empieza a ser muy difícil conseguir un disco magnético menor de 1 TB, y prefiero tener separados el sistema y home.
Eso sí, lo reconozco, y se ve en las fotos; he particionado de forma gráfica, a través de gparted. Para los que prefieran hacerlo de forma manual, puede ser útil esta entrada. Sin embargo, una vez particionado y formateado queda asignado al grupo root (gparted solo actua desde root), y el cambio de grupo y los permisos se hicieron en terminal (chgrp y chmod). Son costumbres de trabajo. Sea como fuere, ambos discos funcionan, son utilizables en el ordenador (casi 4 años, no precisamente de hoy) y el WD TV Live también los lee. Tenemos estas opciones y funcionan.
Como es sabido, las tablas de partición basadas en MBR (Master Boot Record), la famosa partición msdos que llevamos haciendo desde ya no se sabe cuando, no permiten particiones mayores de 2TB, por diferentes razones que en vez de explicar aquí serán más fácil de entender si las miramos aquí. El resultado final es que tenemos dos discos de 2,5 TB (WD Elements) y 3TB (WD My Book) al que tenemos que darle uso.
El uso de estos discos como arranque genera un problema en la BIOS, que tiene que ser capaz de arrancar en formato EFI (Extensible Firmware Interface), en vez de MBR, ya que así podemos utilizar tablas de partición GPT (GUID Partition Table). Es decir, debemos poder cambiar el tipo de arranque en la BIOS. En mi caso no me preocupa. Primero, uso discos de sistema de 30GB y 34GB en mis ordenadores principales. En los demás no uso nunca discos muy grandes (trabajo, pasó el resultado a Dropbox y punto). Mi principal objetivo para estos discos es almacenamiento. Para ello he probado diferentes formas de distribuir los discos:
1. Lo más sencillo es hacer dos particiones, de tal manera que ninguna tenga más de 2TB. Me surge la duda de si eso es posible si la partición se realiza en sectores de 512 bytes, ya que en ese caso chocaríamos con el límite de número de sectores (ver de nuevo aquí). De todas maneras, ahora la partición estándar en gparted es ahora en sectores de 4096 bytes, así que no tenemos ese problema. En este caso el disco de 2,5TB fue particionado tipo msdos (MBR), con dos particiones inferiores a 2TB
El dispositivo WD TV Live como se ve lee perfectamente las dos particiones y sus ficheros. Por supuesto, no es posible ni ext3, ni ext4. El dispositivo solo lee fat, fat32 y NTFS.
Es decir, una forma de usarlos para simple almacenamiento sería particionarlo "tradicionalmente" con dos particiones (o más) inferiores a 2TB. Para asegurar, formatearemos con sectores de 4096 bytes o más.
2. Por supuesto, lo más adecuado -o quizás no- sería particionarlo una sola vez en una tabla GPT. Lo he aplicado sobre el disco de 3TB y por curiosidad he aplicado inicialmente un formateo en ext4. El dispositivo detectaba el disco,
pero era incapaz de encontrar los ficheros.
Sin embargo, con la tabla de partición GPT, pero formateado a NTFS, el dispositivo lo lee perfectamente
Esto nos da una segunda opción; una tabla de partición GPT con una sola partición (o varias si se prefiere). La decisión depende de varios factores. Sin embargo, por comodidad, seguridad y compatibilidad, quizás lo más adecuado en este momento sea hacer dos particiones o más del disco, ya que un fallo en una partición podría no afectar a la otra y se podrían salvar al menos la mitad de las copias priv..., quiero decir de las manzanas (más de una cesta) y en una tabla MBR.
El uso de las particiones GPT para arranque no es, por ahora, algo que me preocupe, ya que tiendo a utilizar el disco más pequeño que encuentro para el sistema. En estos momentos uso discos sólidos para eso, ya que ahora mismo empieza a ser muy difícil conseguir un disco magnético menor de 1 TB, y prefiero tener separados el sistema y home.
Eso sí, lo reconozco, y se ve en las fotos; he particionado de forma gráfica, a través de gparted. Para los que prefieran hacerlo de forma manual, puede ser útil esta entrada. Sin embargo, una vez particionado y formateado queda asignado al grupo root (gparted solo actua desde root), y el cambio de grupo y los permisos se hicieron en terminal (chgrp y chmod). Son costumbres de trabajo. Sea como fuere, ambos discos funcionan, son utilizables en el ordenador (casi 4 años, no precisamente de hoy) y el WD TV Live también los lee. Tenemos estas opciones y funcionan.
viernes, 10 de febrero de 2012
WD TV Live
He sustituido mi antiguo WDTV con un nuevo WD TV live. Una vez configurada la red inalámbrica señala el posible cambio de firmware; supongo que si está cableado lo mostrará inmediatamente. Además, y eso es lo más importante para mi, y la razón por la que lo compré, lee perfectamente los discos de más de 2TB. Tiene capacidad de streaming, como se puede ver en la página de WD
y hasta se le puede conectar un teclado USB para navegar más fácilmente.
y hasta se le puede conectar un teclado USB para navegar más fácilmente.
martes, 7 de febrero de 2012
Fedora, cpulimit y discos NTFS
Debido a mis problemas con los discos NTFS decidí seguir los consejos de hckorootx (véase comentarios aquí). Esto nos lleva a algunos problemas. El primero, cpulimit no esta en los repositorios estándar de Fedora, así que nos queda instalarlo desde un paquete rpm (32 bits o 64 bits), o bien introducir el repositorio sphere. Por ejemplo, la forma más fácil es como administrador
$ su -
palabrita de administrador
# gedit
en ese documento pegamos el texto que podemos extraer de esos enlaces
[rpm-sphere]
name=RPM Sphere
baseurl=http://download.opensuse.org/repositories/home:/zhonghuaren/Fedora_16/
gpgkey=http://download.opensuse.org/repositories/home:/zhonghuaren/Fedora_16/repodata/repomd.xml.key
enabled=1
gpgcheck=1
y luego lo guardamos en el directorio de los repositorios (/etc/yum.repos.d) como rpm-sphere.repo.
Actualizamos (nos basta un simple # yum update y ya se recargan los repositorios) y lo instalamos directamente
# yum install cpulimit
Sin embargo surgen nuevas dudas a partir de aquí. Si nos fijamos en los comentarios de hckoroot, la forma más fácil de usar cpulimit es, en vez de identificar el comando a controlar por su PID, lo mejor es identificarlo por su nombre. Nos quedaría
cpulimit --path=/ruta/ejecutable --limit=N
lo que nos lleva a como copiamos:
- Si usamos cp en terminal, el comando es cp, claro
- Si usamos rsync, que a mi me gusta particulamente, el comando es rsync
El problema radica en que la mayor parte copiará con Nautilus, que lleva embebido los comandos, y no genera una nueva instancia para copiar, si no que todo lo que hagamos con Nautilus se hace dentro de la misma instancia. A eso se suma que el gran consumo del sistema al copiar en discos NTFS se produce no en la copia, si no en el propio manejo del NTFS a través de mount.ntfs. Por ejemplo este top copiando con Nautilus en un disco formateado NTFS:
Y si a ello le sumamos otras aplicaciones que consuman recursos, por ejemplo Chromium y aMule, llegamos al bloqueo del sistema
¿Podemos solucionarlo con cpulimit? Desde mi punto de vista no. Si el límite que le ponemos es sobrepasado, la aplicación deja de funcionar; si de corta mount.ntfs, probablemente perderemos el contenido que hayamos copiado en él, ya que no se guardarán las nuevas tablas, como ya me ha pasado a mi sin incluir cpulimit. Además, ¿cuál sería el límite? Como se puede ver en esa instancia, mount.ntfs estaba momentáneamente por encima de 50%; probablemente esté a veces por debajo y otras veces por arriba. Si llegamos hasta un 70%, ¿cuanto queda para lo demás?
Conclusión: una única recomendación para copiar en discos formateados en NTFS en Linux - paciencia y nunca hacer saltar el sistema. Mejor esperar. Un segundo apunte, que me aplico en estos momentos, copiar en lotes pequeños, como mucho 30-40GB, por que la paciencia tiene un límite y tendemos a ponernos nerviosos.
Si alguien quiere probar cpulimit en la copia sobre NTFS, que lo haga y nos diga que límite hay que poner. Yo prefiero aplicar la paciencia y no perder más material.
$ su -
palabrita de administrador
# gedit
en ese documento pegamos el texto que podemos extraer de esos enlaces
[rpm-sphere]
name=RPM Sphere
baseurl=http://download.opensuse.org/repositories/home:/zhonghuaren/Fedora_16/
gpgkey=http://download.opensuse.org/repositories/home:/zhonghuaren/Fedora_16/repodata/repomd.xml.key
enabled=1
gpgcheck=1
y luego lo guardamos en el directorio de los repositorios (/etc/yum.repos.d) como rpm-sphere.repo.
Actualizamos (nos basta un simple # yum update y ya se recargan los repositorios) y lo instalamos directamente
# yum install cpulimit
Sin embargo surgen nuevas dudas a partir de aquí. Si nos fijamos en los comentarios de hckoroot, la forma más fácil de usar cpulimit es, en vez de identificar el comando a controlar por su PID, lo mejor es identificarlo por su nombre. Nos quedaría
cpulimit --path=/ruta/ejecutable --limit=N
lo que nos lleva a como copiamos:
- Si usamos cp en terminal, el comando es cp, claro
- Si usamos rsync, que a mi me gusta particulamente, el comando es rsync
El problema radica en que la mayor parte copiará con Nautilus, que lleva embebido los comandos, y no genera una nueva instancia para copiar, si no que todo lo que hagamos con Nautilus se hace dentro de la misma instancia. A eso se suma que el gran consumo del sistema al copiar en discos NTFS se produce no en la copia, si no en el propio manejo del NTFS a través de mount.ntfs. Por ejemplo este top copiando con Nautilus en un disco formateado NTFS:
Y si a ello le sumamos otras aplicaciones que consuman recursos, por ejemplo Chromium y aMule, llegamos al bloqueo del sistema
¿Podemos solucionarlo con cpulimit? Desde mi punto de vista no. Si el límite que le ponemos es sobrepasado, la aplicación deja de funcionar; si de corta mount.ntfs, probablemente perderemos el contenido que hayamos copiado en él, ya que no se guardarán las nuevas tablas, como ya me ha pasado a mi sin incluir cpulimit. Además, ¿cuál sería el límite? Como se puede ver en esa instancia, mount.ntfs estaba momentáneamente por encima de 50%; probablemente esté a veces por debajo y otras veces por arriba. Si llegamos hasta un 70%, ¿cuanto queda para lo demás?
Conclusión: una única recomendación para copiar en discos formateados en NTFS en Linux - paciencia y nunca hacer saltar el sistema. Mejor esperar. Un segundo apunte, que me aplico en estos momentos, copiar en lotes pequeños, como mucho 30-40GB, por que la paciencia tiene un límite y tendemos a ponernos nerviosos.
Si alguien quiere probar cpulimit en la copia sobre NTFS, que lo haga y nos diga que límite hay que poner. Yo prefiero aplicar la paciencia y no perder más material.
jueves, 2 de febrero de 2012
Fedora. Habilitar sysrq
Desde que uso Fedora no he tenido una necesidad de usar nuestro famoso REISUO hasta hoy. sin embargo, en Fedora no están habilitadas las teclas "mágicas", así que no podemos usarlas. Es muy recomendable activarlas para no tener que reiniciar con la tecla de Reset como me ha pasado hoy a mi. Es sencillo editando de nuevo sysctl.conf:
- Terminal; nos identificamos como administrador
$ su -
palabra
# gedit /etc/sysctl.conf
y ponemos el valor de 1 a kernel.sysrq
tras el reinicio ya están disponibles las teclas mágicas (y REISUB/O).
- Terminal; nos identificamos como administrador
$ su -
palabra
# gedit /etc/sysctl.conf
y ponemos el valor de 1 a kernel.sysrq
tras el reinicio ya están disponibles las teclas mágicas (y REISUB/O).
QR ¿y en el móvil?
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:
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.
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)
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.
$ 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.
Suscribirse a:
Entradas (Atom)