jueves, 28 de febrero de 2013

Este es el año de Linux.. ¿o quizá tampoco?

 
En mi revisión de blogs encontré ayer esta entrada de Usemos Linux. En ella se relata como en los últimos meses han caído muchos blogs que eran referentes en la comunidad Linux. Envié un comentario, pero no lo encuentro, así que he decidido incorporarlo aquí. No solo se han cerrado blogs. En los últimos meses he visto como han desaparecido revistas "oficiales" en español. Por ejemplo, la primera fue Linux+ (de eso ya hace años). La segunda señal fue la disminución de grosor de Ubuntu Users versión española respecto a la versión inglesa. En los quioscos y librerías se puede ver como la antigua línea de revistas de Linux se ha quedado en una o dos revistas, y han sido sustituidas por una gran cantidad de publicaciones para Mac. A partir de ahí he recibido mensajes de Android Users diciendo que van a reducir los números de la publicación por problemas de redactores (viene a decir que los redactores necesitan comer y tienen que trabajar en otras cosas). Simultáneamente también recibo un aviso de que los ejemplares anuales de Ubuntu Users se van a reducir a dos, asociados a la liberación de las versiones oficiales de Ubuntu (sumado a que la versión española trae unas 10 páginas menos que la inglesa). Por último, los dos últimos números de Linux Magazine, la última que aguanta, viene con una edición nueva más delgada y grapada.
Puede que este sea el año de Linux, pero la documentación en la red y las publicaciones en papel sobre este sistema están disminuyendo de forma palpable.
Yo lo asocio a que en los últimos años en los que me he metido en software libre siempre he estado leyendo a los mismos redactores, y la edad no perdona. Las nuevas generaciones quizá prefieran un sistema más directo, blogs, twitter, facebook para poner a nuestro alcance los conocimientos, pero a nivel de blogs está claro que no es así. Una última señal de que algo está pasando es que mucha de la información que obtengo se encuentra en los últimos meses en los foros de los proyectos de las distintas distribuciones, especialmente en los de Fedora, y mucho menos en los blogs que sigo o en otras fuentes de información. Bueno, siempre me han gustado los foros; hasta intenté generar uno hace muchos años. Solo falta volver a nuestras antiguas y añoradas News en las que aprendí mucho de informática cuando era "joven".
Será la crisis

miércoles, 27 de febrero de 2013

Últimas semanas. Fedora 18

En los últimos días no he traído nada nuevo en el blog por que he estado bastante ocupado instalando el sistema en mi ordenador principal. La historia ha sido más o menos así:
1. El 27 de enero instalaba en el ordenador principal Fedora 18


mediante FedUp.Las primeras impresiones las podéis leer aquí. Podría destacar especialmente los cambios que trae gnome 3.6 en Nautilus y los problemas iniciales con el repositorio de Dropbox. La actualización por FedUp hace que el inicio no muestre el panel gráfico que se ve al instalar de limpio, pero lo que llevó a una instalación nueva fue un bloqueo aleatorio del sistema gráfico, que me impedía refrescar la pantalla y podía ver en terminales que los programas gráficos estaban funcionando pero no podía acceder a ellos.
2. El 16 de febrero instalé de forma limpia Fedora 18. Seguía teniendo bastantes problemas, así que tuve que activar las teclas mágicas, cuya localización ha variado en Fedora 18. Se generaron nuevos problemas:
- Anaconda no pide nombre identificativo para el ordenador (o yo me salto algún botón sin darme cuenta), con lo cual aparece identificado como new-host (problema general que es fácil de solucionar, aunque lo descubrí después)
- Ciertos programas, pero especialmente aMule, se apagaban sin previo aviso, lo que me obligó a generar un script para reiniciarlo.
- Se generaba una cascada de dependencias entre programas, de tal manera que al llamar a un fichero de LibreOffice desde Nautilus, el fichero solo se abría al cerrar Nautilus. Para poder hacer funcionar otros, tenía que matar el terminal y finalmente era casi imposible trabajar con el sistema gráfico. En general solo me afecta en el movimiento de ficheros, ya que últimamente trabajo fundamentalmente en terminal. Aun así, en ocasiones el sistema gráfico estaba completamente bloqueado y tenía que trabajar en las pantallas de texto (de Ctrl+Alt 2 hasta 7) y, de hecho, tenía activa siempre la 2 para poder matar procesos gráficos que bloqueaban a otros mediante la identificación por top y uso intensivo de kill.
3. Como daba la sensación de que parecía haber una "herencia" de unas instalaciones a las siguientes, y pensando que el formateo del disco de sistema no era tal formateo, por que es un disco sólido, y aprovechando de que es bastante antiguo, lo cambié por un INTEL 520 de 60GB, que sale en un precio razonable, e instalé de nuevo Fedora de limpio. Me generó de nuevo un ordenador new-host, pero lo cambié con la orden

hostnamectl set-hostname --static

que descubrí aquí, ya que ahora el nombre está en  /etc/hostname y no en /etc/sysconfig/network.

Estado actual. Debido al cambio de disco, el sistema es mucho más rápido (se nota muchísimo); sin embargo, después de haberlo usado sin problemas varias horas, volvieron a aparecer dependencias de unos programas sobre otros. En general el proceso responsable parece ser nautilus, y una vez que un programa se niega a abrirse, hasta que se cierra nautilus nada parece funcionar. Como falta poco para el nuevo openSUSE 12.3, estoy pensando seriamente probarlo, incluido KDE. Si no me convence, lo que si tenemos en cuenta lo poco que me gusta KDE es casi seguro, me pasaré al que nunca falla, Debian Stable. Ya tengo preparado el 6.0.7 que salió el sabado, 23.Me va a costar, ya que he estado muy contento en Fedora. Las actualizaciones son muy rápidas y, hasta ahora, no he tenido problemas de estabilidad o seguridad. Además, tengo 5 ordenadores funcionando con Fedora 18 y solo el principal genera problemas (será por que es al que más le pido).

martes, 26 de febrero de 2013

Enlaces interesantes para gráficos en R

Revisando R-bloggers, un blog dedicado a R que leo habitualmente he descubierto unos artículos que puedes ser interesantes para ver las posibilidades que nos da R respecto a los gráficos. En el primero veo que no soy el único que ha encontrado la comodidad del uso de los gráficos vectoriales para ahorrarnos problemas de resolución; al mismo tiempo también destaca las limitaciones de Windows cuando utilizamos software libre que ha sido diseñado bajo condiciones muy diferentes a las de un sistema propietario como Windows. He encontrado en este artículo un aliciente más para usar software libre.
El segundo artículo que quiero destacar nos enseña las posibilidades reales de lograr gráficos muy atractivos visualmente en R.


Cierto es que tenemos que aprender al menos algunas nuevas rutinas y trabajar con comandos en terminal, pero ese aprendizaje nos conduce a lograr muchas más habilidades, competencias y conocimientos.

Merece la pena el esfuerzo.

miércoles, 20 de febrero de 2013

Impresoras de Red. Fedora 18 [ACTUALIZADO]

Había perdido la comunicación con las impresoras de red desde que instalé Fedora 18. Por supuesto, era un error mío, no de Fedora. Cuando instala, aunque mantengo sin formateo home, cambio el nombre del directorio de usuario antes de instalar el sistema, precisamente para evitar conservar la configuración anterior, que puede dar problemas de "incompatibilidad" en la distribución nueva. Y por eso mismo, pierdo la configuración del firewall. Por supuesto, siempre me acuerdo de los puertos de amule, pero me olvido de los servicios que deben estar activados para poder detectar las impresoras de red. En concreto, por si os pasa lo mismo, hay que activar en la guía gráfica del firewall

mdns
ipp
ipp-client
samba-client

Si aun así no somos capaces de detectar la impresora en la configuración del sistema, podemos usar este comando en el terminal (comprobar previamente si está instalado)

system-config-printer

y nos lleva a la ventana de configuración de impresoras característica de gnome. Le escribimos la ip (ipp://xxx.xxx.xxx.xxx) y la detecta inmediatamente. Se indican el modelo, carga los drivers y listo.

El problema en este caso es la poca memoria que tenemos de lo que hacemos, sobre todo cuando toca cada 6 u 8 meses.

ACTUALIZACIÓN
Entre todas las impresoras que he estado restaurando para mis equipos, una en concreto, una LaserJet3550n no respondía a la impresión después de haberla detectado e instalado los drivers. El problema es que esa impresora en concreto no admite el protocolo ipp. En impresoras antiguas, conectaros primero con ellas a través de la red y ver las características y que protocolos admiten. En concreto a esta impresora tuve que llamarla socket://xxx.xxx.xxx.xxx:9100 para que respondiera a mis órdenes de impresión. 

domingo, 17 de febrero de 2013

Reinicio automático de amule [ACTUALIZADO]

Bien; voy a empezar por la "historia del arte" de esta entrada. Como indiqué en la entrada anterior, he instalado de forma limpia Fedora 18 en mi ordenador principal. La actualización dejó varios rastros indeseables. En primer lugar, Fedora arrancaba en una pantalla de formato antigua. Segundo, de forma aleatoria no era capaz de refrescar el sistema gráfico aunque los programas seguían funcionando si los controlaba en una pantalla de texto con top. El arranque es ahora con una pantalla más gráfica y visualmente atractiva, pero lo segundo sigue pasando. Por ahora parece que lo he solucionado evitando el bloqueo de pantalla. Mi primo, técnico informático, me ha dicho que él ya había visto casos similares en gráficos HD3000 integrados en procesadores Intel, que eran incapaces de refrescar el sistema gráfico tras el bloqueo. También me ha indicado que eso se producía en escritorios gnome, y no en KDE, así que los que lo deseen, pueden evitarlo pasando su Fedora a KDE en la instalación.
Esta instalación ha generado otro problema. En el proceso configuré mal mi usuario, y en vez de solucionarlo adecuadamente, decidí borrar el usuario y sustituirlo por otro, sin darme cuenta de que así borraba el directorio completo de ese usuario. En resumen, 1,2TB perdidos. Lo importante es recuperable, ya que tengo la copia de seguridad que hice justo antes de la instalación, pero los ficheros ed2k que estaba en descarga, más directorios completos a los que les faltaba algún capítulo o el directorio que tengo compartido se han perdido completamente. Algunos ficheros no son recuperables, ya que eran versiones especiales que ya no conservo (ficheros de versiones originales que he remontado con sonido en español; ficheros que he recodificado pero que se mantenían para la gente que está interesada etc...). Otros, sin embargo, son recuperables bajándolos de nuevo. Bien, desde hace tiempo amule se cierra aleatoriamente, sin que supiera a que es debido. Los envíos a bugzilla no creo que surjan efecto, ya que amule no es un paquete mantenido por Fedora (como dice bugzilla cuando le envías el informe). Cuando le he inyectado 466 hash para intentar recuperar lo perdido, el programa ha decidido cerranse no de forma aleatoria, si no premeditada, y cada 10 minutos. Sin embargo, he encontrado la solución. En esta entrada de los foros de Fedora he leído esta respuesta que ha solucionado el problema. He copiado el texto en un script,


lo he nombrado reinicio.amule; le he dado permiso de ejecución (# chmod +x reinicio.amule) y ya llamo directamente a amule con él

$ . reinicio.amule




Como no encuentra amule, ya lo llama directamente


Cuando se genera una corrupción en amule, la detecta


y al cerrarse amule


lo llama de nuevo y ya está otra vez activo


He borrado los  ficheros por protección de datos, ya que se ve el nick de los ripeadores. Bromas aparte, he estado probando unas 10 horas y se ha cortado varias veces, recuperándose inmediatamente  alcanzando picos e subida de 3MB/s de forma bastante rápida. Un gran script, aunque personalmente, por desconocimiento no sea interpretarlo. Aun así, cubre mis necesidades. Solo me falta generar un ejecutable en aplicaciones y conectarlo a los favoritos. Muchas gracias a stevea, el nick del programador que ha generado las 6 líneas de código bash que nos ha sacado de este aprieto. La otra opción que tenía e mene era usar la versión amule-nogui, que no precisa sistema gráfico, por si la culpa, como casi siempre se debe a la máscara gráfica.

Actualización:
Y para que se vea que funciona, tras varias horas de funcionamiento desatendido, los informes de errores mostrados por ABRT fue este (y lo que no se ve).


Todos estos fallos suponen cuelgues continuados de amule con la recuperación inmediata gracias al script.
Por cierto, ya he generado un acceso directo y lo he puesto en favoritos, ya que ahora llamo a emule a través del script.

sábado, 16 de febrero de 2013

Fedora 18: cambios en la localización de sysctl.conf

Debido a problemas con el sistema gráfico, estoy instalando de manera limpia Fedora 18 en todos los ordenadores en que había usado FedUp. El problema sigue igual, pero eso es otra cuestión. Lo que he encontrado, que no me había dado cuenta hasta ahora, es que la localización del fichero de configuración del sistema ha cambiado. Fedora deja las teclas mágicas deshabilitadas. Como hasta ahora había actualizado con FedUp los ordenadores, seguían activas. Sin embargo, tras la instalación en limpio y repetirse un error en el sistema gráfico, he cortado mediante kill las aplicaciones activas pero no he podido "saltar" (AltGr+ImprPant+K) la máscara gráfica. He llamado al fichero /etc/sysctl.conf y me he encontrado con esto


Mirando en la red he viso que la configuración se localiza ahora en el fichero /usr/lib/sysctl.d/00-system.conf, así que lo he editado


Ahora voy a reiniciar y espero que todo funcione.

viernes, 15 de febrero de 2013

Instalando Windows, ¡otra vez!

Como ya he señalado en alguna entrada, algunas veces es necesario instalar Windows. Por desgracia, los problemas de los drivers del hardware nos obliga a recurrir a otro sistema. He recompuesto otro ordenador a base de trozos de máquinas viejas y he tenido que poner un Windows XP para un escáner Canoscan 8000f, que no es soportado por Linux. La verdad es que es una pena, por que este escáner cumple de sobra mis necesidades, pero no existe driver para poder usarlo.


Tampoco se puede instalar en Windows 7, así que no puedo usar el portátil. Por suerte, esta vez dispongo de más RAM, ya que tengo dos piezas de 1GB de un ordenador que se estropeó y la captura va algo más fluida que cuando solo disponía de 768MB. He probado Vuescan para ver si lograba mayor calidad o facilidad, pero como el objetivo principal son diapositivas y negativos, Vuescan no limita parte de transparencia y el resultado final era poco satisfactorio, así que seguiré con el TWAIN, que es un sistema bien incómodo de comunicar dos máquinas. Como podemos ver en la wiki, "...Esto hace difícil proveer servicios TWAIN a programas ajenos al fabricante del dispositivo." Y es así, ya que he intentado con el software más sencillo posible, y evitar el consumo de recursos que no hay, pero al final he tenido que recurrir a Gimp para poder llamar al TWAIN.
Como reflexión final, esta es la debilidad de Linux. Los fabricantes de hardware dificultan la expansión de este sistema debido a la falta de drivers. Las dificultades de las tarjetas gráficas y WIFI, la dificultad de elección de impresoras y escáneres, provoca que mucha gente rechace un cambio a un sistema más seguro y fiable.

jueves, 14 de febrero de 2013

Como generar un lanzador gráfico de un script e incorporarlo a los favoritos en gnome 3.6

Esta entrada se debe a un comentario en una de las entradas anteriores, alrededor de la instalación de jdownloader en Fedora. La duda era sobre la forma más cómoda de llamar a JDownloader y la conveniencia o no de teclear. Para mi lo más cómodo y lo que hago habitualmente es buscar la línea de comandos en el historial, simplemente dando a la flecha superior. Para ello lo mejor es generar una única línea con los dos comandos

cd .jd && java -Xmx512m -jar JDownloader.jar

Sí, existen formas más cómodas de llamar a un programa, y a ello vamos.
Para no tener que teclear generamos un script en gedit, nano o con el editor de textos que queramos con los comandos y le llamamos por ejemplo j.


Una vez generada, tenemos que darle permisos de ejecución


Como se ve he puesto su (sin -), y así el administrador está situado en la carpeta personal del usuario que ha pedido la autenticación de administrador, y así no hay que jugar con directorios. Sí, sé que se puede hacer de forma gráfica, pero la verdad es que eso nunca lo hago a clics. Ya está; ya tenemos un script en la carpeta personal con permisos de ejecución a la que simplemente tecleando en terminal

. j

ya lanzaría jdownloader (que, por supuesto, hemos instalado antes según las instrucciones de aquí).

Sin embargo, para los que le prefieren los clics del ratón, vamos a generar un lanzador de aplicaciones de forma gráfica. La forma en terminal la ha explicado perfectamente hckorootx en esta entrada. La forma gráfica está explicada en esta página del proyecto Fedora.
Una vez que tenemos el script, generamos un lanzador en nemo (o nautilus, versiones 3.4 o anteriores); en el nautilus actual en gnome 3.6 no aparece esa posibilidad. Simplemente buscamos un área vacía en nemo y mediante el clic derecho de ratón pedimos "create launcher" (perdonar la foto, pero los capturadores de pantalla no capturan estas ventanas emergentes),


y aparece una ventana como ésta


que ahorra a los que odian el terminal tener que cubrir las líneas en gedit. Las rellenamos,


Y el resultado, visto en el gedit, es igual que el que obtiene el amigo hckorootx. Como podemos ver, aunque el nombre solo muestra lo que hemos escrito -jdownl-, el fichero creado tiene un "apellido" jdownl.desktop (lo digo por si luego se quiere editar y dice que no existe tal fichero; su verdadero nombre es con .desktop).


Aunque ya es perfectamente funcional y podemos cliquear sobre él y lanzar JDownloader, podemos ser más puristas y hacerlo visible con el resto de las aplicaciones. Para ello simplemente lo movemos (de forma GUI o CLI, según gustos) al directorio

/usr/share/applications

donde están los lanzadores. Y así ya está disponible en Aplicaciones y con el botón derecho podemos incorporarla a Favoritos, y lo tendremos en el Dash izquierdo.


Con esto espero haber ayudado a los que tienen respeto al terminal. Solo es necesario acudir al terminal una vez (y hasta se puede evitar). Reconozco que es más cómodo así, pero hay varias razones por las que conocer el terminal es muy útil. La primera, las facilidades gráficas cambian muy rápidamente -como ejemplo, nautilus en gnome 3.6- y lo que sabemos ahora puede no servir mañana. Los conocimientos del terminal suelen ser útiles mucho más tiempo. La segunda, cuando sistema gráfico de un ordenador genere problemas y nos encontremos con acceso solo a una pantalla de texto, ¿qué podemos hacer si no conocemos los comandos básicos y un editor de texto de terminal? Tener una chuleta con lo fundamental del terminal al alcance puede ser la salvación en algunos momentos.

Cuando tenga un rato, trataré de generar un lanzador por combinación de teclas, para hacerlo más fácil. Sin embargo, desde mi punto de vista, nada es más rápido que . j; solo cuatro teclas, (punto, espacio, j, Intro). Y aun así seguiré dando a la flechita hasta llegar a la línea con los comandos, por que soy un animal de costumbres.

viernes, 8 de febrero de 2013

Gráficos svg en R. Linux y Windows

La "calidad", medida en número de píxeles, tiene mucha importancia en la publicación de artículos científicos. Como ya he dicho muchas veces, en mi conversión completa a software libre, uno de los pasos más importantes ha sido el uso del paquete estadístico R. La generación de gráficos en R es compleja, ya que se obtienen por comandos, pero aun más complejo es su ajuste cuando se quiere cambiar la resolución. Debido a ello he estado valorando la posibilidad de extraer los gráficos en formato vectorial -svg-, lo que nos daría la opción luego de exportarlos a mapa de bits con los píxeles que queramos en cada momento sin pérdida de calidad. Leyendo en la red parecía imprescindible la instalación del paquete Cairo para la extracción de los gráficos en formato svg. Sin embargo, ha sido solo tiempo perdido, por que en Linux no es necesario. El libro R Graphs cookbook, de Hrishi V. Mittal, me ha aclarado esta y otras muchas dudas (la edición kindle es relativamente barata).
Si bien en windows es necesario la instalación del paquete Cairo para poder generar ficheros svg (a partir de ahora son funciones/comandos internos de R),

install.packages('Cairo') # Intalación del paquete
library(Cairo) # Activación del paquete en R

y luego para obtener el gráfico en svg ejecutaríamos las siguientes funciones (no he comprobado personalmente estos comandos por que no tengo windows):

CairoSVG('nombre.fichero.svg')
comandos del fichero
...
...
dev.off()

en Linux con un simple:

svg('nombre.fichero.svg')
comandos del fichero
...
...
dev.off()

se obtiene el gráfico.
El problema para mi fue que leía las notas de otros sin darme cuenta que la mayor parte de ellos usan Windows. Como de costumbre, en Linux es más fácil.
Ejemplo para ver que los comandos son más simples de lo que parecen; estos comandos,


dan como resultado algo como ésto,



pero en vectorial (la primera orden; para poder mostrarlo en el blog he tenido que hacer un png -la segunda serie de comandos- ya que blogger no admite svg). Pero solo en Linux. Los de Windows, no olvidarse de instalar paquete Cairo y luego llamarlo, para poder hacer lo mismo.


PD. "Save yourself from misery. Puege windows. Install Linux"


domingo, 3 de febrero de 2013

Manipulación de los documentos PDF en terminal

Como de costumbre un compañero me había enviado un documento para generar un PDF. Las fotocopiadoras de ahora nos generan un PDF en un momento, pero siempre hay que manipular los resultados. La que tenía disponible me generaba un PDF individual por cada página escaneada y las deja rotadas 90 grados a la izquierda. Tras la instalación de Fedora 18 algunas aplicaciones gráficas o daban algún error (pdfmod) o no estaban instaladas (pdf-shuffler). Por suerte, como ya he señalado en alguna entrada (1, 2), el terminal nos puede sacar del apuro. La aplicación pdftk nos permite manipular en línea de comandos -CLI- los ficheros PDF.
Lo más fácil en este caso es unir las diferentes páginas convertidas en PDFs individuales -8, en este cas0- y unirlas en un solo documento

$ pdftk 1.pdf 2.pdf 3.pdf 4.pdf 5.pdf 6.pdf 7.pdf 8.pdf cat output documento.pdf

luego rotar el documento completo (E representa East, que gira el documento 90 grados en sentido horario; S -South- lo gira 180 y W -West- 270. N, de North, no gira el documento)

pdftk documento.pdf cat -E output rotado.pdf


Los ejemplos del uso de pdftk los podéis observar en esta página, aunque par mi gusto son algo confusos. Es más fácil de entender algunos ejemplos de esta otra. Por supuesto, es más fácil con las aplicaciones gráficas, pero en algunas ocasiones pueden no responder, o algunos documentos generar problemas, o presentarse dependencias no resueltas u otro tipo de errores gráficos; en esos casos, estas aplicaciones CLI no suelen fallar y nos han salvado de algún apuro de última hora. ¿Qué hay mejor que un terminal? Pues dos, claro, o tres. De hecho en este momento tengo 4 en funcionamiento.

Fedora 18. Bloqueo gráfico y Backslide

He tenido un problema de bloqueo del sistema gráfico, además, tres veces seguidas. Al dejar de actuar sobre el ordenador y tratar de desbloquear la pantalla de bloqueo, queda el fondo sin ninguna posibilidad gráfica de interaccionar. Sin embargo, al llamar a un sistema de texto (Ctrl+Alt+ F2 o F3...) y activar top se puede ver que el sistema continúa en funcionamiento. No he encontrado la forma de llegar a la forma gráfica de nuevo. Puedo llamar a Ctrl+Alt+F1, pero solo sale un escritorio vacío sin acceso a las aplicaciones activas en algún otro sitio virtual. En general siempre he recuperado mediante las teclas mágicas (AltGr+Imp Pant+REISUO). Teniendo en cuenta el retraso que en ocasiones había observado en los momentos de cambio de fondo generado por la extensión Backslide, decidí desactivarla. Una vez desactivada, no se me ha vuelto a bloquear el iema gráfico. Lo lamento, por que me gustaba el cambio de fondo, pero es preferible evitar un bloqueo aleatorio que ver un cambio de fondo, por bonito que sea. El sistema registra varios fallos también de kernel, de los que he informado en bugzilla. No son de extrañar, por que estamos usando un kernel beta


Como se puede ver, el kernel es 3.7.4-204.fc18.x86_64; el 7 es impar, teóricamente una versión beta (impares=beta). Sin embargo, no puedo arrancar con la versión 3.6.11-xxx por que no me reconoce todas las resoluciones de la pantalla