>>>>> "Andrew" == Andrew Hume <[EMAIL PROTECTED]> writes:


  Andrew>       i wonder if the increased complexity of administering
  Andrew> today's systems and the increased rate of configuration
  Andrew> churn has moved beyond many sysadmin's comfort levels, thus
  Andrew> almost forcing the treating-a-symptom approach. if so, this
  Andrew> has dire consequences for our field, for then it is the
  Andrew> problem itself that is the difficulty, and not the
  Andrew> presence/absence of specific tools. a guru elite becomes
  Andrew> necessary, then, simply to figure out the solution,
  Andrew> independently of how it is implemented and deployed.

This is probably straying a little far from the topic, but I have a
friend who used to remark that being in computers in the 90's was like
being a train engineer in the 1860s. At that point, the engineer was
the guy who made everything work; he was in many ways the most
important person on a train. If you look at an amtrak engineer today,
you will see a different picture. 

If we were to decompose system administration into all of the
requisite pieces, I am very comfortable saying that we can write tools
that will substantially simplify some parts of the process. Others are
a lot trickier; problem determination and root cause analysis spring
to mind.  

I find the question of churn quite interesting. Why should it be
expensive? This is one of the cases that I think can be solved fairly
well at this point. 

I have another question at this point. Microarchitecture complexity
has grown substantially in the last 40 years, making directly coding
in assembly much more difficult. (Consider efficiently programming
IA-64) Using my favorite compiler analogy, using compiled, portable
languages made things a lot easier, but also introduced a lot of new
tech that practitioners needed to master. Are we in a similar place
here?  -lnd
lssconf-discuss mailing list

Reply via email to