A Mistral AI apresentou o MathΣtral, um modelo especializado de 7B projetado para raciocínio matemático avançado e exploração científica. Lançado sob a licença Apache 2.0, o MathΣtral homenageia Arquimedes por ocasião do seu aniversário de 2311 anos este ano.

O MathΣtral é adaptado para enfrentar desafios complexos de raciocínio lógico em múltiplas etapas nas áreas de STEM. Desenvolvido em colaboração com o Projeto Numina, o modelo herda capacidades do Mistral 7B, alcançando desempenho de ponta em benchmarks padrão da indústria. Notavelmente, ele atinge 56,6% no MATH e 63,47% no MMLU, demonstrando capacidades de raciocínio superiores dentro de sua categoria de tamanho.

Benchmarks detalhados destacam as robustas melhorias de desempenho do MathΣtral com aumento do cálculo no tempo de inferência. Por exemplo, o MathΣtral 7B alcança melhorias significativas de precisão, com 68,37% no MATH através de votação majoritária e 74,59% com um modelo de recompensa forte entre 64 candidatos.

O MathΣtral está disponível para uso e adaptação imediatos usando as ferramentas da Mistral AI. Os desenvolvedores podem implantar o modelo através do mistral-inference para exploração inicial e aprimorar suas capacidades com o mistral-finetune. Os pesos do modelo são acessíveis via HuggingFace, facilitando a integração direta em projetos acadêmicos e de pesquisa.

Ao disponibilizar o MathΣtral para a comunidade científica, a Mistral AI visa promover avanços na resolução de problemas matemáticos e apoiar empreendimentos acadêmicos. Esta iniciativa destaca o compromisso da Mistral AI em promover arquiteturas de modelos especializados e suas aplicações práticas na descoberta científica.

Fonte: https://mistral.ai/news/mathstral/

Crystal Dock es dock para sistemas GNU/Linux, que se centra en una interfaz de usuario atractiva, simple y fácil de usar y personalizar, y disponible para varios entornos de escritorio

Hoy por el blog comparto Crystal Dock, cuya versión actual (versión 2) es compatible con KDE Plasma 6 en Wayland. Se considerarán otros entornos de escritorio cuando se ejecuten en Wayland y proporcionen suficientes API. La versión anterior (versión 1) es compatible con KDE Plasma 5, GNOME, LXQt, Cinnamon y MATE en X11.

Personalmente nunca he utilizado esos docks o paneles vistosos, con efecto zoom y flotantes en el escritorio para lanzar aplicaciones. Me gusta el panel inferior clásico, con su bandeja de sistema e información básica de audio, aplicaciones que se están ejecutando, etc.

Pero reconozco que hay muchas personas que gustan de customizar sus escritorio GNU/Linux con docks vistosos que les pueden resultar útiles. Hace unos años, un dock muy extendido fue Latte Dock, proyecto que quedó discontinuado en 2022 y quizás este Crystal Dock pueda ser un buen reemplazo a quien eche de menos un dock.

Funcionalidades

Las caracyerísticas propias de Crystal Dock son similares a estas aplicaciones, pero echemos un vistazo a qué ofrece:

• Zoom parabólico suave y efecto translúcido
• Componentes compatibles: Menú de aplicaciones, Programas/Administrador de tareas, Reloj
• Soporte para múltiples docks
• Integración con varios entornos de escritorio: entradas de menú especiales (por ejemplo, Cerrar sesión), lanzadores predeterminados específicos, configuración de fondos de pantalla
• Soporte para configurar diferentes fondos de pantalla para diferentes escritorios virtuales
• Configuraciones separadas para entornos de escritorio separados

Instalación

Se puede compilar desde el código fuente, pero gracias a que en su página de publicaciones tienen un paquete .rpm decidí probarlo en mi openSUSE Tumbleweed.

Descargo el paquete rpm en mi sistema y después ejecuto en la carpeta donde se haya descargado lo siguiente: sudo rpm --install crystal-dock-2.1-1.x86_64.rpm

Una vez instalado, desde el menú de aplicaciones está disponible. Al abrirlo la primera vez nos pregunta algunas configuraciones básicas, que más tarde prodremos cambiar.

Y ya tendremos nuestro Crystal Dock funcionando. Para una mejor experiencia visual recomiendan utilizar el tema de iconos Crystal remix.

Si finalmente no quieres usarlo, yo para cerralo tuve que ir a una terminal y matar el proceso con kill.

Configuración

Pinchando con el botón derecho del ratón en un espacio del dock podremos acceder a las diferentes configuraciones que nos ofrece Crystal Dock, tanto en el aspecto visual como a la hora de comportamiento del dock: Flotante, fijo, ubicación, que desaparezca o siempre visible, etc… Podremos configurar y establecer varios docks a la vez.

Si eres de esas personas que estaban buscando un dock, quizás quieras probar esta opción en tu sistema y te convenza el resultado. Si es así, no dudes en hacérmelo saber en los comentarios y agradecer el trabajo a quienes lo hacen posible.

Enlaces de interés

• https://github.com/dangvd/crystal-dock
• https://github.com/dangvd/crystal-dock/releases
• https://github.com/dangvd/crystal-dock/wiki/Documentation

The openSUSE.Asia Summit 2024 is fast approaching, and we’re excited to invite participants from all over the world to join us Nov. 2 and 3 in Tokyo, Japan.

This year promises a diverse range of sessions and activities, with an inclusive Cross-Distro Track featuring collaborations with community members from AlmaLinux, Debian and Ubuntu .

Those who want to provide a talk need to submit either long talk or short talk presentations by August 4. Those speakers needing financial assistance can use the Travel Support Program (TSP), which is aided through donations to the Geeko Foundation. The TSP helps covering travel expenses. Here’s a detailed look at important deadlines for TSP applications and speaker proposals to ensure you don’t miss out on this incredible opportunity.

Travel Support Program (TSP) Schedule

The Travel Support Program is designed to help you join us at the summit. Here’s the timeline you need to follow:

• TSP Application Open: As soon as possible. Don’t wait to apply for travel support.
• Call for Speakers Deadline: August 4. If you’re interested in sharing your knowledge and experience, submit your proposal by this date.
• TSP Application Deadline: August 20. Ensure your application for travel support is completed and submitted by this date. Visit the wiki for more information
• Call for Speakers Notification: Speakers will be notified if their proposal has been accepted toward the end of August.
• TSP Confirmation: Final confirmation of travel support will follow shortly after the speakers’ notifications. Around August 26.

Submitting Your Proposal

The openSUSE.Asia committee is looking for speakers who can bring diverse perspectives and insights related to openSUSE and other Linux distributions. Here are some guidelines and tips to help you submit a strong proposal:

• Topics: We’re interested in a wide range of topics, including but not limited to openSUSE Projects (Leap, Tumbleweed, MicroOS), desktop environments (GNOME, KDE, XFCE), office and graphic applications (LibreOffice, GIMP), cloud and virtualization (Kubernetes, Rancher), and package supply-chain security.
• Non-Technical Topics: Overviews of Open Source technologies, community management, education, and personal experience stories are also welcome.
• Session Types: You can propose long talks (30 minutes plus Q&A) or short talks (15 minutes plus Q&A). Lighting talk sessions will be announced later.

How to Submit: Proposals should be submitted through events.opensuse.org. Make sure your submission is in English, is between 130 to 250 words, and adheres to the openSUSE Conference Code of Conduct. For guidance on writing a strong proposal, refer to our proposal writing guide.

Presentation Requirements: You can present in English or Japanese, but all slides and documents must be in English. Note that pre-recorded videos or video calls are not permitted; you must be present at the venue. For more details, visit events.opensuse.org.

El mejor gestor de imágenes de la Comunidad KDE (y una de las mejores del mercado tanto libre como privado) sigue su desarrollo y me complace anunciar que ha sido lanzada la cuarta actualización de digiKam 8, una nueva versión que incluye un buen número de soluciones de errores y la incorporación de algunas mejoras, como el traductor automático de etiquetas.

Cuarta actualización de digiKam 8, ahora con traductor automático de etiquetas

Tras cinco meses de mantenimiento activo y una larga selección de errores, el equipo de digiKam se enorgullece de presentar la versión 8.4.0 de su gestor de fotos digitales de código abierto.

Esta versión llega con el algunas novedades como el traductor automático de etiquetas, que permite llamar automáticamente a un traductor en línea para que genere las palabras clave correspondientes en los idiomas que prefiera o el nuevo procesador G’MIC para el gestor de colas por lotes, con el que podremos aplicar más de 600 efectos a nuestras fotos de forma masiva.

Como siempre , esta versión viene con una gran lista novedades, aunque en esta ocasión vienen heredadas de las actualizaciones de sus componentes. De esta forma tenemos:

• Actualizado el decodificador interno RAW Libraw a la rolling-release snapshot 2024-07-11. Esto incluye una lista de nuevas cámaras soportadas.
• El conjunto de herramientas DNG de Adobe se ha actualizado a la última versión 1.7.1, que incluye la compatibilidad con la compresión JPEG-XL para reducir el tamaño del contenedor del negativo digital.
• Ahora DigiKam es compatible con la nueva API del kit de herramientas LensFun 0.4 de esta biblioteca prevista para este año.
• QtAVPlayer interno ha sido actualizado a la última rolling-release snapshot 2024-06-16. Para la versión Qt6, el reproductor multimedia es ahora capaz de avanzar vídeo fotograma a fotograma.
• ExifTool ha sido actualizado en todos los paquetes a la última versión 12.88. También la otra biblioteca compartida de metadatos muy importante Exiv2 se ha actualizado a la última versión 0.28.2.

Más información: Digikam

Las novedades de digiKam 8

El pasado 16 de abril, es decir, ayer fue lanzado digiKam 8.0, la nueva versión de uno de los gestores de imágenes más completo que puedes encontrar en el mundo GNU/Linux, e incluso en el mundo privativo.

Este nuevo digiKam ha recibido un intenso trabajo en muchas de sus facetas, no en vano han pasado más de dos años de desarrollo donde se han ido puliendo aspectos que estaban descuidados, que simplemente se habían quedado obsoletos o que deben adaptarse a los tiempos en los que vivimos.

Y es que, en el mundo del Software, y en cualquier otro mundo también, si no se evoluciona te extingues. De esta forma, una pincelada de las novedades que nos ofrece su octava versión estable son las siguientes:

• Mejoras en la traducciones.
• Revisión completa de la versión Windows.

Más información: digiKam

¿Qué es digiKam?

La mejor forma de definir digiKam es buscar como se describe esta aplicación de userbase.kde.org y realizar una pequeña síntesis:

«DigiKam es una aplicación que te permite la importación de fotografías desde  cámaras, creación de álbumes, etiquetado con fechas, temas y otras propiedades, utilidades de búsqueda excelentes y modificación de imágenes en masa.»

La entrada Cuarta actualización de digiKam 8, ahora con traductor automático de etiquetas se publicó primero en KDE Blog.

Hello!

It's been a long time since a news update here. Many things changed, and there are lots of exciting news which have been partially communicated in emails and meetings, but not in much detail. I try to clean up some of the news backlog gathered in a good half of a year with this post.

Data center move¶

With SUSE moving one of their datacenters (the one which hosted the majority of openSUSE infrastructure) to Prague towards the end of 2023, we got the opportunity to not only move our systems along, but also to introduce fundamental changes which would have otherwise been difficult to implement in the existing environment - both for SUSE, and for openSUSE.

SUSE graciously provided us with not only brand new hardware, but also autonomy over what we do with it. Whereas the physical infrastructure in the old location was entirely operated by SUSE, with openSUSE merely having SSH access to the virtual machines, the new setup allows the openSUSE Heroes to fully manage their hypervisors and networking stack. This freedom allows the team to implement new ideas and react to issues with virtual machines without relying on and waiting for SUSE internal support.

Maintenance¶

Of course, lots of freedom comes with lots of responsibility. That makes it even more important for our infrastructure to be stable and easy to maintain - after all, the Heroes team is made of volunteers, of which there aren't many who can be motivated to spend their free time with boring maintenance tasks. Hence we now enforce automatic security updates on all machines using os-update and rebootmgr, with added logic to reduce outages by staggering the package updates on reboots of machines in high availability clusters, and to alert administrators about machines requiring updates which cannot install them on their own, or ones requiring manual reboot intervention.

Automation¶

We already use Salt as an automation and infrastructure as code solution since a long time, but increased the Salt coverage by a large margin. Whereas previously only a comparatively small amount of machine configuration was actively maintained using Salt, now the whole base system (network configuration, repositories, kernel settings, authentication, monitoring, logging, certificates, email, automatic updates) is covered, with a steadily increasing amount of the various machine specific services (not surprisingly, the large amount of services under the opensuse.org umbrella comes with a large amount of applications requiring configuration).
Using the infrastructure as code approach has multiple benefits, some of which are:

• configuration changes are tracked and documented in a Git history
• configuration is unified across all machines
• central deployment of changes is possible To fully use those benefits, it is essential to have a large coverage, and to reduce the times one needs to manually visit a machine for changes.

We encourage you to check our Git repositories if you are curious (the salt.git repository is now automatically mirrored to code.opensuse.org and GitHub!):
https://github.com/openSUSE/heroes-salt or https://code.opensuse.org/heroes/salt/tree/production
https://github.com/openSUSE/salt-formulas or https://code.opensuse.org/heroes/salt-formulas/tree/main

Monitoring¶

Monitoring already had an important role in our infrastructure before, but it was time to expand it further. The setup which had its center in our old data center, and was based on Nagios and Icinga, served us very well - but after working with it for some time, I gathered the following concerns:

• the server configuration was not managed by Salt, and there was no existing Salt formula community around it
• lots of checks are executed on machines through a central agent which runs as root
• single failure domain
• often the need for custom check scripts to cover new applications

The data center move broke the existing setup, which finally answered my question about whether to refactor or whether to build something new.
After evaluating multiple solutions, including Nagios again, Munin and Zabbix, the choice eventually fell to a stack with Prometheus at its heart. Not only do I have existing experience with Prometheus, but also did I value:

• configuration of all server and client components is either through environment variables, or YAML files - perfect for integration into a code based infrastructure without lots of custom templating
• existing Salt formulas
• each service being monitored is equipped with a dedicated metrics exporter - this for one keeps other services actively monitored if one exporter breaks, but more importantly it allows for deep privilege separation, as most monitoring checks can be performed with only a small set of permissions
• a large amount of applications, especially ones providing web services, which we run plenty of, have built-in support for serving Prometheus compatible metrics - those allow for extremely easy integration with no need to install or write custom monitoring checks or "translation" tools
• plenty of existing community supported exporters for applications which do not provide built-in Prometheus metrics - the configuration of them is usually standardized, making RPM packaging and deployment easy
• easy to add custom checks to collect metrics covered by neither of the above

Already a large amount of additional metrics from various services which were not monitored before are gathered using the new setup. For most we already implemented alerting to notice odd behavior early, and added visualization dashboards with graphs - of course because they are pretty, but also to make spotting anomalies at a glance easier.

The alerting rules which are made of PromQL expression can be found in the previously linked repositories, under salt/files/prometheus/alerts/. Currently, we split alerts based on their severity into either IRC (#opensuse-admin-alerts - still a bit experimental), email, or dashboard receivers.

The alerting dashboard (using Karma) - currently only reachable if connected to the openSUSE Heroes VPN:
https://alerts.infra.opensuse.org/

The visualization dashboards in Grafana - accessible to everyone:
https://monitor.opensuse.org/grafana/.

Our monitoring posture is on a good track, but there is still a lot of work to do to cover more services, fine tune alerts, and to update the internal documentation and response.

Security and internal authentication¶

Previously we used a FreeIPA based LDAP setup for authentication of Heroes to internal services and machines.
We did not use the majority of features FreeIPA offered, and had noone wanting to maintain a machine not running openSUSE anymore - with Kanidm experience in the team, the decision what to migrate to was easy.

In the process, we replaced the sssd installations on all machines with kanidm-unixd, and globally enforced public key based authentications for SSH. Not only is the setup simpler and well maintained, we also found improvements with credential caching, allowing login even throughout potential network issues on a host.

VPN¶

Gateway to all of our internal openSUSE infrastructure is a OpenVPN setup. We improved its security by switching to the current best practices for compression.

Closing words¶

Of course, there have been various other changes, some of which being too small to cover here, some of which simply forgotten about. You will either find out about them in future news posts, or by inspecting our commit and ticket histories.

Have fun!

Veamos cómo utilizar systemd en GNU/Linux para hacer que se ejecute un script al apagar nuestro equipo

En un artículo anterior compartí cómo hacer que se ejecutara un script al iniciar o cerrar el escritorio Plasma:

• https://victorhckinthefreeworld.com/2024/04/02/ejecutar-scripts-al-inicio-o-cierre-de-sesion-en-plasma-6-de-kde/

Pero en mi caso, en un equipo remoto que tenía configurada esa opción, no se estaba ejecuando el script ya que como estaba conectado mediante ssh, apagaba el equipo con el comando poweroff o shutdown desde otro equipo remoto.

Para que siempre se ejecute el script, decidí buscar cómo hacerlo mediante systemd en GNU/Linux.

Ejemplo

Partamos de la premisa que tenemos un script en la siguiente ruta: /home/usuario/Scripts/mi_script.sh Cambia en tu caso, el nombre de usuario, carpeta donde está ubicado y el nombre del script. El script debe tener permisos de ejecución. Ya sabes chmod +x mi-script

Crear el servicio en systemd

Ahora vamos a crear un servicio nuevo para systemd que será el que le indique qué queremos ejecutar y cuando hacerlo. Para ello como root, creamos el siguiente archivo que en mi caso le he llamado antes-apagado.service en la siguiente ruta: vim /etc/systemd/system/antes-apagado.service

Y dentro del archivo pegamos lo siguiente y guardamos el equipo. No olvides cambiar lo necesario en tu caso:

[Unit]
Description=Ejecuta un script antes de apagar el equipo
DefaultDependencies=no
Before=shutdown.target

[Service]
Type=oneshot
ExecStart=/home/usuario/Scripts/mi-script.sh
TimeoutStartSec=0

[Install]
WantedBy=shutdown.target

Siguiendo como root, ejecutamos lo siguiente para reiniciar los servicios de systemd systemctl daemon-reload

Y lo habilitamos para que esté disponible para el próximo apagado: systemctl enable antes-apagado.service

La próxima vez que apaguemos el sistema systemd ejecutará el servicio recién creado que ejecutará nuestro script.

Añadir que se ejecute al reiniciar

Quizás queremos que nuestro script se ejecute no solo al apagar nuestro equipo, si no también al reiniciarlo. Para ello modificaremos el servicio de systemd anterior modificando en el apartado [Unit] la línea de Before y la sustituiremos por esta: Before=shutdown.target reboot.target

Ejecutar un script al iniciar el sistema

También podemos, mediante systemd, hacer que se ejecute el script al inicio del sistema una vez que todos lo servicios de systemd se han arrancado. Para ello tenemos que en vez del servicio anterior, crearemos en la misma ruta otro servicio con el siguiente contenido:

[Unit]
Description=Ejecutar un script al inicio después de que se hayan cargado todos los servicios
After=default.target

[Service]
Type=simple
RemainAfterExit=yes
ExecStart=/home/usuario/Scripts/script-inicio.sh
TimeoutStartSec=0

[Install]
WantedBy=default.target

De manera similar al caso anterior, reiniciamos los servicios y habilitamos el servicio recién creado.

Espero que te resulte útil a ti lector o lectora que recala por el blog, y a mi yo del futuro cuando lo necesite

Me congratula presentaros el episodio Comunitario de KDE Express, titulado «Komunidad con Ivan GJ» donde David Marzal entrevista a Ivan GJ, una de las recientes incorporaciones de KDE España que ha llegado con fuerza colaborando con este blog y realizando vídeos de calidad para sus canales de Peertube y Youtube como ya hemos presentado en esta bitácora.

Komunidad con Ivan GJ en KDE Express

Comenté hace ya bastante tiempo que había nacido KDE Express, un audio con noticias y la actualidad de la Comunidad KDE y del Software Libre con un formato breve (menos de 30 minutos) que complementan los que ya generaba la Comunidad de KDE España, aunque ahora estamos tomándonos un tiempo de respiro por diversos motivos, con sus ya veteranos Vídeo-Podcast que todavía podéis encontrar en Archive.org, Youtube, Ivoox, Spotify y Apple Podcast.

De esta forma, a lo largo de estos más de 30 episodios, promovidos principalmente por David Marzal, nos han contado un poco de todo: noticias, proyectos, eventos, etc., convirtiéndose (al menos para mi) uno de los podcast favoritos que me suelo encontrar en mi reproductor audio.

En esta ocasión cambia de formato ya vuelve el formato Comunitario del podcast. En palabras de David:

Vuelven por fin los episodios de comunidad, en esta ocasión contamos con una de las últimas incorporaciones a la Asociación KDE España.

Hablamos con Iván, sobre como llegó al Software Libre y a KDE, su camino por la divulgación en YT y su nueva etapa enfocada en la cultura y SL.

• Enlaces de las cosas mencionadas en el episodio:
  • Mastodon: https://mastodon.social/@ivangj
  • Peertube: https://fediverse.tv/a/ivangj/
  • Web: https://ivangj.xyz/
  • Repoductor Haruna : https://haruna.kde.org/

¡Seguidle que tiene muchas cosas que contar!

Agradecimientos: Jorge Lama por su asistencia, consejo, apoyo y edición de audio en este episodio.

Y, como siempre, os dejo aquí el audio para que lo podáis disfrutar.

Por cierto, también podéis encontrarlos en Telegram: https://t.me/KDEexpress

La entrada Komunidad con Ivan GJ en KDE Express se publicó primero en KDE Blog.

告知しています通り、openSUSE.Asia Summit 2024 Tokyo を2024年11月2日(土)、3日(日) に麻布台ヒルズの株式会社SHIFTさんで開催します。
openSUSE.Asia Summit はアジア地域の openSUSE コミュニティ（貢献者、ユーザー）が一堂に集まり、交流し、楽しむイベントです。

openSUSE.Asia Summit 2024ではopenSUSE以外にも，Dockerなどのコンテナ，DevOps，日本語IMEなどのLinux Desktop，オープンソースのオフィススイートであるLibreOfficeやセキュリティについてなど幅広いトークを予定しています。また、AlmaLinux、Debian、Ubuntuなどの主要ディストリビューションの講演があるCross Distro Trackもあります。

この openSUSE.Asia Summit 2024 Tokyoにて、学生ボランティアを募集しています。
アジアのオープンソース関係者と交流するまたとない機会です！

学生ボランティアには素敵な特典をご用意。

• イベントTシャツ
• 懇親会11/2(土)のご招待

交通費について

• 関東近郊：交通費実費。上限目安：四日間で4000円（これを超える場合はご相談下さい）
• 宿泊を伴う場合：交通費、宿泊費実費ないし一部。ご相談下さい。（8/20までに予定する交通費、宿泊費をご連絡ください）

ボランティアの仕事

• 会場の準備
• 来場者受付
• スピーカーのサポート（マイク、タイムキーパーなど）
• 4日(月祝)のツアーのサポート

希望するセッションには基本的に参加できます。英語が出来なくても問題ありません。また、発表者として発表されることを推奨します。

詳細

• 日時
  • 2024年11月1日（金）17:00-19:00
  • 2024年11月2日（土）8:00-20:00
  • 2024年11月3日（日）9:00-20:00
  • 2024年11月4日（月祝）※ツアー（詳細未定）
• ※全時間ではありません。
• 会場：麻布台ヒルズ 株式会社SHIFT
• 募集条件: 少なくとも土曜日に参加できること（土曜日に参加できない場合は応相談）

お手伝いいただける方は、以下の情報をopensuse-asia-24-contact@googlegroups.comまでお送りください。

• 氏名：
• 氏名よみがな：
• 所属(大学名/学部名)：
• Tシャツサイズ（XS / S / M / L / XL）：
• メールアドレス：
• 参加日：
• 必要な交通費：

イベント詳細については以下をご覧ください。

• イベントページ：https://events.opensuse.org/conferences/oSAS24

沢山のご応募をお待ちしています。明日のOSSを担うのは君だ！