[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1d0a0772-8b9a-48d6-a0f1-4b58abe62f5e@gedalya.net>
Date: Thu, 23 May 2024 21:39:14 +0800
From: Gedalya <gedalya@...alya.net>
To: Dragan Simic <dsimic@...jaro.org>
Cc: Sirius <sirius@...dheim.com>, netdev@...r.kernel.org
Subject: Re: iproute2: color output should assume dark background
On 5/23/24 9:23 PM, Dragan Simic wrote:
>> For what problem?
>> Obviously, for the problem your patch attempts to solve.
When nothing is indicated and a genuine _guess_ must be made, or a _default_ should be set, should that be dark or light?
This is not a coding question.
All defaults should be good in some situations and bad in fewer situations.
Having a default does not preclude reducing the number of cases it is relied upon. Those are different matters.
>> Yes I asked Debian in the first place to leave colors disabled by
>> default, but nevertheless `ip` is still broken for most users if and
>> when colors are enabled, whether at runtime or build time.
> Well, the coloring support in ip(8) can't be broken if the users
> configure it at runtime accordingly, i.e. following the background
> color configured in their terminal emulator(s), right?
Absolutely right. The manpage says so and it is tested, working.
>>> If Debian configures the terminal emulators it ships to use dark
>>> background,
>> Do they? Or is that the nearly universal default?
> Frankly, I don't know for sure because I don't use many different
> terminal emulators, but you as the submitter of this patch perhaps
> should know that better. However, terminal emulators must be
> configured somehow, because it makes no sense whatsoever that they're
> having their background colors hardcoded.
If you use the word "configure" to refer to the default behavior, set by
upstream and not modified by the distribution, then fine, yes.
It's just a way of saying "terminals tend to be dark".
>>> why not configure the ip(8) utility the same way, i.e. by setting
>>> COLORFGBG in files placed in the /etc/profile.d directory,
>> COLORFGBG where set is automatically set by the terminal emulator. It
>> would be more sensible to add this feature to more terminal emulators,
>> upstream.
> Of course, but that would take a lot of time, both to implement it
> everywhere and for the new feature to reach the users. Shipping
> a few additional files in the /etc/profile.d directory would be a
> reasonable stopgap measure.
No, it would be totally broken as explained.
>> Should Debian come up with a patch that magically adjusts this
>> variable every time the user changes their background color (in one
>> terminal emulator... and another color in another terminal
>> emulator...?)
> That's a valid concern. Perhaps some documentation could be provided,
> to help the users who alter their background colors.
Already documented in the iputils2 manpage and elsewhere.
>> And what about linux virtual terminals (a.k.a non-graphical consoles)?
>>
> In my 25+ years of Linux experience, I've never seen one with a
> background color other than black.
Which is why it's such a reasonable assumption for iputils2 to male.
(BTW I have seen non-black vt colors... just happens to be true. But not
so common)
>> In summary, if the best we can do is manually set COLORFGBG when using
>> a light background then that's the best we can do. I don't see how
>> Debian can possibly help with that.
>> On the iproute2 side, a rock-bottom ultimate default background color
>> assumption will always be needed and that should be dark.
> As others already pointed out, "should be light" or "should be dark"
> can be seen as personal preference.
It can and should be seen as begging the question of what is more common
in the reality out there.
The matter of personal preference is whether deep blue on black is a bad
choice.
What is the more common background color is a question of fact, not
preference. We don't get to have preferred facts. I just do not know how
to find out what the fact is, so I must use reserved language and say I
_think_ dark is more common.
Powered by blists - more mailing lists