I have been a Linux advocate for about ten years now. The first version of Linux I installed was Red Hat 3.0.3. I had used a UNIX-based system in graduate school, and I was somewhat familiar with how to get around (read: how to screw things up). I work at a school that is inundated with Microsoft products. After being there a year or so, I decided to branch out on my own and install Linux on my desktop machine. I have never looked back, and I have been using Linux as my desktop of choice ever since, at home and the office. I occasionally have booted into Windows if I wanted to play a game or read an occasional PowerPoint presentation, but that has been about it. Yes, I know about WINE and CrossOver, but a few games and programs inherently run better when run in a Windows environment. However, more often than not, there are options under Linux that are equally as good as, if not better, than those available under Windows. This is part of the main message I have been touting to our students, faculty and staff for the past few years.

As a result, I have come to be known on campus as a Linux advocate. If people have questions about Linux, they usually find their way to my office as often as they find themselves in the IT office. I also have been bugging our Director of Academic Computing about when the entire campus is going to switch over to Linux. We do have some Linux boxes buried deep in the recesses running our mail server, Blackboard and a few other applications, but we have nothing in the way of a visible Linux presence on campus. The Computer Science department recently converted the Computer Science lab from SGI boxes to Linux boxes, but that is about the extent of Linux on our campus. Is it possible that Linux will be used more widely on campus in the future? I am not sure. It probably will be a long, uphill battle, but one that luckily can be won. If you check out the May 2005 issue of LJ, you can see how a few people got the job done at the Mountainland Applied Technology College.

As you probably can tell, it has been my mission to make Linux more widely accepted on our campus. A colleague from the computer science department, Dr. Kenny Moorman, and I ran a Linux class in our May term a few years ago. May term is a short four-week semester that runs, coincidentally enough, during the month of May. I am running the class again this May. My goal is to try to teach the course in such a way that our students can integrate their PCs into our existing framework. I have to show them how to set up their desktop systems so they can surf, check e-mail, burn CDs, but I also need to teach them some basics on administration. Although I will be teaching them how to turn services on and off, I don't think it would be wise for them to use their boxes as DHCP servers, mail servers or anything of that ilk. I think it would be a nightmare for the campus administrator if students started to hand out IP addresses. At this point, the big question then becomes how I should set up the class?

While Dr. Moorman and I were trying to plan out the class the last time it was taught, we realized that few resources were available in terms of how to make a class like this one successful. A few years later, I still have not found many resources to help develop this class. So, I decided that now might be the time to write down what I think might make the class a success. To start, I have identified four main ideas that I want to address when constructing this course.

Let's address these issues one at a time.

Why is Linux important? I can sum it up for you in one word: freedom. If you have been following the Open Source movement, you know I am not talking about the price of the software when I say freedom. That simply happens to be a nice perk. No, the freedom I speak of is being able to use your computer and software in the manner that you wish. It is about not being tied down to any certain vendors who roll out "upgrades" that are incompatible with your current projects. I am talking freedom from viruses; freedom from monopolistic companies that use unfair business tactics to squash their competition; freedom that leads to imagination and innovation. This is the type of freedom to which open source can lead, and it is the type of freedom that should be important on college campuses.

It seems a natural fit that a class on open source should be available on a college campus. If there is to be a change in the open-source vs. closed-source discussion, then we need to teach the up-and-coming engineers and computer scientists about a world in which there are options. We need to teach them where Linux came from, why it has grown and where it is going. This class needs to talk about the differences and philosophies of the Cathedral and the Bazaar. By giving students the arguments for and against both sides of the story, they can make informed decisions and form educated opinions, instead of simply sticking with the status quo. If you can win their hearts, it is much easier to win their minds.

This has been a tough one. A plethora of books about Linux are available, but I have not found one that I felt would be a great one to use all by itself in a classroom setting. Naturally, the first book I thought about using was Running Linux (Welsh, et. al., O'Reilly), because it tells you how to do just about everything in Linux. However, it doesn't contain too much in terms of open-source and Linux history and philosophy. The last time I ran this course, we used Running Linux in conjunction with The Cathedral and the Bazaar (Raymond, O'Reilly). Again, this a great book on its own, but for students only beginning to get involved in Linux and open source, it can be a little over their heads. These book also is available online (see Resources), so you can pick and choose which parts might be applicable at the time, instead of ordering the entire book.

Last summer I ran a Linux camp for high school students. We used the book Linux for Non-Geeks (Grant, No Starch Press). This book is nice if you are going to work with Linux on your desktop--which was fine for the camp--but it does not contain much about system administration. Transylvania is a liberal arts school, so we tend to ask the question "Why?" a bunch. I want to be able to show the students what is going on from the boot process to shutdown and most everything in between. When a student boots Linux for the first time, a lot of information scrolls across the screen. I want to make sure that students know what it all means or at least most of it. Knowing why and how things are working makes it easier to troubleshoot when they aren't.

These boundaries led me to a couple of books. The first was How Linux Works (Ward, No Starch Press), and the second was Learning Red Hat Enterprise Linux and Fedora (McCarty, O'Reilly). Both books went into some detail on the boot process, from the boot loader, to init, to the login prompt. These were ideas I wanted my students to understand. Most books skip or haze over these concepts, but these two books take some time and depth to explain what was happening. I wound up going with How Linux Works.

This choice obviously varies according to the audience. Being a liberal artsy kind of guy, I wanted a book that is fairly non-technical yet has a lot of essential information. I feel that How Linux Works does that, but I am not knocking any of the other books at all. I have all of them, and I think they all are useful. But, when you are choosing a book for your class, you shouldn't simply pick your favorite. Make sure you pick a book that caters to the material you are going to teach, as well as the level of the class. If you have a room full of upper-class computer science majors, the more technical book might be a better choice. I am running an introductory course this time, though, so I wanted to find a book that was readable, yet covered the material I felt was important. I plan to use Learning Red Hat Enterprise Linux and Fedora as a reference, as well as a few others. Here are some of the other books I considered: Linux Cookbook (Sturtz, No Starch Press), Linux Cookbook (Schroder, O'Reilly), Red Hat Linux Fedora Linux 3 Bible (Negus, Wiley Press), Official Red Hat Linux Administrator's Guide (Red Hat Press) and RHCE Red Hat Certified Linux Study Guide (Jang, McGraw-Hill).

By the way, a book called Linux: The Textbook is available. With a name like that, you might think this is an obvious choice. Unfortunately, it did not cater to what I wanted to do in the course. It talks a good bit about applications and programming, but I am not going to touch on those topics too much. It also is a bit dated; there has not been an update since 2001.

Okay, we have four weeks for our class, five classes per week at two hours per class. In sum, we are looking at forty hours for the class, which is not much time. Here are the topics I am hoping to cover in some kind of approximate order of introduction:

Can I get all of this done in only 40 hours? Obviously these topics are not set in stone. A lot will depend on the speed of the class. If they can assimilate the knowledge in a reasonable amount of time, we should be able to hit most of these topics. If it goes a little slow, though, I will have to cut a few topics.

This is the part of any class that students love, tests! In an academic institution, you usually have to assign some type of grade to the students at the end of the term. What are reasonable methods that can be used to measure the proficiency of the students. Tests? Yes. Quizzes? Sure. Trouble shooting? You bet. Term paper? Maybe.

How can assessment be carried out so that it is not simply another hoop the student has to jump through to get his or her grade? Assessment itself should be another learning experience. So instead of the traditional tests where students get to fill in the blanks, be creative! After class one day, go in and "break" the students machines. That way, when they all get to class the next day, they won't be able to log on. Give them 30 minutes to fix the problem, and at the end of the time, give them some hints or explain the problem. Troubleshooting can be fun unless, of course, it is your own machine. When Dr. Moorman and I last ran the class, it was only a matter of days before a student had his machine cracked from the outside. Luckily, we had planned a demonstration on security that day, so it worked out perfectly.

I also have used the RHCE book mentioned earlier to come up with multiple-choice questions the students can access on-line. This allows them to quiz themselves to see if they are understanding the material. Although you may not want to do this for an official quiz and/or test score, it is a fun exercise the students can do at their own pace and time.

Testing itself probably will come in two forms, written and hands-on. For the writing portion, I can ask the students to write out certain commands they might use to complete a certain task. In the past, we allowed the students to use their workstations to test the commands before they gave their final answer. We then asked the students to answer the questions by memory. In other words, we did not allow the use of man pages, the Internet, their notes or their neighbor. Although this is not how it will be in the real world, I feel it makes for a better system administrator. After all, would you rather have a sys admin who can fix a problem off the top of her head or one who has to take time to look on the Internet to see is someone else has had a similar problem.

The second portion of testing will be the hands-on method of lab practicums. Students will have to set up their machines to a particular state. The state could be setting up new users, permissions, services or many other types of problems. I should be able to log on to their machines and check to see if they have set up their system successfully. I think the students will enjoy this portion of the test much more than the written portion, because there is a certain satisfaction in knowing you have fixed a problem. I know I thoroughly enjoyed this aspect when I became an RHCT. The scary part for the students will be not having access to any resources for this part of their test. Again, they will have to rely solely on themselves to see if they can understand and solve a broken system. Although this may seem harsh, it is my hope that doing this will motivate students to dive deeper into the material. Besides, this is the process they will have to go through if they ever want to become certified.

I can be more lenient on the homework portion. I will give certain assignments and problems for the students to complete before the next class period. Here, they will be allowed to use their books, notes or whatever they want to help them solve a problem. These exercises hopefully will cement the basic knowledge required to pass the tests, if nothing else.

The final method of assessment could be the most unpopular--a term paper. This assignment may not be your cup of tea, so some people might omit this aspect. However, I feel it is important for the students to be able to write as well as to solve problems. If you are at a technical college, you might not think this is important, but being able to express oneself well in written words is a part of our mission as a liberal arts school. For the paper, you could ask the students to write on many different topics. For instance, you could ask them to develop a plan for a small liberal arts college to change their computing structure from closed source to open source. You could discuss the history and importance of Linux and open source. There are many interesting topics for students to choose. The last time we ran this class, we asked our students to talk about the decision Netscape made to open the source code for its browser.

Okay class, time is up. I hope you enjoyed our discussion for the day. If you want to follow the class, feel free to check out our Web site. You can use the username guest1 and the guest password is guest42. The class begins April 27th, so make sure you get there by the time the bell rings at 9:00am. If you have any questions or comments, feel free to raise your hand in class or to send me an e-mail at mlevan@transy.edu.

The Cathedral and the Bazaar

"Putting Linux in Classrooms around the World"

"Linux in the Classroom: an Experience with Linux and Open-Source Software in an Educational Environment"