Subject: Re: bug#33787: Policy Change: Use of /etc/gnu.conf files to configure default system behavior

From: L A Walsh <[email-masked]>
Date: Sun, 23 Dec 2018 23:19:41 -0800

On 12/23/2018 5:46 PM, Paul Eggert wrote:
>> Similarly with 'find'
> 
> "find" is not part of coreutils, and discussion of it should be moved to
> a separate bug report, which you can create by emailing [email-masked].
----
  If you were discussing whether or  not each each county or province in
the state should have a place where the laws and regulations of that state 
and county were on display for reference or consultation, AND you had a 
case where whether or not Santa Clara County in California should include
in its display, Bay Area regulations as well, should such discussion 
or cases be opened and entertained in Santa Clara County at the same
time one is discussing the statewide or national cases?  

  Wouldn't it be proper to discuss the Bay Area's inclusion after the wider
jurisdiction cases have been discussed?  It might be wiser to discuss
other areas for inclusion after until sometime _after_ the larger case
is settled.
> ... configuration files 
> (system-wide? user-specific? directory-specific? it's not clear).
---
   As far as the proposal went, I think it was:

        "Now I suspect that people will want these options to be
        configurable by user and not just at a system level -- so
        ideally, there would be a '~/.gnurc' file for user overrides."
 
> applications and kernels are 
> different animals, and the existence of a configuration method for the kernel 
> does not necessarily imply that the same configuration method is a good idea for 
> applications.
---
  Different animals, yes, but similar eco systems (arch, hw, source
lang(s), users, etc...).  Also, a need to configure both for their
environments.  Both need different methods for building on x86 than on
MIPS, likely different building for a US-based distro vs.
a China-based distro.  Like different need for home environment vs
that of a National-Security-Agency, or a bank.  Even a vastly
different needs based on filesystem type (How many times did we see
a message from the tail program about an unknown file system?).

  Of course in some ways, the kernel stores part of the user's choices
in the hardware config.   If they wanted a graphics pen, they probably
bought one, and windows will turn on pen-input, though on linux it's
probably "each app for themself", however the variability in how the
kernel can be configured not only varies by hardware but by your
desired software behavior.  Turning on FLASK or SMAC security will
result in the utilities behaving differently.

  In all of the above, we see lots of configuration for different
items, but almost non of those items touch on "*user-requirements".
Huh?  user requirements?  Nearly every bit of new work has
a requirements or prereq. list; why not users?

  In new features or improvements in the past year or two -- how many
of them came with some study or poll of users who asked for it?  How
many voted for the feature vs. against?  How many were discussed on
coreutils before they were introduced?  How much weight is given to
user requests?  

  At one point in time there were vendor versions of many of these
tools, but people often sought the gnu version because it had some
extra behavior or feature.  Additionally, I would bet that
many gnu features and utils wooed users by being responsive to
new feature and enhancement requests.  Unfortunately, these days
there usually isn't an alternative.  Gnu has gone from responsive
to the place of "holding the line" against user wanted changes.

  Out of a list of new features or in the past few years, how many
came from user requests?  I wonder if number of requests has dropped
off as fewer people are drawn-to or have the ability to do software
development (hard to think about doing much in the way of development
on an iPad or Android device). 

 I encountered a first, recently: a third-party company that was hired
to support end-users adapting their computers to the program -- but
that did no actual support of the program.  If you wanted a new
feature or bug -- you were directed to a community discussion
list that you are told "is often a place where developers (in
a different country speaking a different language) get new
ideas.  Right....   

  The disconnect seems to almost be complete.  No longer are programs
created to attract users or solve their problems, but users and their
HW are now being adapted to run the programs.

  Maybe this is the first step in computers & hardware laying down
requirements for users.

  So I can see why providing a /etc/gnu.conf file to allow programs
to support diffent user behaviors would seem like a a step backward.
But is it really?