Well the way I read that is there is a lack of useful information. At the very least we need to know if the software installed is identical in both OSs. For that matter the OSs versions involved. The method of determining this "slowness" that you are using. Without those and many more details no one will be able to help you.

Two points firstly you are lucky it is so close to the last Debian  release of Trixie as the unstable files as very similar to it still. So close that it will not cause much trouble skipping a full release and going to two versions ahead which is totally unsupported. Your path to upgrade in normal circumstances should have been the one single release the excalibur the equivalent of Trixie right now then another upgrade to ceres the unstable Debian version now used. The recommended commands to do this type of upgrading has changed Debian now says use apt instead of apt-get . So to do it first apt update then apt upgrade to ensure you are fully up to date with the version currently running after changing to the next one level higher operating system in the sources file you do apt update once more then  apt full-upgrade which now replaces the apt-get dist-upgrade. Of course it is your install you can do it using the old no longer recommended methods if you wish.

It is possible you need to change it manually I did nothing and got it correctly done. The base-files package is responsible for that setting.

zeus@lenovo:~/Downloads$ apt policy base-files
base-files:
  Installed: 13.8+deb13u1devuan1
  Candidate: 13.8+deb13u1devuan1
  Version table:
 *** 13.8+deb13u1devuan1 500
        500 http://de.deb.devuan.org/merged excalibur-proposed-updates/main amd64 Packages
        100 /var/lib/dpkg/status
     13.8devuan1 500
        500 http://de.deb.devuan.org/merged excalibur/main amd64 Packages

zeus@lenovo:~/Downloads$ apt-file list base-files
base-files: /bin                          
base-files: /etc/debian_version
base-files: /etc/dpkg/origins/debian
base-files: /etc/host.conf
base-files: /etc/issue
base-files: /etc/issue.net
base-files: /etc/os-release
base-files: /etc/update-motd.d/10-uname
snip....

root@lenovo:~# cat /etc/devuan_version
excalibur

root@lenovo:~# cat /etc/debian_version
13.1
root@lenovo:~# cat /etc/os-release
PRETTY_NAME="Devuan GNU/Linux 6 (excalibur)"
NAME="Devuan GNU/Linux"
VERSION_ID="6"
VERSION="6 (excalibur)"
VERSION_CODENAME="excalibur"
ID=devuan
ID_LIKE=debian
HOME_URL="https://www.devuan.org/"
SUPPORT_URL="https://devuan.org/os/community"
BUG_REPORT_URL="https://bugs.devuan.org/"

My sources file.

root@lenovo:~# cat /etc/apt/sources.list.d/devuan.sources 
# Devuan 6 excalibur
## The new style method of using repositories to install software.
## This /etc/apt/sources.list.d/devuan.sources is new style and location file
## The /etc/apt/old.style.sources.list contains the same as this.
## https://linuxconfig.org/ubuntus-repository-configuration-ubuntu-sources-have-moved-to-etc-apt-sources-list-d-ubuntu-sources

## Normal excalibur sources
Types: deb
#URIs: http://ca.deb.devuan.org/merged
URIs: http://de.deb.devuan.org/merged
Suites: excalibur excalibur-backports excalibur-proposed-updates  excalibur-updates
Components: main non-free contrib non-free-firmware
Enabled: yes
Signed-By: /usr/share/keyrings/devuan-archive-keyring.gpg
Architectures: amd64

## excalibur security sources
Types: deb
#URIs: http://ca.deb.devuan.org/merged
URIs: http://deb.devuan.org/merged
Suites: excalibur-security
Components: main non-free contrib non-free-firmware
Enabled: yes
Signed-By: /usr/share/keyrings/devuan-archive-keyring.gpg
Architectures: amd64

And the solution was?

Simply create file in the /etc/modprobe.d/ with the module to be blacklisted and now I see/think about it, should the politically correct police have had that term changed to not be offensive in their minds....

An example of the system doing it.

root@9600k:~# cat /etc/modprobe.d/intel-microcode-blacklist.conf 
# The microcode module attempts to apply a microcode update when
# it autoloads.  This is not always safe, so we block it by default.
blacklist microcode

No clue I just adapted what was in the .xsessionrc file to a script for bash. It works and I was not interested trying any other way, I rather like sound it is the reason I switched to Linux when windows messed up my sound card well over twenty-six years ago now.

This posting seems to suggest you can do it on Trixie, so try and see.

https://www.reddit.com/r/linux_gaming/c … ently_got/

One would be to use the system as intended, bookworm sources are for a bookworm based install. There you will find the proper dependencies need for that software to install. Instead you try to use them on an install that is now four generations further along than bookworm. Which is now old stable with Trixie based system the stable, the Forky being the new testing and the Ceres being the unstable. That is just not going to work if you search the packages you will find the winehq-devel does not exist as that is not a Debian package name that would be winehq-dev if it existed as that is how Debian systems name the development packages. In short you try to do something which is impossible to do, install a bookworm based system if you want to have any hope in hell of it working. Or you could try using the modern versions of the packages and see if those will do what you need, see what it tells you is available for your install.

root@9600k:~# apt-cache search wine
dxvk - Vulkan-based translation layer for Direct3D 8/9/10/11
dxvk-wine64 - Vulkan-based translation layer for Direct3D 8/9/10/11 - wine64 build
dxvk-wine64-development - transitional package
fonts-wine - Windows API implementation - fonts
gnome-colors - set of GNOME icon themes
gnome-wine-icon-theme - red variation of the GNOME-Colors icon theme
innoextract - Tool for extracting data from an Inno Setup installer
libd3dadapter9-mesa - state-tracker for Direct3D9
libd3dadapter9-mesa-dev - state-tracker for Direct3D9 -- development files
librust-winapi-dev - Raw FFI bindings for all of Windows API - Rust source code
libwine - Windows API implementation - library
libwine-dev - Windows API implementation - development files
libwinpr3-dev - Windows Portable Runtime library (development files)
mingw-w64-i686-dev - Development files for MinGW-w64 targeting Win32
mingw-w64-ucrt64-dev - Development files for MinGW-w64 targeting Win64/UCRT
mingw-w64-x86-64-dev - Development files for MinGW-w64 targeting Win64
python3-neo - Python IO library for electrophysiological data formats
q4wine - Qt GUI for WINE
samba-common-bin - Samba common files used by both the server and the client
shiki-colors - set of Metacity/GTK-2+ themes
shiki-wine-theme - red variation of the Shiki-Colors theme
tellico - Collection manager for books, videos, music, etc
tellico-data - Collection manager for books, videos, music, etc [data]
tellico-doc - Collection manager for books, videos, music, etc [doc]
tellico-scripts - transitional package for tellico-data
twine - utility for interacting with PyPI
unmass - Extract game archive files
wine - Windows API implementation - standard suite
wine-binfmt - Register Wine as the interpreter for Windows executables
wine64 - Windows API implementation - 64-bit binary loader
wine64-preloader - Windows API implementation - prelinked 64-bit binary loader
wine64-tools - Windows API implementation - 64-bit developer tools
winpr3-utils - Windows Portable Runtime library command line utilities
nvda2speechd - Bridge between Windows applications and Speech dispatcher
nvdacontrollerclient - Bridge between Windows applications and Speech dispatcher
gemrb - Open-source engine to run Baldur's Gate, Icewind Dale and Planescape: Torment
playonlinux - front-end for Wine
proton-caller - Run any Windows program through Valve's Proton
winetricks - simple tool to work around common problems in Wine
libwinpr3-3 - Windows Portable Runtime library

I tried it once and you had better be prepared to be doing a lot of searching on the way to do a lot of things Debian does for you by default. Starting with booting it on another machine if cloning as their broken EFI implementation uses a direct entry to the firmware and does not setup the normal /EFI/BOOT/BOOTX64.efi that allows you to use the boot menu to choose another install. To be fair the Arch people do the same. So you need to set that up yourself then if logging in via ssh good luck on knowing what machine you log into as it does no tell you with either the MOTD when logging in or give a clue in the Terminal title you are using if graphical. Then numerous other things I had to go and copy the sensible Debian default configs to it I forget now but are still laying around in that install notes files. Oh and now I think the total deal breaker for me was in KDE it would show existing bookmarks in Dolphin with absolutely no way to add, modify or delete them without going to the config file and doing it manually. Additional deal breaker totally non intuitive naming of the packages if you need to install and you will because the dependency resolution is trash, if use to the sensible Debian naming scheme. That all from the memory of that experience doing it that comes to mind quickly.

Doubt you would want to the recommended command is now apt full-upgrade after using the normal  apt update then apt upgrade to ensure you are using the latest software before the move to the new OS. For the supposed mess upon upgrading. I did a Excalibur upgrade on one of my servers on cloned drive to test it out couple of days ago. It went perfectly fine so I cloned back the drive to it and two other server machines that were running the Daedalus. I have never really had problems with the old dist-upgrade or the new full-upgrade in twenty years of using a Debian based system. Whenever Woody came out is when I started so the next Debian 4 would have been my first experience doing it. They usually just work for me and the vast majority of people out there. Some have problems but that is to be expected as some have made so many changes to the defaults there are bound to be conflicts.

Since you are using a package that is one generation release on from the default you are using, I would check to make sure you have the iwlwifi packages from the same source as it installed too. The daedalus-backports should have the firmware-iwlwifi need to match that kernel looking at the Debian packages that should be there in it.

https://packages.debian.org/search?keyw … ection=all

At least that is what it would give me if needed running the same kernel on excalibur.

zeus@9600k:~$ apt policy firmware-iwlwifi
firmware-iwlwifi:
  Installed: (none)
  Candidate: 20250410-2
  Version table:
     20250410-2 950
        950 http://de.deb.devuan.org/merged excalibur/non-free-firmware amd64 P>
zeus@9600k:~$ uname -r
6.12.38+deb13-amd64

Edit: and I would make certain you have backup network connection that works before installing the wifi package and risking having none if only method of connecting fails with that package too.

Yes if you enable english to chinese translation which not a lot of people are going to do. Even if they have it installed which checking here I do not. These click-bait fud spreaders are out in full force on this one, I have seen this posted everywhere by them. With the same zero useful information presented as is typical of those postings, as in this posting as well...