replication of stuff in /usr/gnu

[Stephen Hahn]

* Garrett D'Amore <garrett at damore.org> [2007-07-06 11:54]:
> Stephen Hahn wrote:
> >* Garrett D'Amore <garrett at damore.org> [2007-07-06 10:59]:
> >>Stephen Hahn wrote:
> >>>* Garrett D'Amore <garrett at damore.org> [2007-07-03 15:12]:
> >>> (Although you find --help and --version pointless, many *ix users now
> >>> expect commands to process these options.)
> >>>      
> >>I would expect that to be true for commands that actually have some 
> >>non-trivial purpose.  E.g. for GNU grep this argument holds water.  But 
> >>for "true" to have --version and --help?  It seems a bit of a stretch.
> >>
> >>If we expect *all* commands to support this, then we should just 
> >>integrate that into our own command set.  But I think that this is not a 
> >>realistic approach.
> >>    
> > 
> >  (It seems this week that all threads lead to CLIP.)  The CLIP spec
> >  specifically asks for help and version options in 6.1 and 6.2.  That
> >  is, all long option commands should have --version and --help, and
> >  that short option ("getopt-compliant") commands should support -V and
> >  -?.
> >
> >  So, we've already elected that approach.
> 
> Even for commands that take *no* options?  That's a bit of a surprise!
 
  The CLIP classification appears to place a command with no options in
  the "getopt-compliant" class.  

> >>3) in the case of the GNU variants, I submit that the GNU variants of 
> >>these trivial utilities actually have a negative impact on 
> >>performance... the GNU utilities are clearly *larger* than the Sun 
> >>versions, and I can only imagine that this has an increased negative 
> >>impact on cache, etc.
> >>    
> >
> >  But, to run the GNU variant, you must actually change your path to
> >  invoke it--presumably meaning that you were willing to trade absolute
> >  performance for a known variant (used more widely than the historic
> >  Solaris version in most cases).
> 
> *BUT*, I may have good reasons to have GNU variants in my path first... 
> because I prefer the GNU versions (for one reason or another... in my 
> *particular* case I don't, but someone else might) because they offer 
> different functionality.
> 
> If this is the case, should I also pay a performance penalty for these 
> other commands which have no difference?  (In particular I'm thinking 
> about /bin/true and similar commands which may be called from shell 
> scripts.)
 
  This might be an argument for correct minimization boundaries, not for
  exclusion from the largest set of offered components.  (As an aside,
  the shells have direct support for most of the commands we're
  discussing...)

> Note on shared systems (such as Sun Ray servers), the cache impact 
> affects *multiple* users, the performance impact is not limited to just 
> the user using the GNU program.

  Again, this scenario argues against any additions to the system,
  because any potential application changes the working set for whatever
  cache you'd like to examine.

> I agree that the impact is *small*, but why pay *any* such cost if there 
> is no benefit in doing so?
 
  Because the path we take to arrive at this hypothetical "zero cost"
  outcome was substantially more expensive than others.  That appears to
  be the crux of our disagreement:  you believe that developer attention
  should be focussed on refining this kind of integration; I don't.
  There are larger problems to tackle.

> >>The cavalier attitude that "its only 200k" is symptomatic of a larger 
> >>problem, which is that certain developers have stopped caring about 
> >>performance, size, etc... the assumption is that Moore's Law overcomes 
> >>sloppy engineering.
> >>    
> >
> >  Actually, I don't feel that any of my reasoning in this space is
> >  cavalier or sloppy...
> >  
> 
> The 200k argument certainly was, IMO, cavalier.  Just because you have 
> infinite disk space (and other system resources) to burn doesn't mean 
> everyone else does.
 
  I know of no supported system on which we would consider installing
  SUNWgnu-coreutils where 200k is a factor.  I know of no hypothetical
  target system where installing SUNWgnu-coreutils couldn't be omitted
  to achieve footprint goals.  

> I'm saying that this is just one more straw on the camel's back.
> 
> For a large number of system utilities, I agree that the GNU versions 
> offer an EOU enhancement.  But I'm also saying that there is a 
> significant set of GNU utilities for which this is *not* true.
> 
> Understand, please, that GNU coreutils is intended for use on systems 
> that do not otherwise have these utilities.  But for systems like 
> Solaris, which have a native version of commands like /bin/true, 
> providing a 2nd version of the same command, which offers no difference 
> in functionality, seems largely wasteful to me.
 
  I understand that, but I don't think it's a balanced assessment of
  waste.

> >>But then again, I've had in the past year to make Linux work on an 8MB 
> >>system, and had to develop a thin-client application that fit within 
> >>512K of flash.  And more recently, I've been working on IP forwarding 
> >>performance, where each extra branch in IP costs about .1% to .2% hit in 
> >>the number of packets per second that the system can forward.
> >>
> >>Waste is still bad.  Moore's Law notwithstanding.  I will still tend to 
> >>hunt down (and destroy, as much as possible) bloat where I find it, 
> >>particularly where that bloat serves no useful purpose.
> >>    
> > 
> >  I suspect strongly there are more rewarding veins of waste to mine.
> >  
> 
> Probably true.  But yours is also low-hanging.  And more to the point, I 
> hope to prevent *further* growth here.
> 
> I would really, really like to see justification for *any* new utility 
> added to the system.  Where there is different functionality that users 
> or layered software will notice, then I agree the EOU probably 
> overrides.  But where there is no difference, then I'd argue against 
> wasting the system resources.

  Well, we'll be having this discussion again, I suppose, as examination
  of this kind for "upstream integration" cases seems in itself wasteful.

  Perhaps you could come up with some guidelines for easier
  minimization, rather than causing each proposed supported component to
  be subject to some (testable?) assertions about waste.

  - Stephen

-- 
sch at sun.com  http://blogs.sun.com/sch/