Convierte una imagen en un mosaico de varias hojas con PosteRazor
Hoy me salgo un poco de los temas kdeeros y quiero presentaros PosteRazor, una aplicación online que convierte una imagen en un mosaico de varias hojas. Y es que la he descubierto esta semana y es de esas aplicaciones que creo que interesa tener a mano.
Convierte una imagen en un mosaico de varias hojas con PosteRazor
Me encanta pensar que todo aquello que puede hacerse en informática de forma manual pero que puede resultar muy pesado tiene asociada una aplicación que lo simplifica.
Por simple cuestión de usuarios y empresas, este tipo de aplicaciones específicas tienen segura su versión en Windows, pero poco a poco el mundo de GNU/Linux no se queda atrás.
Y no solo eso, ya que el auge de las aplicaciones online en algunas ocasiones se puede realizar de esta forma y evitarnos el problema de la instalación del Software.
Justo eso me pasó el pasado jueves: para el día de la Paz en el colegio, que se celebra el 30 de enero, se nos ocurrió imprimir el famoso cuadro del «Guernika» casi a tamaño real utilizando folios A3.
En otras palabras, debíamos aprender cómo convertir una imagen en un mosaico de varias hojas, en nuestro caso en folios de tamaño A3.
Tras realizar una búsqueda por la red encontré algunas alternativas windoseras pero al final llegué a la mejor solución ya que se trata de una aplicación online basada en Qt: PosteRazor.

Leyendo la definición que hacen sus creadores,
«El PosteRazor corta una imagen en trozos que pueden imprimirse en una impresora y unirse para formar un póster.
Como imagen de entrada, se admiten archivos rasterizados de varios formatos de archivo de imagen. En lugar de imprimir directamente el póster, PosteRazor produce un archivo PDF de varias páginas que contiene las piezas del póster.
Es un programa de código abierto que depende de otros proyectos de código abierto. El PosteRazor está alojado en posterazor.sourceforge.net.«
De esta forma, simplemente debes seguir las instrucciones que te muestra la minimalista página web de Posterazor y que se pueden resumir en: subir imagen, decidir en cuantas partes quieres dividir la imagen y crear un pdf.
openSUSE Tumbleweed – Review of the week 2021/03
Dear Tumbleweed users and hackers,
Shame on me for giving you the information about the changes in Tumbleweed during this week only now, but at least technically this is still the review of Week 03. Since the last weekly review, there have been 6 snapshots published (0114, 0115, 0118, 0119, 0120, and 0121).
The main changes this week include:
- Linux kernel 5.10.7
- GNOME 3.38.3
- Mozilla Tunderbird 78.6.1
- Mesa 20.3.3
- openSSH 8.4p1
- Tcl/Tk 8.6.11
- Bash 5.1.4
- PHP 8 was added
- Wine 6.0
- Multiple versions of python 3 parallel installable. Besides all python-FOO packages being built for python 3.8, they are now also built for python 3.6 (where they make sense and are buildable). The packages are named python36-FOO and python38-FOO. As Python 3.8 is currently the default python 3 interpreter in Tumbleweed, all python38-FOO packages provide/obsolete the python3-FOO symbol, in order to facilitate the migration to the new naming scheme.
The future changes that are currently being planned, worked on and being tested include:
- Postfix: change the default database format to lmdb, migrating away from BerkleyDB.
- icu 68.1: breaks a few things like PostgreSQL. Staging:I
- Rust 1.49: breaks librsvg
- Automake 1.16.3
- Autoconf 2.70: breaks quite a few packages. The list of failures has been noted on the current SR; no active staging left for it (no progress in the last days/weeks on it)
- Migrate to LUA 5.4 as main lua interpreter, mainly relevant in context of RPM and thus the distro bootstrap
Bellas Artes en GCompris – A fondo @g_compris (3)
Sigo aprovechándome de una publicación de Valencia Tech en la que se realizaba un listado completo de juegos que ofrece GCompris he empezado una serie donde se describen con más detalles los juegos. Seguimos la serie con la sección de «Bellas Artes» en GCompris la cual tiene como objetivo hacer que «juguemos» con esta parte básica que despierta el gusto por la belleza y la creatividad humana.
Bellas Artes en GCompris – A fondo @g_compris (3)
Para poder tener claro lo que hacen las aplicaciones de GCompris he pensado hacer una revisión a su enorme colección de juegos y actividades, realizando una simple captura de pantalla y una breve descripción.
Ya hemos descrito la sección de «Descubre la computadora» y los «Juegos de lógica«, es hora de hablar de las «Bellas Artes y Música» en GCompris.
En la subsección de Bellas Artes nos encontramos con:
Monta el rompecabezas: actividad clásica en la que montaremos un puzzle de un cuadro. Al empezar a montarlo nos muestra el nombre de la obra, su autor y el año de creación. Los rompecabezas no tienen demasiadas piezas, con lo que es ideal para utilizar con los más pequeños. En niveles avanzados desaparecen las típicas «muescas» de los puzzles.

Encuentra los detalles: en esta ocasión nos muestra la obra pictórica completa y nos invita a buscar y colocar detalles que nos presentan en la zona de las piezas. Si pinchamos en el cuadro no muestra el nombre de la obra, su autor y el año de creación. Para aprender a disfrutar de los detalles de los cuadros.

Explora los continentes: interesante actividad que nos presenta diferentes mapas con puntos donde se encuentran monumentos. Al pinchar sobre los puntos aparece la información de la construcción. Después nos pedirá que los localicemos. De momento solo hay disponibles solo 7 mapas, pero seguro que poco a poco se irán añadiendo muchos más.

Latency Numbers Every Team Should Know
We design systems around the size of delays that are expected. You may have seen the popular table “latency numbers every programmer should know” which lists some delays that are significant in technology systems we build.
Teams are systems too. Delays in operations that teams need to perform regularly are significant to their effectiveness. We should know what they are.
Ssh to a server on the other side of the world and you will feel frustration; delay in the feedback loop from keypress to that character displayed on the screen.
Here’s some important feedback loops for a team, with feasible delays. I’d consider these delays tolerable by a team doing their best work (in contexts I’ve worked in). Some teams can do better, lots do worse.
| Operation | Delay |
| Run unit tests for the code you’re working on | < 100 Milliseconds |
| Run all unit tests in the codebase | < 20 Seconds |
| Run integration tests | < 2 Minutes |
| From pushing a commit to live in production | < 5 Minutes |
| Breakage to Paging Oncall | per SLO/Error Budget |
| Team Feedback | < 2 Hours |
| Customer Feedback | < 1 Week |
| Commercial Bet Feedback | < 1 Quarter |
What are the equivalent feedback mechanisms for your team? How long do they take? How do they influence your work?
Feedback Delays Matter
They represent how quickly we can learn. Keeping the delays as low as the table above means we can get feedback as fast as we have made any meaningful progress. Our tools/system do not hold us back.
Feedback can be synchronous if you keep them this fast. You can wait for feedback and immediately use it to inform your next steps. This helps avoid the costs of context switching.
With fast feedback loops we run tests, and fix broken behaviour. We integrate our changes and update our design to incoporate a colleague’s refactoring.
Fast is deploying to production and immediately addressing the performance degradation we observe. It’s rolling out a feature to 1% of users and immediately addressing errors some of them see.
With slow feedback loops we run tests and respond to some emails while they run, investigate another bug, come back and view the test results later. At this point we struggle to build a mental model to understand the errors. Eventually we’ll fix them and then spend the rest of the afternoon trying to resolve conflicts with a branch containing a week’s changes that a teammate just merged.
With slow deploys you might have to schedule a change to production. Risking being surprised by errors reported later that week, when it has finally gone live, asynchronously. Meanwhile users have been experiencing problems for hours.
Losing Twice
As feedback delays increase, we lose twice:
a) We waste more time waiting for these operations (or worse—incur context switching costs as we fill the time waiting)
b) We are incentivised to seek feedback less often, since it is costly to do so. Thereby wasting more time & effort going in the wrong direction.
I picture this as a meandering path towards the most value. Value often isn’t where we thought it was at the start. Nor is the route to it often what we envisioned at the start.
We waste time waiting for feedback. We waste time by following our circuitous route. Feedback opportunities can bring us closer to the ideal line.
When feedback is slow it’s like setting piles of money on fire. Investment in reducing feedback delays often pays off surprisingly quickly—even if it means pausing forward progress while you attend to it.
This pattern of going in slightly the wrong direction then correcting repeats at various granularities of change. From TDD, to doing (not having) continuous integration. From continuous deployment to testing in production. From customers in the team, to team visibility of financial results.
Variable delays are even worse
In recent times you may have experienced the challenge of having conversations over video links with significant delays. This is even harder when the delay is variable. It’s hard to avoid talking over each other.
Similarly, it’s pretty bad if we know it’s going to take all day to deploy a change to production. But it’s so worse if we think we can do it in 10 minutes, when it actually ends up taking all day. Flaky deployment checks, environment problems, change conflicts create unpredictable delays.
It’s hard to get anything done when we don’t know what to expect. Like trying to hold a video conversation with someone on a train that’s passing through the occasional tunnel.
Measure what Matters
The time it takes for key types of feedback can be a useful lead indicator on the impact a team can have over the longer term. If delays in your team are important to you why not measure them and see if they’re getting better or worse over time? This doesn’t have to be heavyweight.
How about adding a timer to your deploy process and graphing the time it takes from start to production over time? If you don’t have enough datapoints to plot deploy delay over time that probably tells you something ;)
Or what about a physical/virtual wall for waste. Add to a tally or add a card every time you have wasted 5 mins waiting. Make it visible. How big did the tally get each week?
What do the measurements tell you? If you stopped all feature work for a week and instead halved your lead time to production, how soon would it pay off?
Would you hit your quarterly goals more easily if you stopped sprinting and first removed the concrete blocks strapped to your feet?
What’s your experience?
Every team has a different context. Different sorts of feedback loops will be more or less important to different teams. What’s important enough for your team to measure? What’s more important than I’ve listed here?
What is difficult to keep fast? What gets in the way? What is so slow in your process that synchronous feedback seems like an unattainable dream?
The post Latency Numbers Every Team Should Know appeared first on Benji's Blog.
Cómo instalar juegos Humble Bumble en Linux con Lutris
Hace poco hablé de Lutris, y en estos días de vacaciones he decidido investigar un poco sobre su funcionamiento. Así que bienvenidos a cómo instalar juegos Humble Bumble en Linux con Lutris paso a paso utilizando como ejemplo Outlast, como ya expliqué con juegos Steam hace un tiempo.
Requisitos previos
Antes de empezar quisiera recordar que Lutris es una aplicación que busca centralizar todos los juegos que tu equipo pueda ejecutar (o al menos lo intentará) recopilando los juegos que tengas tiendas virtuales como GOG, Humble Bumble o la todopoderosa Steam y, además, gestionará los juegos que tengas instalados en tu equipo, tanto nativos como emulados.
Evidentemente antes instalar juegos debemos tener instalado Lutris y tener una cuenta de Humble Bumble con juegos adquiridos. Yo tengo unos cuantos, aunque he de reconocer que todos son ofertas y han sido adquiridos muy baratos (o gratis).
Para instalar Lutris os aconsejo seguir las instrucciones de esta reciente entrada del blog en la que se explica con detalle, sobre todo para los usuarios de sistemas Ubuntu y derivados, como hacerlo.

Cómo instalar juegos Humble Bumble en Linux con Lutris
Para nuestro ejemplo he elegido instalar Outlast un juego con gráficos 3D de horror de supervivencia en primera persona desarrollado y publicado por Red Barrels Inc, como vemos en el siguiente vídeo.
Para instalar juegos Humble Bumble en Lutris os recomiendo ir a la sección de «Sources» y buscar el juego en la pestaña de «Community Installers«, seleccionarlo y pulsar el botón de control inferior (quedaos con ese botón en mente que es importante) que tiene el comando «Install«.

A continuación aparecerá una ventana emergente que te indica de qué fuente quieres instalar el juego. En mi caso selecciono desde Humble Bumble, ya que lo tengo en esa tienda. Evidentemente pinchamos en «Install«.

Nos pedirá el directorio de instalación. Se lo decimos y pinchamos en «Install«.

Nos aparecen las dependencias. En este punto podríamos decir que instale algún archivo en local, pero en este caso no era necesario, así que pinchamos en «Continue» y empezará a bajar todo lo necesario.


Una vez terminado pinchamos en «Launch«.

El juego ya está instalado, aparecerá el botón de control con el comando «Stop» preselecccionado y, en mi caso,el juego se ejecutó de inmediato.


Una vez instalado si buscamos el juego aparecerá el botón de control con el comando «Play«, que evidentemente podemos pulsar para empezar a jugar.

Por cierto, para desinstalar simplemente debemos pulsar en la flecha del lado del Botón de Control y seleccionar «Remove«.

Os recuerdo que para que se cierre del todo el juego, además de salir de él debéis pulsar «Stop» del botón de control.
GNOME, VLC, Zypper update in Tumbleweed
Five openSUSE Tumbleweed snapshots were released this week.
The snapshots updated the GNOME desktop, GStreamer, VLC and a couple text editors.
An update of bash 5.1.4 arrived in the latest snapshot 20210120. A few patches were added to the bash version, which is the latest release candidate. The 2.83 version of dnsmasq took care of five Common Vulnerabilities and Exposures; one of the fixes handles multiple identical near simultaneous DNS queries better and another CVE replaced the slightly lesser SHA-1 hash with the SHA-256 hash function, which verifies the DNS answers received are for the questions originally asked. GStreamer 1.18.3 fixed a memory leak and added support for the Apple M1, which made news yesterday as being able to run Linux. Several other GStreamer plugins were updated. Video player VLC updated for version 3.0.12 and added new Reliable Internet Stream Transport access output module compliant with a simple profile. About a dozen more packages were updated in the snapshot including ncurses , openldap2 2.4.57, and perl-Mojolicious 8.71.
The 20210119 snapshot fixed some rendering regressions and some crash in the 20.3.3 version of Mesa. ImageMagick 7.0.10.58 fixed an issue of properly identifying SVG images. An update to the AY configuration file in autoyast2 4.3.65 was made for checking that a valid base product was selected. A few new features were made available in openssh 8.4p1, which prompts a PIN verification to complete a signature operation. The update of text editor nano 5.5 has an option to suppress the title bar and show a bar with basic information; it also removed support for Slang. GNOME’s Wayland display server and X11 window manager mutter 3.38.3 updated translations, set xrandr as the primary output and fixed some crashes. Flatpak 1.10.0 has major new features in this series compared to the 1.8 version, which supports a new repo format that should make updates faster and download less data. PDF renderer poppler also had a new major version with 21.01.0. Poppler has faster jpeg decoding and fixed some potential data loss when fetching a non-existing reference after modifying a document. GNU Privacy Guard updated to 2.2.27 and fixed descriptions of two new options in gpg.conf. There was an improvement to the login screen with gnome-shell 3.38.3 and the update of audio compressor wavpack to 5.4.0 allowed for the assembly of some language optimizations for x86, x64, and arm.
Mozilla Thunderbird 78.6.1 fixed one CVE in snapshot 20210118. CVE-2020-16044, which affected the use-after-free write when handling a malicious COOKIE-ECHO SCTP chunk; this had implication for the email client as well as the Firefox browser. openSUSE’s command line package manager zypper 1.14.42 fixed the extend apt packagemap and the source-download for command help. Another command line package, sudo updated to 1.9.5p1. This version fixed a regression introduced in sudo 1.9.5 where the editor run by sudoedit was set-user-ID root (unless SELinux RBAC was in use); the editor is now run with the user’s real and effective user-IDs. An update of redis to version 6.0.10 fixed a crash in redis-cli after executing a cluster backup. The 2.24 alpine, which is a text-based mail and news client, provided implementation of XOAUTH2 for Yahoo! Mail.
The 20210115 snapshot provided updates for GNOME 3.38.3 with packages gnome-desktop, gnome-maps, gnome-terminal and the evolution information manager all updating a minor version. A minor update was made to the compiler/toolchain llvm11 to version 11.0.1, which provided some random fixes. The snapshot also featured an update to salt 3002.2, which removed the use of an undefined variable in utils/slack.py and restored the ability to specify the amount of extents for a Logical Volume as a percentage. Other packages to update in the snapshot were AppStream 0.13.1, git 2.30.0 brltty 6.2, vala 0.50.3 and vim.
The Linux Kernel was updated to 5.10.7 in snapshot 20210114. Xfce’s thunar file manager updated to version 4.16.2; the package fixed a regression with opening an application and a changes were made to always create new files and folders in a current directory.
dnsmasq icon - Author Justin Clift Creative Commons Attribution-Share Alike 3.0 Unported
CUPS-PDF | Print to PDF from any Application
Actualizar un fork de un repositorio git desde la interfaz web de GitHub
Veamos cómo actualizar desde la propia interfaz web de GitHub nuestro repositorio “forkeado”

En un artículo anterior ya vimos cómo actualizar desde la línea de comandos nuestro repositorio “forkeado”, para mantenerlo al día con las actualizaciones del repositorio original:
En esta ocasión veremos cómo hacerlo desde la propia interfaz web de GitHub (si es que es allí donde tenemos alojado nuestros repositorios, tanto el original como nuestra copia derivada o “fork”).
La cuestión me surgió porque no estaba en mi portátil, no tenía instalado git, ni podía hacerlo y quería enviar un pull request al repositorio original y antes quería actualizar mi fork para después enviar los cambios.
Así que tras una búsqueda por la red encontré un artículo escrito por Adrien Torris, que lo explicaba muy bien. Y he querido traducirlo/adaptarlo para futuras referencias propias y para ti también lector o lectora que recalas en este blog.
Abrimos nuestra página de GitHub donde reside nuestro fork del repositorio original.
1.- Pulsamos sobre el botón “Compare”

2.- Verás el siguiente mensaje: “There’s anything to compare”. Pulsaremos sobre el “switching the base”.

3.- Recopilará los commits desde el repo original. Ahora deberemos crear un pull request

4.- Añadimos un título y si queremos descripción a nuestro pull request
5.- Y pulsamos sobre el botón de crear

6.- Nos abrirá un pull request con los commits desde el repositorio original. Ahora deberemos unir ese pull request en el repostorio. Para ello pulsamos sobre el botón “Merge pull request”.

Y con esto ya tenemos nuestro “fork” actualizado y tendremos incorporadas las mejoras que se hayan hecho en el repositorio original en nuestra copia.
Espero que te haya sido de utilidad.
Lanzada la beta de Plasma 5.21
Una vez finalizado el periodo de mantenimiento de Plasma 5.19 es hora de ir preparando el lanzamiento de la siguiente versión. Es por ello que me complace compartir con vosotros que ha sido lanzada la beta de Plasma 5.21, la próxima versión del escritorio de la Comunidad KDE que nos llega con novedades interesantes, muchas de las cuales se han ido desgranando en el blog de Nate Graham. Es el momento de que esta beta sea probada y que se reporten los errores que se encuentren. ¡No pierdas la oportunidad de contribuir al desarrollo de Plasma!
Lanzada la beta de Plasma 5.21
Hoy 21 de enero ha sido lanzada la beta de Plasma 5.21. En esta primera versión liberada del 2021, no apta todavía para el usuario domésticos, se ha centrado en que el escritorio de la Comunidad KDE
Unas pinceladas de algunas de las novedades más destacada son:
- Nuevo lanzador de aplicaciones.
- Mejoras visuales en el tema por defecto de Plasma.
- Presentación de Breeze Twilight, Nuevo tema oficial disponible que combina lo mejor de los temas claros y oscuros.
- Nueva interfaz de información del sistema: Plasma System Monitor.
- Mejoras y avances en Kwin con Wayland.
Y muchas más pequeñas mejoras que hará las delicias de los usuarios de este entorno de trabajo.
Más información: KDE.org
Pruébalo y reporta errores

Todas las tareas dentro del mundo del Software Libre son importantes: desarrollar, traducir, empaquetar, diseñar, promocionar, etc. Pero hay una que se suele pasar por alto y de la que solo nos acordamos cuando las cosas no nos funcionan como debería: buscar errores.
Desde el blog te animo a que tú seas una de las personas responsables del éxito del nuevo lanzamiento de Plasma 5.20 de la Comunidad KDE. Para ello debes participar en la tarea de buscar y reportar errores, algo básico para que los desarrolladores los solucionen para que el despegue del escritorio esté bien pulido. Debéis pensar que en muchas ocasiones los errores existen porque no le han aparecido al grupo de desarrolladores ya que no se han dado las circunstancias para que lo hagan.
Para ello debes instalarte esta beta y comunicar los errores que salgan en bugs.kde.org, tal y como expliqué en su día en esta entrada del blog.
Curso de Vim: arriba, abajo al centro… y #Vim
Veamos cómo mover el cursor o nuestra pantalla en el editor Vim hacia arriba, hacia abajo o al centro

En esta ocasión un sencillo truco sobre el editor Vim. Sencillo, pero práctico y que siempre viene bien conocer.
Este artículo es una nueva entrega del curso “improVIMsado” que desde hace meses vengo publicando en mi blog sobre el editor Vim y que puedes seguir en estos enlaces:
- https://victorhckinthefreeworld.com/tag/vim/
- https://victorhck.gitlab.io/comandos_vim/articulos.html
En esta ocasión se trata de saber y conocer cómo mover rápidamente nuestro cursor hacia la parte superior, media o inferior de la pantalla. Y cómo mover la línea donde se encuentra el cursor también hacia la parte superior, media o inferior de la pantalla.
Abre una instancia de Vim en tu equipo con un documento y comprueba cómo funcionan los comandos y las diferencias entre ellos. Y la próxima vez ponles a funcionar.
Moviendo el cursor
Veamos cómo podemos mover solo el cursor en nuestra pantalla. Todos estos comandos se ejecutan en modo normal de Vim.
- H → Lleva el cursor a la parte superior de la pantalla (High)
- M → Lleva el cursor a la parte central o media de la pantalla (Medium)
- L → Lleva el cursor a la parte inferior de la pantalla (Low)
Moviendo la pantalla
Ahora veamos cómo mover no solo el cursor, si no también la línea en la que se encuentra el cursor y así mover el documento. También se ejecutan estos comandos en el modo normal de Vim.
- zt → Mueve la línea del cursor a la parte superior de la pantalla (z top)
- zz → Mueve la línea del cursor a la parte media de la pantalla
- zb → Mueve la línea del cursor a la parte inferior de la pantalla (z bottom)
La verdad es que son unos comandos que utilizo bastante mientras estoy editando archivos con Vim. ¿Los conocías? Espero que sí, pero si estás descubriendo Vim, quizás son unos comandos a empezar a conocer y utilizar.
Te recuerdo que tienes más comandos útiles sobre Vim en este enlace, que siempre es interesante consultar:
