I really began to suspect something had changed when I saw this header in /usr/lib/udev/hwdb.d/60-keyboard.hwdb:

# Note: The format of the "evdev:" prefix match key is a contract between the
# rules file and the hardware data, it might change in later revisions to
# support more or better matches, it is not necessarily expected to be a stable
# ABI.

The sheer number of posts about udev & hwdb I found across the web suggests it's a huge source of frustration for Linux users. I remember it took me hours to figure out that my rules needed to be indented by exactly one space. I can't think of another parser that brittle. Even Python is more forgiving! Someone tried to open a bug report about it several years ago, but Pottering himself closed it. He said it sounded "like a support issue!"

Thanks for the suggestion, I hadn't thought about checking with strace. At least I know now that udevadm hwdb --update is successfully opening and reading my .hwdb file:

I checked the trace for the udevadm trigger as well, but it didn't contain anything useful. I checked again to make sure I was using the right name for my keyboard, and it still appeared to be correct:

# udevadm info -a /dev/input/by-path/platform-i8042-serio-0-event-kbd 
    ...
    ATTRS{name}=="AT Translated Set 2 keyboard"

I believe usrmerge was already applied in Trixie before I started the migration to Excalibur. I remember checking for the symlinks shortly after installing Debian.

No argument here; I was only testing the PulseAudio version to help troubleshoot my issues with apulse and OBS Studio. I appreciate the detailed instructions for recompiling Firefox; however, there doesn't appear to be an equivalent way to coerce OBS into support ALSA for output monitoring. It seems this feature is only available if one installs PulseAudio or PipeWire, which is strange, as OBS supports ALSA input sources without issue.

Thanks for sharing that data point. I just tried using apulse with Firefox ESR on a Debian installation. (The Firefox packaged with mainline Debian no longer supports ALSA directly.) I observed exactly what you describe. It seems apulse is the source of the high latency. What's odd is that, according to the documentation, apulse simply wraps the ALSA mixing tools dmix, dsnoop, and plug. Logically, then, it would seem these tools must be the source of the latency.

I actually did find some discussions by people who claimed to have latency issues with the ALSA userspace utilities. Perhaps there is a buffer setting in these tools I can adjust. If that doesn't work, though, I may just give in and install PipeWire, as it appears more and more applications are coming to rely on it.

The problem is that you didn't specify whether you were asking about the three primary additive colors (i.e., the colors of light) or the three primary subtractive colors (pigment, dye, etc.) If the former, the answer would be red, green, and blue. If the latter, the most correct answer would be magenta, cyan, and yellow, although artists may say, red, blue, and yellow, which can serve as reasonable approximations.

I remember when a memory leak was found in a Rust application a while back, some Rust devs (or at least, people claiming to be Rust devs ) were actually shocked. They genuinely did not believe such a thing was possible. I didn't look too deeply into who these people were, but I truly hope they weren't working on anything important, as this attitude reflects a profound lack of basic understanding. It's fundamentally impossible to completely prevent all memory leaks in any language. Rust may be very good at minimizing them (I don't personally know, I haven't looked into it) but it's simply not possible for it to have entirely eliminated them.

He has already made his position on this issue clear.

sudo isn't always easy, but this particular task isn't too difficult. You can give all members of a particular group privileges to run specific commands without a password. Then, you add your regular user account to that group. Generally, people use the existing sudo group for this purpose, although you can create a special group if you want, such as a shutdown group. For example, add this line to your /etc/sudoers file (remember to use visudo to edit!)

%sudo    ALL=NOPASSWD:    /sbin/shutdown,/sbin/poweroff,/sbin/reboot

Then add yourself to the sudo group:

usermod -aG sudo your_username

Now you can reboot without a password prompt:

sudo reboot

This is my preferred method, as a member of the nonsensical hair-shirt brigade! (I don't even use a display manager, just good old xinit.)

I can't even imagine being responsible for a project of this magnitude. I watched as all these big issues came up, usrmerge, 64-bit time_t, and more, and I wondered how it would ever be completely finished. But you folks did it! Thank you so much for everything. After all these years, it still amazes me when I set up a new system, and everything just works.

I assume you folks discussing size differences are using the standard installer? I didn't really notice a huge difference between the sizes of Daedalus and Excalibur, but I install manually, and my systems are pretty minimal. My kid was laughing at me last night because I don't even have a graphical file manager!

Are you talking about too small text in the grub menu specifically, or just small text in general? Changing the console font size is pretty easy; you can do this with dpkg-reconfigure console-setup. I'm not sure it affects the grub menu, though. You actually got me curious about how to change the grub menu text, because mine is really small as well. A quick search turned up this askubuntu post, which goes into a lot of detail about how to use the GRUB_FONT setting in /etc/default/grub (along with grub-mkfont) to get bigger text in the menu. I may give it a try later if I get some free time.

The repository configuration has been moved to the file /etc/apt/sources.list.d/devuan.sources, which uses a new format. It contains basically the same information as the old sources.list, it's just broken out into separate lines with descriptive headings.

I had a Savage3D, which was known for having hardware issues. The card seemed to have a tendency to overheat, even on Windows. It was also pretty new at the time, so Linux/XFree86 driver support may not have been entirely solid yet.