jueves, 30 de enero de 2020

Reordenar las pistas en un fichero mkv

En estas últimas semanas he tenido un pequeño problema en la manera de reordenar las pistas en ficheros matroska. Todo nace en que una de mis televisiones no lee formato flac de sonido. A los ficheros matroska con alguna pista de sonido con formato flac suelo extraerle la/s pista/s flac (para más detalles, ya lo hemos visto aquí):


mkvextract origen.mkv tracks x:salida.flac

y convertirlas a aac con soundkonverter, una máscara gráfica de diferentes conversores de audio, muy fácil de usar, que permite muchos tipos de codificación y facilita la configuración de la transformación con mucho detalle.
Una vez transformadas, simplemente inyectamos la pista aac en el fichero matroska a través de MKVToolNix Gui, de una forma gráfica y mucho más sencilla que mkvmerge.


Una vez insertada, la colocaba en la posición que deseaba simplemente picando con el ratón y moviéndola a mi gusto. Sin embargo desde hace alguna versiones no es posible recolocarlas de esta manera. No tiene más importancia, pero en ocasiones nos interesa colocarla en algún lugar particular, por ejemplo para que sea la segunda pista de sonido, justo después de la predefinida, o para que se pueda ver entre un montón de pistas, cuando por ejemplo hay muchos subtítulos. Pues ayer decidí comprobar por fin de qué manera se puede mover las pistas sin la ayuda del ratón. La forma más fácil es mantener pulsado Ctrl y ordenar mediante las flechas direccionales. Para más información para curiosos, os dejo el enlace a este vídeo que es bastante aclaratorio. No me han funcionado todas las maneras indicadas en él, pero ahora ya puedo volver a colocar las pistas como quiero. ¡Qué cosa tan sencilla y lo que he tardado en averiguar como funcionaba!

jueves, 16 de enero de 2020

Gnome 3.34 y los indicadores de las apps; se ven y ya no se ven

Aunque soy un usuario contento con las últimas versiones de gnome, la 3.34 ha traído algunos problemas de funcionamiento. El principal es la desaparición de los iconos de las aplicaciones en el panel superior. Eso viene de más atrás en el desarrollo de gnome, pero en la versión 3.34 dejaron de funcionar las extensiones que nos permitían seguir viéndolos, como TopIcon Plus. La extensión que estoy usando es KStatusNotifierItem/AppIndicator Support, pero ha aparecido un nuevo problema. El estado habitual al arrancar el sistema es el siguiente, con los iconos en el panel, como se puede ver,


y se pueden manejar los menús, como afirma la extensión kstatus...


Sin embargo, al ocultar el escritorio —Ctrl + L— y luego volver ha mostrarlo desaparecen


Un problema, sobre todo por que no estás seguro de que Dropbox esté conectado y tienes que comprobarlo. Al menos en mi caso desde que gnome está en la versión 3.34 no se me corta Dropbox, por que en la versión que acompañaba a Fedora 30 estaba todo el día ejecutando start dropbox, ya que desaparecía y a veces llegaba al trabajo y no estaba lo que había preparado en casa o al revés y acabé ejecutando casi como rutina ese comando antes de dejar cada uno de los ordenadores.
A esto se puede sumar que la extensión EasyScreenCast no funciona en gnome 3.34. Reconozco que son pequeños problemas, frente a lo bien que va ahora gnome respecto a versiones anteriores, pero molestan un poco.


martes, 7 de enero de 2020

Conversión de sonido TrueHD: la vieja confiable ffmpeg

En estos días de Navidad nos han dado muchas cosas, y entre ellas un fichero matroska de una de las películas que más me ha gustado en mi vida. Jamás había visto ninguna versión, original o copia, con esa calidad. Sin embargo, presentaba varías características que me hizo difícil verla como yo quería; primero, la pista del sonido en lengua original estaba en TrueHD 5.1; segundo, los subtítulos estaban en formato PGS (Presentation Graphic Stream subtitle format). Estos formatos no generan ningún problema en el ordenador, pero prefiero ver una película como esta con más calidad, con más tamaño y con un sonido mejor que el que puede generar un monitor de 24' con altavoces de 2W. Ninguna de las dos televisiones LG de las que dispongo pudo decodificar el sonido TrueHD ni los subtítulos PGS. Ya hemos explicado en una entrada anterior como se transforma un subtítulo PGS, que es una imagen, a un formato texto srt; sin embargo, como es un trabajo laborioso y como entre las muchas versiones de las que dispongo de esa película se incluye —incluía, por que ésta la ha sustituido—  una Versión Final con la misma duración con subtítulos srt extraje esos ficheros del mkv. Pero una cosa muy distinta es el sonido. El formato TrueHD ofrece un sonido sin pérdida de calidad en la compresión y no merecía la pena recurrir a un AC3 antiguo, con lo que el primer objetivo fue la transformación del TrueHD a un formato que mis dispositivos pudieran leer. La extracción siempre es sencilla utilizando mkvextract

mkvextract origen.mkv tracks x:salida.ingles.truehd

siendo x el número de pista que queremos extraer, y teniendo en cuenta que mkvextract empieza a contar sobre cero; es decir, si vídeo = 0, sonido español = 1, sonido inglés TrueHD = 2, PGS Español = 3...
La extracción fue la parte fácil. En general, cuando se trata de transformar un audio extraído de esa manera —en mi caso casi siempre para convertir FLAC a AAC—, utilizo soundkonverter, que es una máscara gráfica —GUI, de Graphical User Interface o a veces wrapper— de ffmpeg, software que lo convierte todo.


Sin embargo, soundkonverter no reconocía el fichero con sonido TrueHD, así que busqué alternativas en el mundo —en google—. Las opciones que aparecían eran:
- de truehd a flac con audiomuxer; es de windows y prefiero no pasar por flac (maneja 5.1?; la televisión más grande y gorda que tengo no lee flac...)
- popcorn mkvaudioconverter: y eto que é?
- eac3to

De todos ellos, incluso intenté usar eac3to en wine, pero faltaban codecs intermedios y no era capaz de construir adecuadamente el comando. Cuando todo falla, tendemos a recurrir a la vieja confiable, que nos soluciona todo; es decir, un simple comando de ffmpeg sin máscaras

ffmpeg -i sonido.in.truehd sonido.in.aac

y todo lo demás lo ajustó directamente ffmpeg. Vean al final de la entrada la salida en el terminal.
Además, al incorporar los subtítulos srt DESPUÉS de los PGS, las máquinas LG tampoco pudieron leerlos, así que finalmente eliminé los PGS. La pista TrueHD no la eliminé, simplemente añadí la aac después, por si algún otro dispositivo lo puede leer TrueHD en el futuro, o en alguna actualización de las LG tienen a bien incorporar este codec. Por cierto, el sonido TrueHD ocupa, para 1h58m 3,2GB, miestras que aac comprimido a máxima calidad —sí, con perdida, lo sé, pero FLAC no leen mis dispositivos y PCM ocupa hasta el infinito y más allá— ocupa la décima parte.

Qué no encuentras una solución nueva, ¡usa la de toda la vida!


Resultado del comando en el terminal
$ ffmpeg -i blader.in.truehd blader.in.aac
ffmpeg version 4.2.1 Copyright (c) 2000-2019 the FFmpeg developers
  built with gcc 9 (GCC)
  configuration: --prefix=/usr --bindir=/usr/bin --datadir=/usr/share/ffmpeg --docdir=/usr/share/doc/ffmpeg --incdir=/usr/include/ffmpeg --libdir=/usr/lib64 --mandir=/usr/share/man --arch=x86_64 --optflags='-O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -fexceptions -fstack-protector-strong -grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection' --extra-ldflags='-Wl,-z,relro -Wl,--as-needed -Wl,-z,now -specs=/usr/lib/rpm/redhat/redhat-hardened-ld ' --extra-cflags=' ' --enable-libopencore-amrnb --enable-libopencore-amrwb --enable-libvo-amrwbenc --enable-version3 --enable-bzlib --disable-crystalhd --enable-fontconfig --enable-frei0r --enable-gcrypt --enable-gnutls --enable-ladspa --enable-libaom --enable-libdav1d --enable-libass --enable-libbluray --enable-libcdio --enable-libdrm --enable-libjack --enable-libfreetype --enable-libfribidi --enable-libgsm --enable-libmp3lame --enable-nvenc --enable-openal --enable-opencl --enable-opengl --enable-libopenjpeg --enable-libopus --enable-libpulse --enable-librsvg --enable-libsoxr --enable-libspeex --enable-libssh --enable-libtheora --enable-libvorbis --enable-libv4l2 --enable-libvidstab --enable-libvmaf --enable-libvpx --enable-libx264 --enable-libx265 --enable-libxvid --enable-libzvbi --enable-avfilter --enable-avresample --enable-postproc --enable-pthreads --disable-static --enable-shared --enable-gpl --disable-debug --disable-stripping --shlibdir=/usr/lib64 --enable-libmfx --enable-runtime-cpudetect
  libavutil      56. 31.100 / 56. 31.100
  libavcodec     58. 54.100 / 58. 54.100
  libavformat    58. 29.100 / 58. 29.100
  libavdevice    58.  8.100 / 58.  8.100
  libavfilter     7. 57.100 /  7. 57.100
  libavresample   4.  0.  0 /  4.  0.  0
  libswscale      5.  5.100 /  5.  5.100
  libswresample   3.  5.100 /  3.  5.100
  libpostproc    55.  5.100 / 55.  5.100
Input #0, truehd, from 'blader.in.truehd':
  Duration: N/A, start: 0.000000, bitrate: N/A
    Stream #0:0: Audio: truehd, 48000 Hz, 5.1(side), s32 (24 bit)
Stream mapping:
  Stream #0:0 -> #0:0 (truehd (native) -> aac (native))
Press [q] to stop, [?] for help
[aac @ 0x55ed8a510b80] Using a PCE to encode channel layout "5.1(side)"
Output #0, adts, to 'blader.in.aac':
  Metadata:
    encoder         : Lavf58.29.100
    Stream #0:0: Audio: aac (LC), 48000 Hz, 5.1(side), fltp (24 bit), 394 kb/s
    Metadata:
      encoder         : Lavc58.54.100 aac
size=  341245kB time=01:57:36.85 bitrate= 396.1kbits/s speed=17.8x    
video:0kB audio:338984kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: 0.667078%
[aac @ 0x55ed8a510b80] Qavg: 418.332







viernes, 20 de diciembre de 2019

Retraso en el apagado del equipo. Esta vez 15 minutos

Para los que hayan leído la entrada anterior, vamos a presentar una variación. Como recordamos mi ordenador de casa tardaba 90 segundos en arrancar por que buscaba un dispositivo con una UUID que ya no formaba parte del equipo. Pues descubrí el viernes pasado —hace hoy una semana— que el de trabajo  tardaba 15 minutos en apagarse... si le dejara, claro. Por partes:
Lo descubrí el viernes por que el ordenador de trabajo solo lo apago cuando termino la semana de trabajo, que suele ser los viernes. Al salir, suelo actualizar la maquina y luego apagarla; salgo un momento después de la orden de apagado y a la vuelta veo el logo de Fedora dándole vueltas a lo de apagar. Antiguamente las distribuciones de Linux mostraban la ruta de arranque y apagado por líneas de comandos, y ahora prefieren que los usuarios no vean como funciona el sistema. Por suerte, eso se arregla dándole a la tecla ESC, y con ello se muestra la serie de ejecuciones que se están realizando. Es decir, al ver la pantalla esperando, le di a ESC y el mensaje es



por escrito
A start job is running for man-db-cache-update.service (2min 28s / 15min).

Es decir, el ordenador quería que me quedara en el trabajo 15 minutos más, sin pagar... lo apagué a machete. El lunes siguiente encendí el ordenador, lo actualicé y hice un reinicio, con el mismo mensaje al apagar el sistema. Estuve esta semana en los ratos libres buscando una solución. La mayor parte hablan de encendido, no del apagado y de la modificación de ficheros que en Fedora no existen, así que me preparé para este jueves —me tomé un moscoso para el viernes— y realicé la rutina; actualicé y luego reinicié y ... se apagó en no más de 8 segundos... ¿problema solucionado? Si es así, algo quedó colgando en alguna actualización, pero me extraña, ya que hice otra después y la situación se repitió. ¿Un bug en man-db que se corrigió en la actualización del jueves? no debiera, ya que lo nuevo se ejecutaría tras el reinicio; ¿sería entonces la actualización del lunes? supongo, o un poltergeist-systemd informático difícil de explicar Como no molesta más, lo dejamos por ahora pero tomamos nota por si se repite.

miércoles, 27 de noviembre de 2019

90 segundos de retraso en el arranque mientras el sistema busca un UUID inexistente

En las últimas semanas he tenido dos problemas en el ordenador y una curiosidad. La curiosidad la dejamos para después y los problemas los he solucionado ayer. ¿Dos problemas?, si el título solo habla de uno. Al solucionar uno ha desaparecido el otro. Los problemas eran, primero, que el ordenador mostraba ciertos momentos de congelación en fases cada determinado tiempo —20-30 segundos—; el segundo, que solo lo notaba al reiniciar el ordenador, lo que pasa solo por actualización de kernel, era que el sistema se paraba 1 minuto y 30 segundos buscando un dispositivo con un UUID —Identificador Único Universal— inexistente en mi sistema. Al arrancar notaba un tiempo en vacío; si le damos a ESC, en vez de verse el logo de Fedora aparece el protocolo de arranque y ahí se podía leer:

A start job is running for /dev/disk/by-uuid/9013.... (34s / 1 min 30s)

y tenía 90 segundos para leer el mensaje hasta que seguía el arranque, que si no fuera por esto tarda unos 30s. Al apagar también tardaba y aparecía el mensaje

A stop job is running for Disk Manager (7s / 1 min 30s)

Lo primero que hice fue comprobar los UUID de los dispositivos del equipo, así que edité fstab

su -c 'nano -$ /etc/fstab'

y ninguna de las particiones del disco del sistema (/, /boot, /boot/efi) ni los otros 4 discos duros tienen ese UUID.
Ademas, lo comprobé de nuevo con blkid, que muestra los atributos de los dispositivos:


su -c 'blkid'

así como

su -c 'lsblk -ff'

que lo deja más claro, ya que dibuja un árbol mejor distribuido. Y, como debería ser, tampoco coincide ningún dispositivo con ese UUID. Revisando la red en muchos sitios se achaca este problema a un cambio de swap y que el UUID nuevo no haya sustituido al antiguo. Sin embargo mi partición swap muestra el UUID que se le asigna por fstab y la swap funciona como podemos ver


Entonces, si no estaba en fstab, y no era un problema de swap, ¿de dónde venía la orden de buscar ese dispositivo? Me puse a buscar parte de la cadena en los ficheros del sistema

su -c 'grep -lir "9013ddb2" /'

y el resultado fue nulo. Luego revisé los logs, y tampoco apareció nada. Miré todo lo que pude sobre systemd, y nada. Así que finalmente acabé en /boot/efi/EFI/fedora/grub.cfg y ahí estaba:

... resume=UUID=9013ddb2-...

Primero, ¿por qué el sistema no me lo había mostrado al pedírselo?; será que el administrador no puede entrar en EFI...
Segundo, el grub.cfg no se debe editar directamente, como dice el mismo,

# DO NOT EDIT THIS FILE
#
# It is automatically generated by grub2-mkconfig using templates
# from /etc/grub.d and settings from /etc/default/grub

así que revisamos el fichero /etc/default/grub y los del directorio /etc/grub.d. Ninguno contenía ese UUID, así que ejecutamos

su -c 'grub2-mkconfig -o /boot/efi/EFI/fedora/grub.cfg'

y reiniciamos y arrancó en un suspiro.

El segundo problema era la congelación temporal del sistema. En algunos sitios había observado que se podía deber a mutter, y que ere error se había corregido para la versión 3.34.1.11, pero era la que tenía y seguía congelándose. Sin embargo, al reiniciar después de haber cambiado grub.cfg el sistema dejo de estar congelado, asi que asumo que cada 20 o 30 segundos el sistema seguía buscando un dispositivo inexistente.

Queda por satisfacer la curiosidad, que es sobre sudo. Si me pongo a ello, lo pondré en otra entrada.


lunes, 18 de noviembre de 2019

Lectores de tarjetas flash como unidades USB

Desde hace bastante tiempo usamos las tarjetas flash como almacén de datos. La primera que tuve fue una Memory Stick que acompañaba a una cámara Sony. Era una tarjeta de poca capacidad—32MB—, así que la sustituí por una Memory Stick Pro de 256MB, que para aquel entonces no estaba mal, ya que las fotos ocupaban alrededor de 1MB y podía sacar bastantes, muchas más que las que entraban en un carrete. Por cierto, conservo esas primeras tarjetas y aun funcionan pero la cámara ya no está conmigo. Las cámaras que siguieron al modelo Sony fueron todos diferentes modelos TZ de Lumix, y todas ellas utilizan tarjetas SD (Security Digital). La primera que tuve fue una Ultimate de Kingston de 2GB, el máximo que podía alcanzar una SD estándar (relegada hoy como unidad de lectura de un escáner de negativos). Presentaba por aquel entonces una velocidad de grabación de 120x, es decir 0,150MB x 120 = 18MB/s; poca cosa hoy en día, pero en las cámaras de aquel entonces permitía grabar vídeos muy dignos. A lo largo del tiempo he ido comprando tarjetas con mayor volumen de almacenamiento y mayor velocidad (SDHC y SDXC), hasta las últimas que tengo disponibles, de 128 y 256GB, clase 3 V30, que en teoría garantizan una escritura mínima de 30MB/s, aunque prometen mucho más.
Para leer esas tarjetas podemos hacer una lectura directa de la cámara, con los cable que suelen acompañar a esos dispositivos —no las he leído así jamás— o extraer la tarjeta de almacenamiento y leerla mediante diferentes tipos de lectores. En esta entrada mostraba diferentes modelos de lectores que he utilizado. La verdad es que son dispositivos que vienen para ser usados un número de veces, y luego fallan, incluso los de marcas conocidas y de garantía teórica —por ejemplo, Kingston, que me ha fallado alguno—. En estos momentos tengo un UGreen, hasta que falle. Sin embargo, hay otros dispositivos que podemos utilizar para leer las tarjetas, diseñados originalmente para las SD, por su tamaño más reducido frente a las CompactFlash y más corto que las MemoryStick, pero ahora también con las MicroSD; son las unidades USB con apertura para la tarjeta. El primero que tuve fue un modelo Kingston TravelLite SD Reader:


El objetivo que nos planteamos con este dispositivo fue probar el uso de las tarjetas SD como unidad de información protegida al usar una unidad USB  en un ordenador no controlado. Las tarjetas SD disponen de una pestaña de bloqueo que impide la escritura en ellas, y permite una protección que un dispositivo USB no presenta. La inseguridad que teníamos como usuarios de ordenadores de acceso público quedaba hasta cierto punto cubierta así. Ese modelo en concreto estaba diseñado para tarjetas SD estándar, pero cuando aparecieron las SDHC probamos otro modelo de DataTraveler Reader,


que además de leer las tarjetas, llevaba interno 1 o 2GB de memoria flash interna. Sin embargo, ¿de que servía proteger la tarjeta si se te infectaba la unidad USB? Después de diferentes pruebas abandonamos el uso de estos dispositivos y preferimos el uso de un repositorio en la nube, Dropbox para ser exactos.

Actualmente disponemos de tarjetas flash SDXC y microSDXC de hasta 512GB. Personalmente tengo unidades de hasta 256GB, SDXC y hasta 128GB microSDXC, pero no las uso en las cámaras o en el teléfono, por varias razones. En mi cámara Lumix TZ100 llevo una SandiskPro clase 10 U3 para que garantice una grabación de videos 4K, pero solo de 64GB —y otra de reserva—, por que esa tarjeta permite aproximadamente grabar 1500 imágenes en la calidad más alta combinada raw2 + jpg. Sí, es cierto, ya no estamos en la época de los carretes, que suponía un coste por carrete de aproximadamente 25-30€ de aquel entonces por carrete, por lo que en ningún viaje he usado más de 4 carretes (140-150 fotos dependiendo de como cargara el carrete la cámara, en doble vuelta o directo). Ahora el coste es la cámara y la tarjeta y no hay revelado, ni impresión a papel y da igual el número que hagas, pero nunca en ningún viaje o salida he pasado de 1500 fotos, así que a partir de 64GB sobra espacio, sobre todo por que llevo dos. Entonces, ¿para que necesitamos unidades tan grandes? Las uso como unidades USB. Es más barato conseguir una unidad de 256GB en SDXC o microSDXC que en un dispositivo USB. Y además hoy disponemos de lectores de tarjetas muy baratos que son carcasas USB. Por ejemplo tengo varias unidades Sandisk para leer microSD,


que funcionan muy bien. Además, para mayor cobertura tengo un dispositivo Kingston que me permite incluir simultáneamente una tarjeta SD y una microSD,



con lo que con las tarjetas de las que dispongo puedo llevar en una unidad 384GB. El inconveniente de la unidad Kingston es que las tarjetas salen hacia afuera y se pueden soltar fácilmente. Respecto a la unidad Sandisk, al caer al suelo, se puede soltar la tarjeta microSD (me ha pasado). Pero ahora he encontrado una unidad que evita esos problemas, el MagiDeal 5GBPS USB 3.0 Mini Lector de Tarjetas Micro SD/SDXC. Es un dispositivo USB en el que la tarjeta microSD se introduce en la base de lectura de una unidad USB


¿Qué puede haber más cómodo? Y al mismo tiempo el coste es menor que las unidades flash con las mismas prestaciones. Como inconvenientes, tanto de la unidad SanDisk como de esta última, es que son muy fáciles de perder; aun no he perdido nunca una, pero siempre estamos a tiempo. Otro problema es la duración de las unidades microSD. Las tarjetas SD que he tenido funcionan aun hoy TODAS, pero las microSD, sobre todo las que usamos en el teléfono, hemos tirado más de media docena.
En resumen, en estos momentos podemos utilizar las unidades SD y microSD como unidades USB, con menor coste, sobre todo por que en general tenemos unidades que ya no usamos en el teléfono o cámara y podemos darle una segunda vida; de hecho tengo una cajita llena de tarjetas que he dejado de usar por ser de volumen pequeño o por otras razones que tengo la intención de usar con estos dispositivos lectores USB.


Por cierto, la caja es de carretes Agfa, así que es muy antigua, de mis primeros carretes, por que luego usé Kodak Ektachrome, de más calidad, y luego Fuji NPH, con un color natural y grano muy fino a pesar de ser ISO400, y así se podían sacar incluso interiores con poca luz.
Último consejo, recomiendo formatear las tarjetas con exFAT, ya que el formato NTFS me está dando bastantes problemas últimamente. Las tarjetas de cierto volumen (64 o más) ya vienen así de fábrica.

martes, 5 de noviembre de 2019

Joystick Logitech F310 en Fedora 31

Estos últimos tiempos comentamos más sobre hardware que sobre software. Quizás se deba a que no profundizo más sobre software, por que no lo necesito, o por que ya quedan pocas cosas que decir en un Linux que está, desde mi punto de vista, bien asentado y cada vez con menos necesidad de ir a terminal. Es decir, otra de hardware. Hace unos meses, por curiosidad, compramos un joystick Logitech F310 para jugar con Cuphead a través de wine. En aquel momento no lo conseguimos, y ni siquiera recuerdo por qué. Ayer encontré de nuevo el joystick y estuve buscando qué era necesario para que funcionara adecuadamente. En muchas páginas señalan la necesidad de incorporar kernel-modules-extras, pero solo unas pocas indican que es necesario incorporar también joystick-support. Además, para ver si está conectado y funcionando recomiendan evtest.
Es decir, ejecutar

su -c 'dnf install kernel-modules-extras joystick-support evtest'

y sí funciona. Como ejemplo, el propio Cuphead:


Si algún usuario de Fedora no había conseguido su funcionamiento, a mi sí me va ahora; a ver si podemos ayudar.

miércoles, 30 de octubre de 2019

Actualización a Fedora 31 por comandos. Esta vez sí

Esta vez, al contrario que cuando lo intenté para hacer el salto Fedora 29 a 30, todo ha ido como la seda. Los mismos comandos de siempre:

su - # Terminal  en administrador para evitar teclear demasiado

dnf upgrade --refresh # Actualización del sistema (reboot, por que cambió kernel...)

dnf install dnf-plugin-system-upgrade # Plugin de actualización

dnf system-upgrade download --releasever=31 # Inicia la actualización y baja el software

dnf system-upgrade reboot # Reinicia y actualiza todo

Dos ordenadores; el primero alrededor de 2890 paquetes, 4,4GB, bajo los paquetes en 7 minutos (11MB/s, aproximadamente) y el segundo más de 2900 paquetes, 4,3 GB en 3 minutos y 20 segundos (23MB/s). Luego el primero tardó un total de 30 minutos en terminar toda la actualización. El segundo, a sabiendas de que iba a tardar más, por que es más viejo y lento, lo dejé con los comandos enlazados (&& si y solo si ha terminado bien el primero, ejecuta el segundo)

dnf system-upgrade download --releasever=31 && dnf system-upgrade reboot

y lo deje a su aire, con lo que no medí el tiempo. Los dos arrancan bien y el único defecto son algunas extensiones de gnome


y que no hay manera de ver el icono de Dropbox en el panel superior.

Solo me falta el portátil. Si hay alguna variación, actualizaré la entrada.

Ventajas: rápido, fácil, software instalado, no hay que modificar configuraciones...
Inconveniente: con lo que nos divierte instalar desde cero, particionar discos, faltarle al respeto a los programadores...
Sin un solo fallo. Casi vale la pena aplicar la actualización grafica para dummies en la aplicación software.

[ACTUALIZACIÓN:] El portátil igual de bien

sábado, 26 de octubre de 2019

Logitech G413. ¡Arriba los teclados mecánicos y olvidemos las membranas plásticas!

Pues así es. En mi ordenador personal había ido probando diferentes teclados hasta encontrar uno que me gustase. La razón fundamental siempre ha sido el tamaño, ya que no me gustan los teclados grandes ni que tengan apoyo de muñeca. El que he usado los último años —muchos, por cierto— en mi ordenador personal de casa era un Logitech K120, barato y pequeño. Al principio funcionaba adecuadamente, pero con el paso del tiempo me fueron fallando teclas al escribir. Al principio me faltaba sobre todo la e, luego el espacio, y últimamente la s y la a. La verdad es que lo fui soportando por que en el ordenador de casa escribo poco y hago más trabajo de edición multimedia; nunca han sido todas y de manera continua. Simplemente, si pulsas de manera un poco más débil, no aparecían. Sin embargo, este último mes he estado escribiendo más de lo habitual, y he tenido que revisar todos los textos por falta de caracteres. Harto de tanto tiempo perdido he estado pensando en que teclado comprar. Siempre he pensado que el culpable era la membrana de plástico que ha sustituido a los muelles, y recordaba con nostalgia los teclados mecánicos que usábamos antes, en el siglo pasado. Así que he buscado un teclado pequeño y mecánico, y sí, aunque lo dudaba, existen algunos modelos que cumplen esas características. Entre los pocos que encontré, analizando las opiniones dadas por sus usuarios, el tamaño de los modelos y otras razones, como el gusto personal, me he comprado un Logitech G413. No es ni el más caro, ni el más barato, pero es del tamaño que quiero y el que más me gusta.


Como se puede ver, es algo más pequeño que el K120. La razón fundamental para su adquisición es el mecanismo de marcado de las teclas, que Logitech llama Romer-G táctil. Foto publicitaria para verlo.


Y además, como es un teclado para gamers, sean quien sean esos seres, trae una novedad poco habitual, un juego de teclas de reserva —q w e r a s d 1 2 3 4 5— y un extractor; creo que aunque se han añadido para los gamers, supongo que también sirven para los simples mortales.
Tiene una superficie sobre la que se asientan las teclas de aluminio-magnesio pulido que le da un cierto peso, más de un quilo, que lo hace mucho más estable que los que he utilizado habitualmente. Las teclas están iluminadas, y creo que los del lado oscuro —Windows—, con la aplicación G HUB pueden controlarlas y hacerlas variar. Para mi en Linux hasta ahora solo han sido rojas, pero lucen bien y permiten escribir en oscuridad —yo, autodidacta en muchas cosas, nunca he sabido la distribución del teclado y solo uso dos dedos, así que necesito mirar con frecuencia—. Lo he estrenado con esta entrada y no me ha faltado ninguna letra; de hecho, me han sobrado algunas, por que las teclas son más altas que las del teclado anterior y estoy en período de aprendizaje.
Exijamos a las compañías de periféricos que ofrezcan más modelos mecánicos. ¡Arriba los muelles! ¡Abajo las membranas!

[ACTUALIZADO]: He recibido con un cierto retraso el ratón que había pedido junto al teclado, un G203. Ahora me dicen en casa que he montado una discoteca en mi estudio



martes, 15 de octubre de 2019

Otro poco de recorte de PDF

Antes de las vacaciones habíamos hablado de como obtener una copia digital de un manual de papel para evitar su deterioro (véase aquí). Hoy vamos a hacer una variación de esta técnica. Hemos vuelto de un congreso donde nos ha facilitado un libro de actas en papel —grapado, por cierto, no cosido—, y sin copia digital. Para justificar nuestra presencia, además de presentar las facturas y certificado de asistencia, siempre es interesante guardar una copia digital de los resúmenes de tus conferencias, que quedan como justificación para el futuro. Sin pensarlo mucho, escaneé directamente desde el libro, doblando como pude, y el resultado fue un fichero PDF A4 con un texto interior B5. En la otra entrada habíamos manejado con convert imágenes jpg, pero la aplicación de convert sobre un PDF puede generar una pérdida de calidad si no manejamos correctamente los argumentos, aparte de lo difícil que es cortar por el lado izquierdo, derecho y abajo. En general, lo podría realizar con pdf-shuffler, aplicación que llevo utilizando desde hace años para el manejo de los pdfs en linux. Sin embargo, pdfshuffler es una aplicación antigua python-gtk que hace de interfaz gráfica de python-pyPdf y depende de python 2; es más, no tiene mantenimiento desde hace bastante tiempo. En Fedora 30 se está haciendo una transición a python 3 y la librería python2-PyPDF2 no permite importar pyPDF2 como solicita shuffler (podemos ver aquí los errores). En resumen, pdf-shuffler no arranca:


Lo más sencillo es utilizar pdfarranger,


pero en esos momentos recordaba que en Fedora 29 pdfarranger no estaba en los repositorios habituales y había que incorporar un repositorio personal o COPR. Desde los últimos tiempos en que aun utilizaba Ubuntu, tengo muy malos recuerdos de los ppa, así que decidí buscar alternativas de terminal, a ver que había. En esta página describen, entre otras aplicaciones, pdfcrop. En Fedora requiere la instalación de texlive-pdfcrop:

su -c 'dnf install texlive-pdfcrop'

y luego ejecutar utilizando el argumento margins (--margins " " (0 0 0 0) para aumentar o disminuir los márgenes —si solo se una un número afecta a todos ellos—). En este caso el comando fue:

pdfcrop --margins '-145 -0 -110 -330' input.pdf output.pdf

Para comprender lo que cortamos, el pdf era de 826x1160 a 100 ppp, es decir, un A4 escaneado a calidad no muy alta, y nos aproximábamos a un B5.

Después descubrí que en Fedora 30 ya está pdfarranger en los repositorios, y además recomiendan no usar pdf-shuffler, ya que pdfarranger es una versión actualizada del otro, optimizada a python 3.

¿Qué hacer? Más fácil es usar pdfarranger; más rápido pdfcrop. Eso sí, pdfarranger permite hacer más cosas que recortar. Para los que estemos acostumbrados a shuffler, acudir a arranger, que es más o menos igual, salvo que tengáis prisa y solo queráis recortar o aumentar los márgenes.