Refreshing [LWN.net]

Refreshing

Posted Jun 9, 2021 6:21 UTC (Wed) by zdzichu (subscriber, #17118)
Parent article: Rewriting the GNU Coreutils in Rust

Recently I've re-trained my muscle memory and started using some alternatives to common utilities:
– grep - https://github.com/BurntSushi/ripgrep
– find - https://github.com/sharkdp/fd
– cat - https://github.com/sharkdp/bat
– ls - https://the.exa.website/
The syntax is a bit different than originals and not all features are present, but the change was worth it. Those new, “modern” utils are pleasure to use and are fast. Incidentally or not, they all are written in Rust.
I'm looking forward to coreutils rewrite. Using all the Linux kernel features and all the CPU cores would be nice. It's 2021, we do not need code to support AIX from the '80s of the last century.

to post comments

Refreshing

Posted Jun 9, 2021 13:18 UTC (Wed) by taladar (subscriber, #68407) [Link] (20 responses)

While these can be nice for interactive use for scripting we really need something that is character-for-character compatible in the output with the original (and the standards) and stable across versions.

Refreshing

Posted Jun 9, 2021 13:35 UTC (Wed) by nix (subscriber, #2304) [Link] (18 responses)

Plus... when even the website for exa, which is surely supposed to be showcasing the best it can do, is actually showcasing how terrible and eye-straining the default choice of colours is (nearly-unreadable ultra-low-contrast dark blue on black is considered a reasonable colour for file sizes, dates, and *directory names*, which should be kept more readable than anything else! while the almost-useless file owner is carefully highlighted and this is bizarrely highlighted as a significant feature)... it doesn't fill me with any confidence regarding its other design decisions. If even really simple stuff like colours is painfully, obviously wrong by default, in ways obvious from a single glance at the screen, what's the complex stuff like? (And yes, I know GNU ls makes some of the same default colour decisions, but the whole point of exa is to make better decisions by default!)

(a lot of the other tools above are really good. In particular rg is amazingly fast for even ridiculously complex regexes.)

Refreshing

Posted Jun 9, 2021 20:51 UTC (Wed) by khim (subscriber, #9252) [Link] (7 responses)

You have made me really curious.

Specifically that:
> nearly-unreadable ultra-low-contrast dark blue on black

And of course what I have find is something which is really well-readable and nice looking. While yellow used for README.md and Makefile is a bit hard for me to read (but not hard enough to declare them not usable).

Finding good colors is hard. People are different and significant percentage of males have issues there. Thus I'm not sure “oh, default colors don't look nice to me — means the whole project is unsuitable for everyone” is a good attitude.

> but the whole point of exa is to make better decisions by default

But what is “better decisions by default”? We may aim to create better peception for the majority of people (the ones with no defects) or we may try to make sure our color scheme is poor-but-acceptable for most people (including the ones with vision defects). My guess would be that ls and axe aim for the 1st (which makes sense for highly-configurable tool) while web sites are usually designed for the 2nd.

This creates strange dilemma: colors which are best for actual program are not best for the website dedicated to that program… so what should be done about that? Should the website use some non-standard palette to make it acceptable for the majority or use the actual default colors program uses? I don't think these are easy decisions and I don't think exa is big enough project to afford market research…

Refreshing

Posted Jun 10, 2021 1:07 UTC (Thu) by kschendel (subscriber, #20465) [Link] (4 responses)

After periodically fiddling with various color schemes for ls and other tools over the years, I've decided that the best color scheme is white on black - at least for me. (and I have no color deficiencies in my vision.) I find that either the colors don't really add any value, or they work sometimes and not others depending on what it is I'm interested in at the moment.

So I guess I have no objection to the (rather peculiar IMO) colors shown on the exa website as long as I can turn it all off and just see black and white.

Refreshing

Posted Jun 10, 2021 2:00 UTC (Thu) by NYKevin (subscriber, #129325) [Link] (3 responses)

In theory, most tools should be smart enough to completely disable color when TERM=dumb. Unfortunately, it seems that GNU ls (with --color=auto) just checks isatty and assumes that all reasonable ttys can support at least 16 colors (which is probably a fair assumption these days, but IMHO "dumb" means "no really, I can't do anything other than clearing the screen, don't try to get clever with me" rather than "just assume I'm a vt100 or whatever"). I have not tried exa.

Refreshing

Posted Jun 24, 2021 12:53 UTC (Thu) by immibis (subscriber, #105511) [Link] (2 responses)

> but IMHO "dumb" means "no really, I can't do anything other than clearing the screen, don't try to get clever with me" rather than "just assume I'm a vt100 or whatever"). I have not tried exa.

Surely "dumb" means "I can't do anything other than printing characters - not even clearing the screen"?

Refreshing

Posted Jun 24, 2021 15:50 UTC (Thu) by james (guest, #1325) [Link] (1 responses)

AIX login assumes you can clear any screen with enough linefeeds.

Refreshing

Posted Jun 28, 2021 13:56 UTC (Mon) by immibis (subscriber, #105511) [Link]

Sounds like a waste of paper :)

Refreshing

Posted Jun 10, 2021 11:26 UTC (Thu) by jengelh (subscriber, #33263) [Link] (1 responses)

>Finding good colors is hard

Yes, it's hard if you try to give a color to every thing under the sun, which leads to a bad tutti-frutti overload like mcedit[1].
No, it's not that hard:
As an application developer, firstly, make colors the user's business and emit as few as possible by default. My recommendation is to do with just {default_fg, fg_hue1_shade1, fg_hue1_shade} and {default_bg}. Such reduced color sets[2] vastly facilitate the user switching between x-on-black and x-on-white and hue1-on-x and hue2-on-x to facilitate room lighting and mood.

[1] https://paste.opensuse.org/view/raw/21792273 (mcedit with 7+ colors, 11+ shades, not all pictured / background never counted)
[2] https://paste.opensuse.org/view/raw/73371546 (2c3s)

Refreshing

Posted Jun 10, 2021 12:07 UTC (Thu) by khim (subscriber, #9252) [Link]

> Yes, it's hard if you try to give a color to every thing under the sun, which leads to a bad tutti-frutti overload like mcedit.

Surely you jest? I'm using mcedit more often than not because I like how it colors things. There are many things I don't like about mcedit (e.g. I really hate that a single long line can slow down it immensely), but colors? Mcedit is one if the best examples IMO. At least for me.

> As an application developer, firstly, make colors the user's business and emit as few as possible by default.

Nope. That's 2nd step. You have omitted extremely important 1st step: accept that you are not developing program which you would like to use in it's default configuration and create program for “someone else”. Maybe even conduct some kind of “UI research” (like GNOME guys did before they developed GNOME 3).

Unfortunately, considering the end result of GNOME3 redesign, I couldn't say that's the road to success.

And if you skip that 1st step and create something which you, personally, would like to use… is that really such an awful sin? Git was created that way, after all. And it's wildly more successful than GNOME3.

> Such reduced color sets[2] vastly facilitate the user switching between x-on-black and x-on-white and hue1-on-x and hue2-on-x to facilitate room lighting and mood.

Indeed. It makes it possible to do something which I never need or want. But why should developer value that ability higher than the ability to do what they need or want?

You somehow skipped that part entirely.

P.S. And I'm all too ready to admit that my tastes may be “wrong”. Perhaps lasting impression of Norton Commander and Turbo Pascal have left it's mark, who knows. But when I hear “color support is not hard, you just need to avoid this <link to something I like> and do this <link to something I hate>” then only reaction it may evict in me is “who died and make your god?” and/or “why should I create the program which you would like and not I would like?” People are different. Deal with this.

Refreshing

Posted Jun 9, 2021 21:07 UTC (Wed) by pizza (subscriber, #46) [Link] (8 responses)

> (nearly-unreadable ultra-low-contrast dark blue on black is considered a reasonable colour for file sizes, dates, and *directory names*, which should be kept more readable than anything else!

"readability" depends on your terminal colors -- if you have a light/white background (which is the "modern" default) then dark blue is a very legible color. But yellow (which is great on a dark background) is equally illegible on a light background.

So while desktop environments make it pretty easy to switch between light/dark themes, there isn't really a sane mechanism to pass that theme-derived information to terminal-based applications.

Refreshing

Posted Jun 9, 2021 23:15 UTC (Wed) by Sesse (subscriber, #53779) [Link]

Actually, there is. vim makes use of it by default if you don't set big=dark or bg=light explicitly.

Refreshing

Posted Jun 10, 2021 14:38 UTC (Thu) by nix (subscriber, #2304) [Link] (6 responses)

> "readability" depends on your terminal colors

Of course it does, which is why any program with colour worth its salt provides at least two defaults, for light and dark background. But... exa has a dark background *on its website*, and then uses colours on it which are only suitable for a light-backgrounded terminal (and I'm not sure they're even suitable for that). It's like it's trying to make sure it's looking as bad as possible to potential new users. Weird.

Refreshing

Posted Jun 10, 2021 17:51 UTC (Thu) by zdzichu (subscriber, #17118) [Link] (5 responses)

Oh great, an actual bikeshedding, discussion about colors. FWIW, exa example on a website looks good to me. It's readable.
I'm not sure why it's not good for you? Maybe your display isn't accurately color-corrected? Have you loaded proper ICC profile? Maybe you have a display with a strange gamma curve, like MacBook? Who knows?
Anyway, people tend to either select suitable color-set for their terminal emulators, or tweak the colors which they don't see clearly to be in better shade.
Exa is not ideal, not because of colors. For example, exa omits directory size, which is very useful information on CephFS. But I like it more than GNU “ls”, still.

Refreshing

Posted Jun 10, 2021 20:54 UTC (Thu) by nix (subscriber, #2304) [Link] (4 responses)

> Oh great, an actual bikeshedding, discussion about colors

When the colours are a stated benefit of the tool, and the choice on the website seem that bad, I think it's justified. (Also: colours really do matter, at least to people who have working vision that's good enough that they can benefit at all. Obviously the colourblind, people with tunnel vision or people who are actually blind are rightly going to think this is not a discussion that could affect them!)

> I'm not sure why it's not good for you? Maybe your display isn't accurately color-corrected? Have you loaded proper ICC profile?

Are you joking? To a first approximation nobody who isn't involved in graphic design will have done that. It takes special hardware and I don't have it (yes, it's not very expensive hardware, but it's also more or less useless unless you're a graphic designer).

Dark blue on black is almost guaranteed to be hard to read right back to the days of the oldest colour-capable DEC terminals (GNU ls's default colours make this mistake too, in case you think I'm letting it off too lightly, and portage, oh boy). Yellow on white likewise. Obviously exa lets you change these, but these seem to me to be examples of just plain bad defaults which have *always* been bad even though everyone always picks them for their new tool: but nonetheless I have no idea why anyone would think this is a good choice of colours to put on a website, unless perhaps they *are* using amazing colour-corrected Retina displays rather than the years-old random Samsungish LCDs which most people not using Macs are more likely to have. My vision is quite poor and my glasses don't make blue or red particularly good colour choices in any case, because of strong dispersion even with extremely expensive lenses -- but dispersion isn't the problem here. Can *anyone* read dark blue on black easily? (Maybe you have the brightness jacked way up? Surely not, everything else would be painfully bright.)

... hm, maybe it's just that newer LCDs have a wider colour gamut than older LCDs (which should lead to dark blue being further separated from black), and both my LCD screens *are* quite old random Samsungs. It's hard for me to say: I've hardly seen any newer LCDs... colour correction seems unlikely to fix *that*. I'd need a new set of displays, at a cost of several hundred quid, so that people with terrible colour choices can inflict a bit less pain on me :P

Hm maybe I *should* replace my monitors. Last time I looked monitors wider than 19" with VESA mount brackets were for whatever reason almost unobtainable... but that drought appears to have passed, and it was in any case years ago. Of course none of them are going to say what their colour gamut is, and shopping for monitors is a headache-inducing nightmare in any case. Argh.

Refreshing

Posted Jun 10, 2021 20:56 UTC (Thu) by mpr22 (subscriber, #60784) [Link]

> Dark blue on black is almost guaranteed to be hard to read right back to the days of the oldest colour-capable DEC terminals

It's tolerable on PC native romfont displays, but a big part of that is that standard PC romfonts have two-pixel vertical strokes.

Refreshing

Posted Jun 11, 2021 10:53 UTC (Fri) by flussence (guest, #85566) [Link] (1 responses)

> I'd need a new set of displays, at a cost of several hundred quid, so that people with terrible colour choices can inflict a bit less pain on me :P

I can save you the expense: on my Dell Ultrasharp (older model, but still well beyond sRGB) the colour choices we're complaining about here are still barely legible. And yes, it does have the correct magic bytes loaded in colord!

Maybe it's readable at 100% brightness but nobody wants to stare into a lightbulb, and this thing's old enough that getting there takes a few minutes now...

Refreshing

Posted Jun 13, 2021 20:39 UTC (Sun) by nix (subscriber, #2304) [Link]

> I can save you the expense: on my Dell Ultrasharp (older model, but still well beyond sRGB) the colour choices we're complaining about here are still barely legible. And yes, it does have the correct magic bytes loaded in colord!

Let no-one say LWN comment threads are not valuable! :)

Refreshing

Posted Jun 11, 2021 12:19 UTC (Fri) by khim (subscriber, #9252) [Link]

> Obviously the colourblind, people with tunnel vision or people who are actually blind are rightly going to think this is not a discussion that could affect them!

That's funny because I was the only guy in our class who never had any vision problems. Never needed glasses neither for reading nor for driving, passed all these medical color-tests with flying colors, etc.

> Dark blue on black is almost guaranteed to be hard to read right back to the days of the oldest colour-capable DEC terminals

What about blue on blue (like immensely popular in xUSSR Norton Commander? I still use that scheme (because it's a default in Midnight Commander) and like it.

> Can *anyone* read dark blue on black easily?

Yes. Me. Dark blue is perfectly fine. Novadays I have slight trouble reading bright yellow or bright blue on black. But dark ones are perfectly fine.

> ... hm, maybe it's just that newer LCDs have a wider colour gamut than older LCDs (which should lead to dark blue being further separated from black), and both my LCD screens *are* quite old random Samsungs.

Maybe, but that's irrelevant. I liked blue on blue back when I used ViewSonic PT810 and I like this setting now.

Refreshing

Posted Jun 10, 2021 11:41 UTC (Thu) by flussence (guest, #85566) [Link]

That default blue in the terminal palette is one of the top three things I'd show to people looking for reasons to avoid Linux, and it ought to be nuked from orbit in a coordinated effort.

I go out of my way to change it in every terminal emulator I use, because otherwise large parts of the OS are unusable (Gentoo's package manager and surrounding tooling is an accessibility disaster that frequently uses blue and yellow text colour to convey *information* - there's no escape even if you try to use a light terminal).

Refreshing

Posted Jun 9, 2021 22:45 UTC (Wed) by rodgerd (guest, #58896) [Link]

That says a lot about the value of "everything's unstructured text" Unix philosophy.