Saturday

21 March, 2020

Ish Sookun posted at 16:58

How will people cope with the COVID-19 confinement financially?

People of Mauritius are under a nationwide confinement since 19 March 2020. This confinement is to last for about two weeks, during which people are to remain at home and special permits are given to certain essential services workers to be able to travel only between their home and workplace.

As per the Cabinet Decisions of 20 March 2020, a COVID-19 Wage Support Scheme will provide financial support to  employees who would become technically unemployed on a temporary basis due to the impact of COVID-19. The scheme will cover formal sectors (mainly Travel and Tourism Sector, Export Oriented Enterprises, ICT/BPO Sector and SMEs). This support will be extended to other formal sectors of the economy.

I could not find a proper reference on the Government portal that highlights what are formal sectors but I assume they mean companies duly registered and operating within a defined industry (like the examples given above, Tourism, ICT/BPO etc).

Therefore, I also assume that my neighbourhood dhollpuri seller, carpenters, construction workers, plumbers and labourers will not benefit from the COVID-19 Wage Support Scheme.

My self-employed friends will be left on their own to pay their rents, utility bills and mortgages.

Confinement means no work, which means no income for them. How will they cope financially during this confinement period? What happens if the confinement is extended after the two weeks?

I am a proponent of this confinement which I feel is a necessary step to stop the propagation of COVID-19 on the island. I know the economy will be severely hit but I am also putting my trust in the capable authorities to sustain its people and help them cope financially.

I sincerely hope that the authorities extend the support to more people currently affected by the COVID-19 confinement.

Oreo, cursores simpáticos para Plasma

Aprovechando que mucha gente va a estar pendiente de su ordenador, no es mala idea personalizarlo hasta que es visualmente perfecto para su gusto. Evidentemente, los cursores son parte de esa personalización. Hoy toca hablar de Oreo un pack de cursores originales para Plasma que lo dotarán de un aspecto simpático y agradable.

Oreo, cursores simpáticos para Plasma

Nacidos de la mano y de la mente de x-varlesh-x nos llega Oreo, un tema de cursores de aspecto monocromático, redondeado y muy simpático que seguro que gusta a más de uno.

Se trata de un tema simple con dos resoluciones, 32 y 64, pero con varios colores a instalar de forma independiente: azul, púrpura, rosa, gris y teal (un color entre un color entre el verde-azulado oscuro y el cian oscuro, cuyo nombre en castellano no he encontrado),  y que podéis ver abajo.

Oreo, cursores simpáticos para Plasma

Y como siempre digo, si os gusta este conjunto de cursores Oreo podéis “pagarlo” de muchas formas en la página de KDE Store, que estoy seguro que el desarrollador lo agradecerá: puntúale positivamente, hazle un comentario en la página o realiza una donación. Ayudar al desarrollo del Software Libre también se hace simplemente dando las gracias, ayuda mucho más de lo que os podéis imaginar, recordad la campaña I love Free Software Day 2017 de la Free Software Foundation donde se nos recordaba esta forma tan sencilla de colaborar con el gran proyecto del Software Libre y que en el blog dedicamos un artículo.

Más información: KDE Store

Cómo cambiar el tema de los cursores en Plasma

Al igual que con los iconos hay varias formas de cambiar el tema de cursores en Plasma, pero la más fácil es:

  • Abrir las Preferencias del Sistema
  • Ir a la sección Temas para el espacio de trabajo
  • Ir a la subsección Tema de Cursor.
  • En esta ventana pinchar en “Obtener nuevos temas”
  • Buscar Moonlight y dar a instalar.
  • Seleccionar el tema y aplicar.

Rápido, sencillo y efectivo, como la mayoría de cosas en en el escritorio Plasma de la Comunidad KDE.

 

#openSUSE Tumbleweed revisión de la semanas 11 y 12 de 2020

Tumbleweed es una distribución “Rolling Release” 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 estas semanas.

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

En estas 2 semanas se han pulicado 7 nuevas Snapshots (0305, 0306, 0307, 0309, 0311, 0312 y 0314). Los cambios más notables han sido:

  • Linux kernel 5.5.7
  • Python 3.8.2, con la actualización de numerosos módulos de python
  • Mesa 20.0.1
  • KDE Applications 19.12.3
  • KDE Plasma 5.18.3

Y esto es lo que pronto llegará en próximas actualizaciones:

  • RPM
  • Linux kernel 5.5.10
  • Qt 5.15.0 (actualmente se están testeando las versiones Beta)
  • Ruby 2.7 quizás junto con la eliminación de Ruby 2.6
  • GCC 10 como compilador predeterminado
  • Eliminación de Python 2
  • GNU Make 4.3

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

——————————–

Reducing memory consumption in librsvg, part 2: SpecifiedValues

To continue with last time's topic, let's see how to make librsvg's DOM nodes smaller in memory. Since that time, there have been some changes to the code; that is why in this post some of the type names are different from last time's.

Every SVG element is represented with this struct:

pub struct Element {
    element_type: ElementType,
    element_name: QualName,
    id: Option<String>,
    class: Option<String>,
    specified_values: SpecifiedValues,
    important_styles: HashSet<QualName>,
    result: ElementResult,
    transform: Transform,
    values: ComputedValues,
    cond: bool,
    style_attr: String,
    element_impl: Box<dyn ElementTrait>,
}

The two biggest fields are the ones with types SpecifiedValues and ComputedValues. These are the sizes of the whole Element struct and those two types:

sizeof Element: 1808
sizeof SpecifiedValues: 824
sizeof ComputedValues: 704

In this post, we'll reduce the size of SpecifiedValues.

What is SpecifiedValues?

If we have an element like this:

<circle cx="10" cy="10" r="10" stroke-width="4" stroke="blue"/>

The values of the style properties stroke-width and stroke get stored in a SpecifiedValues struct. This struct has a bunch of fields, one for each possible style property:

pub struct SpecifiedValues {
    baseline_shift:              SpecifiedValue<BaselineShift>,
    clip_path:                   SpecifiedValue<ClipPath>,
    clip_rule:                   SpecifiedValue<ClipRule>,
    /// ...
    stroke:                      SpecifiedValue<Stroke>,
    stroke_width:                SpecifiedValue<StrokeWidth>,
    /// ...
}

Each field is a SpecifiedValue<T> for the following reason. In CSS/SVG, a style property can be unspecified, or it can have an inherit value to force the property to be copied from the element's parent, or it can actually have a specified value. Librsvg represents these as follows:

pub enum SpecifiedValue<T>
where
    T: // some trait bounds here
{
    Unspecified,
    Inherit,
    Specified(T),
}

Now, SpecifiedValues has a bunch of fields, 47 of them to be exact — one for each of the style properties that librsvg supports. That is why SpecifiedValues has a size of 824 bytes; it is the largest sub-structure within Element, and it would be good to reduce its size.

Not all properties are specified

Let's go back to the chunk of SVG from above:

<circle cx="10" cy="10" r="10" stroke-width="4" stroke="blue"/>

Here we only have two specified properties, so the stroke_width and stroke fields of SpecifiedValues will be set as SpecifiedValue::Specified(something) and all the other fields will be left as SpecifiedValue::Unspecified.

It would be good to store only complete values for the properties that are specified, and just a small flag for unset properties.

Another way to represent the set of properties

Since there is a maximum of 47 properties per element (or more if librsvg adds support for extra ones), we can have a small array of 47 bytes. Each byte contains the index within another array that contains only the values of specified properties, or a sentinel value for properties that are unset.

First, I made an enum that fits in a u8 for all the properties, plus the sentinel value, which also gives us the total number of properties. The #[repr(u8)] guarantees that this enum fits in a byte.

#[repr(u8)]
enum PropertyId {
    BaselineShift,
    ClipPath,
    ClipRule,
    Color,
    // ...
    WritingMode,
    XmlLang,
    XmlSpace,
    UnsetProperty, // the number of properties and also the sentinel value
}

Also, since before these changes there was the following monster to represent "which property is this" plus the property's value:

pub enum ParsedProperty {
    BaselineShift(SpecifiedValue<BaselineShift>),
    ClipPath(SpecifiedValue<ClipPath>),
    ClipRule(SpecifiedValue<ClipRule>),
    Color(SpecifiedValue<Color>),
    // ...
}

I changed the definition of SpecifiedValues to have two arrays, one to store which properties are specified, and another only with the values for the properties that are actually specified:

pub struct SpecifiedValues {
    indices: [u8; PropertyId::UnsetProperty as usize],
    props: Vec<ParsedProperty>,
}

There is a thing that is awkward in Rust, or which I haven't found how to solve in a nicer way: given a ParsedProperty, find the corresponding PropertyId for its discriminant. I did the obvious thing:

impl ParsedProperty {
    fn get_property_id(&self) -> PropertyId {
        use ParsedProperty::*;

        match *self {
            BaselineShift(_) => PropertyId::BaselineShift,
            ClipPath(_)      => PropertyId::ClipPath,
            ClipRule(_)      => PropertyId::ClipRule,
            Color(_)         => PropertyId::Color,
            // ...
        }
    }
}

Initialization

First, we want to initialize an empty SpecifiedValues, where every element of the the indices array is set to the sentinel value that means that the corresponding property is not set:

impl Default for SpecifiedValues {
    fn default() -> Self {
        SpecifiedValues {
            indices: [PropertyId::UnsetProperty.as_u8(); PropertyId::UnsetProperty as usize],
            props: Vec::new(),
        }
    }
}

That sets the indices field to an array full of the same PropertyId::UnsetProperty sentinel value. Also, the props array is empty; it hasn't even had a block of memory allocated for it yet. That way, SVG elements without style properties don't use any extra memory.

Which properties are specified and what are their indices?

Second, we want a function that will give us the index in props for some property, or that will tell us if the property has not been set yet:

impl SpecifiedValues {
    fn property_index(&self, id: PropertyId) -> Option<usize> {
        let v = self.indices[id.as_usize()];

        if v == PropertyId::UnsetProperty.as_u8() {
            None
        } else {
            Some(v as usize)
        }
    }
}

(If someone passes id = PropertyId::UnsetProperty, the array access to indices will panic, which is what we want, since that is not a valid property id.)

Change a property's value

Third, we want to set the value of a property that has not been set, or change the value of one that was already specified:

impl SpecifiedValues {
    fn replace_property(&mut self, prop: &ParsedProperty) {
        let id = prop.get_property_id();

        if let Some(index) = self.property_index(id) {
            self.props[index] = prop.clone();
        } else {
            self.props.push(prop.clone());
            let pos = self.props.len() - 1;
            self.indices[id.as_usize()] = pos as u8;
        }
    }
}

In the first case in the if, the property was already set and we just replace its value. In the second case, the property was not set; we add it to the props array and store its resulting index in indices.

Results

Before:

sizeof Element: 1808
sizeof SpecifiedValues: 824

After:

sizeof Element: 1056
sizeof SpecifiedValues: 72

The pathological file from the last time used 463,412,720 bytes in memory before these changes. After the changes, it uses 314,526,136 bytes.

I also measured memory consumption for a normal file, in this case one with a bunch of GNOME's symbolic icons. The old version uses 17 MB; the new version only 13 MB.

How to keep fine-tuning this

For now, I am satisfied with SpecifiedValues, although it could still be made smaller:

  • The crate tagged-box converts an enum like ParsedProperty into an enum-of-boxes, and codifies the enum's discriminant into the box's pointer. This way each variant occupies the minimum possible memory, although in a separately-allocated block, and the container itself uses only a pointer. I am not sure if this is worth it; each ParsedProperty is 64 bytes, but the flat array props: Vec<ParsedProperty> is very appealing in a single block of memory. I have not checked the sizes of each individual property to see if they vary a lot among them.

  • Look for a crate that lets us have the properties in a single memory block, a kind of arena with variable types. This can be implemented with a bit of unsafe, but one has to be careful with the alignment of different types.

  • The crate enum_set2 represents an array of field-less enums as a compact bit array. If we changed the representation of SpecifiedValue, this would reduce the indices array to a minimum.

If someone wants to dedicate some time to implement and measure this, I would be very grateful.

Next steps

According to Massif, the next thing is to keep making Element smaller. The next thing to shrink is ComputedValues. The obvious route is to do exactly the same as I did for SpecifiedValues. I am not sure if it would be better to try to share the style structs between elements.

Reducción del consumo de memoria en librsvg, parte 2: SpecifiedValues

Para continuar con el tema de la vez pasada, vamos a ver cómo reducir el tamaño en memoria de los nodos del DOM en librsvg. Desde entonces ha habido cambios en el código; por eso es que en este artículo los nombres de algunos tipos han cambiado con respecto al artículo anterior.

Cada elemento del SVG se representa con esta estructura:

pub struct Element {
    element_type: ElementType,
    element_name: QualName,
    id: Option<String>,
    class: Option<String>,
    specified_values: SpecifiedValues,
    important_styles: HashSet<QualName>,
    result: ElementResult,
    transform: Transform,
    values: ComputedValues,
    cond: bool,
    style_attr: String,
    element_impl: Box<dyn ElementTrait>,
}

Los dos campos más grandes son los que tienen tipos SpecifiedValues y ComputedValues. He aquí los tamaños de la estructura completa Element y los de esos tipos:

sizeof Element: 1808
sizeof SpecifiedValues: 824
sizeof ComputedValues: 704

En este artículo vamos a reducir el tamaño de SpecifiedValues.

¿Qué es SpecifiedValues?

Si tenemos un elemento así:

<circle cx="10" cy="10" r="10" stroke-width="4" stroke="blue"/>

Los valores de propiedades de estilos stroke-width y stroke se guardan en un SpecifiedValues; esta estructura tiene un montón de campos, uno para cada propiedad de estilos:

pub struct SpecifiedValues {
    baseline_shift:              SpecifiedValue<BaselineShift>,
    clip_path:                   SpecifiedValue<ClipPath>,
    clip_rule:                   SpecifiedValue<ClipRule>,
    /// ...
    stroke:                      SpecifiedValue<Stroke>,
    stroke_width:                SpecifiedValue<StrokeWidth>,
    /// ...
}

Cada campo es un SpecifiedValue<T> por la siguiente razón. En CSS/SVG, una propiedad de estilos puede estar no especificada, o ser inherit para forzar que se copie la propiedad del elemento padre, o un valor específico. Librsvg lo representa así:

pub enum SpecifiedValue<T>
where
    T: // algunos requerimientos de traits aquí
{
    Unspecified,
    Inherit,
    Specified(T),
}

Ahora bien, SpecifiedValues tiene un montón de campos, 47 para ser exactos — uno por cada una de las propiedades de estilos que soporta librsvg. Por eso es que el tamaño de SpecifiedValues es de 824 bytes. Es la sub-estructura más grande dentro de Element, y sería bueno reducirle el tamaño.

No todas las propiedades se especifican

Volvamos a ver el pedacito de SVG de arriba.

<circle cx="10" cy="10" r="10" stroke-width="4" stroke="blue"/>

Aquí sólo se especifican dos de las propiedades, de modo que los campos stroke_width y stroke de SpecifiedValues van a quedar como SpecifiedValue::Specified(algo) y todos los demás van a quedar como SpecifiedValue::Unspecified.

Sería bueno sólo almacenar los valores completos para las propiedades que están especificadas, y una bandera más pequeña para las propiedades que están sin especificar.

Otra forma de representar el conjunto de propiedades

Como hay un máximo de 47 propiedades por elemento (o más si librsvg añade soporte para adicionales), podemos tener un arreglito de 47 bytes. Cada byte contiene el índice en otro arreglo que sólo contiene el valor de una propiedad especificada, o un valor centinela para indicar que la propiedad no está especificada.

Primero hice una enumeración que quepa en un u8 para todas las propiedades, más el valor centinela al final, que además nos da el número total de propiedades. El #[repr(u8)] nos garantiza que ese enum cabe en un byte.

#[repr(u8)]
enum PropertyId {
    BaselineShift,
    ClipPath,
    ClipRule,
    Color,
    // ...
    WritingMode,
    XmlLang,
    XmlSpace,
    UnsetProperty, // el número de propiedades y el valor centinela
}

Además, desde antes ya había este monstruo para representar "cuál propiedad" además del valor de la propiedad:

pub enum ParsedProperty {
    BaselineShift(SpecifiedValue<BaselineShift>),
    ClipPath(SpecifiedValue<ClipPath>),
    ClipRule(SpecifiedValue<ClipRule>),
    Color(SpecifiedValue<Color>),
    // ...
}

Cambié la definición de SpecifiedValues para que tenga dos arreglos, uno que indica qué propiedades están especificadas, y otro sólo con las propiedades especificadas:

pub struct SpecifiedValues {
    indices: [u8; PropertyId::UnsetProperty as usize],
    props: Vec<ParsedProperty>,
}

Hay una cosa que es incómoda en Rust, o que no he sabido resolver mejor: dada una ParsedProperty, hay que encontrar el PropertyId correspondiente para su discriminante. Puse lo obvio:

impl ParsedProperty {
    fn get_property_id(&self) -> PropertyId {
        use ParsedProperty::*;

        match *self {
            BaselineShift(_) => PropertyId::BaselineShift,
            ClipPath(_)      => PropertyId::ClipPath,
            ClipRule(_)      => PropertyId::ClipRule,
            Color(_)         => PropertyId::Color,
            // ...
        }
    }
}

Inicialización

Primero, queremos inicializar un SpecifiedValues vacío, en donde todo los elementos del arreglo indices están puesto al valor sentinela que indica que la propiedad correspondiente no está especificada:

impl Default for SpecifiedValues {
    fn default() -> Self {
        SpecifiedValues {
            indices: [PropertyId::UnsetProperty.as_u8(); PropertyId::UnsetProperty as usize],
            props: Vec::new(),
        }
    }
}

Eso pone el campo indices a un arreglo lleno del valor sentinela PropertyId::UnsetProperty. Además, el arreglo props está vacío; ni siquiera se ha pedido un bloque de memoria para él. Así, los elementos del SVG que no tienen propiedades de estilos no ocupan memoria extra.

¿Qué propiedades están especificadas y cuáles son sus índices?

Segundo, queremos una función que nos dé el índice en props de alguna propiedad, o que nos diga si esa propiedad no está especificada aún:

impl SpecifiedValues {
    fn property_index(&self, id: PropertyId) -> Option<usize> {
        let v = self.indices[id.as_usize()];

        if v == PropertyId::UnsetProperty.as_u8() {
            None
        } else {
            Some(v as usize)
        }
    }
}

(Si alguien pasa id = PropertyId::UnsetProperty, el acceso al arreglo indices va a mandar un panic, que es lo que queremos, pues ese no es identificador válido para una propiedad.)

Cambiar el valor de una propiedad

Tercero, queremos poner el valor de una propiedad que no estaba especificada, o cambiar el valor de una que ya lo estaba:

impl SpecifiedValues {
    fn replace_property(&mut self, prop: &ParsedProperty) {
        let id = prop.get_property_id();

        if let Some(index) = self.property_index(id) {
            self.props[index] = prop.clone();
        } else {
            self.props.push(prop.clone());
            let pos = self.props.len() - 1;
            self.indices[id.as_usize()] = pos as u8;
        }
    }
}

En el primer caso del if, la propiedad ya estaba puesta y nada más remplazamos su valor. En el segundo caso, la propiedad no estaba puesta; la añadimos al arreglo props y guardamos su índice resultante en indices.

Resultados

Antes:

sizeof Element: 1808
sizeof SpecifiedValues: 824

Después:

sizeof Element: 1056
sizeof SpecifiedValues: 72

El archivo patológico de la vez anterior consumía 463,412,720 bytes en memoria antes de estos cambios. Después de los cambios, consume 314,526,136 bytes.

También medí el consumo de memoria de un un archivo normal, en este caso uno con muchos de los iconos simbólicos de GNOME. La versión anterior consume 17 MB; la versión nueva sólo 13 MB.

Cómo seguir ajustando esto

Por ahora, estoy satisfecho con SpecifiedValues, aunque todavía se podría hacer más pequeño:

  • El crate tagged-box convierte un enum como el ParsedProperty en un enum-de-boxes, y codifica el discriminante del enum en el puntero que apunta al box. De esta forma cada variante ocupa el mínimo posible de memoria, aunque se le suma un bloque de memora extra, y el contenedor en sí ocupa un solo puntero. No estoy seguro si valga la pena; cada ParsedProperty ocupa 64 bytes, pero el arreglo plano de props: Vec<ParsedProperty> queda muy lindo en un solo bloque de memoria. No he visto los tamaños de cada propiedad individual para ver si varían mucho entre sí.

  • Buscar un crate para poder tener las propiedades en un sólo bloque de memoria, una especie de arena de tipos variables. Esto se puede implementar con un poquito de unsafe, pero hay que tener cuidado con la alineación de los elementos de diferentes tipos.

  • El crate enum_set2 representa un arreglo de enums sin campos como un arreglo de bits compacto. Si se cambiara la representación de SpecifiedValue, esto reduciría el arreglo indices al mínimo.

Si alguien quiere dedicarle tiempo a implementar y medir algo así, le estaría muy agradecido.

Siguientes pasos

Según Massif, lo siguiente es seguir haciendo que Element sea más pequeño. Lo que sigue de reducir de tamaño es ComputedValues. La opción obvia es hacerle exactamente lo mismo que a SpecifiedValues. No estoy seguro de si vale más la pena intentar compartir las estructuras de estilos entre varios elementos.

Friday

20 March, 2020

Añade sonidos de fondo a tu escritorio con Kbeat – Plasmoides de KDE (137)

La Comunidad KDE nunca deja de sorprenderme, y cuando pienso que no se puede hacer más innovaciones al escritorio me sorprenden con una. Y es que ha aparecido un plasmoide que añade sonidos de fondo a tu escritorio con Kbeat, una pequeña pero maravillosa tontería disponible para Plasma, el entorno de trabajo de KDE.

Añade sonidos de fondo a tu escritorio con Kbeat – Plasmoides de KDE (137)

Debo reconocer que estos días voy algo escaso de temas, y aunque parezca extraño, con el tiempo un poco limitado por motivos estudiantiles. Lo cierto es que he rebuscado un poco entre la magnífica y mutante KDE Store y he encontrado una pequeña joya que me ha encantado.

Se trata de Kbeat, un pequeño plasmoide creado por el prolífico Adhe y que proporciona una serie de sonidos realajantes para utilizar de fondo al utilizar el ordenador. Su funcionamiento es muy sencillo, simplemente se selecciona el sonido (un bosque, el mar, una tormenta, una fogata, etc) y éste entra en bucle, proporcionando un ambiente especial a tus horas de trabajo. Evidentemente puedes pararlo y se integra en cualquier barra de tareas.

Añade sonidos de fondo a tu escritorio con Kbeat - Plasmoides de KDE (137)

Y como siempre digo, si os gusta el plasmoide podéis “pagarlo” de muchas formas en la nueva página de KDE Store, que estoy seguro que el desarrollador lo agradecerá: puntúale positivamente, hazle un comentario en la página o realiza una donación. Ayudar al desarrollo del Software Libre también se hace simplemente dando las gracias, ayuda mucho más de lo que os podéis imaginar, recordad la campaña I love Free Software Day de la Free Software Foundation donde se nos recordaba esta forma tan sencilla de colaborar con el gran proyecto del Software Libre y que en el blog dedicamos un artículo.

 

Más información: KDE Store

¿Qué son los plasmoides?

Para los no iniciados en el blog, quizás la palabra plasmoide le suene un poco rara pero no es mas que el nombre que reciben los widgets para el escritorio Plasma de KDE.

En otras palabras, los plasmoides no son más que pequeñas aplicaciones que puestas sobre el escritorio o sobre una de las barras de tareas del mismo aumentan las funcionalidades del mismo o simplemente lo decoran.

openSUSE Tumbleweed – Review of the week 2020/11 & 12

Dear Tumbleweed users and hackers,

Last week I missed, for personal reasons, to write up the report. So, slacking in one week means I have to catch up the other week. Of course, you are all eager to hear/read what is happening in Tumbleweed. In the period since covered, we have released 7 Snapshots (0305, 0306, 0307, 0309, 0311, 0312 and 0314). The major changes were:

  • Linux kernel 5.5.7
  • Python 3.8.2, with a lot of python modules being updated
  • Mesa 20.0.1
  • KDE Applications 19.12.3
  • KDE Plasma 5.18.3

Thins currently being staged or close to be shipped:

  • RPM: change of database format to ndb
  • Linux kernel 5.5.10
  • Qt 5.15.0 (currently betas being tested)
  • Ruby 2.7 – possibly paired with the removal of Ruby 2.6
  • GCC 10 as the default compiler
  • Removal of Python 2
  • GNU Make 4.3

Crea tu blog o web con un simple script de bash

Bashblog es un simple script escrito en bash que nos permite crear nuestro blog o web en nuestro servidor de una manera sencilla, simple y sin dependencias extras

Ejemplo de web utilizando bashblog

Ahora están muy de moda los generadores de sitio estáticos como Jekyll, Pelican, Hugo y muchos otros que existen para crear sitios web estáticos, frente a los dinámicos que requieren más funcionalidades.

Esos generadores de sitios web, están escrito en lenguajes como Ruby y otros y requieren de ciertas dependencias a la hora de crear nuestros sitios en un servidor propio.

Frente a esas opciones hoy quiero hablaros sobre la herramienta bashblog, un script escrito en Bash creado por Carlos Fenollosa, que sirve para crear nuestro propio blog.

La idea es ejecutarlo en una carpeta pública de nuestro servidor, y ejecutarlo. Este script nos permite crear los artículos en nuestro editor favorito y al guardarlos, creará todo lo necesario para generar el archivo index.html en nuestro servido y generar así nuestro blog.

Lo podemos adaptar fácilmente a nuestras especificaciones, como: nuestro nombre, nombre del blog, descripción, url, formas de contacto, etc.

Y nos genera el archivo css, que podemos editar para adaptarlo a nuestros gustos, nos genera un feed, al que se pueden suscribir nuestros lectores, soporta etiquetado de artículos, etc.

En el siguiente video tutorial alojado en archive.org en formato .webm lo puedes ver en funcionamiento y ver lo sencillo y completo que es el script.

También está disponible en YouTube para quien prefiera esta plataforma:

https://www.youtube.com/watch?v=7Gh6Rt1NKFQ

¿Quizás es la herramienta que estabas buscando para crear tu pequeña web o blog personal?

Ish Sookun posted at 18:04

Nationwide confinement announced in Mauritius

The Prime MInister of Mauritius had a press conference scheduled at 14h30 today. 1.5 hours later it was canceled and journalists were told that the PM will address the nation directly later.

At around 21h30 Prime Minister P. K. Jugnauth addressed the population through the national TV, Mauritius Broadcasting Corporation. It appeared to be a recorded message.

P. K. Jugnauth announced that four new cases of COVID-19 have been registered today. This makes the total cases of COVID-19 rise to seven in Mauritius. This number is high enough to raise the alarms now.

He announced nationwide confinement starting 06h00 tomorrow to last for two weeks. He assured the population that there won't be shortage of staple food and medicine. He also assured people working in the private sector that their salary won't be affected.

YaST Team posted at 16:00

Highlights of YaST Development Sprint 95

Contents

Due to recent events, many companies all over the world are switching to a remote working model, and SUSE is not an exception. The YaST team is distributed so, for many members, it is not a big deal because they are already used to work in this way. For other folks it might be harder. Fortunately, SUSE is fully supporting us in this endeavor, so the YaST team has been able to deliver quite some stuff during this sprint, and we will keep doing our best in the weeks to come.

Before jumping into what the team has recently done, we would also like to bring your attention to the migration of our blog from the good old openSUSE Lizards blog platform to the YaST website. So, please, if you use some feeds reader, update the YaST blog URL to the new one.

Now, as promised, let’s talk only about software development. These days we are mainly focused on fixing bugs to make the upcoming (open)SUSE releases shine. However, we still have time to introduce some important improvements. Among all the changes, we will have a look at the following ones:

Expanding the Possibilities of Pervasive Encryption

Some months ago, in this dedicated blog post, we introduced the joys and benefits of the so-called pervasive encryption available for s390 mainframes equipped with a Crypto Express cryptographic coprocessor. As you may remember (and you can always revisit the post if you don’t), those dedicated pieces of hardware ensure the information at-rest in any storage device can only be read in the very same system where that information was encrypted.

But, what is better than a cryptographic coprocessor? Several cryptographic coprocessors! An s390 logical partition (LPAR) can have access to multiple crypto express adapters, and several systems can share every adapter. To configure all that, the concept of cryptographic domains is used. Each domain is protected by a master key, thus preventing access across domains and effectively separating the contained keys.

Now YaST detects when it’s encrypting a device in a system with several cryptographic domains. If that’s the case, the dialog for pervasive encryption allows specifying which adapters and domains must be used to generate the new secure key.

To succeed, all the used adapters/domains must be set with the same master key. If that’s not the case, YaST detects the circumstance and displays the corresponding information.

Install Missing Packages during Storage System Analysis

As our reader surely knows, YaST always ensures the presence of all the needed utilities when performing any operation in the storage devices, like formatting and/or encrypting them. If some necessary tool is missing in the system, YaST has always shown the following dialog to alert the user and to allow to install the missing packages with a single click.

But the presence of those tools was only checked at the end of the process, when YaST needed them to modify the devices. For example, in the screenshot above, YaST asked for btrfsprogs & friends because it wanted to format a new partition with that file system.

If the needed utility was already missing during the initial phase in which the storage devices are analyzed, the user had no chance to install the corresponding package. For example, if a USB stick formatted with Btrfs would have been inserted, the user would get an error like this when executing the YaST Partitioner or when opening the corresponding YaST module to configure the bootloader.

Btrfs old error message

Now that intimidating error is replaced by this new pop-up that allows to install the missing packages and restart the hardware probing. As usual, with YaST, expert users can ignore the warning and continue the process if they understand the consequences outlined in the new pop-up window.

Probe callback

We took the opportunity to fix other small details in the area, like better reporting when the YaST Partitioner fails to install some package, a more up-to-date list of possibly relevant packages per technology, and improvements in the source code organization and the automated tests.

Reporting Conflicting Storage Attributes in AutoYaST Profiles

If you are an AutoYaST user, you undoubtely know that it is often too quiet and offers little information about inconsistencies or potential problems in the profile. For simple sections, it is not a problem at all, but for complicated stuff, like partitioning, it is far from ideal.

In (open)SUSE 15 and later versions, and given that we had to reimplement the partitioning support using the new storage layer, we decided to add a mechanism to report some of those issues like missing attributes or invalid values. There is a high chance that, using an old profile in newer AutoYaST versions, you have seen some of those warnings.

Recently, a user reported a problem that caused AutoYaST to crash. While debugging the problem, we found both raid_name and lvm_group attributes defined in one of the partition sections. Obviously, they are mutually exclusive, but it is quite easy to overlook this situation. Not to mention that AutoYaST should not crash.

From now on, if AutoYaST detects such an inconsistency, it will automatically select one of the specified attributes, informing the user about the decision. You can see an example in the screenshot below.

AutoYaST conflicting attributes warning

For the time being, this check only applies to those attributes which determine how a device is going to be used (mount, raid_name, lvm_name, btrfs_name, bcache_backing_for, and bcache_caching_for), but we would like to extend this check in the future.

Usability Improvements in iSCSI-LIO-server Module

Recently, one of our developers detected several usability problems in the iSCSI LIO Server module, and he summarized them in a bug report. Apart from minor things, like some truncated and misaligned texts, he reported the UI to be quite confusing: it is not clear when authentication credentials are needed, and some labels are misleading. To add insult to injury, we found a potential crash when clicking the Edit button while we were addressing those issues.

As usual, a image is worth a thousand words. Below you can see how the old and confusing UI looked like.

Old iSCSI LIO Server Module UI

Now, let’s compare it with the new one, which is better organized and more approachable. Isn’t it?

New iSCSI LIO Server Module UI

Conclusion

It is possible that, during the upcoming weeks, we need to make some further adjustments to our workflow, especially when it comes to video meetings. But, at this point, everything is working quite well, and we are pretty sure that we will keep delivering at a good pace.

So, take care, and stay tuned!