Me complace compartir con vosotros el episodios de septiembre de 2023 de GNU/Linux València en el que hablan un poco de todo como la utilización de un sextante de rayos cósmicos como alternativa al GPS o que Linux pasa a MacOS en Steam:.

Episodio de septiembre de 2023 los podcast de GNU/Linux València

Tras bastante tiempo en silencio, básicamente porque no tenían forma de cuadrar agendas, han vuelto con mucha fuerza los podcast de GNU/Linux València. Unos podcast que suelen ser de tipo tertulia muy amena y destinada a todo el mundo.

Podcast del 27 de septiembre

El primer podcast después de vacaciones ya está aquí. Grabado el 3 de septiembre y lleva por título «Steam, freeBSD y más». Una serie de noticias que destacan porque al final todo acaba en que Linux está en todos los sitios menos en los ordenadores de sobremesa o portátiles de los usuarios. En fin.

Más información: Podcast 27 de septiembnre de GNU/Linux València

¡Únete a GNU/Linux València!

Aprovecho para recordar que desde hace unos meses, los chicos de GNU/Linux Valencia ya tienen su menú propio en el blog, con lo que seguir sus eventos en esta humilde bitácora será más fácil que nunca, y así podréis comprobar su alto nivel de actividades que realizan que destacan por su variedad.

Y que además, GNU/Linux València creció y se ha convertió en asociación. Así que si buscas una forma de colaborar con el Software Libre, esta asociación puede ser tu sitio. ¡Te esperamos!

La entrada Episodio de septiembre de 2023 los podcast de GNU/Linux València se publicó primero en KDE Blog.

En pocos meses vamos a tener un nuevo lanzamiento de un escritorio de la Comunidad KDE. No será un lanzamiento menor, sino todo un lavado de cara del entorno de trabajo que da el salto a la tecnologías que ofrece Qt 6. Es por ello que se ha decidio empezar una campaña de recaudación de fondos para Plasma 6 que dote de músculo económico a la Comunidad para afrontar el gran reto que supone una actualización de este tipo. Vienen meses de trabajo, reuniones, eventos y sprints para dejarlo pulido.

Campaña de recaudación de fondos para Plasma 6

Donar a proyectos abiertos es una de las formas de colaborar más sencillas en el desarrollo de estas iniciativas. Y es que debemos tener claro que gran parte del Software Libre es gratuito pero implica unos gastos básicos, por ejemplo, en cuanto a servidores. Además, si queremos calidad y que se tenga garantías de desarrollo los usuarios, o gran parte de estos, deben colaborar de alguna forma en su desarrollo. Creo que es un buen momento para invitaros a leer este artículo ya algo viejo que publiqué en su día en este humilde blog.

De esta forma se inicia una campaña de recaudación de fondos para KDE para que la Comunidad KDE siga creciendo y tenga los recursos necesarios para afrontar los posibles retos que seguro aparecen. Además, de esta forma se comprometen a serguir ofreciendo más y más software de calidad de forma gratuita, tanto de forma monetaria como en forma de datos personales.

El espiritu con el que se inicia esta campaña es el siguiente:

¡Noticias emocionantes en el horizonte! En febrero de 2024, Plasma 6 hará su gran debut. Pero necesitamos tu ayuda para garantizar el éxito de su lanzamiento.

Y es que la Comunidad KDE necesita dinera para optimizar actividades como:

• Sprints para desarrolladores: Ayudarás a financiar las reuniones presenciales que mantienen a nuestros desarrolladores con energía y centrados en hacer KDE aún mejor.
• Gastos de viaje a eventos: Apoyarás la presencia de nuestro equipo en reuniones y conferencias importantes, como FOSDEM, FOSSAsia y LinuxCons.
• Evento Akademy: Garantizará el éxito del evento anual de la comunidad KDE para todos los miembros, y fomentará la colaboración y el crecimiento.
• Funcionamiento de KDE: Mantendrás las luces encendidas en la sede de KDE y nuestro hogar digital funcionando sin problemas.
• Pagar al personal de apoyo: Te asegurarás de que KDE tenga a mano los expertos que necesitamos para ayudar a nuestros colaboradores y usuarios.

En palabras de los desarrolladores, la razón principal por la que deberías donar es:

Porque la generosidad está en el corazón de KDE y mantiene vivos nuestros proyectos.

Es lo que motiva a nuestros voluntarios a compartir su tiempo y conocimientos para seguir construyendo nuevas características y mantener el software de KDE actualizado y seguro.

La generosidad también impulsa a quienes nos apoyan. Sus contribuciones y patrocinios hacen que los engranajes de KDE sigan girando y garantizan que nuestros desarrolladores puedan continuar con su fantástico trabajo.

Además tu donación te ofrece un reconocimiento ya que, a esperas de alguna que otra sorpresa que se uniará a los siguientes ítems:

• Tu nombre aparecerá en nuestra página de donaciones, reconociendo su contribución.
• Tu nombre aparecerá en el propio Plasma 6.

Si no quieres nada de lo anterior, también está bien, por supuesto. Recuerda marcar la casilla «[✔️] Hacer donación anónima» en el proceso de donación anterior.

Y si eres un desarrollador, puedes beneficiarte de las herramientas y marcos de trabajo de KDE. Las bibliotecas de KDE hacen que sea rápido y fácil construir aplicaciones sofisticadas para todas las plataformas.

Más información: KDE

La entrada Campaña de recaudación de fondos para Plasma 6 se publicó primero en KDE Blog.

A new version of the modern lightweight host operating system Leap Micro 5.5 just entered the Beta of its development.

A quick transition to a Release Candidate (RC) expected and the General Availability (GA) slated for the first half of October.

One of the standout features of Leap Micro 5.5 is its SELinux enhancements. Security-Enhanced Linux (SELinux) has received a significant boost; It brings podman-docker and hyper-v support for AArch64 for a more robust and secure computing experience for users.

In tandem with this exciting update, it’s important to note that Leap Micro 5.3 is nearing its End of Life (EOL). As soon as Leap Micro 5.5 makes its official debut, Leap Micro 5.3 will be retired. Users of Leap Micro 5.3 are strongly advised to consider upgrading to either Leap Micro 5.4 or the upcoming 5.5 release. This ensures access to the latest features, security enhancements, and ongoing support.

Este 27 de septiembre de 2023 se cumplen 40 años el anuncio inicial del proyecto GNU realizado por Richard Stallman

Richard Stallman anunció un 27 de septiembre de 1983 que empezaría a trabajar en un sistema operativo llamado GNU similar a Unix pero con la principal diferencia que sería completamente libre para usarlo, estudiarlo o modificarlo y distribuir esas modificaciones.

Puede determinarse este el inicio del movimiento del software libre, que en 40 años ha permeado en multitud de personas y proyectos.

Cuando se celebraron los 30 años del proyecto GNU escribí un artículo en el blog, que bien podría servir para conmemorar este nuevo aniversario. Muchas cosas han ocurrido en estos 10 años en el mundo del software libre y muchos cambios han ocurrido.

Pero en este caso, no quería hablar solo de fechas, o poner enlaces. Aunque sí enlazaré a la web oficial donde se detalla el evento que tendrá lugar en Suiza con charlas, entre ellas de Richard Stallman o Luis Falcón de GNU Health y otras charlas relacionadas con el software libre.

Pero en esta ocasión quiero hablar específicamente sobre mi visión del software libre.

Lo he dicho en varias ocasiones y sigo creyendo que es cierto. El software libre es algo más que simples bits o licencias que permitan que el software pueda ser usado, estudiado o modificado por otras personas.

Creo en el componente ético que subyace debajo de las funciones y líneas de código de cualquier programa que cumpla las 4 libertades del software libre.

En estos 40 años de existencia el software libre ha hecho posible y ha dado sustento legal y moral a muchos proyectos hoy en día indispensables. El software libre ha dado las herramientas y el pretexto para que multitud de mentes se pudieran unir y pusieran en marcha un proyecto nuevo, continuaran alguno ya acabado o dieran una alternativa a software con una licencia privativa que ata.

Así pues podemos encontrar desde pequeños proyectos específicos hasta grandes proyectos más generales y de un público más amplio que se imbuyen de ese espíritu del software libre que hace que se aglutinen personas de todo el mundo entorno al proyecto, ya sea aportando código, traduciendo, probando en distintas plataformas, etc.

El software privativo planteó su modelo de negocio en el código. Se vendía el código. Después vieron que teniendo atadas a las personas que utilizaban su código era una buena idea explotar los datos y metadatos que generaba el uso de ese código cerrado.

Una de las constantes dentro del software libre es el respeto a la persona que lo utiliza. El tener expuesto el código que se crea, hace imposible crear código malicioso que espíe o sea intrusivo con la privacidad. Siempre habrá alguien que se lea el código fuente y exponga, si lo hubiera, esa funcionalidad no deseada.

En estos 40 años, el software libre ha crecido y se ha expandido en muchos aspectos y proyectos. Las empresas han visto ese potencial y han “desvirtualizado» ese software libre por un término más “suave» que no implique radicalidad y ha aparecido el “open source» o código abierto.

Sin duda que el código sea abierto es una de las premisas del software libre, pero por eso solo no basta. Y además sigo pensando que sigue siendo muy necesario ese componente ético que aporta el software libre.

El tema de las licencias también se ha complicado. Las licencias de software libre implican que quien use ese software para crear algo nuevo, deba publicarlo a su vez bajo una licencia de software libre.

No han sido pocas las ocasiones en las que empresas utilizan licencias permisivas, pero no software libre y después han cerrado esa licencia. Eso con licencias de software libre no pasa.

Seguiré llamándolo como tal software libre, frente a “open source» o similar. Seguiré apoyando las opciones de software libre. No soy perfecto (alguien lo es) e incurriré en incoherencias, pero trataré de que sean las mínimas o de aprender de quien me señale el error.

Felicitar a Stallman como pionero de este proyecto del software libre y hacer extensiva esa felicitación a todas las personas que de una u otra manera crean y fomentan software libre, ya sea de manera profesional en su trabajo diario o de manera altruista contribuyendo con diferentes proyectos.

Empecé en GNU/Linux sin tener ni idea de qué era eso del software libre y poco a poco, leyendo y aprendiendo lo fui conociendo. Hoy reclamo ese derecho a poder utilizar software libre en la medida de lo posible en mis dispositivos. Y eso lo hacen posible un montón de gente en todo el mundo.

Happy hacking!

A recently published openSUSE survey is asking IT professionals and users about their views on open-source technologies and the ever-evolving Linux ecosystem.

The Use Case Survey aims to gather insights on what will shape the future of Linux and its role in various industries. The survey has four groups with the potential of answering up to 30 questions based on the response of the first and only mandatory question. The survey can take less than 10 minutes depending on how in depth of details a surveyee would like to provide. The overarching themes and ideas of the survey are the following:

Understanding User Needs and Satisfaction

The survey kicks off by categorizing respondents based on their use of IT: work/business, home/hobby, or both. This segmentation helps tailor the approach to better serve the needs of the surveyee.

For those in the work/business category, the survey delves into IT services satisfaction. Those not satisfied have options to suggest improvement, and it explores the idea of future growth prospects for Linux.

Home and Hobby Enthusiasts

For those using Linux at home or for hobbies, the survey asks about their preferences among openSUSE’s offerings like Tumbleweed, Leap, MicroOS, and SlowRoll, and why these distributions appeal to users and developers.

Contributions and Open Source Involvement

As an open-source project, it makes sense to inquire about contributions to open-source projects and to openSUSE. This helps to recognize not only the use of open-source software and projects, but how much users are contributing to it.

General Insights and Future Trends

This section asks all respondents about broader use of Linux beyond primary use cases. The aim is to help to understand the benefits respondents experience and the challenges they encounter. Respondents are encouraged to share their preferences for specific Linux distributions and their thoughts on emerging IT trends and technologies. The community members who came up with the survey are keen to understand if Linux is well-positioned to meet the market’s evolving needs with medium to long-term strategies.

The openSUSE’s Use Case Survey is not just a set of questions; it’s a collective effort to ensure that Linux continues to evolve to meet the diverse needs of its users and to make a brighter future for open-source technologies. Stay tuned for more updates and analysis from the results of the survey, which will run until Oct. 31.

After publishing Agama 3 a month ago, it is time for a new release. Among other things, this new version fixes several issues in the startup process, allows the use of a network proxy, adds (partial) support for IPv6, includes a few improvements in the web UI and features a new tool to extract Agama-related logs.

But as important as those changes, we did some internal work that will serve as the base for other features, like proper i18n support and more flexible storage management. Some of those features will land sooner than later, but meanwhile, let's focus on what Agama 4 brings.

Agama startup issues​

Our QA team is testing Agama through several scenarios and in different architectures. Those tests helped identify some issues with Agama's startup process: D-Bus activation errors, time-outs and even potential crashes.

Working closely with QA, we have identified and (hopefully) fixed most of those problems. In a nutshell, you should not see the "Cannot connect to D-Bus" error message anymore. And if that's not the case, please open a bug report attaching the logs 😉

If you are interested in the technical details, there is a bunch of fixes you might want to check: #729, #732, #747, #749, #753.

Installing through a proxy​

Many users and customers are used to deploy their systems with no direct access to Internet, just using a proxy. So it did not come as a surprise that it was one of the most requested features. Agama 4 includes support for specifying a proxy at boot time using the option proxy= when the installation requires to use a HTTP(S) or FTP source. The supported proxy URL format is: protocol://[user[:password]@]host[:port].

Of course, the proxy configuration is copied to the target system at the end of the installation.

The nitty-gritty details are available in #696 and #711.

IPv6 support in the automated installation​

In Agama 4 it is possible to specify the IPv6 configuration when using the automated installation. To accommodate this feature, we decided to introduce some changes in the profile definition. Here is an example that sets up IPv4 and IPv6 addresses.

  "network": {
    "connections": [
      {
        "id": "Ethernet network device 1",
        "method4": "manual",
        "method6": "manual",
        "addresses": [
          "192.168.122.100/24",
          "::ffff:c0a8:7ac7/64"
        ],
        "gateway4": "192.168.122.1",
        "gateway6": "::ffff:c0a8:7a01",
        "nameservers": [
          "192.168.122.1",
          "2001:4860:4860::8888"
        ]
      }
    ]
  }

Matching specific network devices​

In previous versions of Agama, it was not possible specify which interface to use for a given network connection when using the auto-installation mechanism: Agama just delegated on NetworkManager to decide. Now you can associate a network connection with an specific interface by using its name or more complex conditions. See #723 for further details.

  "network": {
    "connections": [
      {
        "id": "Ethernet network device 1",
        "method4": "auto",
        "interface": "enp1s0"
      }
    ]
  }

Agama specific storage settings​

Agama reads the information about the products offered for installation from a configuration (/etc/agama.yaml). Such a file contains a storage section which indicates the options (whether to use LVM, encryption, etc.) and the volumes (file systems) to create in the target system.

Since both Agama and YaST use the same mechanism to calculate the storage layout (known as the Guided Setup in YaST), the configuration for Agama was a direct translation of the YaST settings. But although the internal components and algorithms are the same, Agama's approach for tweaking their behavior is actually different in several aspects from YaST. For that reason, Agama now implements its own storage settings, making the product configuration more straightforward and less error-prone.

This change has a direct impact in Agama's auto-installation profiles.

storage: {
  bootDevice: "/dev/vda",
  lvm: true,
  encryptionPassword: "123456"
}

Interested in the implementation? Feel free to check: #721, #738 and #748.

Better logging support​

As the project evolves and more people try Agama, we need to make the debugging process easier. Recently, we introduced a new command that gathers all the information we need to debug the problems you face when using Agama (similar to the venerable save_y2logs for YaST). Typing agama logs store creates a tarball you can attach to your bug reports.

This first version (#757) is rather basic but we are already working on additional features to have a pleasant debugging process 🐛.

Polishing the web user interface​

Balsa Asanovic has become a regular contributor of Agama. For example, he implemented the "show password" feature (#750) and improved the error reporting in the iSCSI form (#699). But not only that, he is actively involved in our discussions in GitHub. Thank you, Balsa!

Moreover, a bug that prevented to download YaST2 logs through the web UI has been fixed (#746).

i18n support is coming to Agama​

If you follow the project closely enough, you might already know that we are working on i18n support. Many of the pieces are already in place but we did not make it for this version. However, we trust that our next major version will feature a translated web interface. Actually, our translators are already working on that.

Trying Agama 4​

The easiest way to try Agama is to download one of the two variants (ALP or openSUSE) of the Agama Live devel ISO. This image is built in the systemsmanagement:Agama:Devel OBS project and is updated each time we release a new version.

If you are interested in the bleeding edge, try the ISO in the systemsmanagement:Agama:Staging OBS project. It is built automatically and contains the code from Agama's Git repository, so it might get broken occassionally.

What to expect​

We expect to be able to ship a translated Agama interface and better handling of the storage settings in the next release. But, meanwhile, we are already working on other important features like software patterns selection or support for the SUSE Customer Center.

Of course, we appreciate opinions and feedback. As usual, feel free to contact the YaST team at the YaST Development mailing list, our #yast channel at Libera.chat or even the Agama project at GitHub.

Stay tuned!

After publishing Agama 3 a month ago, it is time for a new release. Among other things, this new version fixes several issues in the startup process, allows the use of a network proxy, adds (partial) support for IPv6, includes a few improvements in the web UI and features a new tool to extract Agama-related logs.

But as important as those changes, we did some internal work that will serve as the base for other features, like proper i18n support and more flexible storage management. Some of those features will land sooner than later, but meanwhile, let’s focus on what Agama 4 brings.

Agama startup issues

Our QA team is testing Agama through several scenarios and in different architectures. Those tests helped identify some issues with Agama’s startup process: D-Bus activation errors, time-outs and even potential crashes.

Working closely with QA, we have identified and (hopefully) fixed most of those problems. In a nutshell, you should not see the “Cannot connect to D-Bus” error message anymore. And if that’s not the case, please open a bug report attaching the logs :wink:

If you are interested in the technical details, there is a bunch of fixes you might want to check: #729, #732, #747, #749, #753.

Installing through a proxy

Many users and customers are used to deploy their systems with no direct access to Internet, just using a proxy. So it did not come as a surprise that it was one of the most requested features. Agama 4 includes support for specifying a proxy at boot time using the option proxy= when the installation requires to use a HTTP(S) or FTP source. The supported proxy URL format is: protocol://[user[:password]@]host[:port].

Of course, the proxy configuration is copied to the target system at the end of the installation.

The nitty-gritty details are available in #696 and #711.

IPv6 support in the automated installation

In Agama 4 it is possible to specify the IPv6 configuration when using the automated installation. To accommodate this feature, we decided to introduce some changes in the profile definition. Here is an example that sets up IPv4 and IPv6 addresses.

  "network": {
    "connections": [
      {
        "id": "Ethernet network device 1",
        "method4": "manual",
        "method6": "manual",
        "addresses": [
          "192.168.122.100/24",
          "::ffff:c0a8:7ac7/64"
        ],
        "gateway4": "192.168.122.1",
        "gateway6": "::ffff:c0a8:7a01",
        "nameservers": [
          "192.168.122.1",
          "2001:4860:4860::8888"
        ]
      }
    ]
  }

Matching specific network devices

In previous versions of Agama, it was not possible specify which interface to use for a given network connection when using the auto-installation mechanism: Agama just delegated on NetworkManager to decide. Now you can associate a network connection with an specific interface by using its name or more complex conditions. See #723 for further details.

  "network": {
    "connections": [
      {
        "id": "Ethernet network device 1",
        "method4": "auto",
        "interface": "enp1s0"
      }
    ]
  }

Agama specific storage settings

Agama reads the information about the products offered for installation from a configuration (/etc/agama.yaml). Such a file contains a storage section which indicates the options (whether to use LVM, encryption, etc.) and the volumes (file systems) to create in the target system.

Since both Agama and YaST use the same mechanism to calculate the storage layout (known as the Guided Setup in YaST), the configuration for Agama was a direct translation of the YaST settings. But although the internal components and algorithms are the same, Agama’s approach for tweaking their behavior is actually different in several aspects from YaST. For that reason, Agama now implements its own storage settings, making the product configuration more straightforward and less error-prone.

This change has a direct impact in Agama’s auto-installation profiles.

storage: {
  bootDevice: "/dev/vda",
  lvm: true,
  encryptionPassword: "123456"
}

Interested in the implementation? Feel free to check: #721, #738 and #748.

Better logging support

As the project evolves and more people try Agama, we need to make the debugging process easier. Recently, we introduced a new command that gathers all the information we need to debug the problems you face when using Agama (similar to the venerable save_y2logs for YaST). Typing agama logs store creates a tarball you can attach to your bug reports.

This first version (#757) is rather basic but we are already working on additional features to have a pleasant debugging process :bug:.

Polishing the web user interface

Balsa Asanovic has become a regular contributor of Agama. For example, he implemented the “show password” feature (#750) and improved the error reporting in the iSCSI form (#699). But not only that, he is actively involved in our discussions in GitHub. Thank you, Balsa!

Moreover, a bug that prevented to download YaST2 logs through the web UI has been fixed (#746).

i18n support is coming to Agama

If you follow the project closely enough, you might already know that we are working on i18n support. Many of the pieces are already in place but we did not make it for this version. However, we trust that our next major version will feature a translated web interface. Actually, our translators are already working on that.

Trying Agama 4

The easiest way to try Agama is to download one of the two variants (ALP or openSUSE) of the Agama Live devel ISO. This image is built in the systemsmanagement:Agama:Devel OBS project and is updated each time we release a new version.

If you are interested in the bleeding edge, try the ISO in the systemsmanagement:Agama:Staging OBS project. It is built automatically and contains the code from Agama’s Git repository, so it might get broken occassionally.

What to expect

We expect to be able to ship a translated Agama interface and better handling of the storage settings in the next release. But, meanwhile, we are already working on other important features like software patterns selection or support for the SUSE Customer Center.

Of course, we appreciate opinions and feedback. As usual, feel free to contact the YaST team at the YaST Development mailing list, our #yast channel at Libera.chat or even the Agama project at GitHub.

Stay tuned!

La encuesta realizada a la comunidad de openSUSE ha revelado que una amplia mayoría ha votado por mantener el nombre

Hace una semana podías leer en este mismo blog, que se había puesto en marcha una encuesta a la comunidad de openSUSE para ponerle un nombre a la nueva versión de este sistema operativo basado en GNU/Linux.

La comunidad ya ha expresado su opinión y más de 1.000 personas han dicho cual es su preferencia.

Aunque a openSUSE Leap (la versión estable de publicaciones periódicas y pensada en uso de soporte extendido) todavía le queda cuerda para un tiempo, la comunidad de openSUSE ha puesto ya en marcha una nueva versión de openSUSE.

Esa nueva versión es un compromiso entre el largo soporte de Leap y la evolución constante de Tumbleweed, la versión rolling release de openSUSE.

El proyecto nació con el nombre temporal de Slowroll que indica ese caracter «rolling release» pero más reposado que Tumbleweed.

Después de la buena acogida inicial, se puso en marcha una encuesta para pedir la opinión a la comunidad sobre el nombre definitivo que debería tener este nuevo proyecto. Según se puede leer en el anuncio oficial, más de 1.000 personas han expresado su opinión y este ha sido el resultado de las 5 opciones más votadas:

• Slowroll – 46.33%
• Driftwood – 25.91%
• Snowroll – 21.04%
• Drift – 20.51%
• Wave – 16.36%

A la vista de los resultados, se ve que Slowroll, la primera opción con casi la mitad de los votos es la opción más votada muy de lejos seguida por la segunda opción. Por tanto, Slowroll será el nombre con el que se siga designando a esta nueva versión de openSUSE.

La verdad, es que era mi opción preferida y tampoco quería que se cambiara por no despistar más a las personas que sean ajenas de openSUSE. Son pocas las distribuciones de GNU/Linux que ofrezcan tan variadas opciones de su proyecto (¿quizás Fedora esté a la zaga?)

Ahora viene la fase de diseñarle un logo para esta nueva versión igual que tiene Leap, Tumbleweed, MicroOS o ALP. Puedes participar enviando tu diseño al canal de Telegram de openSUSE.

Choosing a name for anything is not an easy task; the detail can wield significant influence, which is why a survey to make a decision about renaming Slowroll was presented.

Slowroll is a new distribution based on Tumbleweed, but rolls out updates slower; it is designed to implement updates at a pace of one to two months, integrating bug fixes and addressing Common Vulnerability and Exposure issues as they emerge.

As will all things in open source, the name was presented along with the idea for the distribution and discussion took place about the details surrounding Slowroll. The origin of the name was self-describing the distribution, but other names for Slowroll were proposed, so the renaming of it was put to a vote. All names there were proposed were included in the survey.

That voting process concluded today with more than 1,000 votes cast by interested members of the open-source community. This enthusiastic involvement underscores the interest of the openSUSE user base and trajectory of the project. The top results are the following:

1. Slowroll - 46.33%

2. Driftwood - 25.91%

3. Snowroll - 21.04%

4. Drift - 20.51%

5. Wave - 16.36%

6. Orbit - 13.44%

7. Lunar - 12.56%

8. Tide - 12.47%

The percentages surpass the 100% threshold due to the respondents’ option to endorse multiple choices.

With an impressive 46.33% of the votes, the community found Slowroll to remain the best option to describe the naming of the distribution. The decision has been reached to retain the established name as it represents a communal vision and messaging in name.

Members of the project extend their gratitude and appreciation for all those who took the survey and contributed to this pivotal decision.

Anyone interested in making a logo for the new distribution can send design images to the project’s marketing telegram channel. The logo should be an .svg image and should complement other logos for the project that related to a branding direction being discussed on the project’s GitHub.

Thank you for being part of the journey, and have a lot of fun!