tech-userlevel archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: colorls in base
At 15:02 Uhr +0000 16.02.2019, Christos Zoulas wrote:
>Yes, what I don't understand (because nobody has stated a technical
>reason other than 'fluff'),
... I guess that hurt. It wasn't meant to, sorry, just a tongue-in-cheek
handle to a serious point.
> why we shouldn't we have the feature in base at all.
I remember you speaking up against replacing csh(1) with tcsh in base a few
years ago. How about adding tcsh's complete facility to csh(1)? That is
probably an order of magnitude in codesize compared to ls(1) vs.
colo(u)rls, but I see a moral equivalent.
>Things change over time; we don't go rip out color output compiler
>support from the compilers. It is not enabled by default so it is
>invisible.
We don't, because needless deviating from upstream source incurs high
maintenance cost, and is frowned upon.
>So will be having color in some programs in base. It will
>be invisible unless you specifically turn it on.
I guess some of us see a slippery slope?
>It is not frictionless (and should be but that's another issue) to
>"install from pkgsrc" and it's a good question why not have the feature
>in base when the majority of the users just install replacements from
>pkgsrc because of the lack of features.
Careful, that way lie bash and emacs, cups and ...
> It is not 1980 anymore and
>we don't need to be frugal about resources (specially when they can
>be compiled out).
Well, we still support most of the architectures we supported in the
mid-nineties (and even vax from the eighties). So it would be nice if base
ran reasonably well on them.
Cheerio,
hauke
--
"It's never straight up and down" (DEVO)
Home |
Main Index |
Thread Index |
Old Index