Things are seriously wrong at IMSc's computer systems. "Nothing works", "nothing prints", "my screen is ugly" and "mail is bouncing all the time". We hear this a lot at the coffee table and shake our heads and blame the computer committee or "computer-inner-circle" or if we are in one of the latter two we blame the system administrators! So what is the solution? My own answer is "ever increasing community knowledge base".
In the manner of Meena's description of Oracle-style Interactive Proofs (OIP), I am trying to anticipate various queries and answer them since I will not be present at the user's meeting. If your question/comment is not handled by this write-up then either I do not know the answer or you question/comment is meaning-less and you should think again. All responses to me for this message will go directly to /dev/null and will not pass GO or collect Rs. 200.
My own motivation
I find certain programs are well-maintained in a "community" fashion (see below). When I find errors and report them, the authors try to fix them or try to explain why this is a "feature" and not a bug. Without putting too fine a point on it this is essentially the software that you will find on my desktop machine at home and in the Institute; there are a few other things that I do not use but would be quite willing to help in "de-bugging". Whenever anyone (including a system administrator) has come to me with questions about such software I have been found willing to find time to help. Since more than 90% of the software that is used more than 90% of the time on our system is of this nature, it is generally assumed that I am a "computer-hack", geek or "computer expert" or computer-addict.
Further, it is assumed that when I do not help, I am being "pricey" or "ideological" or "obstructive". Far from it. It is a practical matter. Software that I use or can easily fix or get fixed or get credit (from the programmer in the form of thanks) for fixing is enjoyable to fix. Other software is not enjoyable and it is anyway the job of the paid programmer from those big companies in the USA to fix such programs.
Isn't it the sysadmins job then?
Now this could be argued. After all what have we hired him for?
This is to misunderstand the system administrators primary job---maintenance of a running system. Small and routine problems crop up all the time and these need to fixed, machines need to be replaced or vendors notified and so on. An extensive list of system administrator's daily and weekly tasks can easily take up at least the entire morning---and this is assuming that there is no crises (like UPS failure or link failure or someone re-booted the main file-server because his screen hung). Given low community knowledge, crises or imagined crises are more frequent as well.
Certainly, part of the system administrator's job is to respond to user's difficulties with the system. Let us take an example (which is quite a real-life one). A user calls the system administrator and says "I cannot print .bdt files on the new printer. I need it urgently." Leaving aside the problem that there are often other pressing issues such as the mail-server being down let's assume that the sysadmin has one hour at his disposal to solve this problem. How is he supposed to solve it?
Well he should first check the configuration of the printer and see that it is ON! Then he checks to see if the .bdt file will print if he sends it for printing. Suppose it works. Voila! The urgent problem is solved---but it will come again since the user will have to print a .bdt file again! Anyway, the other (and more likely) possibility is that it does not print.
In either case, he will go through all the documentation that he can find locally and on the internet regarding printing .bdt files looking for a hint. His chances of finding a solution are much lower (and his search slower) than the person asking him this question who has a Ph.~D. and is (supposedly) an expert in analytical thought. (Remember, the sysadmin has a degree or a diploma in an unrelated discipline---this is a real-life situation). There are so many printers and types of files out there that no system administrator can know about them all. So he does the next best thing which is to ask other "more knowledgeable" users how they print files and so on---in other words it is the community that provides the answer. His chances of finding a solution are much lower if the user is more specialised and if the user's system is more specialised; for example the community may have no answer on "How does one print .eek files on a bull-doze system?" (You would understand this better if you walked into a typical cyber-cafe trying to print out a ".ps" file).
It is unrealistic to expect the system administrator to find a solution based on helpful hints like "the system administrator in Bangalore could solve it" unless the system administrator at Bangalore is running a similar system and has an e-mail address and is willing to help---in any case this would then again be community knowledge. It is totally delusional to think that the system administrator will use this problem as an incentive to design a shiny new printing system that will work for all files on all printers and on all machines at the IMSc. Most of the programs that we use were either written by software professionals or research-oriented academics like you and me---not system administrators. In any case, if we expect him to do this then we should also expect to get abrupt answers when we ask him questions while he is working on this new system---exactly as we get irritated with irrelevant questions while doing research! So can either have a friendly sysadmin or an expert one---not both!
This brings me to the real answer to "computer problems". Viz. increasing the community knowledge-base about computers and their use; locally and (to the extent possible) globally. This is slow and painful---occasionally you may lose an important file or two days of work or even worse you may spend so much time trying to solve this (apparently) non-research problem that you may be scooped on your great result and thus miss out on a promotion or job. Clearly, individuals have to decide on how much is fair and reasonable. All I can say is that current levels of community knowledge at IMSc are abysmal; just to be painful let me repeat that; current levels of community knowledge at IMSc are abysmal. In such a context a wise system administrator will decline your offer, a good one will take the "next available flight", the guy who stays on will learn to answer "it is being looked into" or use some other delaying tactic.
I had suggested in the past that complex systems or "computer packages" such as "mail", "firewall", "TeX", "printing" be taken up by groups of faculty members as their "pet projects". This way they will learn a little more about the system and increase the community knowledge base. All I can offer is the assurance that this is more (personally) rewarding than the existing system of trying to pay (hire people), coerce (bully people after hiring them) or steal (use illegal software) to get your job done for the moment. You may not get that terrific job or that promotion but you will have the satisfaction of a project well done; as Knuth said about writing "clean" TeX "You will have the satisfaction of having produced a nicely printer paper from a beautifully written computer file". If such rewards are not enough then you should not take up such projects. Unfortunately, if enough people think like this the IMSc computer system is doomed anyway.
And don't even get me started on the responsibility of managing a really large computer budget in such a context...