I wonder why colorizing manpages like this is not default in most distros. That seems like an obvious thing to configure for end user’s quality of life.

My best guess would be that each terminal could display differently or be buggy and a “lowest common denominator” approach where it work everywhere. I know blue tends to be to dark unless I change the color to a lighter shade and the font could make a difference as well.

No

I wasn’t intending to come off confrontational, I apologize for that. I was looking at this from it sounding like you wanted any command on a system. I did find that you can colorize man. see script below for an example. As for busybox, it is a small project, so colorizing just it would be relatively easy and easy to add as a patch to a system. Not sure if that would upstream though as it is intended to work well on low memory systems among others.

#!/bin/bash

export PAGER="less -r"
export GROFF_NO_SGR=1
export LESS_TERMCAP_mb=$'\E[01;31m'
export LESS_TERMCAP_md=$'\E[01;31m'
export LESS_TERMCAP_me=$'\E[0m'
export LESS_TERMCAP_se=$'\E[0m'
export LESS_TERMCAP_so=$'\E[01;44;33m'
export LESS_TERMCAP_ue=$'\E[0m'
export LESS_TERMCAP_us=$'\E[01;32m'

man ls

Edit: it does seem that this man colorization is disabled by default.

Edit2: “export MANROFFOPT=-c” can replace “export GROFF_NO_SGR=1” to limit just man.

Edit3: source Arch Linux bbs

I am getting the feeling the you are mis-understanding than each project has their own independent implementing function and that each one would need to be rewritten. There a 10 of thousands of projects. This is not some simple, change 1 project task.

16 Color terminals didn’t really start getting used until the 90s and early 2000s. And 256 after that. A lot of software was written back then and it would take a lot to add something that might not display well because of the terminal’s color scheme and now we have color theming.

I agree, I just didn’t want to make assumptions about how newer things work with localization these days.

Not everything uses groff. A lot will have their own function or another.

Edit: I think for what you indicting you are wanting to try you’d need to either patch your shell of choice or write your own.

Edit2: If you did patch it, the best way I can think of to get something upstreamed would be to patch bash to use CTRL-Enter to automatically pipe the output to the default pager defined in BASHPAGER followed by PAGER if it doesn’t exist. Then set the BASHPAGER to your “bat” command.

You’d be intercepting all commands just to verify if they have a help flag and then if not executing them as they were intended. If the intercept got broke, then the shell would be completely broken.

I think your best bet to to create a script called help and run “help <command>” and the script would do the rest.

I am using a 4080 on Plasma 6 wayland. It works pretty well. DLSS works. I haven’t tried frame generation, but I think support was added recently. Occasionally I have a wake problem, but I believe that is bios related. I am encountering a gamescope blackscreen freezing issue.

Only stuttering I am experiencing is a Steam overlay bug and Bluetooth interference sometimes.

Compositor choice and how recent of release will effect your experience as they are all independent implementations and still improving.

I wouldn’t expect that a 20 series card to be a specifically buggier experience over the 40 and 30 series though.

I remember that as well.

Edit; moved comment to correct reply.

This isn’t exactly new. I heard a few years ago about a situation where the ai had these wires on the chip that should not do anything as they didn’t go anywhere , but if they removed it the chip stopped working correctly.

Did you happen to enable Bluetooth LE-Audio mode for the Headphones in an app? If so you need to turn it off.

On top of the thermal paste idea, try doing a ram test. Could also try adding “nvidia_drm.modeset=0” to your kernel commandline or add “options nvidia-drm modeset=0” in /etc/modprobe.d/nvidia.conf. It might have that set to 1 somewhere.

There may be more in the logs as well. Are you able to test in windows? Maybe the gpu is failing as well.

I can’t tell from that output if you are using wayland or X11. If it is wayland I’d try X11 as the drivers before 555(?) don’t work as well and some compositors may be more unstable with the nvidia drivers.

I’d also try checking the logs as well. ‘journalctl -b -1 -xe’ to show the prior boot.

These is my only other suggestions.

If I am understanding that output, your bios is 5 years old and there are a LOT of updates since. If that is correct I’d try updating as bios updates fix things like PCIe compatibility which were released after that date.

I wasn’t saying AMD would shut down, but that Intel would take market share from them before truely affecting Nvidia’s market share. ie AMD and Intel would be fighting over the same 25ish% of the pc market.

I see the idea of Intel dropping arc as good news for AMD. Intel was going to chip at AMD’s marketshare well before Nvidia’s. It would be better to have more competition though.

Joining with Nvidia is definitely a way for MediaTek to make inroads against Qualcomm and their Snapdragon chips.

Could be a problem with the SSDs as well. AMD released the X670E last year after all. These aren’t new chipsets.

My community college(1997) had a Suse linux computer lab that I learned on. It was mostly used as a networking/server and programming platform.

Loki was the leading porting developer at the time.