netdev - Re: [PATCH v3] iproute2: color: default to dark background

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <c879a566846187e3313f8448f1c21548@manjaro.org>
Date: Fri, 31 May 2024 00:58:48 +0200
From: Dragan Simic <dsimic@...jaro.org>
To: Gedalya <gedalya@...alya.net>
Cc: David Ahern <dsahern@...nel.org>, netdev@...r.kernel.org
Subject: Re: [PATCH v3] iproute2: color: default to dark background

On 2024-05-29 18:36, Gedalya wrote:
> On 5/30/24 12:23 AM, David Ahern wrote:
> 
>> On 5/22/24 12:43 PM, Gedalya Nie wrote:
>>> Since the COLORFGBG environment variable isn't always there, and
>>> anyway it seems that terminals and consoles more commonly default
>>> to dark backgrounds, make that assumption here.
>> Huge assumption. For example, I have one setup that defaults to dark
>> mode and another that defaults to light mode.
> 
> The code currently assumes light mode and it's generating complaints.
> It seems like we need to figure out a way to find some support for
> whatever is the best assumption.

I think it would be best to modify the logic to require the presence
of COLORFGBG in the environment to enable colored output, if requested
by the user, or if built to be enabled by default.

>>> Currently the iproute2 tools produce output that is hard to read
>>> when color is enabled and the background is dark.
>> I agree with that statement, but the tools need to figure out the dark
>> vs light and adjust. We can't play games and guess what the right
>> default is.
>> 
> That's not possible.
> 
> COLORFGBG won't be allowed through by SSH servers.
> 
> If you try to write \e]11;?\a to the PTY you need to establish a
> timeout. There won't always be a response.
> I'm not aware of any good way to do this, though I'm certainly not an
> expert. But I don't think that tools "figuring out dark vs light and
> adjusting" is a thing. If you just so happen to be happy with your
> results then so was I until Debian changed the way they build iproute2
> and I never even used color overrides -- now I do. Tools just throw
> colors in your face and no, there is no really good and universally
> working way to be smart about it.
> The fact remains that the code currently makes an assumption and I
> don't see why it is better than the other way around.
> We need some kind of (possibly crude) way to assess what is more
> common, light or dark. But as I have pointed out already, as long as
> graphical terminal emulators are concerned, the reality out there is
> that people use themes and such and the ANSI color codes don't dictate
> the actual color displayed. But on a linux vt it is easier to say that
> the background will be dark, and it's neither simple to change the
> background nor to override the way ANSI colors are displayed.