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)
