>>>>> "Andrew" == Andrew Hume <[EMAIL PROTECTED]> writes:
<snip> 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 lssconf-discuss@inf.ed.ac.uk http://lists.inf.ed.ac.uk/mailman/listinfo/lssconf-discuss
