[CentOS] Updates on Centos 4

Benjamin Smith lists at benjamindsmith.com
Wed Mar 1 19:16:37 UTC 2006

This is a discussion. 

It gets personal when I see "dear god I'd hate to be one of your clients...". 
But notice that rather than flame away, and highlight Mom's relationship with 
Dad, I did ask for reasoning to support the criticism. Perhaps some emotion 
is involved, but there's also a chance you or I might learn something here.  

On Tuesday 28 February 2006 20:16, Jim Perrin wrote:
> >Isn't this sorta like saying that "cat foo |
> > grep NNN" is not nearly as good as "grep NNN foo" ? They appear largely
> > equivalent, for all intents and purposes... the output even looks similar.
> That's not a perfect analogy, but given the situation, it's pretty
> good. Yes, the output looks the same, and most people won't notice or
> care, but there's overhead and extra system work in getting the
> answer. Scalability and performance over load where it counts is what
> makes a good admin. It's the attention to detail and the drive to do
> things the right way, not just the way that yeilds the proper answer.

It seems to me that you are dealing with premature optimization. How much are 
you willing to make your clients pay to read documentation that provides 
little discernable benefit? Are they aware that they are, in fact, paying for 
time with marginal value? 

I write software, and do what works first, balancing knowing every permutation 
of every option with simply getting the job done competently. Performance 
optimization generally comes fairly late in the game, after initial spec, 
design, implementation, testing, and frequently, deployment. Even in large 
codebases, it's surprising how often tweaking just a few (perhaps a dozen?) 
key points can result in vast performance increases of the system at large, 
with very little time wasted on "optimization". 

In this case, the performance penalty of the "yes" shell command doesn't even 
qualify for consideration, and the job gets done competently in either case. 

> Your way is a hack, and is evidence of not reading the documentation. 
> It's a functional solution, but not the right one. There is a
> difference.

The *nix environment is not only tolerant of such "hacks", but is actually 
designed to encourage it. Small tools, cobbled together to get whatever you 
need out. See http://www.linuxlots.com/~dunne/unix-philosophy.html 

Compare this idea with "more than one way to skin a cat". 

> If you're going to make something your profession, do it to the best
> of your ability no matter what it is. 

"Best" isn't some ivory tower ideal based on zen-like knowledge. "Best" is 
getting the most done for the least amount of customer's money. Happy 
customers == repeat business + referrals == 6-figure incomes + longevity + 
security. Overcharged customers == bankrupt customers + negative remarks == 
average incomes + high turnover + financial insecurity. 

> Know the tools you use inside 
> and out. 

It's naive to think that the average person could be intimately familiar with 
*ALL* aspects of the *nix environment. There's simply too much accumulated 
over the past 30 years. Just to keep up with current developments in their 
entirety is not possible, even assuming omnipotent knowledge of the present 

Far better to set sights that are comfortably attainable, to ensure that you 
know enough to do the job sensibly and professionally, and invest a 
percentage (I'd suggest about 10%) of your time in ongoing research and 

> And always remember, you can bill the customer for the time 
> you spend reading the documentation if you don't immediately know the
> right answer. If you don't believe me, ask a lawyer what they bill
> for. Might help to have some cash handy just in case they bill you for
> the answer.

Sure, but keep in mind above comments about premature optimization. I'd be 
sorely upset if I asked my lawyer to review a contract, and he spent 3 weeks 
at my expense researching the legal definition and derivatives of every 
single word used. And, this degree of research could be justified by the 
phrase "knowing it inside and out". He should know what words are key, and do 
just enough research to reasonably determine that I'm not about to make a 
mistake I'll regret. 

In short, while it's immature to expect to know every facet of every tool, 
it's expertise to know what facets of the available tools are actually 
relevant and worthy of time investment to get the job done well. 


"The best way to predict the future is to invent it."
- XEROX PARC slogan, circa 1978

More information about the CentOS mailing list