Aviso de cookies

lunes, 7 de abril de 2014

El cierre Ubuntu One, como usuario registrado nunca interesado

Quizá sorprenda que un usuario registrado de Ubuntu One no haya hablado antes del cierre de Ubuntu One. Simplemente, son un "lo que sea" registrado, pero no usuario. Lo utilicé en sus inicios, en 2009, por que utilizaba Ubuntu. Sin embargo, me dio más de un dolor de cabeza, y nunca conseguí en él las prestaciones que había logrado en Dropbox y sus sincronización en aquellos momentos eran "problemática". En estos momentos, como reconocen en el aviso de cierre, no son capaces de mantener una oferta con los volúmenes que los usuarios reclaman, y hasta donde yo he sido testigo de su funcionamiento, no tenía las posibilidades que otros ofrecen. Por supuesto, supongo que generan un gran problema para todos los usuarios que hayan confiado en Ubuntu One como almacenaje on-line, pero a mi, personalmente, no me preocupa, ni me afecta. De hecho, usando otra distribución (Fedora), y en absoluto interesado por nada que ocurra en el "universo Canonical" (un charco, diría yo) hasta he tardado en saberlo (hasta que he recibido el aviso de cierre por parte de Ubuntu). Reconozco que estaría interesado en un almacenaje on-line más parecido a Linux, pero no tengo tiempo ni fuerzas para sustituir a Dropbox, que es como mi "piel digital".





Adiós Ubuntu One. Perdona que no lloremos.

PD. Sí, ya sé que muchos piensan que no me gusta Ubuntu. Pues no es cierto, la distribución me gusta, pero la política de Canonical no.

jueves, 3 de abril de 2014

La importancia de seguir las indicaciones del sistema. e2fsck

Como había indicado hace 2 semanas, tenía un problema en el arranque del sistema. En el arranque me aparecía un mensaje de arranque en modo de memergencia

"Welcome to emergency mode! After logging in type "journalctl -xb" to view system logs, "systemctl reboot" to reboot, "systemctl default" to try again to boot into default mode."





que me obliga a comenzar siempre con Ctrl+D.
Siempre atribuí el error a un quinto disco que había introducido en el equipo, pero cuando estuve reparando la conexión del cable SATA no se corrigió el aviso. Finalmente, algo cansado, decidí leer los logs de arranque. En la línea 1700 (de un total superior a 2700) indicaba claramente que había algún error en la partición sdb1 (disco home) y que se debía aplicar e2fsck sobre esa partición.
Como no se debe realizar en una partición montada, arranque en un LiveDVD de Fedora y ejecuté e2fsck sobre esa unidad


e2fsck /dev/sdb1


y fue señalando algunos sectores e inodes en los que tuve que confirmar el arreglo (Fix?). Si queréis evitar unas cuantas y de "yes", al ejecutar el comando poner e2fsck -y /dev/vuestraparticion.

Y ya está.


Como de costumbre, si quieres hacer algo bien, lee los mensajes de error y hazlo como te dice el sistema.

martes, 1 de abril de 2014

Cambios en el blog. Reactivación de captcha

Respecto a cambios, me refiero a que acabo de activar el "odiado" captcha. Reconozco que es incómodo, y debido a la opinión de algún lector, lo había anulado. Sin embargo, esa anulación supuso, como yo me temía, la entrada de comentarios "spam"; al principio solo eran unos pocos a la semana, pero en estos mementos suponen alrededor de 50 al día. Para muestra, un botón:


Esos 48 son los de las últimas 20 horas. Si bien es cierto que blogger los filtra y los separa a spam, cada día tengo que estar eliminándolos y separando alguno bueno del medio. En ocasiones, muy raramente, blogger no los filtra bien y tengo que eliminarlos de las entradas, aunque tengo que reconocer que eso solo ocurría al principio. Aun así, me resulta muy molesto y me supone un tiempo del que no dispongo, así que he decidido recuperar el captcha, aunque a mi tampoco me gusta.


Otra de las razones de activar de nuevo el captcha es que los spam son cada vez más azules (solo hay que leer de lo que van casi todos) y aunque todos empiecen diciendo lo bueno que es el blog, prefiero ahorrarme el resto.

miércoles, 26 de marzo de 2014

Aunque parezca increíble, hoy me he comprado un libro sobre Windows.



Para ser exactos The Windows Command Line Beguinner's Guide. Parece una incongruencia, pero lo que ocurre es que cada día me siento más ignorante respecto al sistema operativo Windows. No es un grave problema, ya que no lo utilizo, salvo raras excepciones, pero cuando me preguntan sobre los problemas que tienen todos los días las personas que me rodean, me doy cuenta de que me estoy olvidando totalmente de la forma en que funciona ese SO que también fue el mío durante muchos años. Así que cuando tenga un rato libre, me leeré ese folleto para recordar viejos tiempos, y de paso conocer una parte que no usaba mucho cuando era "Windows User", sus comandos. Amazon tiene buen ojo (o me espía en la red) y debió darse cuenta de que necesitaba algo así y me lo ofreció a buen precio... ¿quién se iba a resistir?

PD. Así, de paso, recordaremos a MS-DOS. Los jóvenes no saben seguramente de que hablo, pero en otros tiempos era el sistema con el que hacíamos funcional los PCs (era un terminal puro y duro).

miércoles, 19 de marzo de 2014

Compresión y optimización de documentos PDF

He tenido un problema con un documento extraído directamente con un escáner. El pdf final presentaba una buena calidad de visionado, pero a costa de un tamaño excesivo. La solución podría haber sido extraer cada página, que no era más que una imagen, tratarla individualmente, y generar un nuevo pdf (como ya hemos hecho en ocasiones, empezando como aquí o aquí).



Como tenía que ser algo rápido, primero lo intenté haciendo una conversión a través de pdftk pasando de pdf a un documento ps de gran volumen, y luego reconvertirlo a pdf, que suele quedar más "ligero"

pdf2ps fichero.pdf resultado.ps

ps2pdf resultado.ps fichero.mas.pequeno.pdf

Si bien es cierto que logré una reducción de tamaño, y que el resultado mantenía mucha calidad, la reducción era solo del 20% y el documento seguía aun poco manejable para enviarlo por la red. Así que decidí aplicar el script shrinkpdf. La reducción fue espectacular, quedando alrededor del 8% del volumen original, pero era completamente ilegible. Finalmente, en este enlace encontré este script

#!/bin/bash

DPI=150
PDF_DESTINATION=""

help() {
echo "optimize_pdf help"
echo "-h : show this help"
echo "-d : (optional) output pdf document resolution, by default : 150"
echo "-s : pdf source file, this file must exist"
echo "-o : pdf output file"
}

full_path() {
if [ -z $1 ]; then
exit;
else
if [ `expr substr ${1:-a} 1 2` != "/" ]; then
FULL_FILE=`pwd`"/"$1
fi
fi
echo $FULL_FILE
}

isNumeric(){ echo "$@" | grep -q -v "[^0-9]" ;}

while getopts "s:o:d:h" flag
do
case $flag in
#Source : source file
"s")
PDF_FILE=`full_path $OPTARG`
if [ ! -e $PDF_FILE ]; then
echo "Please provide a valid source file"
exit=1
fi
;;
#Output : output file
"o")
PDF_DESTINATION=$OPTARG
;;
#Dpi : desired resolution
"d")
if [ -z `isNumeric $OPTARG` ]; then
DPI=$OPTARG
else
echo "Please provide a numeric value for your DPI"
exit=1
fi
;;
"h")
exit=1
;;
esac
done

#Is there a target file?
if [ -z $PDF_DESTINATION ]; then
echo "Please provide a file name for output"
exit=1
fi

#At least one error, we're not going any further
if [ $exit ]; then
help
exit
fi

pdftops \
-paper match \
-nocrop \
-noshrink \
-nocenter \
-level3 \
-q \
"$PDF_FILE" - \
| ps2pdf14 \
-dEmbedAllFonts=true \
-dUseFlateCompression=true \
-dOptimize=true \
-dProcessColorModel=/DeviceRGB \
-dUseCIEColor=true \
-r72 \
-dDownsampleGrayImages=true \
-dGrayImageResolution=$DPI \
-dAutoFilterGrayImages=false \
-dGrayImageDownsampleType=/Bicubic \
-dDownsampleMonoImages=true \
-dMonoImageResolution=$DPI \
-dMonoImageDownsampleType=/Bicubic \
-dDownsampleColorImages=true \
-dColorImageResolution=$DPI \
-dAutoFilterColorImages=false \
-dColorImageDownsampleType=/Bicubic \
-dPDFSETTINGS=/prepress \
- "$PDF_DESTINATION"


La guardé como texto plano y la ejecuté directamente

. optimize_pdf.sh -s input.pdf -o output.pdf

y con el conseguí una reducción al 25% y con un documento visible de forma aceptable. Como se puede ver, es fácil manejar alguno de los parámetros, aunque por la premura de tiempo no toqué nada. Cubiertas las necesidades en 1 segundo de computación.

¡Qué haríamos sin el terminal y sin los usuarios que dominan bash y nos regalan estas utilidades!

martes, 18 de marzo de 2014

Reinstalación por "Emergency mode". Sin solución, por ahora [ACTUALIZADA]

Desde el momento en que incluí el quinto disco en el ordenador he tenido un mensaje de Emergency mode

"Welcome to emergency mode! After logging in type "journalctl -xb" to view system logs, "systemctl reboot" to reboot, "systemctl default" to try again to boot into default mode."




que me obliga a comenzar siempre con Ctrl+D.
Después de reinstalar el sistema, con lo que de paso me he vuelto a gnome, el error sigue. Sin embargo ahora sé -o creo saber- cual es el origen. Según he revisado en la red, la razón fundamental para que systemd entre en "Emergency mode" es un error de montaje en uno de los dispositivos indicados en /etc/fstab. En la reinstalación he probado 3 discos distintos en la entrada 3 de la placa de entrada frontal y, a pesar de intentar repetidos arreglos, me ha dado error tras error en los discos introducidos a través de ese punto, tanto lo ponga en SATA 5 como SATA 6. Es resumen, espero que volviendo a fstab y comentando el dispositivo que no monta en arranque (hay que arrancar con el suelto y meterlo luego en caliente) espero repararlo, y a largo plazo pedir una camisa nueva para esa entrada.

[ACTUALIZACIÓN] Pues va a ser que no. fstab está bien y el error persiste. Cuando tenga tiempo tendré que revisar todos los logs. 

[ACTUALIZACIÓN 2] La solución, como es natural, es seguir las instrucciones del sistema. Leyendo los logs aparece un problema en la partición sdb1 (disco home) y recomienda e2fsck. Sencillo. Haré una entrada especial.

jueves, 13 de marzo de 2014

Una de manualidades y estaño

Se trata de una operación a corazón abierto de un ratón. Los síntomas eran muy graves; si bien la rueda permitía deslizarse y pulsar, los movimientos del ratón no se transmitían al monitor. El diagnóstico parecía claro; se habían soltado los conectores del emisor LED. Comenzamos la disección del paciente, y pudimos comprobar que así era. La luz no emitía salvo que se colocara correctamente




La solución más fácil era una eutanasia rápida y papelera, comprando uno nuevo. Pero en estos momentos es difícil encontrar ratones de portátil cableados (pequeños y de cable corto), ya que la moda lleva a inalámbricos, que además son mucho más caros.
Y por esas razones era preferible una recuperación del paciente. Para ello llamamos a un cirujano competente, hckorootx, curtido en la cirugía con estaño.
Por desgracia estaba rota las conexiones de cobre en la plancha, así que hubo que abrir una nueva conexión con cutter homologado y rascado fino (dilatación coronaria electrónica)



Y luego pegar de forma generosa el estaño para generar una nueva conexión (bypass)


Y listo


Cirugía rápida, indolora y de bajo coste. Le llevo más tiempo al ATS ayudante (yo mismo) volver a montar adecuadamente al paciente.

PD. El paciente ya está trabajando.

viernes, 7 de marzo de 2014

La "comodidad" del software propietario

Estos días unos cuantos compañeros me han pedido un curso acelerado y simple de R. Es decir, como entrar, como salir, como introducir datos y los comandos básicos, más algunos manuales para empezar a trabajar con este lenguaje estadístico y evitar otro software más caro, aunque quizás más fácil de empezar a usar.


A pesar de esto, mientras estoy preparando una guía para "dummies", me encuentro todos los días cómo estas mismas personas están trabajando con SPSS.


Nuestra Universidad ofrece este programa comercial para su uso interno. Por supuesto, SPSS es el paquete estadístico, de entre los que conozco, en el que más fácilmente se ejecutan órdenes, aunque no necesariamente donde más fácilmente se interpretan los resultados (sencillo "input", más complejo "output"). El problema fundamental está en que esa sencillez de hacer un análisis con dos clicks (a veces solo uno) hace parecer innecesario entender lo que estamos haciendo, con lo cual luego los usuarios básicos son incapaces de entender la salida. Peor aun, en ocasiones se aplican análisis equivocados, simplemente por que no saben que mecanismos internos ejecutan, y no conocen las características que deben cumplir las variables que entran en esos análisis.

Bien, es cierto que R, como programa que se ejecuta en un terminal, tiene una curva inicial más dura, o vertical, pero una vez superado este primer obstáculo, la propia rutina del programa nos obliga a saber lo que hacemos, al menos en parte, y nos ayda a entender más fácilmente lo que obtenemos, y cometer menos errores en la elección de las pruebas a realizar. Esperemos que tras el curso acelerado, al menos pueda hacer comprender este concepto.

Nos queda señalar que, como última contrapartida del software comercial, si por falta de presupuesto desaparece del portafolios de programas ofrecidos por las Universidades y administración, vamos a tener un problema grave si el personal no está preparado para usar otro software menos intuitivo, pero quizás más completo y versátil...

y además de libre, gratuito, mira tú.

jueves, 6 de marzo de 2014

Windows y el retorno de carro

En ocasiones los diferentes comportamientos de los sistemas operativos nos causan algunos problemillas. Como es bien sabido, Windows domina el mercado, y eso nos supone a los usuarios de Linux que tenemos que llevar todo nuestro material preparado para "otro" SO, ya que raramente encontraremos dispositivos con el nuestro. En general eso no es ningún problema, ya que es algo que llevamos siempre en mente, pero en ocasiones tenemos algunos "olvidos".
En este caso, aparte de la presentación habitual, transformada a PDF y proyectada por impressive, para evitar alteraciones de fuentes y descolocación de imágenes, llevaba ficheros de texto plano con comandos de R. La intención de llevar texto plano era que siempre en más seguro copiar los comandos desde un programa básico de texto plano y pegarlos en R que hacerlo desde un tratamiento de textos más complejo, ya que puede alterar algunos caracteres (comillas, por ejemplo). Como bien sabemos, Windows introduce un carácter de retorno de carro antes del que indica cambio de línea (CR + LF), como hacen Linux y Mac OS (LF). Eso significa que cuando se lee un fichero de texto plano de origen Linux en un bloc de notas sale algo parecido a esto (imagen forzada, pero nos sirve para la explicación)


Y así  es como que quedó a mi la lista de comandos cuando la quise enseñar. Y así la estaban viendo los alumnos en sus dispositivos. Para solucionar el problema la preparé para que llevara los comandos adecuados (CR + LF).
¿Cómo realicé el cambio? Lo intenté inicialmente mediante el comando sed (ver aquí más información), pero por alguna razón no me funcionaba, así que recurrí a unix2dos (que realmente está incluido en el paquete dos2unix). Simplemente instalamos el paquete

su -c 'yum install dos2unix'
   palabra admin

y aplicamos

unix2dos -n ficheroprevio.txt fichero nuevo.txt

y ya está. Fácil.


Más fácil sería si no me hubiera olvidado de estas cosas, que saberlas las sé, al menos algunas.




martes, 25 de febrero de 2014

Fedora, Libreoffice y libcmis. Una historia de impaciencia

Como todas las mañanas, ayer, 24 de febrero de 2014, actualicé mis ordenadores de trabajo.

su -c 'yum -y update'

En todos ellos recibí un mensaje, que recortado decía más o menos

---> Paquete libreoffice-core.x86_64 1:4.2.1.1-1.fc20 debe ser una actualización
--> Procesando dependencias: libcmis-0.4.so.4()(64bit) para el paquete: 1:libreoffice-core-4.2.1.1-1.fc20.x86_64
--> Resolución de dependencias finalizada
Error: Paquete: 1:libreoffice-core-4.2.1.1-1.fc20.x86_64 (updates)
           Necesita: libcmis-0.4.so.4()(64bit)
 Podría intentar utilizar el comando --skip-broken para sortear el problema

Nos indica que hay problemas de dependencias no resultas. Cada vez que ocurre un aviso como este, simplemente tenemos que ejecutar

su -c 'yum -y update --skip-broken'

y se actualiza los paquetes sin problemas de dependencias y los demás esperan.

--> Resolución de dependencias finalizada

Paquetes ignorados por problemas de dependencias:
    1:autocorr-en-4.2.1.1-1.fc20.noarch de updates
    1:autocorr-es-4.2.1.1-1.fc20.noarch de updates
    firebird-libfbembed-2.5.2.26539.0-8.fc20.x86_64 de fedora
    libabw-0.0.2-1.fc20.x86_64 de updates
    libe-book-0.0.3-1.fc20.x86_64 de updates
    libeot-0.01-1.fc20.x86_64 de updates
    libfreehand-0.0.0-3.fc20.x86_64 de fedora
    1:libreoffice-calc-4.2.1.1-1.fc20.x86_64 de updates
    1:libreoffice-core-4.2.1.1-1.fc20.x86_64 de updates
    1:libreoffice-draw-4.2.1.1-1.fc20.x86_64 de updates
    1:libreoffice-emailmerge-4.2.1.1-1.fc20.x86_64 de updates
    1:libreoffice-graphicfilter-4.2.1.1-1.fc20.x86_64 de updates
    1:libreoffice-impress-4.2.1.1-1.fc20.x86_64 de updates
    1:libreoffice-langpack-es-4.2.1.1-1.fc20.x86_64 de updates
    1:libreoffice-math-4.2.1.1-1.fc20.x86_64 de updates
    1:libreoffice-opensymbol-fonts-4.2.1.1-1.fc20.noarch de updates
    1:libreoffice-pdfimport-4.2.1.1-1.fc20.x86_64 de updates
    1:libreoffice-pyuno-4.2.1.1-1.fc20.x86_64 de updates
    1:libreoffice-ure-4.2.1.1-1.fc20.x86_64 de updates
    1:libreoffice-writer-4.2.1.1-1.fc20.x86_64 de updates

Y hoy por la mañana, día 25, al actualizar mis ordenadores de trabajo

su -c 'yum -y update'

.
.
.
---> Paquete libcmis.x86_64 0:0.3.1-8.fc20 debe ser actualizado
---> Paquete libcmis.x86_64 0:0.4.1-2.fc20 debe ser una actualización
.
.
.

Y listo.

El problema está en que entre ayer y hoy el twitter ha estado inundado de avisos de error, que donde se puede encontrar el maldito libcmis 0.4, que debe ser el maldito de todo. Basta con poner en google fedora libcmis y salen páginas y páginas de mensajes de usuarios desesperados por que no pueden actualizar la libreoffice a 4.2.
Bien; yo también estaba esperando la vesion 4.2, entre otras cosas por que por fin tenemos disponible las ecuaciones poligonales


Y se han añadido funciones estadísticas similares al "Analysis ToolPack" de Excel.


No era imprescindible, ya que esas funciones las tenía en gnumeric, pero es interesante añadir funciones similares a las de Excel y que sea más sencillo el cambio de MS Office a LibreOffice para los usuarios de Windows.

Pero de lo que se trata aquí es que podemos tener un poco de paciencia. En los años que llevo en Fedora estas dependencias no resueltas pasan frecentemente, debido a la velocidad de actualización de esta distribución. Este problema se suele resolver en 24-48 horas. ¿Qué podrían decir los usuarios de windows, que tienen que ir actualizando la LibreOffice por la fuerza y si se acuerdan? ¿O los usuarios de Debian?, que seguramente aun están en alguna versión estable 3.x.x.

Un poco de paciencia, por favor, y menos inundar el twitter con minucias.

PD. Y podríamos dar las gracias a los programadores de paquetes como apt-get y yum, que controlan las dependencias y nos hacen la vida (y las actualizaciones) mucho más fáciles. ¿Dónde van nuestros infiernos de dependencias y los viajes al infinito y más atrás en el árbol de las dependencias para instalar cualquier paquete?