Al ejecutar el programa GNU Hello simplemente muestra un saludo familiar y amistoso

Si no lo tienes instalado en tu sistema GNU/Linux el software hello, puedes hacerlo con el gestor de paquetes de tu distribución. Después de instalarlo ya podrás ejecutar en una terminal:

hello

Sí, esta es otra implementación desarrollada en lenguaje C, del programa clásico que imprime «¡Hola, mundo!» (si tienes instalado el paquete de traducciones a distintos idiomas) cuando lo ejecutas.

Hoy echando un vistazo por distintos sitios, veo que el paquete hello, ha publicado su versión 2.11 después en este mes de enero del año 2022 de 7 años desde la última versión 2.10, publicada en noviembre de 2014.

De acuerdo, no es un paquete clave, que necesite actualizaciones contínuas, revisiones, ni correcciones de errores, por tanto 7 años, no me parece mucho tiempo.

Pero ¿por qué hay un paquete de software de GNU para un programa tan sencillo como pueda ser imprimir un simple Hola mundo?

Bueno, el propósito de este programa es sobre todo didáctico. Una manera de mostrar los estándares de cómo crear código en el proyecto GNU, además de servir de ejemplo también sobre cómo mantener un paquete GNU.

Es decir, que GNU Hello no incorpora únicamente el clásico código que unicamente imprime en la pantalla el consabido hola mundo, si no que quiere servir de ayuda y ejemplo a un programa mucho mayor que es la forma que se desarrolla en el proyecto GNU.

Instala el paquete, o descarga el código fuente y échale un vistazo. También puedes consultar el man o la página info en tu sistema.

Estudia cómo funciona el código, modifícalo a tu gusto, aporta tus cambios y distribuye si quieres tu versión, es software libre y puedes hacerlo.

Una vez finalizado el periodo de mantenimiento de Plasma 5.23 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.24, la próxima versión del escritorio de la Comunidad KDE que nos llega con nuevo fondo de pantalla y novedadesha sido lanzada la beta de Plasma 5.24 interesantes. 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.24, pequeñas pero muchas mejoras para un gran escritorio

Hoy 13 de enero ha sido lanzada la beta de Plasma 5.24. En esta primera versión liberada del 2022, no apta todavía para el usuario que busquen estabilidad, se ha centrado en que el escritorio de la Comunidad KDE siga mejorando en aspecto, funcionalidades y usabilidad.

En palabras de sus desarrolladores:

Como es tradicional, hoy os traemos la versión de pruebas de Plasma 5.24 de KDE. Plasma 5.24 Beta está dirigida a probadores, desarrolladores y cazadores de errores.

Para ayudar a los desarrolladores de KDE a eliminar los errores y resolver los problemas, instala Plasma 5.24 Beta y prueba las características que se enumeran a continuación (ver anuncio). Por favor, informa de los errores en nuestro rastreador de errores.

La versión final de Plasma 5.24 estará disponible para el público en general el 8 de febrero.

Muchas de sus novedades se han ido desgranando en el blog de Nate Graham, e ncluso ya ha sido presentado su nuevo fondo oficial, pero si queréis saber qué nos espera no dejéis de ver el anuncio oficial donde veréis el ingente número de novedades para Wayland, el lanzador de aplicaciones, Discover, Breeze, plasmoides, Krunner, etc.

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.24 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.

openSUSE にはパッケージで Blender が提供されています。しかし、起動時には英語のメッセージが表示されます。これを日本語化するには以下のようにします。

Edit->Preferences 画面を開き、 Text Renderning の所を開き(三角マークを
クリックするとメニューが展開します)、Interface Font に
/usr/share/fonts/truetype/みかちゃん.ttf (画面上では□□..ttf となっています)
を選択して下さい。さらに、Translation の所で、 Language に日本語、
Interface にチェックを入れると日本語化します。

Librsvg's documentation tooling is pretty ancient. The man page for rsvg-convert is written by hand in troff, and the C library's reference documentation still uses the venerable gtk-doc.

As part of the modernization effort, I have turned the man page into a reStructuredText document, and the C API documentation into gi-docgen. This post describes how I did that.

You can read librsvg's new documentation here.

From man to rst

The man page for rsvg-convert was written in troff, which is pretty cumbersome. The following gunk defines a little paragraph and a table:

.P
You can also specify dimensions as CSS lengths, for example
.B 10px
or \"
.BR 8.5in .
The unit specifiers supported are as follows:
.RS
.TS
tab (@);
l lx.
px@T{
pixels (the unit specifier can be omitted)
T}
in@T{
inches
T}
cm@T{
centimeters
T}
mm@T{
millimeters
T}
pt@T{
points, 1/72 inch
T}
pc@T{
picas, 1/6 inch
T}
.TE

Yeah, nope. We have better tools now like rst2man, which take a reStructuredText document — fancy plain text — and turn it into a troff man page. I just had to use a command line like

pandoc --from=man --to=rst rsvg-convert.1 > rsvg-convert.rst

and then tweak the output a little:

You can also specify dimensions as CSS lengths, for example ``10px`` or
``8.5in``. The unit specifiers supported are as follows:

   == ==========================================
   px pixels (the unit specifier can be omitted)
   in inches
   cm centimeters
   mm millimeters
   pt points, 1/72 inch
   pc picas, 1/6 inch
   == ==========================================

Much better, right?

I've learned that Pandoc is awesome. Pure magic, highly recommended.

I hope to integrate the man page into a prettier user manual for rsvg-convert at some point. It's no longer a trivial program, and its options allow for some interesting combinations that could use some illustrations and generally more detail than a man page.

From gtk-doc to gi-docgen

I highly recommend that you read Emmanuele's initial description of gi-docgen, which includes the history of gtk-doc, a description of its shortcomings, and how gi-docgen is a simpler tool that leverages the fact that GObject Introspection already slurps documentation from source code and so obviates most of gtk-doc already.

Summary of how gi-docgen works:

• The C code has documentation comments in Markdown format, with annotations for GObject Introspection. (Note: librsvg has no C code for the library, so those documentation comments actually live in the .h header files that it installs for the benefit of C programs.)

• The library gets compiled and introspected. In this step, g-ir-scanner(1) extracts annotations and documentation from the source code and puts them in the MyLibrary.gir XML file.

• You write a small configuration file to tell gi-docgen about the structure of your documentation. Unlike gtk-doc, you don't need to write a DocBook skeleton or anything complicated. Stand-alone chapters can be individual Markdown files, and the configuration file just lists them in the order you want them to appear. Gi-docgen automatically includes all the classes, types, functions, etc. from your code into the docs.

• ... it runs very fast. Gtk-doc was always slow due to xsltproc and complicated stylesheets to turn a DocBook document into browsable HTML documentation. Gi-docgen is much leaner.

Doing the conversion

Unlike the mostly automatic pandoc step for the man page, I converted the documentation comments to from DocBook to Markdown by hand. For librsvg this took me a moderately caffeinated afternoon; it's a little fiddly business, but nothing out of this world.

You can look forward to having good error messages from gi-docgen when something goes wrong, unlike gtk-doc, whose errors I always tended to ignore until the last minute because they were so hard to discern and diagnose.

Some hints:

• DocBook hyperlinks that looked like <ulink url="blahblah.html">blah blah</ulink> get turned into [blah blah](blahblah.html) Markdown.

• Gi-docgen allows references to methods like [method@Gtk.Button.set_child] - see the linking documentation for other kinds of links.

• You can get progressively fancy with introspection attributes.

• There is no direct mapping between DocBook's extremely granular semantic markup and Markdown conventions, so for example I'd substitute both <literal>foobar</literal> and <filename>/foo/bar</filename> for `foobar` and `/foo/bar`, respectively (i.e. the text I wanted to show, between backticks, to indicate verbatim text).

Librsvg seemed to include verbatim text blocks in gtk-doc delimited like this:

/**
 * blah_blah():
 *
 * For example:
 *
 * |[
 * verbatim text goes here
 * ]|
 *
 * Etc. etc.
 */

Those can go between ``` triple backticks in Markdown:

/**
 * blah_blah():
 *
 * For example:
 *
 * ```
 * verbatim text goes here
 * ```
 *
 * Etc. etc.
 */

Errors I found

My first manual run of gi-docgen looked like this:

$ gi-docgen check Rsvg-2.0.gir 
INFO: Loading config file: None
INFO: Search paths: ['/home/federico/src/librsvg/gi-docgen/_build', '/home/federico/.local/share/gir-1.0', '/home/federico/.local/share/flatpak/exports/share/gir-1.0', '/var/lib/flatpak/exports/share/gir-1.0', '/usr/local/share/gir-1.0', '/usr/share/gir-1.0']
INFO: Elapsed time 1.601 seconds
WARNING: Symbol 'Rsvg.HandleFlags' at <unknown>:0 is not documented
WARNING: Return value for symbol 'Rsvg.Handle.get_dimensions_sub' is not documented
WARNING: Return value for symbol 'Rsvg.Handle.get_geometry_for_element' is not documented
WARNING: Return value for symbol 'Rsvg.Handle.get_geometry_for_layer' is not documented
WARNING: Return value for symbol 'Rsvg.Handle.get_position_sub' is not documented
WARNING: Return value for symbol 'Rsvg.Handle.render_document' is not documented
WARNING: Return value for symbol 'Rsvg.Handle.render_element' is not documented
WARNING: Return value for symbol 'Rsvg.Handle.render_layer' is not documented
WARNING: Return value for symbol 'Rsvg.Handle.set_stylesheet' is not documented
WARNING: Symbol 'Rsvg.Handle.base-uri' at <unknown>:0 is not documented
WARNING: Symbol 'Rsvg.Handle.dpi-x' at <unknown>:0 is not documented
WARNING: Symbol 'Rsvg.Handle.dpi-y' at <unknown>:0 is not documented
WARNING: Symbol 'Rsvg.cleanup' at include/librsvg/rsvg.h:447 is not documented
WARNING: Symbol 'Rsvg.DEPRECATED_FOR' at include/librsvg/rsvg.h:47 is not documented
WARNING: Parameter 'f' of symbol 'Rsvg.DEPRECATED_FOR' is not documented

The warnings like WARNING: Return value ... is not documented are easy to fix; the comment blocks had their descriptions, but they were missing the Returns: part.

The warnings like WARNING: Symbol 'Rsvg.Handle.base-uri' at <unknown>:0 is not documented are different. Those are GObject properties, which previously were documented like this:

/**
 * RsvgHandle::base-uri:
 *
 * Base URI, to be used to resolve relative references for resources.  See the section
 * "Security and locations of referenced files" for details.
 */

There is a syntax error there! The symbol line should use a single colon between the class name and the property name, e.g. RsvgHandle:base-uri instead of RsvgHandle::base-uri. This one, plus the other properties that showed up as not documented, had the same kind of typo.

The first warning, WARNING: Symbol 'Rsvg.HandleFlags' at <unknown>:0 is not documented, turned out to be that there were two documentation comments with the same title for RsvgHandleFlags, and the second one was empty — and the last one wins. I left a single one with the actual docs.

Writing standalone chapters

Librsvg had a few chapters like doc/foo.xml, doc/bar.xml that were included in the reference documentation; those were a DocBook <chapter> each. I was able to convert them to Markdown with pandoc individually, and then add a Title: heading in the first line of each .md file — that's what gi-docgen uses to build the table of contents in the documentation's starting page.

Title: Overview of Librsvg

# Overview of Librsvg

Librsvg is a library for rendering Scalable Vector Graphics files (SVG).
Blah blah blah blah.

Build scripts

There are plenty of examples for using gi-docgen with meson; you can look at how it is done in gtk.

However, librsvg is still using Autotools! You can steal the following bits:

• configure.ac
• doc/Makefile.am

Publishing the documentation

Gtk-doc assumed that magic happened somewhere in developer.gnome.org to generate the documentation and publish it. Gi-docgen assumes that your project publishes it with Gitlab pages.

Indeed, the new documentation is published there — you can see how it is generated in .gitlab-ci.yml. Note that there are two jobs: the reference job generates gi-docgen's HTML in a public/Rsvg-2.0 directory, and the pages job integrates it with the Rust API documentation and publishes both together.

Linking the docs to the main developer's site

Finally, librsvg's docs are linked from the GNOME Platform Introduction. I submitted a merge request to the developer-www project to update it.

That's all! I hope this is useful for someone who wants to move from gtk-doc to gi-docgen, which is a much more pleasant tool!

Users of openSUSE Leap 15.2 will not be receiving security and maintenance updates as the version is now EOL (end of life) as of Jan. 4, 2022.

EOL ends updates for the operating system minor version. Those who continue to use EOL versions will be exposed to vulnerabilities because these discontinued versions no longer receive security and maintenance updates. This is why users need to upgrade to the newer minor release; openSUSE Leap 15.3!

Users can upgrade from 15.2 to 15.3 by downloading the iso image or following the instructions on how to upgrade found on https://en.opensuse.org/SDB:System_upgrade.

For new installations, download openSUSE Leap 15.3 images at https://get.opensuse.org/leap/. The Leap 15.3 release is supported with security patches and updates and is expected to reach its EOL in November 2022. Leap 15.4 is expected to be released in June 2022, according to the roadmap.

Users interested in changing from the point release version to the rolling version can move to Tumbleweed, which provides large daily and frequent updates of all software in the official repositories.

Download it from here and the best way to do the change is to reinstall your system, so take a backup of your /home directory and any configuration files you want to save ( f.e. /etc /var ).

What if we could visualise the cost of attrition?

Here’s a team. Someone leaves. We hire a replacement.
We get lucky and manage to find someone more skilled. Looks like we’re better off?

Really when someone leaves we lose all the relationships they had with the rest of the team as well. The team is a diminished more like 40% than the apparent 20% by their loss. It takes longer to rebuild the team than is apparent. Relationships take time.

It’s worse than that. The team probably wasn’t maximally-connected to start with. And it’s not just the interpersonal relationships that matter but the knowledge of tech and domain. A departure can break teams apart and organisational knowledge needs to be rebuilt.

Your organisation probably has multiple teams. Someone leaving your team reduces its connectedness to the rest of the organisation. Increasing the time to recover even with a swift new hire.

Internal mobility is less of a hit to the team’s connectedness due to pre-existing relationships. It also increases the whole organisations resilience by establishing more inter-team relationships.

Teams following the Isolated-individual model of work… (as opposed to collaborative work like pairing and collective ownership) …are particularly brittle & significantly impacted by staff churn.

How would we think about retention if we could visualise the full impact of someone leaving our team?

Beware looking at teams on a spreadsheet. If you have a hiring rate matching attrition rate it might look like the team health is maintained. It’s probably not.

Tracking tenure by team and average tenure in team can be interesting proxy indicators. Teams can be growing but have dropping tenure.

Bear in mind “All models are wrong, some are useful”. Sometimes teams benefit more from fresh ideas than the value of relationships lost in a change. Sometimes gaining someone who helps everyone else in the team form connections at a faster rate can accelerate the team.

This post is also available as a Twitter Thread

Here’s a team. Someone leaves.

We hire a replacement.

We get lucky and manage to find someone more skilled.

Looks like we’re better off? [1/10] pic.twitter.com/nSE8wJxElo

— Benji Weber (@benjiweber) January 9, 2022

The post Cost of Attrition appeared first on Benji's Blog.

The syslog-ng application is part of all major Linux distributions, and you can usually install syslog-ng from the official repositories. If you use just the core functionality of syslog-ng, use the package in your distribution repository (apt-get install syslog-ng), and you can stop reading here. However, if you want to use the features of newer syslog-ng versions (for example, send log messages to MQTT or Apache Kafka), you have to either compile the syslog-ng from source, or install it from unofficial repositories. This post explains you how to do that.

Read the rest of my blog at https://www.syslog-ng.com/community/b/blog/posts/installing-the-latest-syslog-ng-on-ubuntu-and-other-deb-distributions

Lo cierto es que tenemos algunas aplicaciones que realizan esta función, pero nunca está de más tener un nuevo emulador de Plasystation para Linux, en esta caso uno llamado Duckstation que destaca por sus prestaciones y su interfaz basada en Qt. ¿Quieres saber más? Sigue leyendo.

Emulador de Plasystation para Linux Duckstation

No es un secreto mi gusto por los videojuegos, así que también soy aficionado a canales de Youtube como «El rincón de Slobulus«, «Pazos 64«, «Leyendas y Videojuegos» o «La Poción Roja«.

De este último he descubierto un nuevo emulador de Playstation para Linux que me ha llamado la atención pues utiliza librerías Qt para funcionar y se puede ejecutar fácilmente ya que tiene versión en APPimage.

Según leemos en su página de GitHub, DuckStation es un simulador/emulador de la consola PlayStation(TM) de Sony, centrado en la jugabilidad, la velocidad y el mantenimiento a largo plazo. El objetivo es ser lo más preciso posible, manteniendo un rendimiento adecuado para los dispositivos de gama baja, llegando a resoluciones asombrosas aún con estos.

Aunque el emulador lo permite, las opciones de «hackeo» están desaconsejadas, la configuración por defecto debería soportar todos los juegos que funcionen a la primera con sólo algunas de las mejoras que tienen problemas de compatibilidad.

Como muestra un botón, la imagen inferior muestra el Final Fantasy 8 VIII ejecutándose con DuckStation, y os puedo asegurar que se ve mejor que con mi PCSX-ReARMed que ejecuta mi Retrpie (aunque me acabo de dar cuenta que han añadido un lr-duckstation a esta distribución… cuestión de probar).

DuckStation está disponible en los siguientes sistemas operativos: GNU/Linux, Windows x64/ARM64 y Android ARMv7/ARMv8; y su instalación está perfectamente descrita en su GitHub.

Por cierto, ya que lo descubrí en un vídeo de «La Poción Roja» creo que es de recibo compartir aquí dicho vídeo y pediros que le deis «Me gusta» como mínimo al mismo, y si os gusta el canal, ya sabéis, subcribiros.

Vamos a personalizar la barra de pestañas del emulador de teminal Konsole del proyecto KDE para diferenciar la pestaña activa de las otras

Desde hace mucho tiempo Konsole de KDE es el emulador de terminal predeterminado en mi equipo que utilizo a diario.

Es rápido, tiene previsualización de imágenes, posibilidad de dividir la pantalla en vertical y horizontal, uso de pestañas, y un montón de cosas buenas más. Una gran herramienta de KDE para trabajar en la terminal.

Una cosa que no me terminaba de gustar, es que al trabajar con muchas pestañas, no se diferenciaba muy claramente qué pestaña era la activa de todas, ya que el color de la activa y de las no activas era muy similar.

En este tutorial veremos cómo poder solucionar ese pequeño contratiempo y hacer más cómodo el uso de esta gran herramienta.

Tal como nos dice la documentación de Konsole, este permite el uso de hojas de estilo personalizadas para configurar el aspecto de la barra de pestañas, con un archivo .css.

Así que voy a crear un archivo llamado style_konsole.css que voy a ubicar en la ruta ~/.config En tu caso le puedes llamar con otro nombre y ubicarlo en la carpeta que te apetezca.

cd ~/.config
touch style_konsole.css

Ahora abrimos el archivo con el editor que prefiramos y configuramos el color de fondo de la pestaña, y el color del texto de la siguiente manera (violeta y blanco en mi caso):

QTabBar::tab::selected {
    background: #2b0055;
    color: white;
}

Guardamos el archivo. Y ahora abrimos Konsole y pulsamos el atajo de teclado Ctrl+Shift+,

Se nos abrirá la ventana de configuración de Konsole, y nos dirigimos al apartado Barra de pestañas/separadores y en la sección de Aspecto en la sección Otros marcamos la opción Usar hoja de estilos de usuario.

Y en la caja inferior escribimos la ruta completa de la ubicación de nuestro archivo .css recién creado. En mi cado sería ~/.config/style_konsole.css

Aplicamos los cambios y ya deberían verse en nuestro Konsole un aspecto distinto en la barra de pestañas. Puedes abrir varias para ver cómo queda este cambio y comprobar que ahora sí se distinguen perfectamente la pestaña actual de las otras.

También podemos especificar otros colores e incluso el tamaño mínimo de las pestañas y el tamaño de la pestaña seleccionada. Por ejemplo, vamos a establecer un tamaño mínimo de 100 píxeles en las pestañas y la pestaña seleccionada de color gris para el fondo, color rojo para el texto y un tamaño de 200 píxeles.

Nuestro archivo .css tendría este código:

QTabBar::tab::selected {
    background: #999999;
    color: red;
    min-width: 200px;
}
QTabBar::tab {
    min-width: 100px
}

Cabe destacar, que una vez que hemos establecido un archivo .css, si hacemos cambios sobre él para configurar otros colores o lo que sea, deberemos cerrar Konsole por completo y volverlo a abrir para que se recargue el archivo y podamos ver los cambios efectuados.

Si también utilizas Konsole, espero que este pequeño y sencillo tutorial te haya servido. Comenta si lo pusiste en práctica.

¿Configuras de alguna manera más el archivo .css? Compártelo en los comentarios del blog