Guía visual sobre la herramienta tmux con ejemplos de sus comandos

tmux es un multiplexador de la terminal en sistema derivados de Unix por ejemplo GNU/Linux. ¿Pero qué significa eso de un multiplexador?

Con tmux podemos tener no solo una consola, si no muchas. Nuestra consola o terminal, la podemos dividir en paneles, en ventanas en desconectarnos de la sesión y volver a recuperarla cuando queramos. ¿Y cómo podemos hacer todo eso?

Hace un tiempo en el blog ya hice un video tutorial sobre las posibilidades que nos ofrecía tmux y que puedes ver aquí:

• https://victorhckinthefreeworld.com/2018/01/23/guia-rapida-de-tmux-expande-las-posibilidades-de-la-consola-de-linux/

Pero he de reconocer que cuando tengo que cuando busco información sobre algo, a veces me sirve un videotutorial, y otras veces no es la forma que quiero obtener la información que quiero.

Es por eso, que he creado una guía visual sobre tmux, con un pequeño gif animado de los comandos, para ver qué es lo que hace cada uno de ellos en un ejemplo y que sirva como ayuda.

Para consultar la guía puedes hacerlo en este enlace:

• https://victorhck.github.io/guia-tmux/

Cada uno de los comandos o atajos de teclado de tmux se acompaña con el gif demostrativo (que podemos ver en un tamaño mayor al pinchar sobre la imagen) que nos muestra lo que hace el comando.

Quiere ser esta una guía que ayude a conocer esta herramienta y sacarle todo el potencial que ofrece. Tiene un montón de comandos explicados y alguno más que iré añadiendo.

A mí me ha servido como recordatorio de algunos comandos y como medio de descubrir otros y ver toda la potencia que ofrece tmux. Espero que también a tí te resulte de utilidad.

Both openSUSE Leap 15.3 and SUSE Enterprise Linux 15 SP3 are already in the oven and almost ready to be tasted. But although they smell delicious, the openSUSE volunteers and the great SUSE QA team never give up in challenging our beloved distributions to find the corner cases that need more polishing. Since we want to make sure each possible problem have a solution or a documented workaround at the release date, the YaST Team invested quite some time during the last sprint investigating and solving some problems related to AutoYaST, system migration, registration and other tricky areas.

But we also found time to work on more blog-friendly topics like:

• Improvements in the AutoYaST functionality to configure questions during the installation
• Better handling of path names in Arabic and other right-to-left languages
• Progress in the refactoring of YaST Users
• Possibility of installing with neither NetworkManager or wicked

Let’s dive into the details.

One of the many features offered by AutoYaST is the possibility of specifying a so-called ask-list, which lets the user decide the values of some parts of the AutoYaST profile during the installation. That allows to fine-tune the level of flexibility and interactivity, with a process that is highly automated but still customizable on the fly. During this sprint we basically rewrote the whole feature to make it more robust and powerful, while still being fully backwards-compatible. See more details in the corresponding pull request including technical details, before-and-after screenshots and a link to the official documentation that explains how to use this reworked feature.

And talking about before-and-after screenshots, let’s see if you can spot the differences in the following image.

Exactly. In the upper part, the right-to-left orientation of the Arabic writing mangles the mount points and the device names, moving the initial slash of paths like /dev/vda to the end. This is just one of the many interesting software development problems you don’t normally think about, but that makes life as a YaST developer a constant learning experience. If you want to know more about Unicode directional formatting characters and how we solved the problem, check this pull request at the yast2-storage-ng repository.

And talking about challenges and learning, sure you remember we are in the middle of a whole rewrite of the YaST mechanisms to manage local users. We already have a new version of the installer that works perfectly using the new code, including the creation of brand new users and also importing them from a previous installation. We are now integrating that new code into AutoYaST and we will be ready soon to discuss the best procedure and timing to introduce the revamped yast2-users into openSUSE Tumbleweed in a way that it brings all the benefits of the rewrite to our users without any disruptive change in the surface.

Last but not least, we would like to mention a new feature we already submitted to the Tumbleweed installer in search for feedback from you, our beloved users. :wink: In a nutshell, it offers the possibility to install the distribution without NetworkManager or wicked, for those users that want to manually configure an alternative network manager (like systemd-networkd) or that simply want a network-less operating system. Please check the corresponding pull request and reach out to us to tell us what do you think. Remember you can do that at the yast-devel and factory mailing lists at openSUSE, at the #yast channel at Freenode IRC or directly commenting on GitHub.

While waiting for your input, we will keep working in polishing the upcoming releases and bringing new features into Tumbleweed. Stay safe and have a lot of fun!

Nate Finch had a nice blog post on error flags recently, and it caused me to think about error handling in my own greenfield Go project at work.

Much of the Go software I write follows a common pattern: an HTTP JSON API fronting some business logic, backed by a data store of some sort. When an error occurs, I typically want to present a context-aware HTTP status code and an a JSON payload containing an error message. I want to avoid 400 Bad Request and 500 Internal Server Errors whenever possible, and I also don’t want to expose internal implementation details or inadvertently leak information to API consumers.

I’d like to share the pattern I’ve settled on for this type of application.

An API-safe error interface

First, I define a new interface that will be used throughout the application for exposing “safe” errors through the API:

package app

type APIError interface {
    // APIError returns an HTTP status code and an API-safe error message.
    APIError() (int, string)
}

Common sentinel errors

In practice, most of the time there are a limited set of errors that I want to return through the API. Things like a 401 Unauthorized for a missing or invalid API token, or a 404 Not Found when referring to a resource that doesn’t exist in the data store. For these I create a create a private struct that implements APIError:

type sentinelAPIError struct {
    status int
    msg    string
}

func (e sentinelAPIError) Error() string {
    return e.msg
}

func (e sentinelAPIError) APIError() (int, string) {
    return e.status, e.msg
}

And then I publicly define common sentinel errors:

var (
    ErrAuth      = &sentinelAPIError{status: http.StatusUnauthorized, msg: "invalid token"}
    ErrNotFound  = &sentinelAPIError{status: http.StatusNotFound, msg: "not found"}
    ErrDuplicate = &sentinelAPIError{status: http.StatusBadRequest, msg: "duplicate"}
)

Wrapping sentinels

The sentinel errors provide a good foundation for reporting basic information through the API, but how can I associate real errors with them? ErrNoRows from the database/sql package is never going to implement my APIError interface, but I can leverage the error wrapping functionality introduced in Go 1.13.

One of the lesser-known features of error wrapping is the ability to write a custom Is method on your own types. This is perhaps because the implementation is privately hidden within the errors package, and the package documentation doesn’t give much information about why you’d want to use it. But it’s a perfect fit for these sentinel errors.

First, I define a sentinel-wrapped error type:

type sentinelWrappedError struct {
    error
    sentinel *sentinelAPIError
}

func (e sentinelWrappedError) Is(err error) bool {
    return e.sentinel == err
}

func (e sentinelWrappedError) APIError() (int, string) {
    return e.sentinel.APIError()
}

This associates an error from elsewhere in the application with one of my predefined sentinel errors. A key thing to note here is that sentinelWrappedError embeds the original error, meaning its Error method returns the original error’s message, while implementing APIError with the sentinel’s API-safe message. The Is method allows for comparisons of these wrapping errors with the sentinel errors using errors.Is.

Then I need a public function to do the wrapping:

func WrapError(err error, sentinel *sentinelAPIError) error {
    return sentinelWrappedError{error: err, sentinel: sentinel}
}

(If you wanted to include additional context in the APIError, such as a resource name, this would be a good place to add it.)

When other parts of the application encounter an error, they wrap the error with one of the sentinel errors. For example, the database layer might have its own wrapError function that looks something like this:

package db

import "example.com/app"

func wrapError(err error) error {
    switch {
    case errors.Is(err, sql.ErrNoRows):
        return app.WrapError(err, app.ErrNotFound)
    case isMySQLError(err, codeDuplicate):
        return app.WrapError(err, app.ErrDuplicate)
    default:
        return err
    }
}

Because the wrapper implements Is against the sentinel, you can compare errors to sentinels regardless of what the original error is:

err := db.DoAThing()
switch {
case errors.Is(err, ErrNotFound):
    // do something specific for Not Found errors
case errors.Is(err, ErrDuplicate):
    // do something specific for Duplicate errors
}

Handling errors in the API

The final task is to handle these errors and send them safely back through the API. In my api package, I define a helper function that takes an error and serializes it to JSON:

package api

import "example.com/app"

func JSONHandleError(w http.ResponseWriter, err error) {
    var apiErr app.APIError
    if errors.As(err, &apiErr) {
        status, msg := apiErr.APIError()
        JSONError(w, status, msg)
    } else {
        JSONError(w, http.StatusInternalServerError, "internal error")
    }
}

(The elided JSONError function is the one responsible for setting the HTTP status code and serializing the JSON.)

Note that this function can take any error. If it’s not an APIError, it falls back to returning a 500 Internal Server Error. This makes it safe to pass unwrapped and unexpected errors without additional care.

Because sentinelWrappedError embeds the original error, you can also log any error you encounter and get the original error message. This can aid debugging.

An example

Here’s an example HTTP handler function that generates an error, logs it, and returns it to a caller.

package api

func exampleHandler(w http.ResponseWriter, r *http.Request) {
    // A contrived example that always throws an error.  Imagine this
    // is actually a function that calls into a data store.
    err := app.WrapError(fmt.Errorf("user ID %q not found", "archer"), app.ErrNotFound)
    if err != nil {
        log.Printf("exampleHandler: error fetching user: %v", err)
        JSONHandleError(w, err)
        return
    }

    // Happy path elided...
}

Hitting this endpoint will give you this HTTP response:

HTTP/1.1 404 Not Found
Content-Type: application/json

{"error": "not found"}

And send to your logs:

exampleHandler: error fetching user: user ID "archer" not found

If I had forgotten to call app.WrapError, the response instead would have been:

HTTP/1.1 500 Internal Server Error
Content-Type: application/json

{"error": "internal error"}

But the message to the logs would have been the same.

Impact

Adopting this pattern for error handling has reduced the number of error types and scaffolding in my code – the same problems that Nate experienced before adopting his error flags scheme. It’s centralized the errors I expose to the user, reduced the work to expose appropriate and consistent error codes and messages to API consumers, and has an always-on safe fallback for unexpected errors or programming mistakes. I hope you can take inspiration to improve the error handling in your own code.

Como ya hemos comentado en el blog, este año Akademy 2021 se seguirá celebrando en línea, debido a los problemas derivados de la pandemia del COVID’19 que sigue entre nosotros.. No obstante eso no significa que no tengamos camisetas para Akademy 2021, a un precio igual que al año año anterior por problemas logísticos.

Camisetas para Akademy 2021 en línea

Del 18 al 25 de junio la Comunidad KDE va a celebrar su gran evento internacional de forma en línea. Es esta ocasión no tengo excusas para no asistir, aunque me temo que voy a estar muy ocupado con mi fin de curso.

Hoy me gustaría comentar que  ya tenemos el boceto de la camiseta oficial de Akademy 2021 y que  se pueden reservar a un precio de 25€, ya que incluyen los gastos de envío iguales para cualquier destino.

De hecho, la fundación KDE e.V. va a financiar parte para que cada el precio final de las camisetas sea el mismo para todo el mundo, aunque los pedidos sean entre diferentes continentes.

Para asegurarse que recibes tu camiseta para usar durante Akademy es necesario que realices tu pedido directamente a Freewear antes del 20 de mayo.

Si te gusta, no dudes en reservarla ya que no solo te llevas una camiseta chula sino que ayudas tanto a la Comunidad KDE como a una empresa como Freewear que tanto ayuda a la difusión del Software Libre y . Yo ya la tengo reservada.

Más información: Akademy 2021 | Camiseta de Akademy 2021

¿Qué es Akademy?

Para los que no lo sepan, Akademy es el evento de la Comunidad KDE que aúna en una gran conferencia todo tipo de simpatizantes de KDE como desarrolladores, diseñadores, usuarios, traductores, promotores. Allí se reunirán a lo largo de una semana para compartir charlas, cenas, ponencias, talleres y, en definitiva, para trabajar juntos.
Es una gran semana que sirve para unir más fuerte los lazos que unen nuestra Comunidad, así como para crear nuevos.

Akademy lleva realizándose anualmente bajo este nombre desde 2004, en la página web oficial o en la wikipedia podéis encontrar los nombres y fechas anteriores eventos.

Para que os hagáis una ligera idea de la magnitud del evento, os dejo una imagen de grupo de Akademy 2020 en linea en la que se intentó hacer una foto de grupo virtual… evidentemente falta más de un 80% de participantes.

La primera estrella de una galaxia moribunda. Las curvas toman el control mientras los bits sueñan al anochecer

Bienvenidos al espacio de la cebolla. Llevamos aquí desde 2004 y crecemos cada día. En unos meses, algunas cebollas se pudrirán, mientras que otras florecerán.

Dusk fue la primera cebolla; ahora hay cientos de miles.

En un rincón del universo completamente diferente, donde prosperan los contratos inteligentes, Dusk está siendo subastado. Puede ofertar por él interactuando con funciones que viven en una cadena de bloques.

La subasta Dusk durará unas 24 horas. Terminará el viernes alrededor de las 20: 00UTC. Cuando finalice, la persona que haya pujado y haya ganado se convertirá en propietario de una obra de arte generativa creada en colaboración con el artista @ixshells que se ha derivado directamente de la clave privada de Dusk. En noviembre, los propietarios de NFT también obtendrán la clave privada de Dusk directamente de su propietario.

Sabemos que los mineros son una carga ​​para el medio ambiente. Parte de las ganancias de la subasta se donarán a una organización de base que lucha en la primera línea de la crisis climática. Al mismo tiempo, hemos estado monitoreando activamente los desarrollos de Ethereum y creemos que sus esfuerzos por alejarse de PoW es una pelea que vale la pena pelear y no puede llegar lo suficientemente pronto.

Bienvenidos a la subasta. Por favor tome asiento

• https://blog.torproject.org/dreaming-at-dusk
• https://foundation.app/torproject/dreaming-at-dusk-35855
• http://duskgytldkxiuqc6.onion/

Τι είναι το XAMPP

Πλεονεκτήματα - Μειονεκτήματα

Εγκατάσταση

Εκκίνηση

Παράδειγμα εγκατάστασης wordpress

Απεγκατάσταση

La Comunidad KDE es una comunidad responsable y no solo se preocupa en lazar novedades sino que también en mejorarlas. Me complace presentar la primera actualización de KDE Gear 21.04 que apareció hace unos días. Más estabilidad para nuestros entornos de trabajo.

Primera actualización de KDE Gear 21.04

A pesar de lo que puedan pensar muchas personas, las aplicaciones no son perfectas. Entre las líneas de código se pueden colar errores de tipografía o que el usuario realice alguna opción que en un principio no estaba prevista por los desarrollador, por poner solo un par de ejemplos de imperfecciones.

Este no es un problema del Software Libre ya que el Software actual funciona de esta manera ya que no se piensa en él como un producto final que se encierra en una caja y se olvida. En la actualidad se sabe que el Software está vivo y sería estúpido ir guardando las mejoras sin dejarlas a disposición del gran público.

Con esto se gana en rapidez y evolución pero puede aumentar el número de errores (por norma general) leves, los cuales son subsanables con pequeñas actualizaciones.

La Comunidad KDE lo tiene claro: grandes lanzamientos cada cuatro meses y actualizaciones mensuales para subsanar errores.

Por ello me congratula compartir con vosotros la primera actualización de KDE Gear 21.04 que nos ofrece más de 120 errores resueltos entre aplicaciones, librerías y widgets, algo que mejora el rendimiento del sistema.

Por poner un par de ejemplos que podemos ver en la lista de cambios de KDE Gear 21.04:

• Restaurada la compatibilidad con ffmpeg 3.
• Solucionado el error en el espaciado en el panel de lugares.
• Añadida la nueva mascota de Kate en el diálogo de información de la aplicación.
• Solucionado la validación del código de tiempo en el diálogo de configuración en Kdenlive.

Más información: KDE Gear 21.04

Tumbleweed es una distribución “Rolling Release” de actualización contínua. Aquí puedes estar al tanto de las últimas novedades.

openSUSE Tumbleweed es la versión “rolling release” o de actualización continua de la distribución de GNU/Linux openSUSE.

Hagamos un repaso a las novedades que han llegado hasta los repositorios estas semanas.

El anuncio original lo puedes leer en el blog de Dominique Leuenberger, publicado bajo licencia CC-by-sa, en este enlace:

• http://dominique.leuenberger.net/blog/2021/05/opensuse-tumbleweed-review-of-the-week-2021-19/

Primero, pedir disculpas a los usuarios de Steam por hacer su vida más complicada esta semana. Hubo un reporte en openQA sobre un problema que en realidad era un problema con el paquete Mesa.

Esto hizo que algunos usuarios recibieran mensajes al actualizar con zypper. Finalmente se reportó el error en Bugzilla y en la próxima snapshot se incorporará la solución.

Aparte de eso, no ha habido ningún problema grave y se han publicado nada menos que 6 nuevas snapshots esta semana (0506, 0507, 0508, 0510, 0511 y 0512). Los cambios principales son:

• GNOME 40.1
• KDE Plasma 5.21.5
• Mesa 21.1.0
• LibreOffice 7.1.3.2
• QEmu 6.0.0
• Virtualbox 6.1.22
• VLC 3.0.13
• icu 69.1
• Mozilla Firefox 88.0.1
• KDE Frameworks 5.82.0
• Linux kernel 5.12.2, kfence ha sido inhabilitado. Esto permite la suspensión del sistema de una manera más sencilla
• Python 3.8.10

Y en próximas actualizaciones podremos encontrar:

• NodeJS 15 será eliminado
• Linux kernel 5.12.3
• KDE Gear 21.04.1
• Cambios en los sistemas de sistemas de archivos: más directorios bases cambiarán de 755 a 555
• Cambio de go 1.15 a go 1.16
• GCC 11 como compilador predeterminado

Si quieres estar a la última con software actualizado y probado utiliza openSUSE Tumbleweed la opción rolling release de la distribución de GNU/Linux openSUSE.

Mantente actualizado y ya sabes: Have a lot of fun!!

Enlaces de interés

• • • ¿Por qué deberías utilizar openSUSE Tumbleweed?
    • zypper dup en Tumbleweed hace todo el trabajo al actualizar
    • ¿Cual es el mejor comando para actualizar Tumbleweed?
    • Comprueba la valoración de las “snapshots” de Tumbleweed
    • ¿Qué es el test openQA?
    • http://download.opensuse.org/tumbleweed/iso/
    • https://es.opensuse.org/Portal:Tumbleweed

——————————–

Dear Tumbleweed users and hackers,

First, I want to apologize to our Steam users for making their life harder this week than needed. I misjudged an openQA-reported issue as being a Steam packaging bug instead of realizing that it was in fact a Mesa packaging bug. This in turn made some of you receive scary messages from zypper. A bug for this had been filed in Bugzilla of course: https://bugzilla.opensuse.org/show_bug.cgi?id=1185933. A fixed Mesa package will be part of Snapshot 0514.

Other than that, I did not hear/read a lot of complaints regarding the six snapshots released during this week (0506, 0507, 0508, 0510, 0511, and 0512). The main changes included:

• GNOME 40.1
• KDE Plasma 5.21.5
• Mesa 21.1.0
• LibreOffice 7.1.3.2
• QEmu 6.0.0
• Virtualbox 6.1.22
• VLC 3.0.13
• icu 69.1
• Mozilla Firefox 88.0.1
• KDE Frameworks 5.82.0
• Linux kernel 5.12.2, kfence has been disabled. This allows the system to reach idle state easier again
• Python 3.8.10 (security and bug fixes)

The staging areas are currently filled with these major topics:

• NodeJS 15 will be removed
• Linux kernel 5.12.3
• KDE Gear 21.04.1
• Base filesystem layout changes: more base directories will change permission from 755 to 555
• Switch from go 1.15 to go 1.16: most packages fixed, the last failure in Staging:M is cilium
• GCC 11 as default compiler: Move from special-purpose Staging:Gcc7 to Staging:O (incl. openQA test coverage). There are a few more build failures to be addressed.
• UsrMerge: The current state is that we checked in all changes and are planning on actually doing the switch somewhen in the not too far future, likely together with the planned distro-rebuild for GCC 11

Una vez finalizado el periodo de mantenimiento de Plasma 5.21 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.22, 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.22

Hoy 13 de mayo ha sido lanzada la beta de Plasma 5.22. 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 las novedades del escritorio Plasma más destacadas son:

• Plasma System Monitor sustituye a KSysguard como aplicación de monitorización del sistema por defecto
• Nueva función de transparencia adaptativa del panel hace que el panel y los widgets del panel sean más transparentes, pero desactiva la transparencia por completo cuando hay alguna ventana maximizada. También puedes hacer que el panel sea siempre transparente o siempre opaco si así lo deseamos.

• El nuevo Kickoff ya no sufre un retraso antes de cambiar de categoría o de cambiar accidentalmente de categoría al mover el cursor
• Soporte para actividades en Wayland
• El applet del Menú Global ahora permite buscar entre los elementos del menú en Wayland
• La función «Resaltar ventanas» del Administrador de tareas ahora sólo resalta las ventanas cuando se pasa por encima de la miniatura de esa ventana en la información sobre herramientas, y este comportamiento se ha activado por defecto
• Los atajos globales que implican símbolos no latinos de teclados no estadounidenses ahora funcionan correctamente
• Se ha mejorado enormemente el soporte de Wayland en general
• Ahora se puede cambiar el tamaño del texto en los widgets de notas adhesivas

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.