You are not logged in.
Hello:
Ever since I put my system on a 2.5" 120Gb SSD, I set up fstrim as per the instructions I found on-line:
$ ls -1 /etc/cron.weekly
--- snip ---
dev-fstrim
--- snip ---
$ $ cat /etc/cron.weekly/dev-fstrim
#!/bin/sh
# trim all mounted file systems which support it
# added 20200315
#
# PATH=/bin:/sbin:/usr/bin:/usr/sbin:/usr/local/bin:/usr/local/sbin
LOG=/var/log/trim.log
echo "On $(date -R):" >> $LOG
/sbin/fstrim -a -v >> "$LOG" 2>&1
$ I then took to checking /var/log/trim.log every so often to check that it was working and eventually stopped doing it.
fstrim was doing it's thing and doing it well.
If anything went south, my MTA (not Exim4, DMA*) would let me know.
Today I was looking through the logs and on opening /var/log/trim.log I see that it is also working (?) on a 2.5" 1Tb HDD that I set up inside my box to serve as the first repository of my weekly Clonezilla and daily Timeshift backups.
$ cat /var/log/trim.log
--- snip ---
On Thu, 20 Nov 2025 02:11:33 -0300:
/media/1TB/IMG: 109.2 GiB (117271797760 bytes) trimmed on /dev/sda1
/media/1TB/TS: 159.1 GiB (170784149504 bytes) trimmed on /dev/sda2
/home: 27.2 GiB (29253963776 bytes) trimmed on /dev/sdb6
/var/log: 669.7 MiB (702242816 bytes) trimmed on /dev/sdb5
/: 27.4 GiB (29410951168 bytes) trimmed on /dev/sdb1
$This was something I was not expecting.
And I understand that fstrim is not for use with HDDs, only for SDDs.
I recall adding the comments to the /etc/cron.weekly/dev-fstrim so I would remember what it was doing and the bit "# trim all mounted file systems which support it" stuck with me and I (incorrectly) assumed that support it meant that fstrim would act only on SSDs.
Unfortunately I neglected to add the link to the source of the data.
Q:
Should I leave things as they are or not?
If not, what to do?
Best,
A.
*Dragonfly Mail Agent <-- useful reading
Hello:
... picture is worth a thousand words.
Yes.
But only one word was needed: ineptitude.
Cloudfare is arguably an essential part of the web these days.
And those behind it (should) know it. Recent events make me wonder.
Whether that is the proper way to do things or not is for another discussion altogether.
But, like it or not, it is a fact: Cloudfare is a weak link without the needed redundancy.
Redundancy that the WWW was supposed to have, by design.
So it boils down to basic common sense: you do not fuck around with an essential part of the web.
Which is exactly what these DHs did.
A.
Hello:
Thanks ...
You're welcome.
... problems are with version 6, "Excalibur."
Yes, I saw that.
The idea was to shed some light on the comment made by [stultumanto]:
... libc6-dev might be important.
ie: dependencies, etc.
Best,
A.
Hello:
I run on Devuan Daedalus and thought I had safely purged all traces of pulseaudio.
$ apt list | grep installed | grep pulse*
--- snip ...
libpulse0/oldstable,now 16.1+dfsg1-2+b1 amd64 [installed,automatic]
libpulse0/oldstable,now 16.1+dfsg1-2+b1 i386 [installed,automatic]
$
$ apt list | grep installed | grep *audio
$ But it maybe that is not an accurate description (?) of my system's present situation.
libpulse0 is required by the conky-all package:
$ aptitude why libpulse0
i conky-all Depends libpulse0 (>= 0.99.1)
$ I still have a ~/.config/pulse directory with a dangling* symlink:
$ ls ~/.config/pulse
86091d88be5305f82484a8e9692432e0-runtime
$ $ readlink ~/.config/pulse/86091d88be5305f82484a8e9692432e0-runtime
/tmp/pulse-aHntD7qg1y0a
$ * terminal shows it in red and mc shows it both in red and with an exclamation mark
ie: !86091d88be5305f82484a8e9692432e0-runtime
But I cannot see it if I look for it in /tmp:
$ ls /tmp
Temp-a369b4bc-a28a-43a1-8f07-5cd9fe1dc0d8
dbus-AL25kJh8OL
dbus-zhBDcWiF0J
mc-groucho
ssh-KCuRXh08Mpzn
$Is something pulseaudio related generating that symlink?
If so, any idea what it may be?
Synaptic does not show any residual configuration files.
Best,
A.
Hello:
libc6-dev might be important.
For my Daedalus installation aptitude says this:
$ aptitude why libc6-dev
i build-essential Depends g++ (>= 4:10.2)
i A g++ Depends g++-12 (>= 12.2.0-1~)
i A g++-12 Depends libstdc++-12-dev (= 12.2.0-14+deb12u1)
i A libstdc++-12-dev Depends libc6-dev (>= 2.23-1~)
$But then I also see this:
$ aptitude why build-essential
i udiskie Recommends gobject-introspection
i A gobject-introspection Depends build-essential
$And this:
$ aptitude why udiskie
Manually installed, current version 2.4.2-1, priority optional
No dependencies require to install udiskie
$From what I have read (just now) udiskie is a daemon for automounting USB drives, CD-Rs and such.
https://github.com/coldfix/udiskie?tab=readme-ov-file
udiskie gets started on login (?):
$ ps aux | grep udiskie
groucho 19075 0.0 0.0 3332 1568 pts/0 S+ 10:06 0:00 grep --color=always udiskie
$ No idea as to why I have it as manually installed.
If I understand all of the above correctly (?) ...
Installing udiskie dragged in gobject-introspection as a recommends.
As a result, gobject-introspection dragged in build-essential as a dependency.
And then build-essential dragged in all these as dependencies:
build-essential Depends g++ (>= 4:10.2)
g++ Depends g++-12 (>= 12.2.0-1~)
g++-12 Depends libstdc++-12-dev (= 12.2.0-14+deb12u1)
libstdc++-12-dev Depends libc6-dev (>= 2.23-1~)
TL;DR
It would seem that libc6-dev has been installed in my Daedalus system because whoever wrote udiskie thought that it was a good idea to put in gobject-introspection as a recommends.
Not too sure that I got it right so I'd appreciate some input on this.
Edit: maybe a good number of other packages depend on libc6-dev being installed.
Best,
A.
Hello:
... if usrmerge is uninstalled?
You may want to take a few moments to read de Debian advisory I previously linked to.
TL;DR:
If you want to avoid this usrmerge thing you will have to stay at Daedalus; the caveat being that it was not a fresh install.
... installed as buster or bullseye there will be no change, as the new filesystem layout was already the default in these releases.
... the older layout is no longer supported, and systems using it will be converted to the new layout when they are upgraded to bookworm.
buster = Beowulf
bullseye = Chimaera
bookworm = Daedalus
My Devuan box started off as Jesse and was dist-upgraded sequentially to ascii, Beowulf, etc. and then Daedalus, so it retained the now deprecated layout, but that ended with Excalibur.
To upgrade to Excalibur, I have to previously apply the usrmerge package from the Daedalus repository.
But ....
Should I want to go back to a system without usrmerge, I would have to use the last back-up image from my Clonezilla repository.
It would not be Devuan Excalibur.
Excalibur is a usrmerge'd installation, no way around that.
Best,
A.
Hello:
... points users to /etc/alsa/conf.d/, a directory that often doesn’t exist or isn’t used, while the real defaults live in /usr/share/alsa/.
In my Daedalus install (originally Jesse ca. 2017 and dist-upgraded) /etc/alsa/conf.d has 12 symlinks to the same number of [*.conf] files in /usr/share/alsa/alsa.conf.d plus a file not linked to any other: 99-pulseaudio-default.conf.example
$ ls -1 /usr/share/alsa/alsa.conf.d
10-rate-lav.conf
10-samplerate.conf
10-speexrate.conf
50-arcam-av-ctl.conf
50-jack.conf
50-oss.conf
50-pulseaudio.conf
60-a52-encoder.conf
60-speex.conf
60-upmix.conf
60-vdownmix.conf
98-usb-stream.conf
$ $ ls -1 /etc/alsa/conf.d
10-rate-lav.conf
10-samplerate.conf
10-speexrate.conf
50-arcam-av-ctl.conf
50-jack.conf
50-oss.conf
50-pulseaudio.conf
60-a52-encoder.conf
60-speex.conf
60-upmix.conf
60-vdownmix.conf
98-usb-stream.conf
99-pulseaudio-default.conf.example
$ $ cat /etc/alsa/conf.d/99-pulseaudio-default.conf.example
# Default to PulseAudio
pcm.!default {
type pulse
hint {
show on
description "Default ALSA Output (currently PulseAudio Sound Server)"
}
}
ctl.!default {
type pulse
}
$ Best,
A.
Hello:
... ALSA as a fallback — a bare-bones option for when PulseAudio isn’t available.
... overlooks that ALSA, with its default software mixing, is quite capable.
Very practical of them.
How else will they get people to use Poettering's PulseAudio complication?
... a full rewrite — replacing fiction with fact — is the only sensible path forward.
I wonder what the odds on that happening are?
Maybe I'll call my bookie and ask. 8^°
Best,
A.
Hello:
With this setup, Zoom Workplace delivers reliable audio performance on pure ALSA systems ...
I don't use zoom (no need for the time being) but in my PulseAudio-less Daedalus box your tests work as shown. 8^)
So thank you very much for taking the time to research and write up these very clear explanations / instructions.
Best,
A.
Hello:
... part of the linux kernel since version 5.4, making haveged largely obsolete.
Yes, I came across that after posting my question.
... few situations in which the haveged service may be useful ...
Yes, here the author makes a case of sorts:
... it's still useful. It can provide entropy early in the boot when /dev/random is not fully utilized.
On a fully booted system, it can be still used as an additional entropy source. It will insert entropy into the kernel every 60 seconds, thus diversifying your entropy sources.
The " ... diversifying your entropy sources." bit sounds good. Might as well keep it running.
... for real randomness security use a Pi, not your £2K workstation.
Indeed ... 8^D
I could have never paid £2K for a workstation but I am quite sure that you are right, a Pi would work great.
That said, I think that what I need (like most desktop users) is the best randomness available without much ado or expense.
Can't find the post now, but it seems that haveged is not at all expensive to run so my guess is that between the kernel and the haveged service running, I may be properly covered, at least randomness-wise.
Time will tell.
Thank you both for your input.
Much obliged.
Best,
A.
Hello:
Disclaimer:
Reason for asking = a good deal (if not all) of this is over my head.
Not being sure about what to do about Excalibur, I have been having a look at various things related to security.
Yesterday I remembered haveged, checked that it was running and, recalling that I had set it a few years ago, checked the available entropy.
Turns out that it returned a value of 256.
But I recalled having changed it to a higher value (1024?) as suggested in various web pages.
A look at /etc/default/haveged revealed the present setting:
$ cat /etc/default/haveged
# Configuration file for haveged
# Options to pass to haveged:
# DAEMON_ARGS=" "
$ I checked the haveged service was running and the available entropy setting and poolsize:
$ cat /proc/sys/kernel/random/entropy_avail
256
$$ cat /proc/sys/kernel/random/poolsize
256
$ But that was not what I recalled having set as per the recommendations at that time.
So I looked up web pages I had bookmarked and edited the file, uncommenting the setting and editing it to what I remembered (?).
$ cat /etc/default/haveged
# Configuration file for haveged
# Options to pass to haveged:
DAEMON_ARGS="-w 1024"
$ That would give me a value over 1000 which was the accepted minimum value at the time I set it up.
Then I stopped / restarted the service, checked that it was running and the available entropy setting and poolsize:
$ cat /proc/sys/kernel/random/entropy_avail
256
$$ cat /proc/sys/kernel/random/poolsize
256
$ What was going on?
TL;DR
I seems that as of kernel 5.10.119, the value of 256 bytes has been hardcoded.
See this link:
https://unix.stackexchange.com/questions/704737
TL;DR:
As long as your computer doesn't suffer from not enough entropy ever, you're generating secure numbers.
Even just 256 entropy once before starting to get random numbers, and then 0 for the rest of the lifetime of your system would be OK!
Having 256 at any time is way more than ever necessary.
Right ...
Like I said at the start of this post, all this is over my head, reason why I am asking about it.
I do know that entropy is important, more in servers that desktops, but still important.
The "As long as your computer doesn't ... " bit does not mean much to me, more so in the context of all that is going on with Linux these past few years.
And yes, the "... 256 at any time is way more than ever necessary." bit did bring a smile to my face.
That said, I'd appreciate the opinion of those members who actually understand / have a grip on this stuff.
Best,
A.
Hello:
Running up to date Devuan Daedalus:
$ uname -a
Linux devuan 6.1.0-41-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.158-1 (2025-11-09) x86_64 GNU/Linux
$ Default grub:
# grub-install --version
grub-install (GRUB) 2.06-13+deb12u1
# I have a setting for the fonts in /etc/default/grub which suits me:
$ cat /etc/default/grub
--- snip ---
GRUB_COLOR_NORMAL="white/red"
GRUB_COLOR_HIGHLIGHT="yellow/red"
--- snip ---The thing is that when editing the command line in the grub screen, those values do not hold.
The font is green and cannot be distiguished properly because of the background I use.
ie: confetti.png from MiyoLinux
Q: is there a way to get same font colours on the [edit] screen?
Best,
A.
Hello:
@igorzwx Thanks for showing that alsa is actually capable ...
+1
Best,
A.
Hello:
... half the complex software not backed by huge corpos ...
... have produced that same symbol lookup error so far.
And will keep doing it if you are on Excalibur and till all that complex software you need catches up with this last Debian craze.
### You may want to consider patiently waiting it out till that happens ###.
ie: get out the backup* you made before the dist-upgrade and roll back to your last working non [usr-merge] Daedalus.
You will then be able to use that software you need once again, just like before.
* you have one, right? 8^°
As for me, I will (most) probably freeze my box at Daedalus using backṕorts (both kernels and packages) till it achieves [oldoldstable] status.
That should be in (maybe) three or four years in the future.
Five if I strech it a bit more? 8^°
In the meanwhile, I will think about what is going / has gone on in that time span and attempt to elucidate how to proceed.
No idea where we will be at that point.
There may no longer be a Debian.
I may not even care.
Best,
A.
Hello:
... ever anything more than a control thing on their part.
I respectfully beg to differ.
As it has become quite evident, there has been, is and will be (for the long run) an astounding amount of moolah behind the systemd putsch into the Linux ecosystem, the main objective being to infiltrate it, absorb the distribution that is arguably the major player within it and slowly but steadily proceed to morph it into a totally different OS, not much different than any other MS OS till it no longer has any resemblance to Linux as we know it.
That being the case*, I find it very difficult to think of usrmerge as just a control thing: it is just another part of the process towards their main goal.
* as always, YMMV
With those players, nothing is just anything more.
ie: everything they do has a definite purpose and is linked to everything else that has been done up to now.
Best,
A.
Hello:
... everyone suddenly switching to usrmerge?
Easy: from Trixie / Excalibur onwards it is mandatory as per Debian design.
Have a read here:
https://www.debian.org/releases/bookwor … w-required
5.1.14. A “merged-/usr” is now required
Debian has adopted a filesystem layout, referred to as “merged-/usr”, which no longer includes the legacy directories /bin, /sbin, /lib, or optional variants such as /lib64. In the new layout, the legacy directories are replaced with symlinks to the corresponding locations /usr/bin, /usr/sbin, /usr/lib, and /usr/lib64. This means that, for example, both /bin/bash and /usr/bin/bash will launch bash.
For systems installed as buster or bullseye there will be no change, as the new filesystem layout was already the default in these releases. However, the older layout is no longer supported, and systems using it will be converted to the new layout when they are upgraded to bookworm.
The conversion to the new layout should have no impact on most users. All files are automatically moved to their new locations even if they were installed locally or come from packages not provided by Debian, and hardcoded paths such as /bin/sh continue to work. There are, however, some potential issues:
dpkg --search
will give wrong answers for files moved to the new locations:dpkg --search /usr/bin/bash
will not identify that bash came from a package. (Butdpkg --search /bin/bash
still works as expected.)Local software not provided by Debian may not support the new layout and may, for example, rely on /usr/bin/name and /bin/name being two different files. This is not supported on merged systems (including new installations since buster), so any such software must be fixed or removed before the upgrade.
Systems that rely on a “base layer” that is not directly writable (such as WSL1 images or container systems using multi-layer overlayfs filesystems) cannot be safely converted and should either be replaced (e.g., by installing a new WSL1 image from the store) or have each individual layer upgraded (e.g., by upgrading the base Debian layer of the overlayfs independently) rather than dist-upgraded.
For further information, see The Case for the /usr merge and the Debian Technical Committee resolution.
* underlining is mine
Right ...
Now you know why it is the default and the bandwagon is full. 8^°
Best,
A.
Hello:
Is it possible ...
I think not.
I run XFCE and if I do that I get this:
$ xfdesktop -Q
(xfdesktop:25174): dbind-WARNING **: 10:14:44.059: AT-SPI: Error retrieving accessibility bus address: org.freedesktop.DBus.Error.ServiceUnknown: The name org.a11y.Bus was not provided by any .service files
~$ As a result I lose my desktop.
ie: all icons and wallpaper dissapear and the background is just the usual base grey.
The warning is because the at-spi packages have been purged.
Only open windows, XFCE4 panels and conky remain.
Best,
A.
Hello:
Yes it could ...
Actually, it can and does.
The main reason being that Devuan is just Debian without systemd.
With all that it entails.
Devuan developers/maintainers and admins make a truly herculean effort to keep it running.
But they are severely overworked and understaffed.
There is only so much that can be done under such dire circumstances.
Best,
A.
Hello:
... won't let distro developers change it.
... supposed to fork xfce4-desktop if we want that.
Right ...
Cute little buggers, aren't they? 8^°
Yet one more reason to ditch XFCE as the Devuan default desktop and seriously consider an Openbox / #! type alternative.
Like #!++ or BunsenLabs but without the systemd ballast.
Just an idea.
Best,
A.
Hello:
... how to get rid of the cruft installed along with LXQt ...
You can start by first making a list to check if there is any.
eg:
$ apt list | grep installed | grep -i lxqtBest,
A.
Hello:
Welcome back ...
I was wondering what happened to your USB sticks. 8^°
... bios ...
... turned off usb charging.
Hmm ...
Could be, but then it would imply a severe hardware malfunction or BIOS problem.
USB ports have (should have) protection to avoid excess current draw and damage, particularly those that can be used for charging.
It is part of the design parameters of any on-board / external USB socket.
... (those I didn't plug yet) work perfectly.
I see.
For the sake of completion to this thread, I think that it would be of interest to the forum (and you) to know some details.
[please humour me]
Reason?
Although not by any means the same quality of the legendary IBM T43 Thinkpad, today's Lenovo Thinkpad T400 is not a toy laptop on which such a thing would just happen, so it would be good to check a couple of things which may be of interest.
What brand and model are the USB sticks you used before and use now?
What does the dmesg printout say after you plug in one of the non-functioning sticks?
Please post the output.
With that same stick plugged in, please bring up gparted.
Does the stick show up? ie: /dev/sdx
If so, can you format it to 'cleared' first and then to 'fat32'?
Let's see if we can get to the bottom of this within a reasonable time frame. 8^D!
Best,
A.
Hello:
I'll be staying on Daedalus.
So will I.
... even LXDE itself.
Don't get me started, I have XFCE ...
Some time ago I posted about the need(?) to upgrade from Daedalus to Excalibur.
A very relevant question if you run on ca. 2007 hardware.
Not a Mickey Mouse job, a high quality workstation* working as well as new.
Suits all my needs, no issues.
... significantly more bloated and resource-hungry ...
Indeed ...
In the 10+ years I have been running on Linux I have seen the size of each release grow and grow and cannot but wonder what more is in store.
eg:
Devuan Chimaera netinstall *.iso: 372.00 MB - UEFI installer: 0.754 MB
Devuan Daedalus netinstall *.iso: 477.80 MB - UEFI installer: 23.000 MB
30X more code was added to the UEFI partition on the road between Chimaera and Daedalus.Frankly, I do not think I can expect anything in the way of improvements for my hardware.
I have not seen a suitable explanation for the 30X additional code [ie: just WTF does it do?] but I strongly suspect that it holds something akin to a separate/independent OS.
The problem at hand is that there seems to be no alternative in sight.
Or any indication that there will, at some point, be one.
Maybe we have to carve ourselves a future in the [whatever]BSD arena? 8^/
Best,
A.
* Sun Microsystems U24 - Released by Sun 10/2007 - EOL'd by Oracle 10/2009.
Hello:
... advice on AMD or nvidia ...
- no one really needs bleeding edge, choose your hardware carefully
- new & shiny is always expensive and isn't necessarily the best choice *
- avoid any and all NVidia stuff like the plague.
- AMD video cards are excellent and have much better Linux support
* I run Devuan on a ca. 2007 Sun Microsystems U24 WS purchased used and upgraded 11/2015
Best,
A.
Hello:
Thx for responding
You're welcome.
Best,
A.