Byfield, B. (2007). Expert shares secrets to saving thousands with K12LTSP. <http://www.linux.com/feature/59614>
This is a short article, but one that clarifies some things I have been reading about regarding the K12LTSP. It also raises a number of issues I have not read elsewhere.
Robert Arkiletian is a contributor to the K12 Linux Terminal Server Project (K12LTSP). The K12LTSP is a Linux distribution that allows one standard desktop computer to run a number of other computers as thin clients. The clients can be older computers, which don’t even need a functioning hard drive. Depending on the specifications of the computer which acts as a server, 5-30 or more clients can run off of a single computer. This setup is familiar to system administrators, but the drive of the K12LTSP is to make this setup simple enough for non-technical teachers to administer.
The K12LTSP site lists a set of minimum requirements for the computer acting as a server. With three years’ experience administering a lab with 30 clients, Arkiletian recommends a more powerful set of capabilities:
- A dual processor so that runaway processes can be stopped immediately and dealt with at a later time. This allows the classroom teacher to maintain a functioning network without significantly interrupting the class.
- Two hard drives which “mirror each other in a RAID 1 array” (p. 1).
- 100MB of RAM per client. This number is interesting, because it is a familiar specification to most teachers. This suggests that a standard teacher’s desktop computer with 1GB of RAM might be capable of running 10 clients.
- Two ethernet cards. One creates a private network for the clients, and one connects to the rest of the network.
For client machines, specifications are significantly lower. However, some features can make the client more responsive to student needs.
- Processor speed is unimportant. Arkletian says that anything less than 100Mhz may cause problems, but a computer would have to be around ten years old to have a processor that slow now.
- A 4MB video card should be sufficient.
- 128MB of RAM is recommended, to prevent over-reliance on swapping with the server’s hard drive.
- A light window manager such as IceWM rather than GNOME or KDE can also allow more efficient use of client and server resources.
- An ethernet card is needed to connect to the server.
- A USB port allows students to use memory sticks, and presumably external devices like digital cameras.
One of the primary goals of the K12LTSP is to make system administration responsive to teachers’ needs. These include technical needs such as simplicity and reliability, and pedagogical needs such as the ability to easily monitor students’ work on the computers. The Fl_TeacherTool supports teachers in these regards.
- Teachers can see which terminals are in use at any time.
- Teachers can see which programs are running on each client.
- Teachers can click a button to see the desktop of any client on their own screen. This is a tremendous help in watching for appropriate use by students.
- At any time, the teacher can take control of any student’s desktop.
- Teachers can send files to students.
- Teachers can send active copies of whatever the teacher is working on to students’ desktops, thus acting as individual whiteboards.
Arkiletian sees a number of advantages to using the K12LTSP setup with students.
- Maintenance is low.
- Software only needs to be installed on the server computer.
- Problematic clients can be swapped out easily.
- Computers that are seven or eight years old can be used as clients long after their standalone service has ended.
- A computer lab can cost one tenth what it would if workstations were used. This money can be reinvested in smaller workstation-style labs for specific purposes.
The only limitation Arkiletian mentions is that the clients are limited to “standard computing” (p. 3). Animation requires too much memory swapping for this kind of setup.
Evaluation and Educational Relevance
The use of OS-based systems in education is hardly mentioned in educational literature. A search for the keyword “Linux” in the ERIC database brings up just 22 results, and most of these articles only talk about the possibilities of using OS applications in schools. There is very little in the way of describing actual implementations, and even less about evaluating the impact of these implementations. This motivates me to write up my experience with OS in education. It also makes me want to publish these articles in non-technical journals and magazines. The teachers we want to reach most, educators who are not experts, do not read journals like Computers & Education, Tech & Learning, and Newsweek. They read things like The Reading Teacher and Journal of Social Studies Research. Writing for non-technical audiences about the pedagogical benefits of OS implementations is sorely needed.
This article points to the need for visionary technology leaders in school districts. I am reminded of the band aid story. A student in a first grade classroom went up to the teacher and said, “I just cut my finger! Can I have a band-aid?” As the teacher gave the student a colorful band-aid, another student went up to the teacher and said, “If he gets a band-aid, I want one too!” All too often, this is the conception of fairness that students have. When it comes to technology, many educators feel the same way. If one teacher has a new powerful computer, other teachers feel they should have access to the same technology. People feel this way regardless of whether they have an actual pedagogical need for the more powerful computer. A better conception of fairness is one in which everyone gets what they need, when they need it. We need technology leaders who can apply this kind of thinking to district-wide technology decisions. For example, we might consider putting thin clients in a language-arts based classroom, and powerful workstations in a computer science lab. The money saved from putting only the necessary resources in each area can be used to hire a computer science teacher with the expertise to teach students to use the full capabilities of the more powerful workstations. This question of whether we should make teaching programming a priority is another conversation altogether. This requires the leadership of technology experts in the district who can accurately match resources to actual needs, and explain these distribution decisions in a friendly manner to non-expert teachers.
The Fl_TeacherTool makes me think of one specific application in my old school. We had a number of smaller rooms that student groups often used for project work. These groups were usually not supervised directly. We hesitated to put computers in these rooms because of the difficulty of monitoring their use. With the Fl_TeacherTool, I wonder if the server could be placed in a classroom and the clients in the smaller work rooms. The work rooms would become more productive spaces, and the monitoring would cease to be an issue.