Skip to main content
  1. Planet
  2. Global
  3. Page 194

a silhouette of a person's head and shoulders, used as a default avatar
a silhouette of a person's head and shoulders, used as a default avatar

Vuelve el evento24H24L edición 2024

Todo cambia, y esa es la constantedel evento 24H24L, que ha pasado de ser un evento intensivo a una serie de charlas puntuales publicadas en un solo día a los mismo pero que no espera y que se van publicando a medida que se graban. En otras palabras, vuelve el evento 24H2L edición 2024 donde destacados (o no tnato porque participo yo) miembros de la Comunidad hablan de forma distendida sobre diversos aspectos del mundo del Software Libre. Estos audios tienen la intención de ser una puerta de entrada para todo el mundo, así que son 10%% recomendable a los nuevos o potenciales usuarios.

Vuelve el evento24H24L edición 2024

Este año José Jiménez, promotor de esta iniciativa, vuelve a dar otra vuelta y se está dedicando a realizar charlas puntuales y las va publicando poco a poco. De hecho, os comporto el rss para que las vayáis escuchando a medida que se van publicando a que después se acumulan y colapsan de GNU/Linux nuestros podcaster.

Debo reconocer que tengo pendiente de escuchar todavía muchas de ellas, incluso de la edición del 2021, pero que todos los que escucho me parecen de los más interesantes por la variedad de temas y la calidad de los contertulios.

Además, este año, debido a que algunos se han grabado en febrero los participantes han destacado algún proyecto de Software Libre al que darle las gracias, lo cual hace que no solo se hable de los temas especializados de los colaboradores sino que se multilpique por dos o tres las iniciativas presentadas, aunque sea solo dando una pincelada.

En palabras de su promotor:

El evento 24H24L consiste en la grabación de 24 audios de 1 hora sobre una temática especifica, en esta tercera edición se centrará en GNU/Linux. El propósito es cualquier usuario independientemente de su nivel descubra que le puede aportar este sistema operativo y le facilite el camino para empezar a utilizar este sistema.

Y, como es habitual en este tipo de entradas, os pongo aquí mismo la charla extraída del canal de PeerTube de 24H24L que tiene en FediverseTV, al cual os pido encarecidamente que le deis un vistazo.

Aprovecho para poner algunos enlaces de interés para poder disfrutar de esta iniciativa que ya lleva mucho tiempo promocionando el Software Libre y en la que espero poder partcipar pronto.

Más información: 24H24L

La entrada Vuelve el evento24H24L edición 2024 se publicó primero en KDE Blog.

the avatar of Federico Mena-Quintero
the avatar of Federico Mena-Quintero

Rustifying libipuz: character sets

It has been, what, like four years since librsvg got fully rustified, and now it is time to move another piece of critical infrastructure to a memory-safe language.

I'm talking about libipuz, the GObject-based C library that GNOME Crosswords uses underneath. This is a library that parses the ipuz file format and is able to represent various kinds of puzzles.

The words "GNOME CROSSWORDS" set inside a crossword puzzle

Libipuz is an interesting beast. The ipuz format is JSON with a lot of hair: it needs to represent the actual grid of characters and their solutions, the grid's cells' numbers, the puzzle's clues, and all the styling information that crossword puzzles can have (it's more than you think!).

{
    "version": "http://ipuz.org/v2",
    "kind": [ "http://ipuz.org/crossword#1", "https://libipuz.org/barred#1" ],
    "title": "Mephisto No 3228",
    "styles": {
        "L": {"barred": "L" },
        "T": {"barred": "T" },
        "TL": {"barred": "TL" }
    },
    "puzzle":   [ [  1,  2,  0,  3,  4,  {"cell": 5, "style": "L"},  6,  0,  7,  8,  0,  9 ],
                  [  0,  {"cell": 0, "style": "L"}, {"cell": 10, "style": "TL"},  0,  0,  0,  0,  {"cell": 0, "style": "T"},  0,  0,  {"cell": 0, "style": "T"},  0 ]
                # the rest is omitted
    ],
    "clues": {
        "Across": [ {"number":1, "clue":"Having kittens means losing heart for home day", "enumeration":"5", "cells":[[0,0],[1,0],[2,0],[3,0],[4,0]] },
                    {"number":5, "clue":"Mostly allegorical poet on writing companion poem, say", "enumeration":"7", "cells":[[5,0],[6,0],[7,0],[8,0],[9,0],[10,0],[11,0]] },
                ]
        # the rest is omitted
    }
}

Libipuz uses json-glib, which works fine to ingest the JSON into memory, but then it is a complete slog to distill the JSON nodes into C data structures. You need iterate through each node in the JSON tree and try to fit its data into yours.

Get me the next node. Is the node an array? Yes? How many elements? Allocate my own array. Iterate the node's array. What's in this element? Is it a number? Copy the number to my array. Or is it a string? Do I support that, or do I throw an error? Oh, don't forget the code to meticulously free the partially-constructed thing I was building.

This is not pleasant code to write and test.

Ipuz also has a few mini-languages within the format, which live inside string properties. Parsing these in C unpleasant at best.

Differences from librsvg

While librsvg has a very small GObject-based API, and a medium-sized library underneath, libipuz has a large API composed of GObjects, boxed types, and opaque and public structures. Using libipuz involves doing a lot of calls to its functions, from loading a crossword to accessing each of its properties via different functions.

I want to use this rustification as an exercise in porting a moderately large C API to Rust. Fortunately, libipuz does have a good test suite that is useful from the beginning of the port.

Also, I want to see what sorts of idioms appear when exposing things from Rust that are not GObjects. Mutable, opaque structs can just be passed as a pointer to a heap allocation, i.e. a Box<T>. I want to take the opportunity to make more things in libipuz immutable; currently it has a bunch of reference-counted, mutable objects, which are fine in single-threaded C, but decidedly not what Rust would prefer. For librsvg it was very beneficial to be able to notice parts of objects that remain immutable after construction, and to distinguish those parts from the mutable ones that change when the object goes through its lifetime.

Let's begin!

In the ipuz format, crosswords have a character set or charset: it is the set of letters that appear in the puzzle's solution. Internally, GNOME Crosswords uses the charset as a histogram of letter counts for a particular puzzle. This is useful information for crossword authors.

Crosswords uses the histogram of letter counts in various important algorithms, for example, the one that builds a database of words usable in the crosswords editor. That database has a clever format which allows answering questions like the following quickly: What words in the database match ?OR?? — WORDS and CORES will match.

IPuzCharset is one of the first pieces of code I worked on in Crosswords, and it later got moved to libipuz. Originally it didn't even keep a histogram of character counts; it was just an ordered set of characters that could answer the question, "what is the index of the character ch within the ordered set?".

I implemented that ordered set with a GTree, a balanced binary tree. The keys in the key/value tree were the characters, and the values were just unused.

Later, the ordered set was turned into an actual histogram with character counts: keys are still characters, but each value is now a count of the coresponding character.

Over time, Crosswords started using IPuzCharset for different purposes. It is still used while building and accessing the database of words; but now it is also used to present statistics in the crosswords editor, and as part of the engine in an acrostics generator.

In particular, the acrostics generator has been running into some performance problems with IPuzCharset. I wanted to take the port to Rust as an opportunity to change the algorithm and make it faster.

Refactoring into mutable/immutable stages

IPuzCharset started out with these basic operations:

/* Construction; memory management */
IPuzCharset          *ipuz_charset_new              (void);
IPuzCharset          *ipuz_charset_ref              (IPuzCharset       *charet);
void                  ipuz_charset_unref            (IPuzCharset       *charset);

/* Mutation */
void                  ipuz_charset_add_text         (IPuzCharset       *charset,
                                                     const char        *text);
gboolean              ipuz_charset_remove_text      (IPuzCharset       *charset,
                                                     const char        *text);

/* Querying */
gint                  ipuz_charset_get_char_index   (const IPuzCharset *charset,
                                                     gunichar           c);
guint                 ipuz_charset_get_char_count   (const IPuzCharset *charset,
                                                     gunichar           c);
gsize                 ipuz_charset_get_n_chars      (const IPuzCharset *charset);
gsize                 ipuz_charset_get_size         (const IPuzCharset *charset);

All of those are implemented in terms of the key/value binary tree that stores a character in each node's key, and a count in the node's value.

I read the code in Crosswords that uses the ipuz_charset_*() functions and noticed that in every case, the code first constructs and populates the charset using ipuz_charset_add_text(), and then doesn't modify it anymore — it only does queries afterwards. The only place that uses ipuz_charset_remove_text() is the acrostics generator, but that one doesn't do any queries later: it uses the remove_text() operation as part of another algorithm, but only that.

So, I thought of doing this:

  • Split things into a mutable IPuzCharsetBuilder that has the add_text / remove_text operations, and also has a build() operation that consumes the builder and produces an immutable IPuzCharset.

  • IPuzCharset is immutable; it can only be queried.

  • IPuzCharsetBuilder can work with a hash table, which turns the "add a character" operation from O(log n) to O(1) amortized.

  • build() is O(n) on the number of unique characters and is only done once per charset.

  • Make IPuzCharset work with a different hash table that also allows for O(1) operations.

Basics of IPuzCharsetBuilder

IPuzCharsetBuilder is mutable, and it can live on the Rust side as a Box<T> so it can present an opaque pointer to C.

#[derive(Default)]
pub struct CharsetBuilder {
    histogram: HashMap<char, u32>,
}

// IPuzCharsetBuilder *ipuz_charset_builder_new (void); */
#[no_mangle]
pub unsafe extern "C" fn ipuz_charset_builder_new() -> Box<CharsetBuilder> {
    Box::new(CharsetBuilder::default())
}

For extern "C", Box<T> marshals as a pointer. It's nominally what one would get from malloc().

Then, simple functions to create the character counts:

impl CharsetBuilder {
    /// Adds `text`'s character counts to the histogram.
    fn add_text(&mut self, text: &str) {
        for ch in text.chars() {
            self.add_character(ch);
        }
    }

    /// Adds a single character to the histogram.
    fn add_character(&mut self, ch: char) {
        self.histogram
            .entry(ch)
            .and_modify(|e| *e += 1)
            .or_insert(1);
    }
}

The C API wrappers:

use std::ffi::CStr;

// void ipuz_charset_builder_add_text (IPuzCharsetBuilder *builder, const char *text);
#[no_mangle]
pub unsafe extern "C" fn ipuz_charset_builder_add_text(
    builder: &mut CharsetBuilder,
    text: *const c_char,
) {
    let text = CStr::from_ptr(text).to_str().unwrap();
    builder.add_text(text);
}

CStr is our old friend that takes a char * and can wrap it as a Rust &str after validating it for UTF-8 and finding its length. Here, the unwrap() will panic if the passed string is not UTF-8, but that's what we want; it's the equivalent of an assertion that what was passed in is indeed UTF-8.

// void ipuz_charset_builder_add_character (IPuzCharsetBuilder *builder, gunichar ch);
#[no_mangle]
pub unsafe extern "C" fn ipuz_charset_builder_add_character(builder: &mut CharsetBuilder, ch: u32) {
    let ch = char::from_u32(ch).unwrap();
    builder.add_character(ch);
}

Somehow, the glib-sys crate doesn't have gunichar, which is just a guint32 for a Unicode code point. So, we take in a u32, and check that it is in the appropriate range for Unicode code points with char::from_u32(). Again, a panic in the unwrap() means that the passed number is out of range; equivalent to an assertion.

Converting to an immutable IPuzCharset 

pub struct Charset {
    /// Histogram of characters and their counts plus derived values.
    histogram: HashMap<char, CharsetEntry>,

    /// All the characters in the histogram, but in order.
    ordered: String,

    /// Sum of all the counts of all the characters.
    sum_of_counts: usize,
}

/// Data about a character in a `Charset`.  The "value" in a key/value pair where the "key" is a character.
#[derive(PartialEq)]
struct CharsetEntry {
    /// Index of the character within the `Charset`'s ordered version.
    index: u32,

    /// How many of this character in the histogram.
    count: u32,
}

impl CharsetBuilder {
    fn build(self) -> Charset {
        // omitted for brevity; consumes `self` and produces a `Charset` by adding
        // the counts for the `sum_of_counts` field, and figuring out the sort
        // order into the `ordered` field.
    }
}

Now, on the C side, IPuzCharset is meant to also be immutable and reference-counted. We'll use Arc<T> for such structures. One cannot return an Arc<T> to C code; it must first be converted to a pointer with Arc::into_raw():

// IPuzCharset *ipuz_charset_builder_build (IPuzCharsetBuilder *builder);
#[no_mangle]
pub unsafe extern "C" fn ipuz_charset_builder_build(
    builder: *mut CharsetBuilder,
) -> *const Charset {
    let builder = Box::from_raw(builder); // get back the Box from a pointer
    let charset = builder.build();        // consume the builder and free it
    Arc::into_raw(Arc::new(charset))      // Wrap the charset in Arc and get a pointer
}

Then, implement ref() and unref():

// IPuzCharset *ipuz_charset_ref (IPuzCharset *charet);
#[no_mangle]
pub unsafe extern "C" fn ipuz_charset_ref(charset: *const Charset) -> *const Charset {
    Arc::increment_strong_count(charset);
    charset
}

// void ipuz_charset_unref (IPuzCharset *charset);
#[no_mangle]
pub unsafe extern "C" fn ipuz_charset_unref(charset: *const Charset) {
    Arc::decrement_strong_count(charset);
}

The query functions need to take a pointer to what really is the Arc<Charset> on the Rust side. They reconstruct the Arc with Arc::from_raw() and wrap it in ManuallyDrop so that the Arc doesn't lose a reference count when the function exits:

// gsize ipuz_charset_get_n_chars (const IPuzCharset *charset);
#[no_mangle]
pub unsafe extern "C" fn ipuz_charset_get_n_chars(charset: *const Charset) -> usize {
    let charset = ManuallyDrop::new(Arc::from_raw(charset));
    charset.get_n_chars()
}

Tests

The C tests remain intact; these let us test all the #[no_mangle] wrappers.

The Rust tests can just be for the internals, simliar to this:

    #[test]
    fn supports_histogram() {
        let mut builder = CharsetBuilder::default();

        let the_string = "ABBCCCDDDDEEEEEFFFFFFGGGGGGG";
        builder.add_text(the_string);
        let charset = builder.build();

        assert_eq!(charset.get_size(), the_string.len());

        assert_eq!(charset.get_char_count('A').unwrap(), 1);
        assert_eq!(charset.get_char_count('B').unwrap(), 2);
        assert_eq!(charset.get_char_count('C').unwrap(), 3);
        assert_eq!(charset.get_char_count('D').unwrap(), 4);
        assert_eq!(charset.get_char_count('E').unwrap(), 5);
        assert_eq!(charset.get_char_count('F').unwrap(), 6);
        assert_eq!(charset.get_char_count('G').unwrap(), 7);

        assert!(charset.get_char_count('H').is_none());
    }

Integration with the build system

Libipuz uses meson, which is not particularly fond of cargo. Still, cargo can be used from meson with a wrapper script and a bit of easy hacks. See the merge request for details.

Further work

I've left the original C header file ipuz-charset.h intact, but ideally I'd like to automatically generate the headers from Rust with cbindgen. Doing it that way lets me check that my assumptions of the extern "C" ABI are correct ("does foo: &mut Foo appear as Foo *foo on the C side?"), and it's one fewer C-ism to write by hand. I need to see what to do about inline documentation; gi-docgen can consume C header files just fine, but I'm not yet sure about how to make it work with generated headers from cbindgen.

I still need to modify the CI's code coverage scripts to work with the mixed C/Rust codebase. Fortunately I can copy those incantations from librsvg.

Is it faster?

Maybe! I haven't benchmarked the acrostics generator yet. Stay tuned!

the avatar of Hollow Man's Blog
the avatar of Hollow Man's Blog

My Igalia Coding Experience 2023 I & II at Wolvic

Wolvic is a fast and secure browser for standalone virtual-reality and augmented-reality headsets. ex. Mozilla Firefox Reality.

Project summaries

List of things I have done

PRs opened/handled

Issues opened/helped with

a silhouette of a person's head and shoulders, used as a default avatar
a silhouette of a person's head and shoulders, used as a default avatar

Nuevo podcast «Accesibilidad con Tecnologías libres»

Me complace compartir con vosotros la presentación de el nuevo podcast «Accesibilidad con Tecnologías libres». Bueno en realidad no es tan nuevo, pero hasta ahora no me había podido centrar en él y no me gusta publicar cosas sin escucharlas antes. Fue presentado el 30 de septiembre de 2023 y ya lleva cuatro programas, el de presentación y tres más que iré desgranando poco a poco.

Nuevo podcast «Accesibilidad con Tecnologías libres»

Nuevo podcast "Accesibilidad con Tecnologías libres"

Jorge Lama, Víctor , David Marzal, Thais Pusada, Pablo Arias, Jonathan Chacon y Markolino son el equipo reunido para crear el podcast Accesibilidad con Tecnologías libres, un podcast para hablar sobre temas de accesibilidad y tecnologías libres.

En palabras de sus creadores:

En informática, la accesibilidad incluye diferentes ayudas como pueden ser las tipografías de alto contraste o gran tamaño, magnificadores de pantalla, lectores y revisores de pantalla, programas de reconocimiento de voz, teclados adaptados y otros dispositivos apuntadores o de entrada de información.

Además, las inteligencias artificiales están empezando a ser un gran aliado para mejorar la accesibilidad en muchos aspectos. Existen podcasts y canales de vídeo que hablan de la accesibilidad centrándose en entornos Windows o de Apple porque son los más conocidos por el público generalista. Pero en este podcast queremos dar a conocer otros aspectos de la accesibilidad y su relación con otras tecnologías menos conocidas.

Tecnologías que consideramos libres y que nos parecen mejores para la sociedad, en muchos casos…

Aprovecho para dejaros el enlace del rss para que no os perdáis ningún episodio y también os dejo el audio del programa de presentación donde Jorge va presentando a cada uno de los co-presentadores, explicando su sección y haciendo una intro de lo que hablarán en el próximo programa.

Por supuesto, os invito a visitar la página de Archive.org donde están recogidos el resto de programas y donde nos indican también aquellos que estań subtitulados, aunque creo que al final lo estarán todos:

Créditos de la música:

La música usada ha sido «Evening» de Kevin MacLeod (incompetech.com)
Licensed under Creative Commons: By Attribution 4.0 License
http://creativecommons.org/licenses/by/4.0/

Personalmente, me parece un podcast muy interesante que aborda un tema recurrente en el mundo del Software Libre pero que todavía está lejos de solucionarse. Los diferentes proyectos de escritorio de GNU/Linux implementan cosas pero en muchas ocasiones no están coordinadas realmente con las personas que las necesitan. Esperemos que en los próximos años este aspecto se vaya mejorando y, si ocurre, creo que este podcast tendrá parte de culpa, en el buen sentido de la palabra.

Más información: Accesibilidad con Tecnologías Libres

La entrada Nuevo podcast «Accesibilidad con Tecnologías libres» se publicó primero en KDE Blog.

the avatar of Nathan Wolf
the avatar of Nathan Wolf

du | Directory Size in the Terminal

This is a letter to future me for the next time I need to look up the disk usage in the terminal. If you find this useful, great, if you think this is lacking and unhelpful, that’s fine too. I don’t always remember how I used various commands in the terminal when there are weeks […]
the avatar of Nathan Wolf

a silhouette of a person's head and shoulders, used as a default avatar
a silhouette of a person's head and shoulders, used as a default avatar

#openSUSE Tumbleweed revisión de la semana 7 de 2024

Tumbleweed es una distribución de GNU/Linux «Rolling Release» o de actualización contínua. Aquí puedes estar al tanto de las últimas novedades.

Tumbleweed

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 esta semana.

Y recuerda que puedes estar al tanto de las nuevas publicaciones de snapshots en esta web:

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

Esta semana se han publicado 5 nuevas snapshots (0209, 0211, 0212, 0213, y 0214). Lo que es la media de publicaciones semanales de actualizaciones en Tumbleweed.

Los cambios más relevantes son:

  • SDL 2.30.0
  • c-ares 1.26.0
  • fwupd 1.9.13
  • PostgreSQL 16.2
  • Pulseaudio 17.0
  • GTK 4.12.5
  • Python 3.11.8
  • KDE Frameworks 5.115.0
  • RPM 4.19.1.1
  • Node.JS 21.6.1

Y esta es la lista de cambios que se estñán testeando para próximas semanas:

  • Meson 1.3.2
  • Shadow 4.14.5
  • pkgconf 2.1.1
  • RPM
  • Un trabajo de limpieza para eliminar python2
  • dbus-broker
  • libxml 2.12.x
  • GCC 14

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

Geeko_ascii

——————————–

a silhouette of a person's head and shoulders, used as a default avatar
a silhouette of a person's head and shoulders, used as a default avatar

openSUSE Tumbleweed – Review of the weeks 2024/07

Dear Tumbleweed users and hackers,

This week we have released 5 snapshots (0209, 0211, 0212, 0213, and 0214). With 5 snapshots, this is quite a normal week.

The most relevant changes in those snapshots were:

  • SDL 2.30.0
  • c-ares 1.26.0 (after a lengthy staging phase)
  • fwupd 1.9.13
  • PostgreSQL 16.2
  • Pulseaudio 17.0
  • GTK 4.12.5
  • Python 3.11.8
  • KDE Frameworks 5.115.0
  • RPM 4.19.1.1
  • Node.JS 21.6.1

The list of things currently being tested remained largely unchanged:

  • Meson 1.3.2
  • Shadow 4.14.5
  • pkgconf 2.1.1
  • RPM: enable reproducible builds by default (bsc#1148824). For upstream versions see: https://github.com/rpm-software-management/rpm/pull/2880
  • A bunch of cleanup work to eliminate more of python2 (boo#1219306)
  • dbus-broker: a big step forward; upgrades seem to be an issue that needs to be addressed
  • libxml 2.12.x: slow progress
  • GCC 14: our usual 2-phase approach to introduce it. Currently working on phase 1, meaning GCC14 will be providing the base libraries (libgcc_s1, libstdc++…). The compiler itself will stay at version 13 for now. Only one issue left: qemu fails to build
the avatar of openSUSE News
the avatar of openSUSE News

Exploring Agama's 2024 Roadmap

A recent post on the YaST blog about Agama’s roadmap looks at the new installer as functional enough to embark on tasks ranging from localization and network configuration to storage setup and initial software selection.

For those who don’t follow the YaST blog, here is what lies ahead for Agama in 2024.

The team has outlined a strategy for this year and, despite the fluidity of its development, the team is committed to a steady release schedule for Agama with two significant milestones. The first is set for mid-April and the other toward mid-July.

The milestone in April is set to revolutionize Agama’s architecture. It will be moving away from its reliance on Cockpit toward a more autonomous framework that is coupled with a refined user interface that aims to streamline storage configurations.

The aim of the second milestone is to improve Agama’s flexibility and capabilities for unattended installations, which seeks to position Agama as a formidable alternative to AutoYaST.

The scaffolding provided by the Cockpit Project makes the vision for Agama’s future clear in evolving a direction of a new path. The coming months will be dedicated to redefining this approach to ensure Agama’s growth is unhindered by external dependencies.

While architectural modifications lay the groundwork for future advancements, an equal focus must be made to enhance the user experience. The revamped storage configuration interface will be both user-friendly for newcomers and more versatile for the experience. This aims to provide a balance of simplicity and customization.

The openSUSE Conference 2024 is nestled between the milestones and the team will make use of this event to serve as a platform for discussing Agama’s potential to redefine the installation experience within the openSUSE ecosystem. insights and contributions are vital to Agama’s success so stakeholders are encouraged to engage with the team, share ideas and participate in the ongoing development of Agama.

Read more information about Agama on the YaST blog.

a silhouette of a person's head and shoulders, used as a default avatar
a silhouette of a person's head and shoulders, used as a default avatar

Nuevo Slimbook Manjaro, otro ultrabook gamer fruto del trabajo colaborativo

Cada cierto tiempo me gusta hablar de Slimbook, la marca de dispositivos 100% compatibles con GNU/Linux por varias razones, entre las que destacan que soy usuario habitual de la marca y que tengo la convicción de que debemos promocionar las empresas que confían en el Sotware Libre. Es por ello que me complace compartir con vosotros que ha sido lanzado el nuevo Slimbook Manjaro, ultrabook gamer fruto del trabajo colaborativo compatible 100 % con GNU/Linux.

Nuevo Slimbook Manjaro, otro ultrabook gamer fruto del trabajo colaborativo

Ya no es complicado encontrar ordenadores portátiles con la posibilidad de disfrutar de un sistema operativo libre. Gracias a compañías como Slimbook esto se ha convertido en un juego de niños, y no solo por la venta de dispositivos con distribuciones GNU/Linux por defecto sino porque te los afinan como solo los profesionales saben hacer para que funcionen a pleno renidmiento (y si no me creéis os remito a este artículo donde un producto puesto a punto por los chicos y chicas de Slimbook barría en las pruebas de rendimiento a ordenadores, en principio, más potentes).

De tal forma que el lanzamiento de un nuevo producto de esta empresa es motivo de alegría ya que demuestra dos que la empresa valenciana siempre está buscando «nuevos mercados» y que no se queda estancada en el pasado, intentando ofrecer las máximas opciones para el usuario.

Según podemos leer en su blog:

En los últimos años, ha habido un crecimiento notable en el soporte para juegos en Linux, gracias a iniciativas como Proton de Valve, que permite que los juegos de Windows se ejecuten en sistemas Linux. Como resultado de este progreso, Slimbook y Manjaro se complacen en anunciar el lanzamiento de su altamente esperado portátil para juegos diseñado para superar las expectativas de juego, el Slimbook Manjaro.

Sumérgete en el universo del juego con aplicaciones preinstaladas como Steam, Heroic Games Launcher, Lutris y muchas más. Accede a una amplia biblioteca de juegos para una experiencia sin problemas desde el principio. Este equipo está listo para manejar los juegos más exigentes con facilidad. Experimenta un rendimiento sin igual y gráficos impresionantes que te sumergirán por completo en cada juego.

Nuevo Slimbook Manjaro, otro ultrabook gamer fruto del trabajo colaborativo

De esta formas nos encontramos un equipo que tiene las siguientes características básicas:

  • Procesador Intel® Core™ i7 de 13ª generación
  • Gráfica NVIDIA® GeForce RTX™ 4060 140W
  • 16GB de memoria RAM ampliable hasta 64GB DDR5 a 5200Mhz
  • 250Gb de disco M.2 NVMe Gen4 y ampliable gracias a su doble Sloth
  • Pantalla LCD IPS de 2560x1440px a 165Hz con 100% de cobertura de sRGB
  • Chasis de aluminio y ABS
  • Teclado completo RGB
Nuevo Slimbook Manjaro, otro ultrabook gamer fruto del trabajo colaborativo

Como vemos, la compañía valenciana no deja de ofrecer novedades, mejorar sus servicios y buscar nuevas formas de llegar a más gente, respetando siempre a la comunidad GNU/Linux.

Por cierto, y como suelo comentar en estos casos, esto tampoco es una entrada patrocinada. Mi relación con Slimbook es de cliente habitual, amistad e intereses mutuos (el dominio del mundo por parte de la filosofía GNU/Linux).

Más información: Slimbook

La entrada Nuevo Slimbook Manjaro, otro ultrabook gamer fruto del trabajo colaborativo se publicó primero en KDE Blog.