AutoYaST is a crucial tool for our users, including customers and partners. So it was clear from the beginning that D-Installer should be able to install a system in an unattended manner.

This article describes the status of this feature and gives some hints about our plans. But we want to emphasize that nothing is set in stone (yet), so constructive comments and suggestions are more than welcome.

The architecture​

When we started to build D-Installer, one of our design goals was to keep a clear separation of concerns between all the components. For that reason, the core of D-Installer is a D-Bus service that is not coupled to any user interface. The web UI connects to that interface to get/set the configuration settings.

In that regard, the system definition for auto-installation is another user interface. The D-Bus service behaves the same whether the configuration is coming from a web UI or an auto-installation profile. Let me repeat again: we want a clear separation of concerns.

Following this principle, the download, evaluation and validation of installation profiles are performed by our new command-line interface. Having an external tool to inject the profile can enable some interesting use cases, as you will discover if you keep reading.

Replacing XML with Jsonnet​

Although you might have your own list, there are a few things we did not like about AutoYaST profiles:

• XML is an excellent language for many use cases. But, in 2023, there are more concise alternatives for an automated installation system.
• They are rather verbose, especially with all those type annotations and how collections are specified.
• Runtime validation, based on libxml2, is rather poor. And jing is not an option for the installation media.

For that reason, we had a look at the landscape of declarative languages and we decided to adopt Jsonnet, by Google. It is a superset of JSON, adding variables, functions, imports, etc. A minimal profile looks like this:

{
  software: {
    product: 'ALP',
  },
  user: {
    fullName: 'Jane Doe',
    userName: 'jane.doe',
    password: '123456',
  }
}

But making use of Jsonnet features, we can also have dynamic profiles, replacing rules/classes or ERB with a single and better alternative for this purpose. Let's have a look to a complex profile:

local dinstaller = import 'hw.libsonnet';
local findBiggestDisk(disks) =
  local sizedDisks = std.filter(function(d) std.objectHas(d, 'size'), disks);
  local sorted = std.sort(sizedDisks, function(x) x.size);
  sorted[0].logicalname;

{
  software: {
    product: 'ALP',
  },
  user: {
    fullName: 'Jane Doe',
    userName: 'jane.doe',
    password: '123456',
  },
  // look ma, there are comments!
  localization: {
    language: 'en_US',
    keyboard: 'en_US',
  },
  storage: {
    devices: [
      {
        name: findBiggestDisk(dinstaller.disks),
      },
    ],
  },
  scripts: [
    {
      type: 'post',
      url: 'https: //myscript.org/test.sh',
    },
    {
      type: 'pre',
      source: |||
        #!/bin/bash

        echo hello
      |||,
    },
  ],
}

This Jsonnet file is evaluated and validated at installation time, generating a JSON profile where the findBiggestDisk(dinstaller.disks) is replaced with the name of the biggest disk.

Beware that defining the format is still a work in progress, so those examples might change in the future.

Replacing the profile with an script​

While working on the auto-installation support, we thought allowing our users to inject a script instead of a profile might be a good idea. That script could use the command-line interface to interact with D-Installer. Somehow, you would be able to set up your own auto-installation system.

#!/bin/bash

dinstaller config set software.product="Tumbleweed"
dinstaller config add storage.devices name=/dev/sda
dinstaller wait
dinstaller install

Please, bear in mind that it is just an idea, but we want to explore where it takes us.

Better integration with other tools​

Integrating AutoYaST with other tools could be tricky because it does not provide a mechanism to report the installation progress. Again through our CLI, we plan to solve that problem by providing such a mechanism which, to be honest, is already available in many configuration systems.

What about backward compatibility?​

In case you are wondering, we have plans to (partially) support good old AutoYaST profiles too. We know that many users have invested heavily in their profiles and we do not want all that work to be gone. However, not all the AutoYaST features will be present in D-Installer, so please expect some changes and limitations.

We now have a small tool that fetches, evaluates and validates an AutoYaST profile, generating a JSON-based one. It is far from finished, but it is a good starting point.

Current status​

Now let's answer the obvious question: which is the current status? We expect to deliver the basic functionality in the following release of D-Installer, but with quite some limitations.

• The user interface is still needed to answer questions or watch the progress.
• Dynamic profiles are supported, but the hardware information injected in the profiles is incomplete.
• A mechanism for error reporting is missing.
• iSCSI and DASD are not supported in auto-installation yet.

Closing thoughts​

We hope we have addressed your main concerns about the auto-installation support in D-Installer. As you may see, it is still a work in progress, but we expect to shape the implementation in the upcoming releases to have 1st class support for unattended installation sooner than later.

If you have any further questions, please, let us know.

AutoYaST is a crucial tool for our users, including customers and partners. So it was clear from the beginning that D-Installer should be able to install a system in an unattended manner.

This article describes the status of this feature and gives some hints about our plans. But we want to emphasize that nothing is set in stone (yet), so constructive comments and suggestions are more than welcome.

The architecture

When we started to build D-Installer, one of our design goals was to keep a clear separation of concerns between all the components. For that reason, the core of D-Installer is a D-Bus service that is not coupled to any user interface. The web UI connects to that interface to get/set the configuration settings.

In that regard, the system definition for auto-installation is another user interface. The D-Bus service behaves the same whether the configuration is coming from a web UI or an auto-installation profile. Let me repeat again: we want a clear separation of concerns.

Following this principle, the download, evaluation and validation of installation profiles are performed by our new command-line interface. Having an external tool to inject the profile can enable some interesting use cases, as you will discover if you keep reading.

Replacing XML with Jsonnet

Although you might have your own list, there are a few things we did not like about AutoYaST profiles:

• XML is an excellent language for many use cases. But, in 2023, there are more concise alternatives for an automated installation system.
• They are rather verbose, especially with all those type annotations and how collections are specified.
• Runtime validation, based on libxml2, is rather poor. And Jing is not an option for the installation media.

For that reason, we had a look at the landscape of declarative languages and we decided to adopt Jsonnet, by Google. It is a superset of JSON, adding variables, functions, imports, etc. A minimal profile looks like this:

{
  software: {
    product: 'ALP',
  },
  user: {
    fullName: 'Jane Doe',
    userName: 'jane.doe',
    password: '123456',
  }
}

But making use of Jsonnet features, we can also have dynamic profiles, replacing rules/classes or ERB with a single and better alternative for this purpose. Let’s have a look to a complex profile:

local dinstaller = import 'hw.libsonnet';
local findBiggestDisk(disks) =
  local sizedDisks = std.filter(function(d) std.objectHas(d, 'size'), disks);
  local sorted = std.sort(sizedDisks, function(x) x.size);
  sorted[0].logicalname;

{
  software: {
    product: 'ALP',
  },
  user: {
    fullName: 'Jane Doe',
    userName: 'jane.doe',
    password: '123456',
  },
  // look ma, there are comments!
  localization: {
    language: 'en_US',
    keyboard: 'en_US',
  },
  storage: {
    devices: [
      {
        name: findBiggestDisk(dinstaller.disks),
      },
    ],
  },
  scripts: [
    {
      type: 'post',
      url: 'https: //myscript.org/test.sh',
    },
    {
      type: 'pre',
      source: |||
        #!/bin/bash

        echo hello
      |||,
    },
  ],
}

This Jsonnet file is evaluated and validated at installation time, generating a JSON profile where the findBiggestDisk(dinstaller.disks) is replaced with the name of the biggest disk.

Beware that defining the format is still a work in progress, so those examples might change in the future.

Replacing the profile with an script

While working on the auto-installation support, we thought allowing our users to inject a script instead of a profile might be a good idea. That script could use the command-line interface to interact with D-Installer. Somehow, you would be able to set up your own auto-installation system.

#!/bin/bash

dinstaller config set software.product="Tumbleweed"
dinstaller config add storage.devices name=/dev/sda
dinstaller wait
dinstaller install

Please, bear in mind that it is just an idea, but we want to explore where it takes us.

Better integration with other tools

Integrating AutoYaST with other tools could be tricky because it does not provide a mechanism to report the installation progress. Again through our CLI, we plan to solve that problem by providing such a mechanism which, to be honest, is already available in many configuration systems.

What about backward compatibility?

In case you are wondering, we have plans to (partially) support good old AutoYaST profiles too. We know that many users have invested heavily in their profiles and we do not want all that work to be gone. However, not all the AutoYaST features will be present in D-Installer, so please expect some changes and limitations.

We now have a small tool that fetches, evaluates and validates an AutoYaST profile, generating a JSON-based one. It is far from finished, but it is a good starting point.

Current status

Now let’s answer the obvious question: which is the current status? We expect to deliver the basic functionality in the following release of D-Installer, but with quite some limitations.

• The user interface is still needed to answer questions or watch the progress.
• Dynamic profiles are supported, but the hardware information injected in the profiles is incomplete.
• A mechanism for error reporting is missing.
• iSCSI and DASD are not supported in auto-installation yet.

Closing thoughts

We hope we have addressed your main concerns about the auto-installation support in D-Installer. As you may see, it is still a work in progress, but we expect to shape the implementation in the upcoming releases to have 1st class support for unattended installation sooner than later.

If you have any further questions, please, let us know.

A inteligência artificial ChatGPT atraiu o interesse em diferentes campos de atuação, pois oferece uma interface de linguagem com impressionante competência conversacional e capacidade de raciocínio em vários domínios. Mas como o ChatGPT é treinado com linguagens, atualmente ele não é capaz de processar ou gerar imagens do mundo visual.

Na contra partida, modelos como Transformers ou Stable Diffusion, apesar de mostrarem grande compreensão e capacidade de geração imagem, eles são especialistas em tarefas específicas com entradas e saídas de uma única vez.

Então para facilitar esta integração entre ambos recursos, foi construído um sistema chamado Visual ChatGPT (ACABEI DE INSTALA NA MINHA MAQUINA!), incorporando diferentes Modelos para processamento de imagem. Assim permitindo que o usuário interaja com o ChatGPT enviando e recebendo não apenas textos, mas também imagens.

É possível também fornecer questões de imagens complexas ou instruções de edição imagens que exigem a colaboração de vários modelos de IA com etapas múltiplas. Podemos contar com o recursos de envio de feedback e solicitar correções do trabalho processado. Foi desenvolvido uma série de prompts para injetar as informações do modelo visual no ChatGPT, considerando modelos de múltiplas entradas/saídas e modelos que trabalham com feedback visual.

Os experimentos que efetuei mostram que o Visual ChatGPT abre a porta para analisar imagens no ChatGPT com a ajuda dos Modelos de Visão Computacional. O sistema está disponível com o código fonte aqui: https://github.com/microsoft/visual-chatgpt

Instruções de Instalação

# Download do repositório
git clone https://github.com/microsoft/visual-chatgpt.git

# Entre na pasta recém criada
cd visual-chatgpt

# Crie um ambiente com python 3.8
conda create -n visgpt python=3.8

# Ative o ambiente recém criado.
conda activate visgpt

#  Instale os requisitos básicos
pip install -r requirements.txt

# Insira a sua licença
export OPENAI_API_KEY={Your_Private_Openai_Key}

# comando para 4 GPUs Tesla V100 32GB                            
python visual_chatgpt.py --load "ImageCaptioning_cuda:0,ImageEditing_cuda:0,Text2Image_cuda:1,Image2Canny_cpu,CannyText2Image_cuda:1,Image2Depth_cpu,DepthText2Image_cuda:1,VisualQuestionAnswering_cuda:2,InstructPix2Pix_cuda:2,Image2Scribble_cpu,ScribbleText2Image_cuda:2,Image2Seg_cpu,SegText2Image_cuda:2,Image2Pose_cpu,PoseText2Image_cuda:2,Image2Hed_cpu,HedText2Image_cuda:3,Image2Normal_cpu,NormalText2Image_cuda:3,Image2Line_cpu,LineText2Image_cuda:3"

Memória utilizada da GPU

Aqui listamos o uso de memória da GPU para cada modelo, você pode especificar qual deles você deseja utilizar:

A inteligência artificial ChatGPT atraiu o interesse em diferentes campos de atuação, pois oferece uma interface de linguagem com impressionante competência conversacional e capacidade de raciocínio em vários domínios. Mas como o ChatGPT é treinado com linguagens, atualmente ele não é capaz de processar ou gerar imagens do mundo visual.

Na contra partida, modelos como Transformers ou Stable Diffusion, apesar de mostrarem grande compreensão e capacidade de geração imagem, eles são especialistas em tarefas específicas com entradas e saídas de uma única vez.

Então para facilitar esta integração entre ambos recursos, foi construído um sistema chamado Visual ChatGPT (ACABEI DE INSTALA NA MINHA MAQUINA!), incorporando diferentes Modelos para processamento de imagem. Assim permitindo que o usuário interaja com o ChatGPT enviando e recebendo não apenas textos, mas também imagens.

É possível também fornecer questões de imagens complexas ou instruções de edição imagens que exigem a colaboração de vários modelos de IA com etapas múltiplas. Podemos contar com o recursos de envio de feedback e solicitar correções do trabalho processado. Foi desenvolvido uma série de prompts para injetar as informações do modelo visual no ChatGPT, considerando modelos de múltiplas entradas/saídas e modelos que trabalham com feedback visual.

Os experimentos que efetuei mostram que o Visual ChatGPT abre a porta para analisar imagens no ChatGPT com a ajuda dos Modelos de Visão Computacional. O sistema está disponível com o código fonte aqui: https://github.com/microsoft/visual-chatgpt

Instruções de Instalação

# Download do repositório
git clone https://github.com/microsoft/visual-chatgpt.git

# Entre na pasta recém criada
cd visual-chatgpt

# Crie um ambiente com python 3.8
conda create -n visgpt python=3.8

# Ative o ambiente recém criado.
conda activate visgpt

#  Instale os requisitos básicos
pip install -r requirements.txt

# Insira a sua licença
export OPENAI_API_KEY={Your_Private_Openai_Key}

# comando para 4 GPUs Tesla V100 32GB                            
python visual_chatgpt.py --load "ImageCaptioning_cuda:0,ImageEditing_cuda:0,Text2Image_cuda:1,Image2Canny_cpu,CannyText2Image_cuda:1,Image2Depth_cpu,DepthText2Image_cuda:1,VisualQuestionAnswering_cuda:2,InstructPix2Pix_cuda:2,Image2Scribble_cpu,ScribbleText2Image_cuda:2,Image2Seg_cpu,SegText2Image_cuda:2,Image2Pose_cpu,PoseText2Image_cuda:2,Image2Hed_cpu,HedText2Image_cuda:3,Image2Normal_cpu,NormalText2Image_cuda:3,Image2Line_cpu,LineText2Image_cuda:3"

Memória utilizada da GPU

Aqui listamos o uso de memória da GPU para cada modelo, você pode especificar qual deles você deseja utilizar:

I recently encountered a new interesting openQA issue:

[2023-03-13T14:18:22.651705+01:00] [warn] [pid:18929] !!! : qemu-system-x86_64: -netdev tap,id=qanet0,ifname=tap3,script=no,downscript=no: could not configure /dev/net/tun (tap3): Operation not permitted

This is an error that you likely are encountering on a older openQA instance, after you setup multimachine jobs but haven’t used them in a while. For me the solution was to grant the CAP_NET_ADMIN capabilities to the qemu binary (again):

Siguiendo la estela de Akademy-es 2022, el próximo encuentro de la Comunidad española de KDE se celebrará de forma presencial en Málaga el 9 y 10 de junio junto con Opensouthcode. Estamos todavia a unos meses y es el momento de comentar que se acaba de abrir el Call for Papers, es decir, el momento de participar activamente en el evento. Así que ya sabes: presenta tu charla a Akademy-es 2023 y muestra al mundo tu proyecto.

Presenta tu charla a Akademy-es 2023 de Málaga Opensouthcode edition #akademyes

Hace unos días compartí con vosotros que este año Akademy-es 2023 se va a realizar en Málaga el 9 y 10 de junio, en otra edición muy especial ya que se va a celebrar de forma paralela con la Opensouthcode en La Térmica.

Siguiendo el esquema habitual cuando coincide con una Akademy, las charlas se celebrarán el jueves y el viernes, para dejar libre el fin de semana para las ponencias el evento Internacional.

Dado la realización de esta Akademy-es con la Opensouthcode, las charlas se celebrarán el viernes y el sábado, dejando el domingo para alguna actividad social, si es posible.

Si crees que tienes algo importante que presentar, por favor házselo saber a la organización. Y si crees que alguien debería presentar su ponencia, no dejes de animarlo para que lo haga. Todas las contribuciones son útiles.

Para más detalles, mira las líneas generales del Call for Papers. Tienes de plazo para enviar tu propuesta hasta el domingo 2 de abril 23:59:59 CEST al correo akademy-es-org@kde-espana.org.

Es importante tener en cuenta las siguientes consideraciones:

• Se puede elegir entre dos formatos de charlas:
  • Charlas de 45 minutos.
  • Charlas relámpago (Lightning talk) de 10 minutos.
• Si la duración de las charlas propuestas no se ajusta a ninguno de estos dos esquemas (por ejemplo, si se necesita más tiempo), esto debe indicarse claramente en la comunicación.
• Se permitirá a KDE España la distribución bajo una licencia libre de todo el material utilizado para la realización de la actividad, así como de la grabación de la misma.
• La charla puede ser tanto a nivel de usuario como de nivel técnico.

¿Qué es Akademy-es?

Akademy-es (#akademyes, que es la etiqueta para las redes sociales) es evento más importante para los desarrolladores y simpatizantes de KDE, que se ha ido celebrando desde el 2006 con éxito creciente.

En general, las Akademy-es son el lugar adecuado para conocer a los desarrolladores, diseñadores, traductores, usuarios y empresas  que mueven este gran proyecto.

En ellas se realizan ponencias, se presentan programas, se hace un poco de caja para los proyectos libres (camisetas, chapas, etc) pero sobre todo se conoce a gente muy interesante y se cargan baterías para el futuro.

Podéis repasar las anteriores ediciones en estas entradas del blog:

• Camino Akademy-es 2013: Las anteriores ediciones (I): 2006 – 2008
• Camino Akademy-es 2013: Las anteriores ediciones (II): 2009-2010
• Camino Akademy-es 2013: Las anteriores ediciones (III): 2011-2012
• Anteriores ediciones de Akademy-es (IV): 2013 y 2014

La entrada Presenta tu charla a Akademy-es 2023 de Málaga Opensouthcode edition #akademyes se publicó primero en KDE Blog.

Finalizo el repaso de la gran actualización del último entorno de trabajo de la Comunidad KDE. La inicié con la presentación con el nuevo asistente de bienvenida, continué con el nuevo mosaico, le siguió las Preferencias de Sistema , Discover, Krunner y los plasmoides. Hoy toca terminar este repaso con las novedades de Wayland en Plasma 5.27 edición ‘KDE Free Software’, que sigue afinando y ya puede considerarse muy maduro y óptimo para la mayoría de usuarios.

Las novedades de Wayland en Plasma 5.27 edición ‘KDE Free Software’

La Comunidad KDE anunció y publicó el 14 de febrero la última versión la rama 5.x de su escritorio. Se trata de de Plasma 5.27, una versión que nos ofrecen un gran conjunto de novedades y propuestas que nos acercan a lo que vendrá cuando se realice la transición a Plasma 6.

Muchas son las nuevas funcionalidades que he desgranando artículo y artíiculo, y hoy, como decía en la introducción, finalizo la serie con las novedades de Waylando, el gestor gráfico que moderniza aún más las opciones gráficas de nuestro entorno de trabajo.

La migración de Plasma a la nueva tecnología del servidor de visualización Wayland no ha resultado fácil. Pero a pesar de lo duro que ha sido el trabajo, merece la pena, ya que Wayland abre muchas formas nuevas de interactuar con el escritorio. La compatibilidad con Wayland en Plasma 5.27 es mejor que nunca, con muchos problemas solucionados y mejoras de fiabilidad por todas partes.

Además, los artistas se alegrarán al saber que las aplicaciones de diseño, como Krita, ya tienen en cuenta la inclinación y la rotación del lápiz en las tabletas de dibujo. Plasma sobre Wayland también permite el uso de ruedas de desplazamiento de alta resolución, con lo que podrá moverse con más suavidad a través de vistas largas.

Plasma en Wayland también es compatible con el portal de Accesos directos globales. Esto permite que las aplicaciones de Wayland ofrezcan una interfaz de usuario estandarizada para configurar y editar accesos directos globales.

Finalmente, Plasma en Wayland es ahora más inteligente a la hora de definir factores de escalado apropiados para sus pantallas de forma automática, para que no tenga que hacerlo usted mismo.

Las novedades de Plasma 5.27

No quiero dejar de hablar de las novedades en general que nos han facilitaron inicialmente los desarrolladores para que tengamos una visión general.

• Nuevas pantallas de bienvenida.
• Mejoras en las preferencias de permisos para Flatpak.
• Mejoras en la refactorización multimonitor.
• Sistema de mosaicos de KWin.
• Añadido el Calendario Hebreo en el calendario emergente del reloj digital.
• Mejoras en Discover.
• Más funcionalidades para Krunner.
• Mejoras en los plasmoides.

En los próximas entradas más detalles.

La entrada Las novedades de Wayland en Plasma 5.27 edición ‘KDE 💖 Free Software’ se publicó primero en KDE Blog.

Me complace anunciar la actualización de marzo del 2023 de KDE Frameworks. Con esta se llega a la versión 5.104 que evidencia el compromiso y constancia que no tiene un final cercano, a no ser que consideremos el salto al número 6 dado que ya se está haciendo la migración a Qt 6..

Actualización de marzo del 2023 de KDE Frameworks

A pesar de que para los usuarios corrientes esta noticia sea algo confusa ya que no se trata de realzar una nueva aplicación ni de una nueva gran funcionalidad del escritorio, el desarrollo de KDE Frameworks tiene repercusiones directas en él a medio y largo plazo.

La razón de esta afirmación es que KDE Frameworks es básicamente la base de trabajo de los desarrolladores para realizar sus aplicaciones, es como el papel y las herramientas de dibujo para un artista: cuanto mejor sea el papel y mejores pinceles tenga, la creación de una artista será mejor.

De esta forma, las mejoras en KDE Frameworks facilitan el desarrollo del Software de la Comunidad KDE, haciendo que su funcionamiento, su estabilidad y su integración sea la mejor posible.

El 11 de marzo de 2023 fue lanzado KDE Frameworks 5.104 la nueva revisión del entorno de programación sobre el que se asienta Plasma 5, el escritorio GNU/Linux de la Comunidad KDE, y las aplicaciones que se crean con para él.

Más información: KDE

La constancia del equipo de desarrollo de la Comunidad KDE

Hay que recordar que los desarrolladores de KDE decidieron lanzar actualizaciones mensuales de este proyecto y lo están cumpliendo con puntualmente. La idea es ofrecer pocas pero consolidadas novedades, a la vez que se mantiene el proyecto evolucionando y siempre adaptándose al vertiginoso mundo del Software Libre.

Una gran noticia para la Comunidad KDE que demuestra la evolución continua del proyecto que continua ganando prestigio en el mundo de los entornos de trabajo Libres.

¿Qué es KDE Frameworks?

Para los que no lo sepan, KDE Frameworks añade más de 70 librerías a Qt que proporcionan una gran variedad de funcionalidades necesarias y comunes, precisadas por los desarrolladores, testeadas por aplicaciones especí­ficas y publicadas bajo licencias flexibles. Como he comentado, este entorno de programación es la base para el desarrollo tanto de las nuevas aplicaciones KDE y del escritorio Plasma 5.

Aquí podéis encontrar un listado con todos estos frameworks y la serie de artículos que dedico a KDE Frameworks en el blog,

Recuerda que puedes ver una introducción a Frameworks 5.0 en su anuncio de lanzamiento.

La entrada Actualización de marzo del 2023 de KDE Frameworks se publicó primero en KDE Blog.