kernelthread.com

The Intel Lab Survival Guide

Department of Computer Science and Engineering
Indian Institute of Technology
Hauz Khas, New Delhi, India

It is a pleasure to bring to you this document, which shall hopefully be of use in understanding and using better the facilities offered in the Intel Laboratory of the Computer Science Department at IIT Delhi. It is expected that all users of the Lab, especially those who are new, would have read and understood the guidelines and suggestions offered in this document before doing anything substantial in the Lab. Apart from this, the guide is meant as a general reference to some important issues (technical or ethical) of concern to the Lab and its users. Please feel free to contact Dr Subhashis Banerjee (suban@cse.iitd.ernet.in) or Dr S Arun Kumar (sak@cse.iitd.ernet.in) if you wish to discuss further the semantics of this document. Any information about the Lab not found in this document may probably be found on the official homepage of the Department.

Wherever the word 'you' has been used in the document in the context of a problem in the Lab, it refers to those who cause (or are likely to cause) the problem under discussion. The comments while discussing problems are not directed at anyone in particular, but at the subset of people responsible for those problems. Further, the words 'he', 'him' or 'his' etc have been used everywhere for consistency but they must be interpreted to represent either sex.

How the Intel Lab happened ...

Sometime in August 1995, computing equipment donated by Intel Corp. arrived in the department. The room which was to house the Intel Lab had already been given a rebirth, complete with new flooring and a new ceiling, and trendy air-conditioners. The equipment was truly state-of-the-art at that time, as the following specs may reflect (they represent the different kinds of machines the lab contains):

Type CPU RAM HDD Audio CD-ROM Monitor Other
0 P5@166MHz 16M 1G SB-16 8X 15' Flat PS/2,SVGA1
1 PPro@166MHz 32M 2G SB-16 8X 17' Flat PS/2,SVGA1
2 2xP5@166MHz 32M 4G SB-16 8X 15' Flat PS/2,Server2
3 4xP5@166MHz 128M 4G SB-16 8X 15' Flat PS/2,Server2

1 The graphics adapters on these systems are from ATI, with the Mach64 chipset, and 4 MB of video memory onboard. Well, in case you're wondering why there's no AGP ... there was no AGP then!

2 These are server machines, that is, apart from more muscle, they have features which allow them to be kept on for prolonged periods of time, say, months or years (of course, operating system permitting!). Some of these high-end features include:

That was in 1995. Admittedly, the hardware is perfectly usable (on the high-end side) even today (1998). Especially, having good monitors is almost a necessity - a bright spot (!) in the otherwise dull lives of hackers who're glued to the glass screen for hours on end. The monitors have digital controls, and the larger ones have on-screen display of the controls. It is perfectly alright to occasionally fiddle with the controls (it's neat), and degauss them sometimes, but do not leave the monitors with a horrible color setting!

When the machines were shipped, all of them were pre-loaded (sic) with Microsoft Windows NT 3.51 (either the Workstation or the Server version of the OS, depending on the heftiness of the machine). Try as we would, we could not convince ourselves that the machines were really P5's and P6's (Windows NT apparently runs a high-end ix86 machine in a simulated 286 mode, or so the empirical evidence suggested): thus, before the formal advent of the Lab, Slackware Linux was installed on most of the machines, with a few retaining Windows NT resulting in a hybrid computing environment. Gradually however, as the lab needed more machines, Windows NT was phased out, and in its current state, it's totally a Linux based computing environment.

Next we shall see some of the remarkable features of the Lab.

What makes the Intel Lab cool ...

As stated earlier, the Intel Lab currently runs Linux, specifically, RedHat release 5.0 (whose codename happens to be "Hurricane", and in case you want to know more about RedHat, visit http://www.redhat.com). In the opinion of many, and perhaps rightly so, the Intel Lab is one of the most well setup and well managed laboratories of its kind, anywhere. Before we look at special systems features of the Lab, it must be mentioned that the success of the Lab, and its usually well-functional state is a result of the immense hard work put in by one of the keenest hackers in the CS faculty: Dr Subhashis Banerjeee (popularly known as "suban"). It is absolutely amazing how he has, to begin with, sustained a deep interest in the Lab over the years, and how he's managed to do so in spite of the maddening array of nuances and nuisances that just happen when one is dealing with an installation like this! Kudos. Suban has been helped in this noble cause (hey, no kidding, it is indeed a noble cause!) by many, including Dr S Arun Kumar, and a number of students. All this fits so well: Linux is a product of the hacker culture - a collective effort, and it requires hackers to take care of it. Simple! Time for a few reasons that make the Intel Lab cool ...

Multiprocessor Linux

Since we have systems with two and four processors, we must run an operating system that supports SMP (Symmetric Multi Processing, a processing model in which each processor runs an identical copy of the operating system, and these copies can talk to each other). It is important to note that SMP does not make all tasks that you run necessarily faster - only that you expect a better throughput. Moreover, since Linux lacks threads at the kernel level (this is arguable, for there is an experimental system call named clone that could almost pass as a form of kernel threading), you cannot assign threads to specific processors at will. The bottom-line is that it's a faster system all the same, and can take more load.

Remote Booting

For a long time, it was a real pain installing and managing so many Linux systems. You had to install the OS on each of them, configure each of them, and keep track of each of them, and more. Also, we were not really gaining a lot by having a local copy of the operating system on each machine because all the home directories (hereafter referred to as "homes") came from the servers via NFS, and so did many of the binaries (applications). Thus, it was decided to keep the entire operating system (well, not quite, except for the kernel) on the server, and let the (client) machines access everything via NFS. This means, only the kernel resides on the local disk, and upon booting, even the root file system is mounted from a NFS server. For one thing, now one has an almost diskless machine, so no problems with just switching it off if one is in a hurry (hey wait, there could be other users logged in!), but the greatest utility comes from the fact that in this situation, you need to manage only at the server. So, configuration changes or additions to the system can be made much faster, and in one place. I can already hear some people shaking their heads and saying "single-point-of-failure" ... Hey man, re-read the paragraph. Even before, if the server crashed etc, the client machines were typically useless. For the trivia buffs, we are using DHCP (Dynamic Host Configuration Protocol) for booting purposes. The dhcpd also doubles up as a BOOTP server.

Truly Diskless (EEPROM) Booting

With the success of the remote booting and all, we came up with an even better idea: Why keep the kernel on the local disk? It would be really neat if we managed to work up a boot ROM (residing on the network interface card) that would do the needful. So that was it. The idea was implemented and we now have a prototype setup wherein the machine does not have a hard disk, but contains a network card housing our boot ROM. Upon booting, it sends an ARP request to figure out its IP address, and then sends a BOOTP request. To cut a long story short, the machine (if configured alright at the server end) will display a menu of operating systems to boot - simply take your pick and enjoy! This way, a machine could be running Linux now, and MS-DOS a little later, and FreeBSD later still ... Till now, we've got Linux and MS-DOS going smoothly. FreeBSD is giving some trouble, but it'll hopefully work out. Yes, in theory you could run Windows 95 (maybe even NT) this way, using a Netware simulator of sorts, but there are no plans to do so yet, so no promises. Oh yes, this PROM booting stuff would be used when new machines are added to the Lab - you could add one, completely configured to run Linux or any of the other supported systems, in five minutes flat!

Heterogeneous Systems

The Intel Lab also provides NFS and NIS ("yellow pages") services to the systems in the adjacent Lab (the Minicomputer Lab). This means, various platforms (SPARC/SunOS, UltraSparc/Solaris, HP-PA/HP-UX and x86/Linux) work together in reasonable harmony. This also means that if you login from a HP workstation, you are running HP-UX, but using the same account as you would in the Intel Lab. The Lab also provides name service (DNS) to whosoever in the department requires it.

Power Games

There were quite a few power cuts this summer, and it was soon obvious that we should really be using software controlled shutdown features in the Lab, with help from the central UPS of course. So a simple client-server signal driven software was written to do the following: whenever there's a power outage, the UPS tells "desh" (a central server) via a serial cable of the impending doom. Now, "desh" tells the other servers and the clients to shut themselves down after a stipulated while. If the power is back before the deadline, "desh" tells the clients to forget about the shutdown and enjoy. Hey wait, before the system smashers among you plan to go on a shutdown spree in the lab, be it known that the clients will not accept shutdown orders or cancellations just like that. They verify a few things ... Finally, on systems that support automatic power-off at shutdown, the feature has been enabled (this is an APM (Advanced Power Management). APM is a BIOS extension, rather, a BIOS extra, at the time of this writing). With newer systems, it should even be possible to remotely turn the client machines on, using features like power-up on modem activity or power-up on LAN activity.

Local Network

The machines have fast Ethernet adapters, and there are a few hubs (both of the 10 and 100 Mbps kind), and sure, there's a router. Even with almost everything working courtesy the network, there's hardly any sluggishness or other network errors (don't believe us, look at the packet error statistics using the ifconfig command!). The computers are connected to the central hubs through UTP (untwisted pair) cables. You can use the hash command of your FTP client to display the bits (well, a few hundred bytes) as they go by, and get awed by the speed of the LAN!

Development Environment(s)

The primary function of the Lab is to provide a rich and salubrious development environment, where development is of the academic or technical nature. With this goal, a number of programming language facilities are installed, or can be installed upon request. Though this may seem like an overstatement, it is possible to make happy a person who's interested in (at least) the following programming languages: Ada, APL, Assembly (Intel x86, 8051, motorola 68k, MIPS), BASIC, BCPL, C, C++, Eiffel, Euler, FORTH, FORTRAN, Intercal, Java, Limbo, Logo, Modula-2, Modula-3, Oberon, Objective-C, PASCAL, Perl, Prolog, Python, REXX, Simula, Smalltalk, SML, Tcl ... (quite a mouthful, isn't it?). Then of course, there are almost all utilities you can dream of, from typesetting systems (like the TEX family) to GUI builders to parallel processing systems (PVM) to ... You name it, and if you really need it, it'll be there. Also, for the truly motivated, it may be possible to setup almost any (freely available) operating system, if his project or research work demands that (among the systems that have run in the Lab at some time or other include Windows NT, Windows 95, MS-DOS, OS/2, Linux, FreeBSD, NetBSD, 386BSD, GNU HURD, and Minix).

The Internet

With the advent of the Internet at IIT-D in a big way, the Intel Lab is also "permanently online" (believe it or not, it was not so previously!). Everyone having an account in the Lab automatically can receive email (the email address would be user@cse.iitd.ernet.in, where user is to be replaced by your username). Moreover, cse.iitd.ernet.in also serves as the official web server for the Lab, and also as the FTP server. The thing which has been attracting people from all over the place to the Intel Lab is the modem dial-up service it offers to a select few. This was started as an experiment sometime back, and is essentially like a dial-up account one would get at some ISP (Internet Service Provider), but what everyone must understand is this: firstly, there are only a few (just three!) modems, and already close to two dozen dial-up accounts. Clearly this is a problem. Secondly, the faculty must be given priority, because they are among the less likely guys to misuse such access, and more likely to be really needing such access. Thirdly, a similar facility, with a much larger number of modems, is being set-up at the CSC, so just be patient for some time and you shall have your dial-up account.

Laws of the Intel Lab

This is the most legal section of this document, and is mandatory. This is also the hardest part to write for the author, but it is absolutely needed. Therefore, it is imperative that you read this section carefully, and find out if you are in disagreement with any of the things stated here. If yes, then feel free to contact the author. The section discusses the most acute problems faced by the Lab, and for each problem, a solution is suggested (recommended):

Pronunciation of the word "Linux"

Surprised that this is a problem? Well, before discussing really serious problems, let us get over with a few lighter, but nonetheless important issues. The correct pronunciation of the word is 'lih-nucks' or 'lee-nucks', and certainly not 'lie-nucks', which everybody seems to call it. See, it's a matter of being perfect. Linus Torvalds, the guy who wrote the Linux kernel, has even recorded a file (found on the Net by the name "english.au") in which he tells the correct pronunciation of Linux. So, once you know, it should not be too hard to say it correctly. Come on, guys, would you really like it if someone deliberately spoke your name in a funny way? Please pronounce Linux properly, otherwise it hurts the ears. And please do not chant stereotypically: "It is a proper noun, so I'll speak it the way I want it." Accept your fault if you are wrong, and correct yourself.

Pronunciation of the word "TEX"

This word is also often mispronounced. Prof Donald E Knuth, the grand old man of computer science, who invented this wonderful typesetting system, also happens to be a biblical scholar. He is very particular about written English, and spoken English (just see any of his papers or his legendary The Art Of Computer Programming series books), and he directs that the word be spoken as, well, "TeX", where the X sounds like the Greek letter chi! This means, in the worst attempt, you can make it sound like "Tek", or "Teck", but not "Tex", as in textile! It sounds awful. Furthermore, Professor Knuth says that the way to pronounce "Knuth" is 'ka-nooth'.

Term, Terminal and Computers

People invariably call the computers in the Intel lab as "terminals", or worse still, "terms"! Have a heart, guys. For one thing, a terminal (even the smart one) is not so smart as the workstations in the Lab. In the olden days, where the mainframe computer chugged happily in some central place, serial lines went from that mainframe to people's offices and rooms, where at the terminal end of the wire was attached a relatively dumb thing with a screen and a keyboard, and some other hardware. That, is a terminal. Not only is calling the machines 'terms' incorrect, it insults the computers, as well as the people who have set them up. Let me explain how. That the computer is insulted if called a 'term' is obvious. It insults those who manage them because far lesser effort would be needed if they were to manage 'terms', and this way you are not appreciating their hard work! You know what, if you like 'terms' so much, I think the Lab should have a single 'terminal server', that is, one machine (say, "desh"), and lots of terminals. That way, everyone logs onto the server and do their job. Heh, now try running all your Netscapes and other stuff. You bet it'll take you ages to compile your "Hello, World!". Please call the machines by name (like desh, bhim, behag, ...), or call them PC's, or even 'machines', or 'workstations'.

That #%$@!!&^****#$% phone in the Lab

Isn't that what many of us feel when the Intel Lab telephone rings, and nobody picks it up. This problem may not be evident, but there have been altercations in the past where people have said nasty things to each other about not picking up the phone. In extreme cases, people have even kept the phone off-hook! Come on fellas, the phone is there as a tool which everybody needs (What if your loved one has had an accident and you must be contacted?). The rule should be that the person sitting nearest to the phone is supposed to pick it up, but then, the fellow will die of monotony. I'll forget about the phone and tell you a scientific fact: sitting in front of a computer for long hours, without getting up at all, could lead to serious physical trouble - have you heard of the term "typing injury"? No? Well, your nerves may go dead, you may be paralyzed, and you may even die. None of this is funny or made-up. Typing injury is a real problem in the western world, and it could happen here. What's worse, many doctors (especially in India) wouldn't even know about such problems, let alone their solution. Now, why do you think that stylish keyboard from Microsoft (yeah, the oddly shaped broken-looking one that costs more than 4000 bucks) was designed? That is an ergonomic keyboard, designed to minimize typing stresses. I'll tell you something more of interest, the Compaq computers in the Microsoft Lab (upstairs) came with a warning booklet each, that discussed fatal and non-fatal injuries due to computer stress! Convinced? If not, look for related information on the Net (Wallach, Dan S. (1995) "Typing Injury FAQ: General Information" would be a good starting point), and you may be surprised. So, getting back to the problem of picking up the phone, hey wait, it should not be a problem anymore! Each one of us should try to pick up the phone, simply because it gives us the opportunity to move our limbs a little from time to time - free of cost!

IRC: To Chat Or Not To Chat?

Sometime back, the guys in the CSC firewalled off the IRC ports. People found alternatives easily: use stuff like "Yahoo Chat", or use servers that allow for connection on weird port numbers, or simply login to some other computer (say a VSNL student account), and chat from there. For once, let it be known that a) IRC is not bad b) Chatting is not a sin and c) No, IRC is not banned. So what's the problem, you ask? Well, chatting is okay, agreed, but guys have this great ability to distort everything. They will not usually be chatting with their senior friends who have gone abroad. Nor would they be chatting on channels like '#Linux' or '#Unix' or '#Perl'. They would also not be chatting on '#philosophy'. They would typically be chatting on allegedly funky or fetish channels, and their fingers won't hurt from typing "Hi. Any girls want to chat?", or "Hey Natasha, How're you tonight?" or "Hey Sonya, where have you been?". Again, nobody's at fault if these Natasha's and Sonya's happen to be their girl-friends or fiancés or sisters. Nah, do our IRC heroes even know whether they actually are girls? Sorry fellas, there's no spare bandwidth for allowing people to chat on '#sex' or '#hottub' or similar downright nauseating stuff.

Pornography

This is another classic problem that refuses to go away, and trust me, won't. Then why discuss it here? Well ... You see, this thing is a bandwidth hog, and a disk space hog, and a mental hog (it makes your mind like sh*t, believe it or not). Most users are well aware of the moral issues surrounding pornography, and I'm sure it's no use if anyone bangs his head against a wall pleading morality and ethics. No, your morality and ethical standards are not the concern of the Lab, and interested people may even get themselves photographed as centerfolds somewhere for all we care. But it becomes the concern of the Lab when you use the computers of the Lab for downloading the garbage, and the disks of the Lab for storing it. Come to think of it, watching the same thing (more or less) again and again and again, and it isn't boring for the ones who watch? Okay, I already hear arguments like 'natural', 'at this age', 'bodily needs' and so on. The arguments seem okay, but if you must, then go get yourself a VSNL connection and watch all the pornography you like from your own computer. The Lab inherits the culture of India as a nation, and that culture prohibits blatant display of nudity and distorted sex (and sex with animals or concepts like bondage are certainly unnatural, abnormal and hey! are you out of your mind?). The Department, and probably the Institute, are going to take a very strong standpoint against this activity, and soon a policy may be formalized. It's probably going to be very strict. Anyway, howsoever important pornography may seem, it is still less important than earning your degree! Please restrain yourself.

Hacking? Sure.

Before you say "Look, who's talking" or something like that, let me explain. A hacker never calls himself a hacker. I admire hackers, and believe that they are the ones who make computing worth its name. Ken Thompson and Dennis Ritchie are hackers before anything else. Richard Stallman, the guy who started the GNU movement, and wrote stuff like Emacs, is a hacker. Linus Torvalds is a hacker. The list is endless (billg@microsoft.com may not be a hacker, but he is one of the smartest, at least the luckiest, people around). While it is very noble, and intellectually satisfying, and probably good for one's career to aspire and attempt to be a hacker, one must not be led astray! Do you even know what a hacker is? It is a grave problem facing computer science that most people tend to confuse between the terms hacker and cracker. The latter is someone whose primary aim is to break into systems - you know, steal passwords, crack passwords, become root on every damn system possible, and so on. Sounds familiar? Isn't that what you thought a hacker is? A hacker would "know" how to do all that, but he would not do it. That's it. If you're trying hard to crash the system, or bring the network to a halt, or make someone cry by deleting his files, or reading someone else's love-letters, man, you are sick. Doing all that will not get you anywhere. In spite of what you learn from the media, it is not a recommended way to make a living off hacking commercial installations and the like. If you must learn break-in techniques, try them on your own computer, or a LAN that belongs to you (I am tempted to say the CSC, but I am not saying it). The Intel Lab is a vital installation, with lots of important things happening there all the time (people's emails, for instance). It would harm everybody a lot if something happened to the lab (where else would you run your Netscape from?). Please do not crack in the lab.

If you have an account in the Lab, then your entire hostel effectively has one

People somehow don't seem to grow up. Not sharing your account with the entire hostel is a basic thing, right? On many a night, herds of scary guys throng the Lab, and sit many to a machine, ogling at the pornography, and leave in the wee hours of the morning, as if they've been to a free-for-all! If you don't have an account, then please do not come to the Lab for such purposes (see, that's the point. Nobody is saying that your friends and relatives are not welcome to the Lab, but if they come for doing stuff that is disallowed, then they are more unwelcome than you are.). Moreover, the Intel Lab has been extremely liberal in allowing people from other departments to work here, with or without an account. If you have a valid need, get an account. But simply coming to the Lab and using your friend's account because you think it is a nice place to hang out (rather than the CSC) hurts the genuine users of the Lab, and should be avoided.

Well, that's about it for now. The set of laws for the Intel Lab still seems pretty flexible to me. Of course, I have not mentioned the extremely obvious things like "Don't steal stuff from the lab" or "Don't break the furniture", etc. There is an interesting question that some of you may ask, or wish to ask: "What if we don't follow these laws? What if we do not stop watching pornography? What if we do not ..., etc?". Well, you wouldn't be shot, that's for sure. But do you know that the faculty and students (that means you too) are among the best in the world. If you indulge in the forbidden activities, you lose your mind's cutting edge (simply because you employ the energy elsewhere). So, the faculty and the "good" students (don't cry, you're good too), who have ways of finding out who did what, and when, will take appropriate action. Hey, no kidding, anyone who thinks he's smart enough has usually a smarter person overlooking his shoulders! None of us may be smart, but you make enough mistakes to let us on the trail. If people are disbelieving, the Lab may consider releasing a list of people with their "crimes": like, Person A visited the following dirty sites (yeah, yeah, delete your files or whatever right now, there are rock solid ways otherwise), Person B made the following pathetic attempts to crash the system (okay, crashed the system), and so on. That would be pointless mud-slinging, in my opinion, and should be avoided. Hoping that everyone would understand and cooperate.

Intel Lab Anecdotes

In a place like the Intel Lab, where people associate with people, and with computers (and computers associate with computers too), interesting things are bound to happen. The author could not resist putting in a few anecdotes that may interest the readers.

The 5.25' Floppy!

This happened in the summer of 1997. I was sitting in front of a computer, as usual, when one of my friends (heh, I am not going to name him whatever happens) came to me with anxiety copied all over him. "Hey pal, I would like to copy some stuff from the Lab to a floppy, so can I do it?", he asked. "Hey man, sure. No one's gonna stop you from copying files to a floppy.", I said. "Cool", and off he went. After ten minutes he comes back running to me, obviously in great distress. "Help me man, I think I have a problem. I cannot copy to the floppy like the way you told me, and what's more, the floppy won't come out of the drive!", he gasped. "Huh? What??", I was a bit taken aback, "What do you mean it won't come out, you've gotta push the eject button and that's it!". "No", said he, "I've pushed everything, but it won't come out. I can't even see it!". Now I was really curious. "Alright. Show me how you put it in." I walked over to the machine with him, and soon it dawned on me: the guy had a 5.25' diskette (all the machines in the Intel Lab have 3.5' drives), and in his imaginative efforts, had figured that since he couldn't put the floppy into the 3.5' slot (at least that part was smart), it had to be the little slit below where the CD-ROM drive was mounted - it looked the right size! And in doing so, the guy had pushed the diskette inside the cabinet! Well, I guess it's okay - everyone makes mistakes, but remember that he had just finished his third year as a CS undergrad!

The MultiCD-Floppy System

A long while after the 5.25' diskette incident, I had a chance to narrate it to a few juniors (a year junior to me). Halfway through the story, a few bystanders got interested and started paying attention to what I was saying (I don't remember whether they were the batch mates of my juniors, or still junior to them). Apparently they didn't get the whole of it and only understood that something was being said about CD-ROM's and Floppies. So I decided to pull a fast one (heck, they weren't going to believe me anyway, so why not!). I told them, pointing to the air-vent slits on the front of the cabinet, "See these slots, count them. 1.2.3.4..., okay? This is a high-end Multi-CD Floppy system that Intel has donated us. All these slots can take in compact discs or 5.25' floppies - there is automatic media detection built-in, so you could be using so many discs or floppies at one time. Now isn't that cool?". I expected sneers of disbelief, but lo and behold! There stand those guys, mouths half open, and drooling, "Wow man, that sure is one hell of a system!". A little later, one of them was telling a newcomer, "See that system? It is a Multi-CD Floppy ...".

Finger Print Enabled Keyboards

This happened as recently as in May 1998. I was working late night on my project, when one of the juniors looked troubled since he couldn't login. Anyway, he was probably trying to login to a friends account or something like that, and apparently the password had been changed. So he came to me, "Hey man I've got a problem. I can't login to this account while yesterday I could!". I was feeling a bit naughty so I told him, "Hmmm ... I'm sure you can't. That's a test machine you're trying - it's a project in collaboration with CMU wherein we put a thin membrane over the keyboard, and that way the system denies login to anyone whose fingerprints don't match. I mean, it's really cool, and seems like it's working!". "Well man, you sure keep doing interesting things in the Intel Lab, Nice. Could you please switch it off or something?"

Home went, Gone!

Sometime last autumn, I was working with Dr Banerjee in the Lab as we were going through yet another overhaul of the lab. It had been a tiresome day, and the drudgery of the whole thing was overpowering. We were testing out the automount daemon on "bhim", where the home directories of the faculty and the research students used to reside. Now this amd (automount daemon) thing had a "rm -rf /nfs" somewhere in its shutdown scripts, which simply removed any stale directories while the system was being shut down. Surely, /nfs was not supposed to have any live file systems mounted at that time. Soon we were required to reboot the system. Since rebooting the servers takes infinity, one of us suggested (and the other seconded) that instead of rebooting, lets just switch runlevels, that is, run init with a numeric argument (like "init 1" for single user, etc). Upon doing so, the shutdown script for amd was executed, with file systems not having been unmounted ... Sob. Dr Banerjee sat down to write an email to the users informing them of their lost homes, while I sat there doing a string search on the raw device for recoverable textual data ... It was not funny then!

People behind the scene

Over the years, ever since I got the "green light" to create the Lab, many guys have helped the Lab grow by devoting their time and energy. Foremost among them are Dr Subhashis Banerjee (suban@cse.iitd.ernet.in), Dr S Arun Kumar (sak@cse.iitd.ernet.in) and Rahul Garg (rahul@cse.iitd.ernet.in). Well, in a way almost everyone who has done some meaningful project work in the Lab has contributed to its betterment, because demonstrating how to optimally utilize the resources provided is a needed activity. The batch graduating in 1998 (popularly known as the "btech94" group) has so far been the biggest beneficiary of the Intel Lab, and it is hoped that future batches would benefit even more.

Want to Help?

It should be obvious that a large and complicated installation like this requires a lot of hard work just to make sure that things keep functioning okay. This does not mean that all the effort needed is of the mundane or boring nature - often the problems that shoot up demand superior technical skills and imaginative thinking, and solving such problems is satisfying from various points of view.

If some user feels that he has the expertise, or at least the motivation to help, he is certainly welcome, but(oh, there had to be a fly in the ointment!) please understand that taking care of the lab and implementing new facilities is not something that people do for vested interests. It is a unique form of social service (and indeed, things like this should be there as alternative to the mandatory NCC or NSS). So, volunteering to help simply means you are volunteering to be in a responsible position, and willing to undertake some duties which you shall impart as your abilities and time permit. There is always some pending work in the Lab (well, that's a way of life in general), and your help would be precious, no doubt. In fact, it would be a good idea if certain aspects of the system (say, the mail system, the NFS, the DHCP stuff, and so on) are assigned to different people, or groups of people, wherein each person is responsible for the well-being of his part. This kind of division of labor also scales well as more machines are added to the Lab.

Certainly, this way you also learn a lot about operating systems and how they run, and possibly their internals (if you do delve deeper). Please contact Dr Subhashis Banerjee (suban@cse.iitd.ernet.in) for offering help.

(Useless) Glossary

Links of Interest

http://www.redhat.com RedHat's Web Site
http://www.cdrom.com Walnut Creek's site (also, home of Slackware)
http://www.intel.com Intel's home
http://developer.intel.com Intel's site for developers
http://www.sunsite.unc.edu Site of interest for Linuxers
http://www.linuxhq.com Linux's headquarters
http://www.kernel.org For the latest in Linux kernels and lots more
http://www.microsoft.com Uh, eh?
http://www.cse.iitd.ernet.in Hey, our own site!
http://www.freebsd.org FreeBSD's home site
http://www.startelevision.com Monthly schedule of Star TV's various channels