> > 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?
Hey you hit the reason why I said it wasn't a perfect analogy, but you
veered to the left at the last moment and took it a tad to literally.
> 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".
More of the same from above. Taking my inital point a bit too literally.
> 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.
It gets the job done. Competently is up for discussion, as this thread
indicates.
> > 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".
Do you use a chainsaw, or a tool built specifically for skinning cats
(that in this case is BUILT INTO THE CAT) ? They both work. There are
varying degrees of right. Your way works, and I never said it didn't;
however there's a way documented 'better way'.
> > If you're going to make something your profession, do it to the best
> > of your ability no matter what it is.
> > Know the tools you use inside
> > and out.
I don't do consulting as my primary business, so I have the luxury to
not have to be all things to all people. I specialize in a few
toolsets, and I do make an effort to know them inside and out. Sure
there are things you miss, but I'd rather focus on doing one group of
things well, than having a passing knowledge of most everything else.
> 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
> scene.
> 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
> self-improvement.
Given that yum is the primary means for updating centos systems, I'd
say if falls squarely in your realm of 'know enough to do the job
sensibly and professionally' and yet from all appearances you didn't
even glance at the man page for it, as check-update is at the very top
of the documentation, and is the 3rd item under *command*. It's right
under description. THAT seems to be the primary factor that started
this insanity/flamefest/discussion/whatever. Emotion aside, would you
as a customer knowingly hire someone who ignored the documentation for
updating the OS of a mission critical system? Whether it's an accurate
statement or not, that is the perception you gave with your hack.
> > 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.
No new counterpoint here. same as above. Yum is your key word, and you
appear to have not looked it up.
> 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.
Covered this above.
--
"They that can give up essential liberty to obtain a little temporary
safety deserve neither liberty nor safety''
Benjamin Franklin 1775
