Mastodon nos permite eliminar toots que hemos publicado pudiendo elegir qué lapso de tiempo y características permitimos
Allá por el prescindible 2020 escribí un artículo sobre esto mismo, borrar toots antiguos de tu cuenta de Mastodon. Por aquel entonces mencionaba dos herramientas que a día de escribir este ya no están disponibles.
Lo bueno, es que Mastodon ha evolucionado lo suficiente para incorporar esta funcionalidad de manera nativa. Así que vamos a actualizarnos y ver cómo lo podemos hacer.
En primer lugar quizás te preguntes ¿Por qué iba a querer yo borrar toots antiguos? Mi respuesta a eso es: ¿Por qué no ibas a quererlo?
Los toots ocupan espacio en el servidor donde están alojados, y ¿realmente te interesa mantener algo que dijiste hace un tiempo?
Quizás ya no pienses lo mismo sobre aquello que dijiste hace medio año, quizás sí piensas lo mismo pero no crees que esto pueda ser importante a día de hoy para nadie más. O quizás simplemente eres consciente de la imperdurabilidad de las cosas en el continuo espacio tiempo y más en algo tan efímero como es internet.
Bueno, en todo caso y sea cual sea las razones, os voy a explicar cómo configurar la fecha de caducidad de tus toots en Mastodon y que estos desaparezcan.
Desde la interfaz web de Mastodon, abrimos el menú de configuración de tu cuenta pinchando sobre los tres puntitos al lado de tu avatar y de todas las opciones escogemos «Eliminación automática de publicaciones».
En la pantalla que nos aparece tenemos distintas opciones que podemos configurar. Son bastante intuitivas y está todo bien explicado, así que no faltaría más que escoger las opciones que queremos para nuestro caso y aplicar los cambios.
En mi caso, tengo configurado que elimine mis toots más antiguos de 2 meses, pero que mantenga los toots que he marcado como fijados, los que me he marcado como favoritos, los mensajes directos que envío a otros usuarios y a los que he añadido un marcador (marcador que no he utilizado en la vida).
También puedes hacer que se mantengan aquellos toots tuyos que hayan tenido cierta relevancia, haciendo que no se borren los que han llegado un número determinado de impulsos o favoritos. Haciendo así perennes aquellos toots que a tus seguidores más les ha gustado y recreándote de ser un «influencer» del fediverso.
Establece (o no) el borrado de tus toots y configúralo a tu gusto en Mastodon de manera nativa en las opciones. Y si te gusta lo que escribo en Mastodon, disfrútalo, porque en dos meses (más o menos) se perderán como lágrimas en la lluvia…
Users of openSUSE can now rely on the built-in switcherooctl tool for GPU switching, which is already integrated into our distributions with major desktop environments like GNOME and KDE Plasma.
This is a game changer because it eliminates the need for additional tools and simplifies multi-GPU management while enhancing compatibility and performance with users’ systems.
For years, tools such as suse-prime and bbswitch have been staples in managing NVIDIA Optimus laptops and multi-GPU systems, but advancements in kernel drivers and desktop environments have made these tools unnecessary in most cases.
Installations of openSUSE now handle these configurations out of the box, whether using the open-source Nouveau driver or NVIDIA’s proprietary drivers.
In a recent update on multi-GPU systems, users are encouraged to move away from legacy tools like suse-prime, bbswitch, and bumblebee, as they can cause more harm than good on modern systems.
The recommended solution is switcherooctl, which is a lightweight userspace utility designed to manage GPU switching on systems with multiple GPUs. It integrates well with Wayland and Xorg; its functionality extends across both Intel + NVIDIA and AMD + NVIDIA setups. By using switcherooctl, users can easily select which GPU to use for specific applications and eliminate the need for complex scripts or environment variables.
Benefits of switcherooctl
Seamless Integration: Unlike older tools, switcherooctl is designed to work natively with modern Linux systems and desktop environments. This ensures a smoother user experience without requiring complex configurations.
Improved Performance: Users can specify which GPU to use for specific tasks, so switcherooctl enables optimal performance. Compute-heavy applications, such as gaming or 3D rendering, can utilize the discrete GPU, while less intensive tasks default to the integrated GPU to save power.
Enhanced Power Management: Switching back to the integrated GPU when the discrete GPU is not needed conserves battery life and makes it ideal for laptops and portable systems.
Wayland and Xorg Compatibility: With increasing adoption of Wayland, having a tool that supports both Wayland and Xorg ensures compatibility across a broad range of systems and setups.
Cross-Vendor Support: The Intel + NVIDIA or AMD + NVIDIA configuration make the systems more versatile for all users.
Users should being embracing switcherooctl for multi-GPU management as some of the older tools like suse-prime, bbswitch and bumblebee are likely to be phased out.
Users of openSUSE can now rely on the built-in switcherooctl tool for GPU switching, which is already integrated into our distributions with major desktop environments like GNOME and KDE Plasma.
This is a game changer because it eliminates the need for additional tools and simplifies multi-GPU management while enhancing compatibility and performance with users’ systems.
For years, tools such as suse-prime and bbswitch have been staples in managing NVIDIA Optimus laptops and multi-GPU systems, but advancements in kernel drivers and desktop environments have made these tools unnecessary in most cases.
Installations of openSUSE now handle these configurations out of the box, whether using the open-source Nouveau driver or NVIDIA’s proprietary drivers.
In a recent update on multi-GPU systems, users are encouraged to move away from legacy tools like suse-prime, bbswitch, and bumblebee, as they can cause more harm than good on modern systems.
The recommended solution is switcherooctl, which is a lightweight userspace utility designed to manage GPU switching on systems with multiple GPUs. It integrates well with Wayland and Xorg; its functionality extends across both Intel + NVIDIA and AMD + NVIDIA setups. By using switcherooctl, users can easily select which GPU to use for specific applications and eliminate the need for complex scripts or environment variables.
Benefits of switcherooctl
Seamless Integration: Unlike older tools, switcherooctl is designed to work natively with modern Linux systems and desktop environments. This ensures a smoother user experience without requiring complex configurations.
Improved Performance: Users can specify which GPU to use for specific tasks, so switcherooctl enables optimal performance. Compute-heavy applications, such as gaming or 3D rendering, can utilize the discrete GPU, while less intensive tasks default to the integrated GPU to save power.
Enhanced Power Management: Switching back to the integrated GPU when the discrete GPU is not needed conserves battery life and makes it ideal for laptops and portable systems.
Wayland and Xorg Compatibility: With increasing adoption of Wayland, having a tool that supports both Wayland and Xorg ensures compatibility across a broad range of systems and setups.
Cross-Vendor Support: The Intel + NVIDIA or AMD + NVIDIA configuration make the systems more versatile for all users.
Users should being embracing switcherooctl for multi-GPU management as some of the older tools like suse-prime, bbswitch and bumblebee are likely to be phased out.
Sigo con entradas de mi marca de ordenadores favorita: Slimbook. Y es queme he dado cuenta que algunos de sus dispositivos no habían sido presentados en el blog. Como podemos ver en su página web ofrecen su nuevo NAS CUBE, un pequeño servidor ideal para pequeñas empresas que no quieran perder su información y centralizar sus servicios.
NAS CUBE de Slimbook, un servidor compacto y potente
Antes de empezar quiero destacar no penséis que hago toda esta publicidad porque reciba una compensación económica, simplemente porque confio en esta empresa que no olvida que el Software Libre es algo más que Software y que busca ofrecer no solo productos sino un excelente servicio post-venta, algo que en muchas ocasiones olvidamos que es importante.
Dentro de la gama de ordenadores de sobremesa, la empresa valenciana Slimbook presentó hace poco su NAS CUBE, un compacto pero potente servidor, que según ellos mismos es:
el servidor que toda PYME necesita, ideal para compartir ficheros, con una CPU potente que permite ejecutar contenedores, máquinas virtuales y servicios. Incluye redundancia con cuatro puertos de red de 2.5 Gbps
Algunas de las características de este NASS CUBE son las siguientes:
Welcome to the second edition of our new spotlight series. With these posts we
want to give you an insight into activities of the SUSE security team beyond
major security findings for which we are publishing dedicated reports. Autumn
is always a busy time at SUSE, when new service pack releases and new products
are prepared. This results also in an increased amount of review requests
arriving for the SUSE security team. This time we will be looking at various
D-Bus interfaces, Polkit authentication, temporary file handling issues, a
small PAM module and setgid-binary, Varlink IPC in systemd as well as some
other topics.
Keepalived Follow-up Review
In bsc#1218688 we looked
into Keepalived, a load-balancing software
written in C. A colleague in the team noticed suspicious handling of temporary
files in /tmp and asked for a more in-depth review.
Temporary File Handling
The creation of temporary files in Keepalived is indeed a bit peculiar. The
make_tmp_filename()
helper function takes the basename of a temporary file and returns a path to this file in
$TMPDIR. An example use would be make_tmp_filename("keepalived.json") and
the function will return /tmp/keepalived.json. This can easily lead to
unsafe temporary file creation.
In the code the resulting filenames are always coupled with another utility
function
fopen_safe(),
though. This function intercepts attempts to open files for writing ("w"
mode) and calls the mkostemp() function behind the scenes to safely create a
temporary file. The resulting file will then not be used as-is, though, but
will be rename()‘d to the expected predictable filename. This is safe,
because rename() will not follow symlinks or otherwise reuse the target
path, but simply replace it.
D-Bus Implementation
Keepalived also implements a D-Bus system service running as root. Our team
reviewed this component many years
ago, which led to
multiple CVE assignments. Therefore it seemed like a good idea to have a fresh
look at the current situation, while we’re at it. We couldn’t find any
problems, though. The code is non-trivial but robust. The D-Bus methods can
only be called by root. Only some D-Bus properties can be accessed by
unprivileged users, but they are not sensitive in nature.
DKIMproxy Symlink Attack
Our team is monitoring changes to systemd services across all of openSUSE
Tumbleweed. One such change occurred in
DKIMproxy and led us to
bsc#1217173. DKIMproxy
is a proxy designed for the Postfix mail server. It implements the DKIM
standard for signing outgoing email or verifying incoming email.
The package’s systemd service is not part of the upstream sources, but has
been added by the package maintainer on packaging level in the Open Build
Service.
In this service unit a shell script is executed via ExecStartPre with root
privileges, while the actual service runs with the lowered privileges of a
dedicated service user and group. The shell script performs naive write
operations in a directory owned by the unprivileged user. Therefore the
unprivileged user can prepare symlink attacks to cause arbitrary file
overwrite in the system, as soon as the script is executed again. The content
that is written is not controlled by the attacker, therefore this only has
denial-of-service impact and does not allow to raise privileges.
We can observe a number of aspects in this case that, based on our experience,
represent typical patterns. In the following sections we will look at these in
more detail.
Files Added on Packaging Level
Assets like configuration files, scripts or code that are added on packaging
level have an increased probability of introducing problems. Some of the
reasons for this could be:
there are less people that review such contributions.
the process for adding these files is less formalized than e.g. in a GitHub
project.
packagers that add such files might be lacking knowledge about the upstream
project.
packagers might accept such files from others that want a certain feature or
behavior and don’t know exactly what it does.
packagers might take over such files from other Linux distributions,
assuming that they are of high quality.
Since we identified that such packaging assets carry an increased risk for
issues, we are monitoring additions of and changes to such files in the Open
Build Service to look out for problems proactively.
Pre- or Post-Scripts in systemd Services
When privilege separation is in place for a systemd service, we can often
find such ExecStartPre and ExecStartPost scripts that are run with raised
privileges. This mixture of two different security domains can easily
introduce local security issues. This risk is further increased by the fact
that these programs are often shell scripts that offer no built-in mechanisms
to safely access files owned by unprivileged users as root.
Privilege Separation added after the Fact
Especially in older software that was initially designed to run with full
root privileges, privilege separation is sometimes only added as an
afterthought, or an unofficial downstream add-on on packaging level. On the
surface, such setups often seem to provide privilege separation, i.e. one or
more components are running as non-root accounts. This privilege separation
can often be easily circumvented as soon as the unprivileged account is
compromised, however.
Such weak privilege separation can still offer some level of protection and
is usually an improvement over services running as full root. Still, the
lack of robustness means that a false promise is given to administrators:
namely, that strong separation of privileges exists for such services. The
defense in depth is lacking, though, and a change of security scope can
happen. Thus, such issues are usually considered worthy of a CVE assignment.
In our team we assign or request CVEs for such issues on a case-by-case basis,
depending on the severity of the issue, the popularity of the affected
software and so on. In the case of DKIMproxy only a denial-of-service can
happen and the software is not that widespread, thus we decided not to assign
a CVE for it.
Handling of a Vulnerability Report in MirrorCache (CVE-2024-49505)
We have been privately approached by security researcher Erick Fernando about
a reflected XSS vulnerability in the openSUSE
MirrorCache repository. MirrorCache
is a web server that redirects download requests to a mirror according to
configuration. We handled the report in
bsc#1232341 and assigned
CVE-2024-49505 to it. The responsible maintainer applied a fix for the issue
and our team member Paolo Perego verified the patch.
Luckily the MirrorCache project is not part of any official products or server
side infrastructure of SUSE. We want to thank Erick Fernando again for
reaching out to us and reporting this issue.
Issues with Temporary Files in Hardinfo2
Hardinfo2 is a utility to obtain hardware
information on Linux, create reports from that data and compare different
systems for benchmarking. Hardinfo2 has been newly packaged for openSUSE
Tumbleweed in October, and the following lines showed up in our systemd
monitoring:
The use of fixed temporary file paths sticks out right away, so we created
bsc#1231839 to handle the
issues resulting from this. By default, kernel protections like
protected_symlinks prevent more severe issues like overwriting system files,
which would lead to denial-of-service. Even with these protection measures, a
local user can pre-create these files and Hardinfo2 will then use the attacker
controlled data found in them, causing integrity violation.
Furthermore this logic causes information leaks. The data from /proc/ioports
is made world-readable via the temporary file /tmp/hardinfo2_ioports. By
default this information is already public in /proc on openSUSE. But it seems
on some systems this was not the case, because Hardinfo2 performs these steps
to allow unprivileged processes to access that data in /tmp. Another
information leak is the chmod a+r operation for
/sys/firmware/dmi/tables/*. The permissions of pseudo files should not be
altered in a drive-by fashion by system services this way.
We reported the issues to upstream, which quickly worked on improvements in
these areas. The shell code has been moved into a proper script named
hwinfo2_fetch_sysdata. The problematic files in /tmp are now placed
into a dedicated directory in /run/hardinfo2. Users that want to use
hardinfo2 now need to be a member of a newly introduced “hardinfo2” group
to be able to access the data placed into this directory. The permissions
of files in /sys are no longer changed.
Upstream created a new release 2.2.1 containing the changes. We did not
request a CVE for these issues, since the biggest impact they can have by
default is integrity violation of Hardinfo2 itself.
Aeon-Check Encryption Key in Fixed Temporary File (CVE-2024-49506)
Aeon-Check is a small utility
used in openSUSE Aeon. Currently it consists
only of a simple bash script invoked via a systemd unit. This script can
detect a bug in the TPM-based LUKS disk encryption setup and fix it. To this
end, an additional LUKS key slot is temporarily added to the root LUKS device:
keyfile=/tmp/aeon-check-keyfile
dd bs=512 count=4 if=/dev/urandom of=${keyfile}iflag=fullblock
chmod 400 ${keyfile}
<snip>
# Writing keyfile to slot 31 (end of the LUKS2 space) to avoid clashes with any customisation/extra keys
cryptsetup luksAddKey --token-only--batch-mode--new-key-slot=31 ${rootdev}${keyfile}
The temporary file used to store the ephemeral LUKS key has a fixed filename
in /tmp. Fortunately the script has the errexit option set; combined with
the protected_regular and protected_symlinks kernel features, no unsafe use
of an already existing file in that path will succeed. Without the kernel
protection, though, another local user could pre-create this file, and
intercept or stage the data used as temporary LUKS key. Even then the chances
for exploitation are small, since this systemd service typically only runs
once during boot, and the time window during which the temporary LUKS key is
valid is short.
Since LUKS encryption is a sensitive area, we still decided to assign a CVE for
the issue. We handled the problem in
bsc#1228861, and a simple
bugfix has been made by the author of the script to use mktemp for safe
creation of the temporary file holding the LUKS key data.
SDDM Follow-Up Review of D-Bus Interface
The openSUSE package for the SDDM display
manager has been forked for the openSUSE
Kalpa flavour. This made a new
D-Bus service whitelisting necessary, which was requested in
bsc#1232647. The
sddm-kalpa package is a Wayland-only version of SDDM, but the sources used in
the package are the same as for regular SDDM.
We still used this opportunity to take a fresh look at the situation in SDDM.
The D-Bus service shipped with it is practically only a skeleton without
implementation. Only a single D-Bus method
SwitchToGreeter()
is implemented. There is no Polkit authorization, which means that any user
can trigger the logic to switch to the greeter. While this situation is not
ideal, it is not critical. Therefore we accepted the new package.
Libcgroup Revisited
Libcgroup is a library and set of
utilities for using control groups on Linux systems. These days systemd is
taking care of this job and, since libcgroup upstream was unmaintained, the
package was dropped from openSUSE in 2018. We received a request to
reintroduce libcgroup in bsc#1231381.
Upstream is active again and there seem to exist some use cases for the package.
Our team was involved because the package contains a setgid binary and a PAM
module. We also had a look at the main daemon cgrulesengd, which is running
as root. At startup, the daemon iterates over all running processes in
/proc and assigns them to control groups according to configuration. Then a
netlink socket is set up to obtain events from the kernel about newly created
processes and exec() events. These new processes will also be placed into
control groups based on configuration.
The approach taken by the daemon is subject to race conditions by design,
which is also kind of
documented
in the upstream repository. Entries in /proc/<pid> can disappear or change
security scope e.g. when setuid-root binaries are involved. The configuration
is matched to processes based on their name as found in /proc/<pid>/status
and the process’ effective uid and gid. We can imagine that a dedicated
local attacker will be able to have the libcgroup daemon wrongly assign an
unprivileged process to a control group destined only for privileged processes
e.g. by exploiting race conditions and using setuid-root binaries like sudo.
Since this is by design, we did not approach upstream about this possibility.
Users of the package should be aware that this could result in local DoS
attack vectors, though.
The setgid program cgexec found in the package is a simple program
that only forwards an IPC request to the libcgroup daemon, asking it to mark
the calling process as “sticky”. The binary requires special group permissions
to be allowed to connect to the UNIX domain socket of the libcgroup daemon.
The extra privileges are dropped right after connecting to the socket. The
socket is also closed right after sending the request. So escalating group
privileges, leaking the socket file descriptor or otherwise influencing the
IPC communication done by cgexec is not a concern.
The PAM module shipped with the package only implements a PAM session type
hook. It calls into the libcgroup library to assign the calling process to an
appropriate control group, thereby placing new sessions into control groups
according to configuration.
Supergfxctl D-Bus Service
Supergfxctl is a D-Bus daemon
that takes care of low level kernel settings in NVIDIA hybrid GPU systems. The
software has been newly packaged in November and we’ve been asked to whitelist
it in bsc#1232776.
There are some worries with this daemon, mostly with regards to local
denial-of-service attack surface. For example there is some racy logic in the
daemon that looks up and kills all processes that have /dev/nvidia0 open.
The D-Bus methods allow to completely control the daemon’s configuration and
are by default accessible to all members of the sudo, users, adm and
wheel groups. This selection of groups is rather broad and surely targeted
towards maximum compatibility with various Linux distributions. It is unlucky,
because there is a possibly large range of users that are allowed to control
the supergfxctl daemon this way.
To make the new service acceptable for openSUSE we asked the packager to limit
access to the D-Bus service to members of the video group instead. Users
that are in the video group have increased privileges with regards to
accessing the video hardware in the system, thus it is a better match for
supergfxctl than just the users group, for example. An even better approach
would be to add Polkit authentication in this D-Bus service, but this is
something that would require larger efforts by upstream and is not currently
in sight.
Systemd v257 Polkit for Varlink IPC
We routinely review additions to the D-Bus and Polkit interfaces in new
systemd releases. This time we have been asked
to check a few new Polkit actions in systemd-containerd, systemd-homed,
systemd-networkd, and systemd-resolved. Interestingly these daemons have
all been migrated from using D-Bus to using Varlink
for Inter-Process-Communication (IPC).
In our experience, the code quality of systemd components is generally high.
These additions were no different. All new Polkit actions are limited to
auth_admin authorization, thus no additional attack surface is made
available to unprivileged local users.
At first sight the switch to Varlink doesn’t change much security-wise:
there are still individual methods in a service that can be invoked by clients
and some or all of them can be protected by Polkit authentication. The switch
to Varlink requires new glue code for the authorization against Polkit,
however. Thus we looked deeper into how this is done in systemd.
When using D-Bus the
SystemBusName
Polkit subject is used, which identifies a client process by its D-Bus sender
address. This way polkitd can securely identify the credentials of the
client process by asking the dbus-daemon about the credentials of the
owner of the UNIX domain socket used by the client to connect to D-Bus.
With Varlink this is no longer possible. Instead the
UnixProcess
subject is used to identify the client. This made us a bit nervous at first,
because the UnixProcess subject is deprecated and often used insecurely. The
problem here is that polkitd needs to use racy logic to lookup the process
by PID in the /proc file system and extract its credentials. Former SUSE
security team member Sebastian Krahmer discovered this in
2014, and it
affected a lot of programs that implemented Polkit actions using this subject. The
use of this subject in systemd to authenticate Varlink methods is robust,
though. The client’s credentials are obtained from the UNIX domain socket
underlying the Varlink connection, and thus via the kernel. Also a
pidfd can be passed
to Polkit nowadays, which allows polkitd to operate in a race-free fashion
on the client process.
As the Polkit glue code turned out all right we accepted the changes and
whitelisted the additions in systemd v257.
Miscellaneous
The following reviews didn’t yield much of interest, so we’re just providing a
short listing here for reference:
GNOME Remote Desktop follow-up review (bsc#1230406).
Last time we looked into GNOME Remote Desktop, we found a couple of issues in
its D-Bus implementation.
Another D-Bus service “org.gnome.RemoteDesktop.Configuration.service” has been
added in the meantime and we have been asked to take a look. The new service is
rather small and all of its methods are protected by a single Polkit
action “org.gnome.remotedesktop.configure-system-daemon”, which requires
Polkit auth_admin authentication. So there shouldn’t be additional attack
surface for local non-privileged users in the system. Overall the complexity
of GNOME in this area continues to grow, though, and it is a challenge to
review it fully without being an expert in GNOME and the remote desktop
protocols.
Additional D-Bus and Polkit features in the UPower Daemon
(bsc#1232835). This
just adds a boolean switch to control whether a battery charging threshold
should be active or not. It is allowed for users in a local session without
authentication.
Added “memoryinformation” D-Bus Method in kinfocenter6 (bsc#1231659).
Our packager backported this feature from a newer upstream version. This new
action allows users in a local session to obtain the output of dmidecode
--type 17, which contains some low-level information about physical RAM in
the system. The implementation of this is straight-forward and we had no
worries accepting this change.
Conclusion
We hope that with this post we have been able to give you some additional
insights into our daily review work for openSUSE and SUSE products. Feel free
to reach out to us if you have any questions about the content discussed in
this article. We expect the winter issue of the spotlight series to be
available in about three months from now.
Tras un parón debido al salto de Qt5/KF5 a Qt6/KF6 que realizó la Comunidad KDE hace ya más de seis meses decidí retomar esta sección aunque renombrándola ya que en ella solo hablaré de Plasmoides para Plasma 6. Así que, visualiza la Luna en tu escritorio gracias a Luna 3, un widget que muestra las fases de nuestra hermana de viaje alrededor del Sol.
Visualiza la Luna en tu escritorio, Luna 3 – Plasmoides para Plasma 6 (12)
Como he comentado en otras ocasiones, de plasmoides tenemos de todo tipo funcionales, de configuración, de comportamiento, de decoración o, como no podía ser de otra forma, de información sobre nuestro sistema como puede ser el uso de disco duro, o de memoria RAM, la temperatura o la carga de uso de nuestras CPUs.
Así que espero que le deis la bienvenida a un plasmoide llamado Luna 3, una creación de Samuel Jimenez que nos ofrece la visión de la Luna en nuestro fondo de escritorio, pudiendo configurar la imagen que queremos mostrar, desde una simple luna amarilla hasta una que muestra sus mares, o el tipo de sombra generada por nuestro planeta.
Y como siempre digo, si os gusta el plasmoide podéis «pagarlo» de muchas formas en la página de KDE Store, que estoy seguro que el desarrollador lo agradecerá: puntúale positivamente, hazle un comentario en la página o realiza una donación. Ayudar al desarrollo del Software Libre también se hace simplemente dando las gracias, ayuda mucho más de lo que os podéis imaginar, recordad la campaña I love Free Software Day de la Free Software Foundation donde se nos recordaba esta forma tan sencilla de colaborar con el gran proyecto del Software Libre y que en el blog dedicamos un artículo.
Para los no iniciados en el blog, quizás la palabra plasmoide le suene un poco rara pero no es mas que el nombre que reciben los widgets para el escritorio Plasma de KDE.
En otras palabras, los plasmoides no son más que pequeñas aplicaciones que puestas sobre el escritorio o sobre una de las barras de tareas del mismo aumentan las funcionalidades del mismo o simplemente lo decoran.
El 7 de diciembre de 2004 se publicaba la versión 1.0 del cliente de correo thunderbird
Thunderbird cumple hoy 20. Un hito tan grande invita a la reflexión sobre el pasado y la emoción para el futuro. Durante dos décadas, Thunderbird ha sido más que una aplicación de correo electrónico: ha sido un compañero firme para millones de usuarios, ofreciendo comunicación, productividad y privacidad.
Esta es una traducción/adaptación del artículo original escrito en inglés en su web que puedes encontrar en este enlace:
El viaje de Thunderbird comenzó en 2003, pero la versión 1.0 se lanzó oficialmente el 7 de diciembre de 2004. Comenzó como una rama del Proyecto Mozilla y fue desarrollado para desafiar el status quo, proporcionando una alternativa de código abierto, segura y personalizable a los clientes de correo electrónico privativos .
Lo que comenzó como un proyecto pequeño y humilde pronto se convirtió en la solución de correo electrónico para personas y organizaciones que valoraron el control sobre sus datos.
El camino no siempre ha sido fácil. A lo largo de los años, Thunderbird enfrentó su parte de los desafíos, desde las mareas cambiantes de la tecnología y los competidores de mil millones de dólares que vienen a la escena hasta problemas para financiar el proyecto.
En 2012, Mozilla anunció que el apoyo a Thunderbird terminaría, dejando el proyecto en gran medida para valerse por sí mismo. Increíblemente, un grupo apasionado de desarrolladores, usuarios y seguidores dio un paso al frente y se negó a dejar que se desvaneciera.
Veinte millones de personas continuaron dependiendo de Thunderbird, creyendo en su potencial, reuniéndose detrás de él y transformándolo en un proyecto alimentado por sus usuarios, para sus usuarios.
En 2017, la Fundación Mozilla, que supervisó a Thunderbird junto con un grupo de voluntarios en el Consejo Thunderbird, una vez más contrató a un pequeño equipo de 3 personas para trabajar en el proyecto, respaldando nueva vida en su desarrollo.
Este equipo decidió tomar el asunto en sus propias manos y hacerle saber a los usuarios a través de apelaciones de donaciones que Thunderbird necesitaba su apoyo. El proyecto comenzó a recuperar fuerza e impulso y Thunderbird una vez más volvió a la vida. (Más sobre esta historia se puede encontrar en «La historia del Thunderbird«.
Los últimos años, en particular, han sido fundamentales. La interfaz de usuario de Thunderbird obtuvo un nueva renovación estética con el lanzamiento de Supernova 115 en 2023.
El lanzamiento de Nebula de 2024 fijó gran parte del código de back-end y la deuda técnica que afectaba a la innovación y el desarrollo más rápidos.
La primera aplicación de Android se lanzó, extendiendo Thunderbird a usuarios móviles y abriendo un nuevo capítulo en su historia. La introducción de Thunderbird Pro Services, incluidas herramientas como el intercambio de archivos y la reserva de citas, señala cómo se está expandiendo el proyecto para convertirse en una suite de productividad integral.
Y con eso, Thunderbird se está preparando para la próxima era de crecimiento y relevancia.
En aquellos primeros días, antes de que se llamara Thunderbird, el proyecto se denominó brevemente «Minotauro». Sin embargo, ese nombre no cuajó, y el equipo optó por algo más dinámico y apropiado para su visión.
¡Thunderbird está disponible en más de 50 idiomas!
Fue publicado el mismo año que Gmail. Thunderbird y Gmail se lanzaron en 2004. Mientras Gmail revolucionó el correo electrónico basado en la web, Thunderbird estaba capacitando a los usuarios para administrar su correo electrónico de manera local con control y personalización total y utilizando software libre.
Thunderbird se basa completamente en donaciones de usuarios para financiar su desarrollo. Sorprendentemente, menos del 3% de los usuarios donan, pero su generosidad es lo que mantiene el proyecto vivo e independiente para los otros 97% de los usuarios.
El recientemente lanzado Thunderbird para Android es en realidad la evolución del proyecto de correo K-9, que fue adquirido por Thunderbird en 2022.
Fue más inteligente trabajar con un cliente existente que compartía los mismos valores de código abierto, respetando al usuario y ofreciendo personalización y opciones de funciones enriquecidas.
Navegando por la red siempre se encuentran cosas interesantes, como es el caso de las noticias del Canal de Reca Linux. ¿Qué no sabéis lo que es? Pues yo tampoco hasta hoy, así que como es habitual, me dispongo a compartirlo con todos vosotros.
Noticias del Canal de Reca Linux
Hay muchos canales que se dedican a hablar de Linux en Youtube, aunque siempre serán menos que los que se dedican a hablar de otros sistemas operativos, aunque sea solo porque el público objetivo es mayor aunque en realidad tengan muchas menos cosas que contar.
Así que es bueno hacer un poco de promoción de los canales que hablan de «nuestras cosas» como es el caso de Reca Linux, una ¿empresa? ¿iniciativa? ¿serie de canales en diversas redes sociales? (lo tengo que averiguar) que según la descripción de su canal de Youtube:
Reca Linux ayuda a empresas y profesionales a incorporar Linux en sus sistemas, procesos y soluciones.
Desde hace más de 30 años, Linux demuestra una y otra vez su gran versatilidad, seguridad y estabilidad, logrando ser el corazón de los mayores avances de los últimos años: desde internet y almacenamiento en la nube, hasta Inteligencia Artificial.
Aun así, todavía quedan preguntas: ¿Cómo puedo utilizar Linux en mi empresa? ¿Linux sólo en el servidor o también en el escritorio? ¿Si envio un archivo a otra persona, lo podrá abrir? ¿Linux es difícil?
Reca Linux te brinda información de muy alta calidad para resolver ésta y otras dudas que te permitan aumentar tu productividad y sacar el máximo provecho de Linux y su ecosistema de aplicaciones y soluciones.
Recuerda suscribirte para conocer las últimas novedades.
Mientras investigo os dejo uno de sus últimos vídeos donde nos presentan novedades de Elementary OS 8, Warehouse , Warp, LEGO Horizon Adventures , Snap, Firefox 133, KDE Plasma 6.2.4 y The Wind’s Path
Inacreditável, o novo modeloLlama 3.3de 70B da Meta, que oferece desempenho semelhante ao modelo Llama 3.1 de 405B! Modelos já disponível naMultiCortex!
O Meta Llama 3.3 é um modelo de linguagem grande multilíngue (LLM) pré-treinado e ajustado para instruções, com capacidade de 70B (texto para texto). O modelo Llama 3.3, ajustado apenas para texto e instruções, é otimizado para casos de uso de diálogo multilíngue e supera muitos dos modelos de chat abertos e fechados disponíveis nos benchmarks comuns da indústria.
Benchmark do Llama 3.3
Idiomas suportados: inglês, alemão, francês, italiano, português, hindi, espanhol e tailandês. Novas capacidades
Esta versão introduz novas capacidades, incluindo uma janela de contexto mais longa, entradas e saídas multilíngues e possíveis integrações por desenvolvedores com ferramentas de terceiros. Construir com essas novas capacidades requer considerações específicas, além das melhores práticas que geralmente se aplicam a todos os casos de uso de IA Gerativa.
Uso de ferramentas: Assim como no desenvolvimento de software padrão, os desenvolvedores são responsáveis pela integração do LLM com as ferramentas e serviços de sua escolha. Eles devem definir uma política clara para seu caso de uso e avaliar a integridade dos serviços de terceiros utilizados para estar cientes das limitações de segurança e proteção ao usar esta capacidade. Consulte o Guia de Uso Responsável para melhores práticas sobre a implantação segura das salvaguardas de terceiros.
Multilinguismo: Llama 3.3 suporta 7 idiomas além do inglês: francês, alemão, hindi, italiano, português, espanhol e tailandês. O Llama pode ser capaz de produzir texto em outros idiomas que não aqueles que atendem aos limiares de desempenho para segurança e utilidade. Desencorajamos fortemente os desenvolvedores a usar este modelo para conversar em idiomas não suportados sem implementar o ajuste fino e controles de sistema alinhados com suas políticas e as melhores práticas compartilhadas no Guia de Uso Responsável.
Esta semana 4 nuevas snapshots publicadas 1129, 1202, 1203, y 1204
Las actualizaciones más destacadas de esta semana:
Mozilla Firefox 133.0
LibreOffice 24.8.3.2
SQLite 3.47.1
elfutils 0.192
mozjs 128.5.1 (motor de JS utilizado por GNOME-Shell)
systemd 256.9
libcap 2.73
Python setuptools 75.6.0
Pero hay mucho más que se está preparando
Linux kernel 6.12.3
Systemd 257.x
Rust 1.83
Python 3.11.11, 3.12.8
Si quieres estar a la última con software actualizado y probado utiliza openSUSE Tumbleweed la opción rolling release de la distribución de GNU/Linux openSUSE.
Mantente actualizado y ya sabes: Have a lot of fun!!
Member
Victorhck
