Trinity Desktop Environment R14.1.5 Released with Support for #Debian Trixie, #Ubuntu 25.10, and #openSUSE Leap 16 https://9to5linux.com/trinity-desktop-environment-r14-1-5-released-with-support-for-debian-trixie
alcinnz
boosted
alcinnz
boosted
Three years ago, I experimented with introducing automated build testing for RISC-V in Linux GPU drivers. Back then, it was a bit hacky due to the older Debian version used in CI [ https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19917 ]
Recently, Mesa3D CI was upgraded to Debian 13, which supports RISC-V out of the box — and we’ve already been testing basic RISC-V builds for the past two days!
https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/37445
Hopefully, Imagination will start testing on real hardware soon!
Three years ago, I experimented with introducing automated build testing for RISC-V in Linux GPU drivers. Back then, it was a bit hacky due to the older Debian version used in CI [ https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19917 ]
Recently, Mesa3D CI was upgraded to Debian 13, which supports RISC-V out of the box — and we’ve already been testing basic RISC-V builds for the past two days!
https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/37445
Hopefully, Imagination will start testing on real hardware soon!
Alex Akselrod
boosted
Debian to add hard Rust dependency to APT
It seems like a number of Debian ports are going to face difficult times over the coming months. Debian developer Julian Andres Klode has sent a message to the Debian mailing lists that APT will very soon start requiring Rust.
I plan to introduce hard Rust dependencies and Rust code into APT, no earlier than May 2026. This extends at first to the Rus
https://www.osnews.com/story/143696/debian-to-add-hard-rust-dependency-to-apt/
Debian to add hard Rust dependency to APT
It seems like a number of Debian ports are going to face difficult times over the coming months. Debian developer Julian Andres Klode has sent a message to the Debian mailing lists that APT will very soon start requiring Rust.
I plan to introduce hard Rust dependencies and Rust code into APT, no earlier than May 2026. This extends at first to the Rus
https://www.osnews.com/story/143696/debian-to-add-hard-rust-dependency-to-apt/
alcinnz
boosted
I didn't think a netbook with an Intel Atom and 2GB RAM would be a usable computer in the present day, but I wanted to know for sure! #retrocomputing #linux #debian
https://www.howtogeek.com/i-tried-a-netbook-in-2025-and-it-didnt-go-well/
How to switch your Windows 10 PC to Linux Mint - for free https://zdnet.com/article/how-to-switch-your-windows-10-pc-to-linux-mint-for-free/ by @sjvn
There’s still time to switch from #Windows10 to #Linux. Just saying!
Not just free, but ALL upgrades and security fixes are free too. Forever.
And it won't spy on you, or put handcuffs on your stuff or lie.
Friends made a gift for you, security experts tested it, and artistic folks added ease of use. And flair.
A bunch of folks used linux and free open Blender to make a movie, and got the OSCAR for Animated Film, and they added to Blender a little.
Hubert Chathi
boosted
ARM is great, ARM is terrible (and so is RISC-V)
I’ve long been interested in new and different platforms. I ran Debian on an Alpha back in the late 1990s and was part of the Alpha port team; then I helped bootstrap Debian on amd64. I’ve got somewhere around 8 Raspberry Pi devices in active use right now, and the free NNCPNET Internet email service I manage runs on an ARM instance at a cloud provider.
ARM-based devices are cheap in a lot of ways: they use little power and there are many single-board computers based on them that are inexpensive. My 8-year-old’s computer is a Raspberry Pi 400, in fact.
So I like ARM.
I’ve been looking for ARM devices that have accelerated AES (Raspberry Pi 4 doesn’t) so I can use full-disk encryption with them. There are a number of options, since ARM devices are starting to go more mid-range. Radxa’s ROCK 5 series of SBCs goes up to 32GB RAM. The Orange Pi 5 Max and Ultra have up to 16GB RAM, as does the Raspberry Pi 5. Pine64’s Quartz64 has up to 8GB of RAM. I believe all of these have the ARM cryptographic extensions. They’re all small and most are economical.
But I also dislike ARM. There is a terrible lack of standardization in the ARM community. They say their devices run Linux, but the default there is that every vendor has their own custom Debian fork, and quite likely kernel fork as well. Most don’t maintain them very well.
Imagine if you were buying x86 hardware. You might have to manage AcerOS, Dellbian, HPian, etc. Most of them have no security support (particularly for the kernel). Some are based on Debian 11 (released in 2021), some Debian 12 (released in 2023), and none on Debian 13 (released a month ago).
That is exactly the situation we have on ARM. While Raspberry Pi 4 and below can run Debian trixie directly, Raspberry Pi has not bothered to upstream support for the Pi 5 yet, and Raspberry Pi OS is only based on Debian bookworm (released in 2023) and very explicitly does not support a key Debian feature: you can’t upgrade from one Raspberry Pi OS release to the next, so it’s a complete reinstall every 2 years instead of just an upgrade. OrangePiOS only supports Debian bookworm — but notably, their kernel is mustly stuck at 5.10 for every image they have (bookworm shipped with 6.1 and bookworm-backports supports 6.12).
Radxa has a page on running Debian on one specific board, they seem to actually not support Debian directly, but rather their fork Radxa OS. There’s a different installer for every board; for instance, this one for the Rock 4D. Looking at it, I can see that it uses files from here and here, with custom kernel, gstreamer, u-boot, and they put zfs in main for some reason.
From Pine64, the Quartz64 seems to be based on an ancient 4.6 or 4.19 kernel. Perhaps, though, one might be able to use Debian’s Pine A64+ instructions on it. Trixie doesn’t have a u-boot image for the Quartz64 but it does have device tree files for it.
RISC-V seems to be even worse; not only do we have this same issue there, but support in trixie is more limited and so is performance among the supported boards.
The alternative is x86-based mini PCs. There are a bunch based on the N100, N150, or Celeron. Many of them support AES-NI and the prices are roughly in line with the higher-end ARM units. There are some interesting items out there; for instance, the Radxa X4 SBC features both an N100 and a RP2040. Fanless mini PCs are available from a number of vendors. Companies like ZimaBoard have interesting options like the ZimaBlade also.
The difference in power is becoming less significant; it seems the newer ARM boards need 20W or 30W power supplies, and that may put them in the range of the mini PCs. As for cost, the newer ARM boards need a heat sink and fan, so by the time you add SBC, fan, storage, etc. you’re starting to get into the price range of the mini PCs.
It is great to see all the options of small SBCs with ARM and RISC-V processors, but at some point you’ve got to throw up your hands and go “this ecosystem has a lot of problems” and consider just going back to x86. I’m not sure if I’m quite there yet, but I’m getting close.
ARM is great, ARM is terrible (and so is RISC-V)
I’ve long been interested in new and different platforms. I ran Debian on an Alpha back in the late 1990s and was part of the Alpha port team; then I helped bootstrap Debian on amd64. I’ve got somewhere around 8 Raspberry Pi devices in active use right now, and the free NNCPNET Internet email service I manage runs on an ARM instance at a cloud provider.
ARM-based devices are cheap in a lot of ways: they use little power and there are many single-board computers based on them that are inexpensive. My 8-year-old’s computer is a Raspberry Pi 400, in fact.
So I like ARM.
I’ve been looking for ARM devices that have accelerated AES (Raspberry Pi 4 doesn’t) so I can use full-disk encryption with them. There are a number of options, since ARM devices are starting to go more mid-range. Radxa’s ROCK 5 series of SBCs goes up to 32GB RAM. The Orange Pi 5 Max and Ultra have up to 16GB RAM, as does the Raspberry Pi 5. Pine64’s Quartz64 has up to 8GB of RAM. I believe all of these have the ARM cryptographic extensions. They’re all small and most are economical.
But I also dislike ARM. There is a terrible lack of standardization in the ARM community. They say their devices run Linux, but the default there is that every vendor has their own custom Debian fork, and quite likely kernel fork as well. Most don’t maintain them very well.
Imagine if you were buying x86 hardware. You might have to manage AcerOS, Dellbian, HPian, etc. Most of them have no security support (particularly for the kernel). Some are based on Debian 11 (released in 2021), some Debian 12 (released in 2023), and none on Debian 13 (released a month ago).
That is exactly the situation we have on ARM. While Raspberry Pi 4 and below can run Debian trixie directly, Raspberry Pi has not bothered to upstream support for the Pi 5 yet, and Raspberry Pi OS is only based on Debian bookworm (released in 2023) and very explicitly does not support a key Debian feature: you can’t upgrade from one Raspberry Pi OS release to the next, so it’s a complete reinstall every 2 years instead of just an upgrade. OrangePiOS only supports Debian bookworm — but notably, their kernel is mustly stuck at 5.10 for every image they have (bookworm shipped with 6.1 and bookworm-backports supports 6.12).
Radxa has a page on running Debian on one specific board, they seem to actually not support Debian directly, but rather their fork Radxa OS. There’s a different installer for every board; for instance, this one for the Rock 4D. Looking at it, I can see that it uses files from here and here, with custom kernel, gstreamer, u-boot, and they put zfs in main for some reason.
From Pine64, the Quartz64 seems to be based on an ancient 4.6 or 4.19 kernel. Perhaps, though, one might be able to use Debian’s Pine A64+ instructions on it. Trixie doesn’t have a u-boot image for the Quartz64 but it does have device tree files for it.
RISC-V seems to be even worse; not only do we have this same issue there, but support in trixie is more limited and so is performance among the supported boards.
The alternative is x86-based mini PCs. There are a bunch based on the N100, N150, or Celeron. Many of them support AES-NI and the prices are roughly in line with the higher-end ARM units. There are some interesting items out there; for instance, the Radxa X4 SBC features both an N100 and a RP2040. Fanless mini PCs are available from a number of vendors. Companies like ZimaBoard have interesting options like the ZimaBlade also.
The difference in power is becoming less significant; it seems the newer ARM boards need 20W or 30W power supplies, and that may put them in the range of the mini PCs. As for cost, the newer ARM boards need a heat sink and fan, so by the time you add SBC, fan, storage, etc. you’re starting to get into the price range of the mini PCs.
It is great to see all the options of small SBCs with ARM and RISC-V processors, but at some point you’ve got to throw up your hands and go “this ecosystem has a lot of problems” and consider just going back to x86. I’m not sure if I’m quite there yet, but I’m getting close.
This week in #FDroid (TWIF) is happening:
* Hardware upgrades can't come quicker
* #Syncthing Lite is back
* #Taler hits one point zero
* #ShatteredPixel needs Android 5
* #WebLibreBrowser wraps #Gecko in #Flutter
* More stats panels
* #Debian Trixie is here!
* #Wikipedia fights #OnlineSafetyAct
* #Rethink hits some bugs
+ 12 new apps
& 160 more updates
- 8 apps archived
#ItsFriday Friday Friday: https://f-droid.org/2025/08/14/twif.html
¡Abbie!
boosted
Debian GNU/Hurd 2025 released with Rust, 64bit support, and more
We removed ads from OSNews. Donate to our fundraiser to ensure our future!
The Hurd, the collection of services that run atop the GNU Mach microkernel, has been in development for a very, very long time. The Hurd is intended to serve as the kernel for the GNU Project, but with the advent of Linux and its rap
https://www.osnews.com/story/143060/debian-gnu-hurd-2025-released-with-rust-64bit-support-and-more/
Debian GNU/Hurd 2025 released with Rust, 64bit support, and more
We removed ads from OSNews. Donate to our fundraiser to ensure our future!
The Hurd, the collection of services that run atop the GNU Mach microkernel, has been in development for a very, very long time. The Hurd is intended to serve as the kernel for the GNU Project, but with the advent of Linux and its rap
https://www.osnews.com/story/143060/debian-gnu-hurd-2025-released-with-rust-64bit-support-and-more/
Luc, framage
boosted
Précaution à prendre pour la mise à jour vers Debian Trixie d’un cluster Ganeti
TL; DR: installez Ganeti 3.1 depuis les backports Bookworm, faites la mise à jour du cluster Ganeti et ensuite seulement faites vos mises à jour vers Debian Trixie.
Ce billet fait écho à celui-ci.
Lors du passage de Debian Buster à Bullseye, il y avait eu un problème empêchant la mise à jour du cluster : la version 2.16 de Ganeti était supprimée lors de la mise à jour du système et on en avait besoin pour mettre à jour le cluster.
Lors du passage à Bookworm : pas de mise à jour du cluster à faire car la version de Ganeti était la même qu’en Bullseye (la 3.0).
Un problème similaire arrive par contre lors du passage à Trixie : la version de Ganeti de Trixie est la 3.1, il faut donc mettre à jour le cluster.
Mais Ganeti 3.0 ne fonctionne pas sous Trixie, empêchant le dæmon ganeti de démarrer après la mise à jour de Debian.
On peut passer manuellement à la nouvelle version, ce que j’ai fait, mais mes machines virtuelles KVM n’ont pas aimé (mauvaises options de démarrage).
Il manquait la mise à jour du cluster Ganeti : après un coup de gnt-cluster upgrade --to 3.1, tout refonctionne à nouveau.
Sur mon serveur personnel, je n’ai que deux machines virtuelles, majoritairement dédiées à mes besoins, donc si j’ai un problème comme celui-ci, ce n’est pas le truc le plus gênant du monde.
Par contre, pour mon boulot, les machines virtuelles se comptent par dizaines et j’ai 17 serveurs de virtualisation.
Comme il faut que tous les serveurs du cluster possèdent la nouvelle version de Ganeti avant de pouvoir lancer le gnt-cluster upgrade --to 3.1 et que je n’ai pas très envie d’avoir une coupure importante sur tous les serveurs de virtualisation et leurs machines virtuelles, il m’est nécessaire de faire la mise à jour du cluster avant la mise à jour de Debian.
Pour ceux dans le même cas que moi, la solution est simple : avant le passage à Trixie, installer les paquets de Ganeti depuis les backports de bookworm sur tous vos serveurs et faire la mise à jour du cluster Ganeti vers la 3.1 après cela (gnt-cluster upgrade --to=3.1 depuis le master).
apt install ganeti ganeti-3.1 ganeti-haskell-3.1 ganeti-htools-3.1 -t bookworm-backportsVous pourrez ensuite mettre à jour les machines vers Trixie en toute quiétude.
Précaution à prendre pour la mise à jour vers Debian Trixie d’un cluster Ganeti
TL; DR: installez Ganeti 3.1 depuis les backports Bookworm, faites la mise à jour du cluster Ganeti et ensuite seulement faites vos mises à jour vers Debian Trixie.
Ce billet fait écho à celui-ci.
Lors du passage de Debian Buster à Bullseye, il y avait eu un problème empêchant la mise à jour du cluster : la version 2.16 de Ganeti était supprimée lors de la mise à jour du système et on en avait besoin pour mettre à jour le cluster.
Lors du passage à Bookworm : pas de mise à jour du cluster à faire car la version de Ganeti était la même qu’en Bullseye (la 3.0).
Un problème similaire arrive par contre lors du passage à Trixie : la version de Ganeti de Trixie est la 3.1, il faut donc mettre à jour le cluster.
Mais Ganeti 3.0 ne fonctionne pas sous Trixie, empêchant le dæmon ganeti de démarrer après la mise à jour de Debian.
On peut passer manuellement à la nouvelle version, ce que j’ai fait, mais mes machines virtuelles KVM n’ont pas aimé (mauvaises options de démarrage).
Il manquait la mise à jour du cluster Ganeti : après un coup de gnt-cluster upgrade --to 3.1, tout refonctionne à nouveau.
Sur mon serveur personnel, je n’ai que deux machines virtuelles, majoritairement dédiées à mes besoins, donc si j’ai un problème comme celui-ci, ce n’est pas le truc le plus gênant du monde.
Par contre, pour mon boulot, les machines virtuelles se comptent par dizaines et j’ai 17 serveurs de virtualisation.
Comme il faut que tous les serveurs du cluster possèdent la nouvelle version de Ganeti avant de pouvoir lancer le gnt-cluster upgrade --to 3.1 et que je n’ai pas très envie d’avoir une coupure importante sur tous les serveurs de virtualisation et leurs machines virtuelles, il m’est nécessaire de faire la mise à jour du cluster avant la mise à jour de Debian.
Pour ceux dans le même cas que moi, la solution est simple : avant le passage à Trixie, installer les paquets de Ganeti depuis les backports de bookworm sur tous vos serveurs et faire la mise à jour du cluster Ganeti vers la 3.1 après cela (gnt-cluster upgrade --to=3.1 depuis le master).
apt install ganeti ganeti-3.1 ganeti-haskell-3.1 ganeti-htools-3.1 -t bookworm-backportsVous pourrez ensuite mettre à jour les machines vers Trixie en toute quiétude.
Alex Akselrod
boosted
It's here — Debian 13 "Trixie" released with RISC-V support, Linux 6.12 LTS, APT 3.0 and a bunch of other improvements.
https://www.omgubuntu.co.uk/2025/08/debian-13-trixie-released-with-2-years-worth-of-improvements