Recopilación y traducción del boletín mensual de noticias relacionadas con el software libre publicado por la Free Software Foundation.

La Free Software Foundation (FSF) es una organización creada en Octubre de 1985 por Richard Stallman y otros entusiastas del software libre con el propósito de difundir esta filosofía.

La Fundación para el software libre (FSF) se dedica a eliminar las restricciones sobre la copia, redistribución, entendimiento, y modificación de programas de computadoras. Con este objeto, promociona el desarrollo y uso del software libre en todas las áreas de la computación, pero muy particularmente, ayudando a desarrollar el sistema operativo GNU.

Además de tratar de difundir la filosofía del software libre, y de crear licencias que permitan la difusión de obras y conservando los derechos de autorías, también llevan a cabo diversas campañas de concienciación y para proteger derechos de los usuarios frentes a aquellos que quieren poner restricciones abusivas en cuestiones tecnológicas.

Mensualmente publican un boletín (supporter) con noticias relacionadas con el software libre, sus campañas, o eventos. Una forma de difundir los proyectos, para que la gente conozca los hechos, se haga su propia opinión, y tomen partido si creen que la reivindicación es justa!!

• En este enlace podéis leer el original en inglés: https://www.fsf.org/free-software-supporter/2022/august
• Y traducido en español (cuando el equipo de traducción lo tenga disponible) en este enlace: https://www.fsf.org/free-software-supporter/2022/agosto

Puedes ver todos los números publicados en este enlace: http://www.fsf.org/free-software-supporter/free-software-supporter

Después de muchos años colaborando en la traducción al español del boletín, desde inicios del año 2020 he decidido tomarme un descanso en esta tarea.

Pero hay detrás un pequeño grupo de personas que siguen haciendo posible la difusión en español del boletín de noticias de la FSF.

¿Te gustaría aportar tu ayuda en la traducción? Lee el siguiente enlace:

• https://victorhckinthefreeworld.com/2016/12/22/quieres-ayudar-a-traducir-el-boletin-mensual-de-la-free-software-foundation/

Por aquí te traigo un extracto de algunas de las noticias que ha destacado la FSF este mes de agosto de 2022

Acercándose a BIOS totalmente libres con el equipo técnico de la FSF

Del 13 de julio

Como parte de la recaudación de fondos de primavera de la FSF, el administrador sénior de sistemas, Ian Kelling, escribió un artículo que detalla el trabajo reciente del equipo técnico para migrar los últimos servidores que ejecutan BIOS no libres a otros que ejecutan BIOS libres.

Hubo muchos desafíos involucrados, pero el equipo técnico pudo enfrentar esos desafíos, y este artículo brinda una buena hoja de ruta para otras personas que planeen liberar sus computadoras de la red.

• https://www.fsf.org/blogs/sysadmin/closing-in-on-fully-free-bioses-with-the-fsf-tech-team

Publicado LibreJS 7.21.0

Del 21 de julio por Yuchen Pei

¡Hay una nueva versión de LibreJS, el complemento del navegador que lo ayuda a proteger su libertad!

Lea las notas de la versión, que detallan las correcciones de errores y las nuevas funciones, como una nueva prueba sin interfaz para desarrolladores de sitios web y documentación actualizada. Además, lea sobre la campaña Free JavaScript, que presenta a LibreJS como un recurso importante que se puede usar para navegar por Internet con libertad: https://www.fsf.org/campaigns/freejs.

• https://lists.gnu.org/archive/html/info-gnu/2022-07/msg00004.html

Declaración de EFF sobre la adopción de la ley de servicios digitales y la ley de mercados digitales por parte del Parlamento de la UE

Del 5 de julio por la Electronic Frontier Foundation

La Electronic Frontier Foundation (EFF) publicó su declaración sobre la reciente aprobación por parte de la Unión Europea (UE) del «paquete de la Ley de Servicios Digitales». Hay algunas mejoras en las protecciones para los usuarios comunes, pero la DSA también obliga a las plataformas a evaluar y mitigar los riesgos sistémicos, y existe mucha ambigüedad sobre cómo resultará esto en la práctica. Mucho dependerá de cómo las plataformas de redes sociales interpreten sus obligaciones bajo la DSA y cómo las autoridades de la UE hagan cumplir la regulación.

Mientras tanto, organizaciones europeas como European Digital Rights (EDRi) han estado haciendo campaña contra lo que llaman «control de chat» durante meses. Los derechos de cifrado en las aplicaciones de chat y mensajería están en juego, y las organizaciones han formado diez principios de lo que significa, como dicen, «realmente defender a los niños en la era digital», que incluyen proteger el cifrado.

Tanto si vive dentro de la UE como si no, le recomendamos que se informe sobre los problemas y lo que está en juego. Lea la declaración completa de la EFF, respalde la lista de principios de EDRi en su sitio o en el sitio alemán https://chat-kontrolle.eu/ y lea lo que la FSF ha dicho anteriormente sobre la importancia del software libre en la tecnología de comunicación que realmente respeta la privacidad. La verdadera privacidad y seguridad dependen del software libre.

• https://www.eff.org/press/releases/eff-statement-eu-parliaments-formal-approval-digital-services-act-and-digital-markets
• https://edri.org/our-work/chat-control-10-principles-to-defend-children-in-the-digital-age/
• https://edri.org/wp-content/uploads/2022/02/EDRi-principles-on-CSAM-measures.pdf
• https://www.fsf.org/bulletin/2020/spring/privacy-encryption

Thomas Lord 1966-2022

Del 27 de julio por Trina Pudurs

Thomas Lord nació el 26 de abril de 1966 en Pittsburgh, Pensilvania. Apoyó el software libre durante toda su vida. Trabajó como empleado de la Free Software Foundation (FSF), desarrollando para el Proyecto GNU durante varios años a principios de la década de 1990.

La FSF reconoce y honra la contribución de Lord al software libre y su comunidad. Lamentamos la pérdida de Lord y expresamos nuestras condolencias a su familia, sus amigos y colegas.

• https://berkeleydailyplanet.com/issue/2022-06-26/article/49837

Estas son solo algunas de las noticias recogidas este mes, pero hay muchas más muy interesantes!! si quieres leerlas todas (cuando estén traducidas) visita este enlace:

• https://www.fsf.org/free-software-supporter/2022/agosto

Y todos los números del «supporter» o boletín de noticias de 2022 aquí:

• https://www.fsf.org/free-software-supporter/2022

—————————————————————

Cette année encore, notre association fondée en 2001 sera présente au forum des associations qui se tient le samedi 10 septembre 2022 de 10h à 18h sur les quais bas rive gauche entre le pont Guillaume-le-Conquérant et le pont Jeanne-d’Arc. Venez nous rencontrer au stand 107 et nous vous réserverons notre meilleur accueil. Toute la …

Forum A l’asso de Rouen 2022Read More »

The post Forum A l’asso de Rouen 2022 appeared first on Cybersécurité, Linux et Open Source à leur plus haut niveau | Network Users Institute | Rouen - Normandie.

Time for more news from the YaST-related ALP work groups. As the first prototype of our Adaptable Linux Platform approaches we keep working on several aspects like:

• Improving Cockpit integration and documentation
• Enhancing the containerized version of YaST
• Evolving D-Installer
• Developing and documenting Iguana

It’s a quite diverse set of things, so let’s take it bit by bit.

Cockpit on ALP - the Book

Cockpit has been selected as the default tool to perform 1:1 administration of ALP systems. Easing the adoption of Cockpit on ALP is, therefore, one of the main goals of the 1:1 System Management Work Group. Since clear documentation is key, we created this wiki page explaining how to setup and start using Cockpit on ALP.

The document includes several so-called “development notes” presenting aspects we want to work on in order to improve the user experience and make the process even more straightforward. So stay tuned for more news in that regard.

Improvements in Containerized YaST

As you already know, Cockpit will not be the only way to administer an individual ALP system. Our containerized version of YaST will also be an option for those looking for a more traditional (open)SUSE approach. So we took some actions to improve the behavior of YaST on ALP.

First of all, we reduced the size of the container images as shown in the following table.

We detected more opportunities to reduce the size of the container images, but in most cases they would imply relatively deep changes in the YaST code or a reorganization of how we distribute the YaST components into several images. So we decided to postpone those changes a bit to focus on other aspects in the short term.

We also adapted the Bootloader and Kdump YaST modules to work containerized and we added them to the available container images.

We took the opportunity to rework a bit how YaST handles the on-demand installation of software. As you know, YaST sometimes asks to install a given set of packages in order to continue working or to configure some particular settings.

Due to some race conditions when initializing the software management stack, YaST was sometimes checking and even installing the packages in the container instead of doing it so in the host system that was being configured. That is fixed now and it works as expected in any system in which immediate installation of packages is possible, no matter if YaST runs natively or in a container. But that still leaves one open question. What to do in a transactional system in which installing new software implies a reboot of the system? We still don’t have an answer to that but we are open to suggestions.

As you can imagine, we also invested quite some time checking the behavior of YaST containerized on top of ALP. The good news is that, apart from the already mentioned challenge with software installation, we found no big differences between running in a default (transactional) ALP system or in a non-transaction version of it. The not-so-good news is that we found some issues related to rendering of the ncurses interfaces, to sysctl configuration and to some other aspects. Most of them look like relative easy to fix and we plan to work on that in the upcoming weeks.

Designing Network Configuration for D-Installer

Working on Cockpit and our containerized YaST is not preventing us to keep evolving D-Installer. If you have tested our next-generation installer you may have noticed it does not include an option to configure the network. We invested some time lately researching the topic and designing how network configuration should work in D-Installer from the architectural point of view and also regarding the user experience.

In the short term, we have decided to cover the two simplest use cases: regular cable and WiFi adapters. Bear in mind that Cockpit does not allow setting up WiFi adapters yet. We agreed to directly use the D-Bus interface provided by NetworkManager. At this point, there is no need to add our own network service. At the end of the installation, we will just copy the configuration from the system executing D-Installer to the new system.

The implementation will not be based on the existing Cockpit components for network configuration since they present several weaknesses we would like to avoid. Instead, we will reuse the components of the cockpit-wicked extension, whose architecture is better suited for the task.

D-Installer as a Set of Containers

In our previous report we announced D-Installer 0.4 as the first version with a modular architecture. So, apart from the already existing separation between the back-end and the two existing user interfaces (web UI and command-line), the back-end consists now on several interconnected components.

And we also presented Iguana, a minimal boot image capable of running containers.

Sure you already guessed then what the next logical step was going to be. Exactly, D-Installer running as a set of containers! We implemented three proofs of concept to check what was possible and to research implications like memory consumption:

• D-Installer running as a single container that includes the back-end and the web interface.
• Splitting the system in two containers, one for the back-end and the other for the web UI.
• Running every D-Installer component (software handling, users management, etc.) in its own container.

It’s worth mentioning that containers communicate with each other by means of D-Bus, using different techniques on each case. The best news if that all solutions seem to work flawlessly and are able to perform a complete installation.

And what about memory consumption? Well, it’s clearly bigger than traditional SLE installation with YaST, but that’s expected at this point in which no optimizations has been performed on D-Installer or the containers. On the other hand, we found no significant differences between the three mentioned proofs of concept.

• Single all-in-one container:
  • RAM used at start: 230 MiB
  • RAM used to complete installation: 505 MiB
• Two containers (back-end + web UI):
  • At start: 221 MiB (191 MiB back-end + 30 MiB web UI)
  • To complete installation: 514 MiB (478 MiB back-end + 36 MiB web UI)
• Everything as a separate container:
  • At start: 272 MiB (92 MiB software + 74 MiB manager + 75 MiB users + 31 web)
  • After installation: 439 MiB (245 MiB software + 86 manager + 75 users + 33 web)

Those numbers were measured using podman stats while executing D-Installer in a traditional openSUSE system. We will have more accurate numbers as soon as we are able to run the three proofs of concepts on top of Iguana. Which take us to…

Documentation About Testing D-Installer with Iguana

So far, Iguana can only execute a single container. Which means it already works with the all-in-one D-Installer container but cannot be used yet to test the other approaches. We are currently developing a mechanism to orchestrate several containers inspired by the one offered by GitHub Actions.

Meanwhile, we added some basic documentation to the project, including how to use it to test D-Installer.

Stay Tuned

Despite the reduced presence on this blog post, we also keep working on YaST beside containerization. Not only fixing bugs but also implementing new features and tools like our new experimental helper to inspect YaST logs. So stay tuned to get more updates about Cockpit, ALP, D-Installer, Iguana and, of course, YaST!

El comando locate sirve para encontrar archivos por el nombre en nuestro sistema GNU/Linux

El comando locate de GNU creado pro Miloslav Trmac, forma parte del paquete «GNU Find Utilities«, un conjunto de herramientas que trabajan junto con otros programas para ofrecernos herramientas muy útiles a la hora de buscar archivos en nuestros sistemas GNU/Linux.

«GNU Find Utilities» incluyen programas como:

• find – busca archivos en una jerarquía de directorios (del que ya escribí un artículo)
• locate – enumera los archivos en que se encuentran en una(s) base(s) de datos que coincidan con un patrón
• updatedb – actualizar una base de datos de nombres de archivos
• xargs – construye y ejecuta líneas de comando desde la entrada estándar

En esta ocasión vamos a ver cómo usar locate para buscar archivos en nuestro equipo, cuyos nombres están indexados en una base de datos.

El comando locate es el comando más rápido y la manera más rápida de buscar por el nombre un archivo en nuestro sistema GNU/Linux.

Si ya tenemos instalado el programa en nuestro sistema, ya podremos empezar a usarlo. El comando locate busca un patrón que le pasamos al ejecutarlo.

Ese patrón es el nombre (o parte del nombre) de un archivo y el comando lo que hace es buscarlo en una base de datos que mantiene y muestra los resultados por pantalla, de manera predeterminada un resultado por línea aunque eso se puede cambiar como veremos.

La base de datos en la que busca el comando se actualiza de manera diaria mediante una tarea «cron» que se instala en nuestro sistema al instalar el programa.

También podemos actualizar nosotros de manera manual la base de datos en cualquier momento ejecutando el comando updatedb Y dependiendo de nuestro sistema, esa actualización puede llevar más o menos tiempo.

Esa base de datos está localizada en la ruta /var/lib/mlocate/mlocate.db aunque podemos establecer otras rutas.

Pero vamos ya a ver cómo se usa el comando. El uso básico del comando es invocando el comando junto con un patrón de búsqueda. Imaginemos que queremos buscar en nuestro equipo un archivo que se llama hola.txt. Para ello ejecutaríamos:

locate hola

Nos mostrará todos los archivos que contengan la cadena hola en su nombre, ya que sin más parámetros busca el patrón no de manera estricta, si no como si fuera un comodín.

Así encontrará por ejemplo:

locate hola
/home/victorhck/Documentos/hola_mundo.html
/home/victorhck/Documentos/hola2.md
/home/victorhck/hola_mundo.txt
/home/victorhck/hola.txt

Eso sí, de manera predeterminada locate tiene en cuenta las mayúsculas y minúsculas, por lo que con la búsqueda anterior no mostrará por ejemplo ningún archivo HOLA.txt.

Si queremos que no tenga en cuenta mayúsculas y minúsculas deberemos ejecutar el comando con la opción -i

locate -i hola
/home/victorhck/Documentos/hola_mundo.html
/home/victorhck/Documentos/hola2.md
/home/victorhck/hola_mundo.txt
/home/victorhck/hola.txt
/home/victorhck/HOLA.txt

He dicho antes que el comando busca los nombres de archivo en una base de datos que se actualiza una vez al día o de manera manual.

Es decir que si creamos un nuevo archivo, si queremos que lo pueda encontrar, antes deberemos actualizar la base de datos como hemos visto antes.

Y quizás también se han borrado archivos desde que se actualizó la base de datos, si no queremos actualizarla y queremos que nos muestre los archivos que existen actualmente a la hora de ejecutarse el comando locate deberemos incluir la opción -e

locate -e prueba

El comando nos muestra cada coincidencia del patrón buscado en una línea, pero podemos hacer que nos devuelva todos los resultados seguidos mediante la opción -0

O podemos hacer que nos devuelva únicamente el valor del número de coincidencias encontradas con la opción -c

Si queremos buscar un archivo llamado hola.txt y no queremos que nos muestre otras opciones que no sean los archivos que se llaman exactamente como lo que buscamos, deberemos añadir la opción -b y añadir un caracter comodín al nombre para que así nos busque exactamente hola.txt y no *hola.txt*

locate -b '\hola.txt'
/home/victorhck/hola.txt

Lo mismo si queremos buscar todos los archivos que se llamen prueba ya sea mayúscula o minúscula y tenga cualquier extensión podremos hacerlo mediante:

locate -ib 'prueba.*'
/home/victorhck/prueba.txt
/home/victorhck/prueba.html
/home/victorhck/Prueba.html

Podemos obtener las estadísticas de la base de datos indexada que usa el comando locate ejecutando el comando con la opción -S

locate -S
Base de datos /var/lib/mlocate/mlocate.db:     
   95.284 directorios
        1.378.246 archivos
        100.906.228 bytes en los nombres de archivo
        39.657.601 bytes utilizados para almacenar la base de datos

Podemos especificar varios patrones de búsqueda junto con el comando locate, no solo uno. El comando mostrará todos los archivos que cumplen uno u otro patrón de búsqueda.

En el siguiente ejemplo vamos a hacer que el comando nos muestre cuantos archivos coinciden con el patrón «mi_» o con el patrón «prueba», en mi caso:

locate -c mi_ prueba
127

Esto es muy distinto si incluimos la opción -A. Con esta opción el comando nos devuelve solo los archivos encontrados que cumplen ambos patrones de búsqueda. Es decir que tienen tanto «mi_» como «prueba». Veamos la diferencia:

locate -Ac mi_ prueba
4

Y estas son algunas de las opciones que tiene el comando locate de GNU a la hora de realizar búsquedas de archivos en tu equipo. Para una vista más detallada a otras opciones te recomiendo usar la página man del comando.

Espero que esta pequeña guía te haya resultado útil e incorpores el comando locate al arsenal de comandos que ya usas y manejas en la terminal de tu sistema GNU/Linux.

Si conocías el comando y quieres compartir algún truco, o si no conocías alguna opción o ni siquiera el comando, puedes usar los comentarios del blog para dejar tu comentario.

Microsoft vuelve a dar ejemplos de la política de monopolio que subyace en sus venas por muy bonito que quede el eslogan de que ama al «open source»

Os traigo un par de ejemplos recientes de cómo Microsoft sigue siendo… Microsoft ¿sorpresa? la empresa se niega a ceder sus beneficios y parte de pastel a proyectos de código abierto o software libre… aunque quede muy bonito poner lo contrario en la publicidad.

El primer ejemplo tiene como protagonista a Nextcloud, software libre para crear tu propia nube con un montón de opciones que podemos ir implementando y sí, es software libre.

En una reciente entrevista al creador y CEO de Nextcloud, una persona que viene del software libre desde hace años, en la revista Wall Street Journal, este comentaba que a principios de año 2022 fue contactado por un abogado de Microsoft.

En la reunión, la persona de Microsoft ofreció beneficios en forma de colaboración y marketing a Nextcloud. Por ejemplo, querían promocionar el logotipo de Nextcloud en el material de marketing de Microsoft, si Nextcloud consideraría retirar su denuncia antimonopolio.

Esta queja antimonopolio es que a principios de 2021, bajo el liderazgo de Nextcloud, un grupo de empresas presentó una queja oficial ante la Dirección General de Competencia de la UE sobre el comportamiento de Microsoft. Esta coalición de empresas europeas en la nube aboga por la igualdad de condiciones en la UE.

Es decir Microsoft trata de seguir manteniendo su potencial en cuanto a la nube en Europa, donde va perdiendo poco a poco posiciones, chantajeando al CEO de Nextcloud para que sea bueno y retire la denuncia y a cambio le dan una palmadita en la espalda y poco más.

En la entrevista del Wall Street Journal el CEO de Nextcloud comenta:

“Básicamente nos estaba ofreciendo una galletita. No se trata de tener un logo en algún lado o hacer un trato rápido. No estamos interesados ​​en eso. Estamos preocupados por la situación antimonopolio en general”.

El Zasca todavía resuena en Redmond

Pero hay más ejemplos.

Según ha denunciado a principios de julio de 2022 la Free Software Conservacy, Microsoft quiere prohibir en su «store» todo el software que sea FOSS (Free Open Source Software).

Han añadido una nueva cláusula que revierte las políticas de la tienda de aplicaciones y ya está interrumpiendo el comercio en su plataforma. En particular, Microsoft ahora prohíbe a los redistribuidores de FOSS cobrar dinero por casi todos los FOSS.

Sí el mismo «open source» que dicen querer, ahora les niegan que los proyectos de software libre cobren dinero y se financien a través de su «tienda». Bueno es su tienda y hacen lo que quieran, eso sí, están dañando seriamente el software libre.

Durante décadas, Microsoft hizo un gran esfuerzo para asustar al sector del software comercial con historias de cómo FOSS (y Linux en particular) no eran productos comercialmente viables. Microsoft incluso afirmó una vez que cualquiera que desarrollara FOSS bajo copyleft estaba en contra del estilo americano. (¡Qué tiempos aquellos que Microsoft no se escondía!)

Hoy en día, hay muchos desarrolladores que se ganan la vida creando, apoyando y redistribuyendo FOSS, que financian (en parte) cobrando por FOSS en las tiendas de aplicaciones.

Esto es, ante todo, una afrenta a todos los esfuerzos por ganarse la vida escribiendo software de código abierto. Esta no es una consideración meramente hipotética. Muchos desarrolladores ya respaldan su desarrollo FOSS (legítimamente, al menos bajo las propias licencias FOSS) a través de implementaciones de tiendas de aplicaciones que Microsoft prohibió recientemente en su Store.

Bueno, eso sí adoran el software libre que alojan en GitHub y del que Autopilot ahora puede beneficiarse. ¡Es hora de abandonar GitHub!

Os dejo los enlaces por aquí para que consultéis las fuentes de primera mano y saquéis vuestras propias conclusiones, podéis usar los comentarios del blog para compartirlas. Siempre con respeto y con ánimo constructivo, por favor.

In an effort so gain more user insight and perspective for the development of the Adaptable Linux Platform (ALP), members of the openSUSE community workgroup will have a MicroOS Desktop install workshop on August 2.

There will be feedback sessions the following weeks during the community workgroup and community meeting.

Users are encouraged to install the MicroOS Desktop (ISO image 3.8 GiB) during the week of August 1. There will be a short Installation Presentation during the ALP Workgroup Meeting at 14:30 UTC on August 2 for those who need a little assistance.

During the next two weeks’ meetings, follow ups will be given with a final Lucid Presentation on August 16 during the regularly scheduled workgroup.

Users are encouraged to note how their use, installation and experience goes on a spreadsheet while also using it as a reference for tips and examples on what to try.

Workflow examples like tweaking the immutable system by running sudo transactional-update shell or podman basics with container port forwarding and podman volumes are also on the list.

The call for people to test spin MicroOS Desktop has received a lot of feedback like the need for documentations for Flatpak on flatpak user profiles (located at ~/.var/app) and many other key points, which is the whole point of the exercise to try MicroOS to gain some valuable lessons for ALP.

In managing expectations, people testing MicroOS should be aware that it is based on openSUSE Tumbleweed, that YaST is not available and that MicroOS’ release manager would appreciate contributions rather than bug reports. MicroOS currently supports two desktop environments. GNOME is currently supported as a Release Candidate and KDE’s Plasma is in Alpha. MicroOS Desktop is currently the closest representation of what users can expect from next generation Desktop by SUSE.

Users have download the MicroOS Desktop at https://get.opensuse.org/microos/ and see instructions and record comments on the spreadsheet.

Comparto unas modificaciones que he realizado a sendos scripts en Bash que sirven para subir texto o una imagen al servicio de paste mantenido por la comunidad openSUSE

Hace tiempo que he estado modificando y adaptando un par de scripts existentes que suben un texto o archivo de texto o una imagen al servicio susepaste para compartir logs o capturas en foros, listas de correo, etc.

Comparto con vosotros el resultado, que quizás lejos de ser perfecto es perfectamente válido y así me sirve para ver si hay que mejorar algo. Ya sabes: «release soon, release often».

susepaste.org es un sitio en el que poder compartir de forma efímera, textos, archivos o imágenes, para compartir con otras personas esa url que genera y así compartir un log, un mensaje de error, una captura de pantalla con un problema específico, etc.

Si usas openSUSE, seguro que ya tienes instalado en la ruta /usr/bin los scripts susepaste y susepaste-screenshot. Mis versiones actualizan y corrigen algún error además de eliminar partes que no se utilizaban y añadir nuevas opciones.

Si queremos utilizar mis scripts, lo primero vamos a renombrar los scripts originales, para ello en la ruta /usr/bin renombramos (como usuario root) ambos scripts añadiendo por ejemplo _orig al nombre de ambos archivos.

Ahora descargamos desde mi repositorio en Codeberg los scripts que he modificado en la misma ruta, ejecutando:

• wget https://codeberg.org/victorhck/paste_scripts/raw/branch/main/susepaste
• wget https://codeberg.org/victorhck/paste_scripts/raw/branch/main/susepaste-screenshot

Y ya los podremos utilizar. Si queremos volver atrás borramos los scripts descargados y volvemos a renombrar los scripts originales eliminando _orig del nombre.

susepaste

Este script sirve para enviar un archivo de texto, la salida de un comando o un texto que escribamos al servicio de susepaste y nos genera una url que nos devuelve y será la que podemos compartir. La modificación de mi script sigue haciendo eso, pero algunas cosas más.

¿Cómo utilizarlo?

Si ejecutamos susepaste -h nos muestra una pequeña información de cómo usar este sencillo script.

susepaste [-n nick] [-t title] [-e expire] [-f <file> or <path/to/file>]
(expire: 30m=30minutes; 1h=1hour; 6h=6hours; 12h=12hours; 1d=1day; 1w=1week; 1m=1month; 3m=3months; 1y=1year; 2y=2years; 3y=3years; 0=never)

Podemos especificar nuestro nick, un título, un periodo después del cual el archivo desaparecerá y un archivo.

Si no especificamos el nick, el título o el tiempo de expiración, se asignarán valores predeterminados. Y el archivo es opcional, ya que podemos poner la salida de un comando o escribir nosotros un texto. Si escribimos nosotros el texto deberemos terminar el comando con Ctrl+d

Vamos con unos ejemplos:

susepaste -n Victorhck -t repositorios -e 3m -f lista_repos.txt

Subimos el archivo lista_repos.txt indicando mi nick un título y que dure 3 meses en el servidor de susepaste. Otro:

zypper lr | susepaste -t repos -e 1h

Envía la salida del comando que muestra los repositorios (zypper lr) al script y este lo sube al servidor con un título y que dure 1 hora. Otro:

uname -a | susepaste

Envía la salida del comando al servicio susepaste. Y te devuelve la url y también la copia en el portapapeles.

susepaste-screenshot

Este script sirve para tomar una captura de pantalla y enviarla al servidor o para subir una captura que tengamos ya realizada.

¿Cómo utilizarlo?

Si ejecutamos susepaste-screenshot -h nos muestra una pequeña información de cómo usar este sencillo script.

susepaste-screenshot [--all] [-n nick] [-t title] [-e expire] [-d delay secs] [-f <file> or <path/to/file>]
(expire: 30m=30minutes; 1h=1hour; 6h=6hours; 12h=12hours; 1d=1day; 1w=1week; 1m=1month; 3m=3months; 1y=1year; 2y=2years; 3y=3years; 0=never)

Muy similar al anterior, pero se incluye la opción -d para indicar unos segundos de retraso a la hora de realizar la captura, para poder cambiar de pantalla, escritorio, etc…

Vamos con unos ejemplos:

susepaste-screenshot -n Victorhck -t error -e 3m -f /home/mi_usuario/capturas/mi_captura.png

Establecemos un nick, un título un tiempo de 3 meses de duración en el servidor y la ruta al archivo donde está la captura.

susepaste-screenshot -e 1m -d 5

La imagen durará 1 mes en el servidor y esperará 5 segundos antes de tomar una captura y enviarla.

Bueno, tanto si usas openSUSE como si no, podrás usar el servicio susepaste o paste.opensuse.org que en definitiva son los mismos para alojar textos o imágenes.

Y si usas estos scripts te ahorrarán tiempo y quizás te hagan la vida más fácil. Si los usas y encuentras algo que no funciona, o que habría que mejorar usa los comentarios del blog para compartir tu aporte.

No quiere decir que lo vaya a hacer dependerá del tiempo que tenga, de las ganas, pero sin duda tu aporte será leído y tenido muy en cuenta.

Enlaces de interés

• https://codeberg.org/victorhck/paste_scripts
• https://github.com/openSUSE/paste/tree/master/script
• https://susepaste.org/

The openSUSE Project is preparing to celebrate its 17th Birthday on August 9.

The project will have a 24-hour social event with attendees visiting openSUSE’s virtual Bar.

Commonly referred to as the openSUSE Bar or slash bar (/bar), openSUSE’s Jitsi instance has become a frequent virtual hang out with regulars and newcomers.

People who like or use openSUSE distributions and tools are welcome to visit, hang out and chat with other attendees during the celebration.

This special 24-hour celebration has no last call and will have music and other social activities like playing a special openSUSE skribble.io edition; it’s a game where people draw and guess openSUSE and open source themed topics.

People can find the openSUSE Bar at https://meet.opensuse.org/bar.

There will be an Adaptable Linux Platform (ALP) Work Group (WG) feedback session on openSUSE’s Birthday on August 9 at 14:30 UTC taking place on https://meet.opensuse.org/meeting. The session follows an install workshop from August 2 that went over installing MicroOS Desktop. The session is designed to gain feedback on how people use their Operating System to help progress ALP development.

The openSUSE Project came into existence on August 9, 2005. An email about the launch of a community-based Linux distribution was sent out on August 3 and the announcement was made during LinuxWorld in San Francisco, which was at the Moscone Convention Center from August 8 to 11, 2005. The email processing the launch discussed upgrading to KDE 3.4.2 on SuSE 9.3.

El desarrollador griego Michail Vourlakos aka psifidotos creador de Latte Dock se despide del proyecto

Latte Dock es uno de esos «docks» o muestrario animado de aplicaciones que vino a dar un nuevo aspecto a los escritorios Plasma de KDE hace 6 años creado por psifidios.

Algunos ususarios lo adoptaron desde el principio en sus escritorios y quitaron la ya más que conocida barra (normalmente inferior) y pusieron en su lugar este nuevo dock.

Ofrece unas animaciones muy visuales, flexibilidad para adaptarlo a tus gustos y que se integraba perfectamente con el escritorio Plasma de KDE.

Poco a poco ha ido corrigiendo fallos e integrando nuevas opciones hasta la versión 0.10.8 publicada en febrero de 2022.

Y hoy el desarrollador que llevaba a cabo buena parte del trabajo ha anunciado en su blog que después de 6 años se despide del proyecto por falta de tiempo, motivación o interés por su parte en Latte Dock.

Iba a publicar una versión 0.11 pero eso implicaría que alguien debería mantenerla, y como (de momento) no es el caso, ahí se ha quedado estancado el proyecto.

Esto no quiere decir que Latte Dock vaya a desaparecer, seguirá estando funcional y disponible, peeeero con el tiempo se irá quedando obsoleta… a menos que alguien tome el relevo y mantenga este código corrigiendo, puliendo y mejorando.

El desarrollador se despide agradeciendo estos 6 años de desarrollo en el que ha aprendido mucho a la comunidad de KDE (miembros, desarrolladores, entusiastas, etc)

Así que si lo deseas puedes ponerte manos a la obra con este proyecto y retomarlo para seguir que siga mantenido y actual. ¡Todos las personas que usen Latte Dock te lo agradecerán!

Enlaces de interés

• https://psifidotos.blogspot.com/2022/07/latte-dock-farewell.html
• https://invent.kde.org/plasma/latte-dock/
• https://store.kde.org/p/1169519

The Berlin hackfest and conference wasn't a polished, well organized experience like the usual GUADEC, it had the perfect Berlin flavor. The attendance topped my expectations and smaller groups formed to work on different aspects of the OS.

GNOME shell's quick settings, the mobile form factor, non-overlapped window management, Flathub and GNOME branding, video subsystems and others.

I've shot a few photos and edited the short video above. Even the music was done during the night sessions at C-Base.

Big thanks to the C-Base crew for taking good care of us in all aspects -- audio-visual support for the talks and following the main event in Mexico, refreshments and even outside seating. Last but not least the GNOME Foundation for sponsoring the travel (mostly on the ground).