In 2002 the Foundation started to actively promote the use open source software as a computer lab solution for schools. The Foundation funded several projects to establish open source based computer labs in schools, as well as an internally initiating a pilot to prove the effectiveness of open source software as a school computing solution. The Foundation also initiated a project to facilitate the involvement of volunteers in refurbishing computers and establishing open source learning centres.

Based on the success of the pilot and volunteer project, the Foundation extended the pilot to establish a further 80 open source learning centres in the Western Cape. This goal was reached in November 2004.

Both primary and secondary schools are being targeted. In order to maximise the impact of the program, schools are selected in clusters. Through clustering, schools are able to plan the use of the centres together, and they can share resources and community support. The Shuttleworth Foundation believes that clustering is the best method of ensuring that schools remain self-sufficient in terms of support in the future. This is supported by the Computers in Schools survey of 2000, which states (my emphasis):

Within a cluster, schools are selected based on criteria set by the Foundation. At a very minimum, these criteria will include the availability of a secure computing environment, guaranteed commitment of the school (including governing body) to the project, as well as proof of comprehensive plans to introduce the Shuttleworth tuXlab into school activities. Additional criteria may be set for each cluster.

Within each school, a 20 to 24 seat tuXlab is established. Refurbished hardware is used for the workstation computers, and new hardware purchased for the server. The Shuttleworth tuXlabs are implemented using a thin-client paradigm, with GNU/Linux used as the primary operating system and open source applications wherever possible.

The Shuttleworth Foundation requires that staff and students participate fully in the installation process. In accordance with its mandate, the Foundation adopts a skills transfer methodology during installation --- all participants will receive the necessary skills to establish and maintain further Shuttleworth tuXlabs. The Foundation will also facilitate the involvement of external volunteers, such as students, throughout the entire process.

Throughout the course of this program, the Foundation intends to partner with as many organisations as possible. On its own, the Foundation does not have the resources and infrastructure to take the tuXlab program national. Through partnership we hope to maximise the impact of the program, develop skills, reduce costs, grow resources, and hopefully facilitate the adoption of the program within other contexts.

In 2005, hundreds of tuXlabs are being installed throughout South Africa in partnership with local organisations and user groups. The project is also being launched in Namibia, and reports of roll-outs overseas (such as a large-scale project in Azerbijan! (XXX: link)) have also come in.

A tuXlab consists of computers, a lot of cables, a room to put them in, and software to make the computers do something useful.

Most of the computers are client workstations. They're the computers that are used every day by the lab users. One or two computers, however, are servers. They are locked away and normally only accessed via the network. The classroom server is by far the most powerful computer in the lab, and does all the work.

All the equipment in a tuXlab is networked. For this, all the computers need a network card, which is connected to a network switch using a length of cable.

Lastly, the computers need software to run. The software falls roughly into two categories: the operating system software, and applications. All the computers in the lab run the Linux operating system (the workstations fetch their copy from the server upon startup). This enables the server to display the applications it is running for all the workstations on the screens of the workstations themselves, using the X Windows system, the graphical windowing environment used by Linux.

The applications installed in a tuXlab are focussed on an educational environment, and include software that is essential for general computer literacy such as word processors, spreadsheet and web browsers, as well as educational software that allow learners to practice skills (e.g. typing, arithmetic) and knowledge (e.g. spelling, geography). See Chapter 11, Open source Educational Software for some examples. Besides these, a tuXlab contains a great variety of programming languages, tools, texts and examples that can be used to teach programming and to study how existing programs work, all the way from first principles to systems architecture. Nothing is proprietary: you may examine the source code of every component in the system.

In the following sections, we'll look much more closely at how these parts fit together.

In the earliest days of computers, a whole machine was built to do only one thing, for example numerical integration. There was no clean distinction between hardware and software, as aspects of the program might be reflected by physical switches and jumpers set on the machine itself.

As computers became more general, the same computer could be programmed to do many different things. All these programs, however, would still have to deal with the hardware aspects of the machine, writing to the printer, reading from the magnetic drum memory, and so on. Since these jobs needed to be done over and over and over again, the bits of code that dealt with them could be shared among all the programs that run on that computer. This shared code, the code that handles the basic tasks any program needs in order to run, was the beginning of operating systems.

Today's operating systems are complex, sophisticated systems, that can schedule many different programs to run at once, and that provide such a comprehensive range of services that many programs can be compiled to run on many different operating systems, regardless of the variations in the underlying hardware.

An operating system (OS for short) is the most basic layer of the software, and if your computer is switched on, the operating system kernel is the one program that will always be executing. It provides a framework for all the subsystems that make up the computer.

Imagine, for a moment, that a computer is like a ship. The physical hardware is the steel or wooden hull that floats. The operating system is like the officers of a ship, and its subsystems are like the captain, the first mate, the engineer, the cook, and so on. They see to it that the engine is running and that the ship is on an even keel.

All the other software that runs on the computer are like the rest of the crew and the passengers. The operating system manages the resources of the computer like the captain manages the crew of the ship. He maintains discipline, sees to it that the crew don't fall all over one another, do things in an orderly fashion, and keep everything shipshape.

If a program does something wrong (such as writing to memory that the operating system is using for something else. In the ship example, this is like making a hole in the hull!), the operating lets the offending program know, shutting it down completely if necessary (it gets thrown in the brig).

Which operating system is best?

Our consumer culture puts huge stress on having "the best". Usually this means wearing some fashionable brand of jeans, or driving a fancy car. Obviously this is a very superficial measurement, and we have to look deeper when trying to compare operating systems.

It's important to remember that computer science is relatively young. I don't think that any operating system has been in continuous use for longer than a single human lifespan. At the dawn of the computer age, there was a great explosion of diversity, like in the Cambrian period in prehistory, when different designs and architectures proliferated. This was succeed by a period of consolidation, with the result that today, even though the details "under the hood" may be very different, a great deal of consensus has emerged about the types of services an operating system should provide. ^[2]

At the moment, the operating systems you're likely to encounter on desktops are to some extent interchangable. Linux, Macintosh OS X and Windows all implement POSIX to some degree. Software that was written to make use portable use of the operating system's services may be compiled to run on all of them.

These operating systems can all do the same jobs, and you may develop skills that apply to other operating systems on any of them. Therefor there is no quick, objective answer to the question as which one is "best". You have to forget that one, and ask a better question: "Which operating system is best for me?"

Well, of course that depends on who you are and what you need it for. If you're interested in tuXlabs then you probably don't have lots and lots of money, and you're probably interested in learning: learning about computers, yes, but also education in general. When answering this question for yourself, here are two things to keep in mind:

• How does it impact the world I live in? . The software you choose can influence many aspects of your life. For example, you need to ask: "Who controls the technology?" If you teach yourself to use a product that belongs to some company, you'd better hope that they don't go out of business.

  Governments are also starting to use computers for tasks such as counting votes. During the previous two elections in America, there was great controversy about the results turned in by Diebold's vote counting machines. Diebold controls the software, and expect voters to take the trustworthiness of their software on faith. For matters such as this, democracies in the digital age must use open source software.

• Current technical merit is only one measure . Even if something is imperfect now, if you can get at it, you can make it better and learn in the process.

  For example, the open source program called the GIMP (the GNU Image Manipulation Program) goes head-to-head with Adobe Photoshop. At the moment, Photoshop still comes out pretty far ahead, but it has been under continuous development for a decade or more. Does this mean that aspiring designers should turn their back on the GIMP? If they do, they lose the things that the GIMP already gives them which Photoshop doesn't, such as the ability to write extensions in a variety of high-level programming languages, and to build on the contributions of the entire community of users.

In the following text, you'll read about a number of different distributions, e.g. Debian, K12LTSP and RedHat Fedora. This is a term that emerged from the open source way of gathering and organising software for sharing: a coherent, well-maintained, up-to-date collection of software (especially on the scale of an operating system) is called a distribution.

As you saw above, Linux is the source code of an operating system being written by hundreds of volunteers who pursue their own goals and interests. It uses tools from other projects, such as the GNU project, and is used on a very wide range of machines, for widely varying goals. From this, you may imagine that it is a hugely complex system, and you'd be right. Assembling just the subset of code that is relevant to you, and compiling it to run optimally on the hardware that you happen to have, is a major undertaking requiring deep skill and experience. Keeping your system up to date with changes in disparate parts of the whole is a major undertaking in itself.

In order to have a manageable system, well-understood and reasonably easy to customise and keep up to date, groups of users began to band together to collect just the right combinations of software, and to coordinate this job. Some people built their business around the process of gathering, labelling, testing, documenting and marketing free software, for example RedHat and SuSE. Some communities assemble distributions that conform to their ideals; Debian, for example, operates in accordance with a Social Contract which maintains the same principles of good husbandry and mutual cooperation that prompted Richard Stallman to found the Free Software Foundation.

tuXlabs and Wizzy actually make use of no less than four related distributions.

In part, the reasons for the variation are historical: the Wizzy solution was developed independently of the tuXlab project.

The idea of free software, with source code that could be shared by everyone, started in academia. In America, it was Richard Stallman at MIT, the Massachusetts Institute of Technology, who started the ball rolling, but the person who accidentally turned it into an avalanche was Linus Torvalds, a Finnish university student.

Richard Stallman

At MIT, Stallman had been part of a community of programmers that came to an end when their work was commercialized and access to the source code was restricted. To Stallman, this felt like having the air he needed to breathe cut off. Because Stallman believed strongly that programmers should be able to help one another by sharing their source code, he set out to write a complete free operating system. He began systematically, though, first setting out to write all the supporting tools that an operating system requires to work. This is a mammoth task, and in fact they're still busy refining better and better tools.

Linus Torvalds, in Helsinki, wasn't burdened with any such a sense of responsibility or thoroughness. He just wanted to make the most of the PC he had at home, which had an Intel 80386 CPU. The 80386 contained a memory management unit, which was big news at the time. The operating systems he had at his disposal didn't take advantage of this and he dearly wanted to use it, and so he started to write his own operating system. To do this, he used many of the tools created by the GNU project. After months and months of steady work, he released a very early version of the kernel that became known as Linux to the internet. To his surprise, other people started sending him fixes and improvements for his kernel, and eventually he found himself managing and coordinating a global community of programmers. All of them were using and improving Linux, and building on each others' work.

Linus Torvalds

In a sense, the free software community that Stallman had known at MIT had risen anew, on a global scale. Their rallying point was a system made up of the Linux kernel, and the GNU development environment.

The first one to think of a name for the kind of software that could be shared without restrictions on how you could use it was Richard Stallman. He called it Free Software, because he wanted to emphasize the freedoms that he valued highly enough to dedicate his life to writing a free operating system.

The Free Software Foundation supports the freedoms of speech, press, and association on the Internet, the right to use encryption software for private communication, and the right to write software unimpeded by private monopolies. Stallman formulated a license, the GNU Public License, which uses the mechanism of copyright to protect these freedoms, and to add the responsibility of passing them on to other users of the software.

When Linux started to be noticed by business, and when it began to be marketed as a serious IT platform, this emphasis on freedom made some people uncomfortable. The argument was that people don't run their businesses in order to advance someone's freedom of speech --- they run their business to make money!

Instead of emphasizing the freedom aspects so dear to Stallman's heart, more emphasis was placed on the fact that everyone had access to the source code of Linux. The programmer and writer Eric Raymond wrote some influential papers in which he argued that the Linux style of community development produced better software than the proprietary alternative. The choice for open source software could be made on a purely pragmatic basis. The critical factor, in his view, was the availability of the source code, and therefor he coined the term Open Source to describe this kind of software.

The contrast may be summed up in the sentence: "Open source is a development methodology; free software is a social movement." FSF

Neither one of these approaches encompass the whole truth, they simply emphasize different aspects of a rich sphere of human endeavour. The pragmatic approach taken by tuXlabs in the selection of software for inclusion leans more toward the open source side of the debate, but the Shuttleworth Foundation's goal of "social innovation" is in line with the FSF philosophy.

Various other streams exists. The BSD license of the FreeBSD project, for example, does not specify the responsibilities of the GPL, and allows code under the BSD license to be incorporated into proprietary software. For many years, for example, the Windows TCP/IP stack (see the section called “TCP/IP”) was based on BSD code right up to the period of Windows 2000 --- perhaps it still is?

As the open source culture matured, the principles of mutual education, self-sufficiency and sharing were applied to many things besides software. One of the first projects to bring the wider world of culture into the open source community was Project Gutenberg, a project to make available as many as possible public domain and freely redistributable texts at no cost. Due to recent changes in American legislation (which enables copyright holders to keep works out of the public domain forever), this essentially means works created before 1923. At the moment, there are more than 13,000 books available for download.

Another open source project is the Wikipedia, an online encyclopedia read and edited entirely by volunteers. The English edition, started in 2001, already has almost half a million articles. If your tuXlab includes a Wizzy internet server, the entire Wikipedia can be made available on the tuXlab network.

A law professor at XXX, Larry Lessig, noticed the need to apply the open source principles of collaboration and sharing in other domains besides software, and set about crafting a flexible set of licenses that could be used to bring music, books, movies and educational material into the open source world. Since his project has as a goal the re-establishment of a commons, a area for the use of the community as a whole, to replace the endangered public domain, these licenses are called the Creative Commons licenses.

Free Software can be a valuable resource in education, and can also promote the values of the GNU project, namely freedom and cooperation, in schools.

There are general reasons why all computer users should insist on free software. ^[3] It gives users the freedom to control their own computers --- with proprietary software, the computer does what the software owner wants it to do, not what you want it to do. Free software also gives users the freedom to cooperate with each other, to lead an upright life. These reasons apply to schools as they do to everyone.

But there are special reasons that apply to schools.

Proprietary software rejects their thirst for knowledge: it says, "The knowledge you want is a secret --- learning is forbidden!" Free software encourages everyone to learn. The free software community rejects the "priesthood of technology", which keeps the general public in ignorance of how technology works; we encourage students of any age and situation to read the source code and learn as much as they want to know. Schools that use free software will enable gifted programming students to advance.

Schools will be selected in clusters. Through clustering, schools are able to jointly plan and prepare for their tuXlabs, and can share resources and community support. Clustering is a method of ensuring that schools remain self-sufficient in the future.

A cluster consists of at least three schools. Each cluster will form a committee consisting of at least two representatives from each cluster school. These cluster committees should meet on a regular basis (at least quarterly) to discuss and share ideas, experiences and methodologies. Cluster communities should be in a position to setup a future Shuttleworth tuXlab with their collaborative knowledge and experience.

Open source communities are generally formed by developers, administrators and users that freely provide their expertise and time to the projects that interest them or that further their way of making a living. Contributing to an open source project does not just take the form of submitting source code, but rather any activity which benefits the community or open source in general. Establishing tuXlabs is similar in many respects to an open source software project --- rather than developing software, the Shuttleworth Foundation is installing labs, but still using the concept of open source volunteerism to facilitate this process. Establishing a volunteer group is a daunting task; however, with many possible methods to solicit volunteers, it is possible.

While the above may be used as a guide, the diameter and the finish of the bars can be further determined by the school authorities and the project manager, as is deemed necessary according to the known risk in the area.

Galvanized metal mesh should be fitted on all outside windows.

The sides of the frame should be closed. For fasteners, use tamperproof coach screws with turn-off heads.

A coach screw. Note the double head. The top part turns off, making the screw very hard to remove once it's in.

Wherever possible, the room identified for the lab should have a concrete floor above it. This means that in schools with two levels, it is preferable to select a room on the lower level. Where this is not possible and the ceiling is of hardboard or something equally flimsy, the ceiling should be covered with wire mesh or razor wire. In order to notice tampering, it's probably best for the wire to be beneath the ceiling.

Since the gate is the key security feature, it should be made of steel of substantial thickness. In some cases, an internal security cage with steel gate or double steel gates are advised, depending on finances and risks. Methods of securing and fitment of locks should be strategic to make breaking in as difficult as possible.

Specifications:

A security alarm system with at least two room sensors is required. If the lab has a ceiling, a sensor in the ceiling is advised. The alarm must be monitored around the clock, with armed response in the event of an alarm event.

The number and location of sensors should be determined with input from security companies.

The design and length of desktops in most cases is determined by the number of computers and learners, and the size of the room. If there is room, it's advisable to install desktops for future expansion of computer network at once, depending on the finances available.

New desktops should be postform, minimum 28mm thick or similar stock, with a melamine/formica/varnished finish. They must be 900mm deep, to accommodate the keyboard, screen, and cabling without crowding and with proper ventilation. Depending on the chair height and the age of the learners, the top of the desktops should be 700 to 720mm from the floor. It is important for the desks to be at an appropriate height for the learners who will be using the lab, as an awkward posture can impair concentration.

For every workstation, the desktops have a hole that collects and passes through the network and power cables to the trunking under the desks.

Desktops should be mounted on 40mm x 40mm x 5mm angle iron brackets. They should only have legs if brackets are not a option, as legs tend to get in the way of learners sharing workstations. Each bracket must be a minimum of 750mm x 650mm. The brackets must be no less than 1000mm apart and each must be fixed with at two heavy duty rawlbolts, one of which must be as high up as possible.

Where appropriate, provision should be made for ducting along which to run wiring and network cabling underneath the work surfaces, with holes in the desktops to allow the cables to reach the computers and peripherals.

Where possible, the length of the desk should be chosen to allow 1200mm of space for each computer.

If it's at all possible, put the server in a separate room, where it's out of sight and locked away permanently. All that is necessary is for a network flylead to reach from the server to the network switch. Otherwise, a well ventilated, lockable cabinet should be built.

This cabinet should be at least 900mm square inside, as it will house the classroom server, another server acting as internet gateway, and a modem. The cabinet will be set away from the wall to allow for ventilation, since a pair of servers will generate a good deal of heat.

Notes:

It's important that all electrical work be done by a qualified technician, who should issue a certificate of compliance to the school upon completion of the work.

There must be enough 15 amp 3-point plugs to accommodate each computer on a separate plug, and in addition, there should be enough plugs for peripherals as well. A good rule of thumb is to have a double plug for each computer point. For safety reasons, electrical wiring must be in conduit piping below the work surfaces, but Surfix-type cable and wall mounted sockets are also acceptable and should be installed below desktops.

This is a cross section of a Surfix cable.

To avoid power spikes and dips, which are extremely damaging to workstations, the computer lab must be on its own electrical circuit. The circuit must be broken into segments, each adequate to accommodate the computers and peripherals on that segment. Air conditioners, or other equipment that use a lot of electricity, must not share the circuit with the computers.

Don't use extension leads or multi-plugs. They can cause shorts and power spikes that may damage your equipment.

Electrical wires to an island worktop in the middle of the room must preferably be under the floor or must have suitable ducting. Otherwise, it is a perfect certainty that someone will fall over the wires, breaking their neck and bringing all the workstations within reach crashing to the floor.

The subdistribution board should be fitted with earth leakage protection, if required. A maximum of five wall plug sockets should be connected to one circuit, and each circuit should be protected by a 20 amp circuit breaker.

Where required, a 4U cabinet will be installed to house a minimum of two 24-port switches ^[7], leaving some space for expansion. Server equipment is a bit like bricks: they're all the same basic shape. One switch is 1U (or unit) big, so a 4U cabinet has room for four of them. Computer suppliers will know what you're talking about.

The placing of the switch cabinet should determined by the lab layout, and to minimize the required cable lengths, it should be placed in a central position. If installed in the lab, the cabinet should be 1000mm above or below desktops.

Cabinet to house switches

Network cabling must run in 40mm x 40mm square trunking. If financial considerations require that network cabling share the trunking of the electrical cabling, it is imperative for the electricity to be switched off at the subdistribution board whenever the trunking is opened during network troubleshooting.

Trunking running under the desks.

Ensure that 10mm holes are made in trunking for the cable ends to reach their workstations. Allow at least 500mm of free network cable per computer, and loop and tie the extra length neatly. Network cables that are too short can be just as irritating as socks that are two sizes too small, and moreover lead to high blood pressure and increased risk of cardiac arrest. Cabling to an island desktop must preferably be under the floor or must have suitable ducting that will ensure the safety of pupils who have to walk over these cables.

If a user reconfigures a workstation in a fat client computer lab, all the other users of that workstation will have to cope with these changes. This means that if someone inadvertently sets the workstation to use black type on a black background, for example, then no-one will be able to see what's going on.

In contrast, in a thin client lab, every user has their own files, their own email, and their own desktop environment that they can change to their liking without influencing anyone else, all stored on the classroom server. A configuration slipup like the above will inconvenience only themselves. ^[8]

Most of the equipment in a computer lab are workstations for learners to use. There may be one or two printers, network switches and a server, but they are far outnumbered by between 20 and 40 client workstations.

In a tuXlab, these can all be really old, used, previous-generation computers. This is because the demands on these machines is so slight that almost anything will do. All those stacks of old computers everywhere that no one knows what to do with are suddenly useful, and saving schools vast amounts of cash that they would normally have to outlay on relatively new equipment so they can run contemporary software.

The thin client paradigm also means that requirements for uniformity among terminals is relaxed. As long as they conform to a couple of basic requirements (network boot, SVGA graphics card, enough RAM) it doesn't matter if they have idiosyncratic hardware. Only the server configuration needs to be maintained. Heterogenous hardware doesn't make life difficult for the admin.

The thin-client network in the lab ensures that each terminal, no matter what its own computing characteristics, behaves with all the speed and capability of the server, so each user has an experience of top quality, smooth, fast computing. Unfortunately, this does mean that if some of your client workstations are powerful, modern machines, they may not be fully utilised in a default tuXlab configuration, as they will still be letting the server do all the work.

In a tuXlab, the most accessible hardware is also the easiest to replace and the hardest to use outside the lab. A tuXlab client workstation on its own, without the classroom server, is more or less useless. It's too bulky for a doorstop, and it can't run modern software. It doesn't even have a hard drive. ^[9]

As the terminals only serve to display a session from the classroom server, it doesn't matter which one you use. If one breaks while you've using it, you can move to the next one, log on, and pick up where you left off. If someone is using the workstation where you were working, go to another one and log in there to regain access to your desktop.

All the data in a tuXlab resides on the disk array of the classroom server. Instead of having to backup 20 or 40 individual hard drives, it's possible to backup only one, and still get a complete backup of everyone's data.

Locally, FreeCom supplies tested refurbished computers. Because of the high volume of hardware required by the large number of tuXlabs installed, the Shuttleworth Foundation has procured the client workstations from international distributors such as Computer Aid. Other workstations have been donated by private industry.

A tuXlab classroom server is based on the K12LTSP distribution, with some configuration changes and additional software packages.

K12LTSP is based on RedHat Fedora Linux and the work of the LTSP. It's easy to install and configure. It's distributed under the GNU General Public License. That means it's free and it's based on Open Source software.

This is quite a mouthful, so I'll unpack the terms one by one.

The K12LTSP distribution tries to make it as easy as possible for you. It is a regular Fedora distro with an option to install LTSP right there in the setup screen. When installing, the LTSP option is the first item on the menu, added above the default Workstation, Server and Custom options. This means that you don't have to mess around with the configuration files until you've had a chance to see what it is they do, and by then you'll probably only need to tweak them a little.

The LTSP server defaults to an IP gateway and firewall when two ethernet cards are present. This will only be the case in tuXlabs that are permanently online, which will usually not be the case. Normally, the Wizzy server will be the gateway, as all tuXlabs with Internet access use a Wizzy server.

Every student can have email and web access without the cost of being online. This is true even for schools that don't have a telephone.

While the delay in retrieving web pages is a necessary consequence of the Wizzy solution, it has a desirable side effect in that it helps educators to manage web access. Since anybody with an Internet connection can publish on the Web, there is an absolute ocean of complete trash that threatens to engulf the unwary browser. Groping through this mess just wastes school resources. Automated solutions to this issue have been proposed, often by companies that market filtering products. Apart from the fact that these products suffer from both false positives and negatives, blocking material unnecessarily and letting undesirable material through, it shifts responsibility from the teacher to a software product.

The Wizzy solution believes that it's better to let the teacher decide what is appropriate. This also allows the teacher to stay in touch with the material accessed by the learners he or she is teaching. Teachers can explicitly choose the web material that learners can access and definitively reject web material that is not appropriate. They can also set the Wizzy server to monitor websites, retrieving new versions as they become available.

Because the school is never in direct connection with the internet, but rather has its web content delivered upon request, students cannot "surf" the Internet. However, since all the web sites that have been requested by the IT administrator of the school are delivered and stored on the school's server, the students can "surf" this local web cache as though it were a mini-internet.

These specially chosen web sites can easily number in the hundreds. They can be updated daily; and should a new site be desired on a regular basis, the school would have to wait only one day for the delivery to begin. The "surfing" of this mini-internet within the tuXlab costs nothing, and is fast enough to give you whiplash, since all communication takes place within the tuXlab, between the server and the client computers. ^[13]

tuXlabs aims to give educators the tools to help learners explore computers and the Wizzy server allows them to put reasonable limits on learners' access, guiding them towards independent use of the computer as they mature. tuXlabs does not make any judgement regarding what content is regarded as appropriate, but is there to help provide the tools and documentation to help educators with these decisions. The focus is more on the "guidance" aspect, rather than restriction, as the former is a positive activity while the latter is negative.

The Wizzy solution integrates seamlessly with existing labs. Normally, no additional equipment is required to have this kind of Internet lab.

First, a recap of the basics. ^[14] How does mail from far away get to your account, say: somebody@myschool.wizzy.org.za?

OpenOffice is a full office suite, intended to measure up to and surpass Microsoft Office. This is what its original author, Marco Börries, intended when he started StarDivision to create the software that would eventually become OpenOffice in 1984, when he was just sixteen. He called it StarOffice. By the time Sun Microsystems bought Marco's company in 1999, over 25 million copies of Star Office had been sold to customers who needed platform independence (see the section called “Glossary”) and an alternative to Microsoft.

In July 2000, Sun released most of the Star Office source code (about 7.5 million lines of C++) to the stewardship of the open source community, under the Free Software Foundation's LGPL license. The community project has as its goal: "To create, as a community, the leading international office suite that will run on all major platforms and provide access to all functionality and data through open-component based APIs and an XML-based file format." The open APIs (see the section called “Glossary”) and file formats are turning OpenOffice into a platform in its own right, supporting projects such as OpenGroupware, which aims to provide an open alternative to Microsoft's Exchange and SharePoint products.

This is in direct contrast to Microsoft's approach, who have always used the fact that only their own software could easily use their document formats to keep customers locked in, in effect reserving the Office platform to Windows applications.

OpenOffice includes a word processor, spreadsheet, interfaces to many databases, a presentation builder, and a diagramming tool. It is now able to decode most variants of Microsoft Office document formats, but although its StarBasic macro language is syntactically identical to Visual Basic, OpenOffice cannot execute Visual Basic scripts. Although these are preserved upon conversion, the scripts need to be adjusted to use the OpenOffice API before they can be used.

OpenOffice can be used to teach all the basic computer skills required to enter the job market, and as the design paradigms of the software is very close to Microsoft Office, the skills learnt are readily transferable.

In 1998, Netscape Communications released the source code of its Navigator web browser software as open source, and the Mozilla project was born. Netscape released their software as open source in order to compete with Microsoft, who were bundling Internet Explorer with every copy of Windows sold. Netscape hoped that the cooperation of thousands of developers around the world would create a better product than Internet Exporer. It did, but it took years, and Netscape fell by the wayside. The code lived on, though.

In 2004, six years after the start of the project, the non-profit Mozilla Foundation that was created to coordinate the project finally released version 1.0 of the Firefox browser. Earlier versions of the software had been in use for years, but at last it was deemed ready for a high-profile release to the general public.

The full Mozilla suite includes far more than the web browser. It includes Thunderbird, a mail client with address books and calendaring support, and Composer, a web page editor. For developers, it includes Venkman, a Javascript debugger, and the DOM Inspector, a wonderful tool for interactively exploring the enormous, intricate internal structure of complicated web pages.

The codebase has been painstakingly restructured to get as much use out of it as possible. So, for instance, all the Mozilla applications use the same rendering engine, called Gecko, to layout and display HTML pages on screen. This is critical, since it is extremely hard work to implement the standards that govern web page structure and display correctly. Mozilla has the best support for the HTML and CSS standards of any browser out there. In the past, Microsoft has used Internet Explorer's idiosyncratic and incomplete implementation of web standards to coerce people to craft their web pages to look good in Internet Explorer at the expense of other browsers. For the web to become a dependable platform, however, developers have to be able to build on solid public standards that don't leave them at the mercy of any company's prosperity.

As with OpenOffice, the Mozilla project is becoming a platform for extensions from the community.

A tuXlab will usually have only one or two printers for the lab as a whole. Since everyone will use these, it's worthwhile to get the best printers you can afford: as long as they're on a network, everyone will benefit.

Depending on the make of printer, it may be connected to the network switch with a network cable, or it may be connected directly to a print server (which may be the classroom server) with a parallel cable.

Printing in a tuXlab will be managed using CUPS, the Common Unix Printing System. It provides a web interface (accessible at http://printserver:631/) where you may check the status of printers and print jobs, print test pages, and so on. (printserver is the hostname of the printer or the server to which the printer is connected.)

Email has been called the "killer application" of the Internet. It's the most ubiquitous and accessible way to communicate with people across the world.

Not all tuXlabs have email. Generally, you'll only have email if a Wizzy server is installed along with the classroom application server. The Wizzy server functions as a post office and a stand-in, or a proxy, for the world wide web.

If your tuXlab is equiped with a Wizzy server, you'll be able to send mail to each other and to other schools or mailing lists all over the world.

XXX: How does Wizzy handle delivery of local email? Does that also go via the Cape Town Wizzy server, and take a day for the round trip? Probably not ..

Without a network, transferring files from one computer to another is a difficult and inconvenient process. You have to copy the file onto some storage medium (such as a floppy disk or a CD) and carry it over to the other computer yourself. Floppy disks tend to break or become silently corrupted. CDs can only be written once, and are relatively expensive. Even rewritable CDs are slow to use, and even more expensive. Finally, all kinds of disk drives have many moving parts, and they have to deal with a disk platter that spins hundreds of times per second. They all break eventually.

Watch out for this one, it only looks innocent.

If you're lucky, the floppy will let you know when it's broken.

It's much better to shift the job to network cables. Once laid, a cable will keep on working forever. It doesn't cost anything to transfer data over it, and it's very fast.

In the thin-client configuration of a tuXlab, the reality is even better. None of the client workstations store any data, so the need for them to have internal hard disk drives has also been eliminated. The only computer in a tuXlab that must contain at least one disk drive is the classroom server. Every user of the tuXlab --- in other words, every person with a username and password to login at a workstation --- has some storage space on the classroom server's hard drive allocated to them, where they may store their data. They all reach their data via the network.

This means that making a copy of a file for another user comes down to making a copy elsewhere on the same disk drive. Similarly, for files that many people need to share without necessarily needing their own copies to modify, this means that everyone may access the exact same copy of the file. In a non-networked situation, every single workstation would need their own copy of such files. This is the case for all the operating system and application software, for example.

Without a network, every workstation needs to be sufficient unto itself, and to provide all the storage space and processing power that a user is likely to need. With the introduction of a network, it becomes feasible to differentiate between computers, and equip them according to their roles. For a tuXlab, this means removing everything that can break or costs money from the client workstations --- their role is only to receive data over the network, and to display the user's desktop, sent from the server. The server does all the work, so it can have all the memory, disk space and computing power that you can afford. Everyone benefits from money spent on the server.

There are different ways of wiring an Ethernet local area network. One way is to simply lay coaxial cable from one computer to the next, until all the computers are connected, forming a ring. This is relatively simple, but the resulting network is slow, both because of the electrical properties of the coaxial cable, as well as because all the data has to share a single cable.

Since a tuXlab needs more speed, a star topology is used instead diagram. In this configuration, a single CAT-5 cable connects each workstation to a central node. This central node acts as an interchange. In a simple network where speed isn't critical, this node can be a hub. This is a device with ports where you can plug in many network cables; usually 8, 16 or 24. A hub is very chatty: it simply repeats all the data coming in on one port on all the other ports. This way, the data is sure to reach the computer it's meant for. Unfortunately, it also reaches all the other computers, taking up precious network bandwidth.

Instead of a hub, you can also use a switch. It looks just like a hub, but it's cleverer about routing the traffic that moves across it. In short, it remembers which computer is where, so that when it receives a data packet meant for a particular computer, it sends it only to the port where that computer is connected.

Switches can be linked together to form one bigger switch. For example, if you have a lab with 25 workstations, you can link together two 16-port switches using a flylead. See the section called “Switch cabinet”.

Every switch has a couple of special high-speed ports. These are used to link the switch to the server, or to link switches to each other.

Category 5 cable, commonly known as CAT-5, is an unshielded twisted pair type cable designed for high signal integrity. The actual standard defines specific electrical properties of the wire, but it is most commonly known as being rated for its Ethernet capability of 100 Mbit/s. Its specific standard designation is EIA/TIA-568. CAT-5 cable typically has three twists per inch of each twisted pair of 24 gauge copper wires within the cable. Another important characteristic is that the wires are insulated with a plastic (FEP) that has low dispersion; that is, the dielectric constant of the plastic does not depend greatly on frequency. Special attention also has to be paid to minimizing impedance mismatches at connection points. In practice, this means that, when you attach connectors to the cable ends, you shouldn't untwist more of the cable than absolutely necessary.

When laying CAT-5 cable, you need a crimping tool, RJ45 jacks, and boots for the jacks.

The crimping tool is a clever piece of work. It combines the functions of a cable-cutter, wire-stripper, and a special grip specifically designed to fix the RJ45 jack to the cable. I'll explain them as I go through the steps of preparing a cable.

An RJ-45

A crimping tool

Crimping the cables

Stepping back, your lab looks the same as before, with the addition of cable ends emerging above the desks, and a whole bundle of cables terminating at the switch cabinet. Now you need to attach RJ45 jacks to the cable ends, so that they can be plugged into the switch at the one end, and into each workstation's network card on the other end.

To do this, complete the following steps for each cable.

• Insert the 'boot' over the cable. This will cover the exposed wires where the RJ45 jack attaches to the cable wires.

• Cut through the sheath around the cable to expose the pairs of coloured wires, without damaging them.

• Untwist about 2cm of each pair of wires (no more, as this impairs the effectiveness of the cable for data transmission).

• Arrange the wires in the correct colour sequence. (Straight-through cabling for cables between the switch and workstations, or Cross-over cabling for flyleads that connect switches, or that connect the switch to the server).

• Insert the wires into the RJ45 connector. Push them up so that all the wires terminate right at the tip of the connector.

• Check the colour sequence of the wires again.

• Crimp the wires to the connector using the tool. You'll notice that the connector has copper strips along the top. These connect to matching strips in the plug of the workstation's network card or the switch. When you crimp the connector, it bites into the wires through their plastic covering, connecting its copper strips to the copper wire. This is why it's critical to push the wires right up to the tip of the connector, so that the connector's teeth find the wire.

• Test the cable using a continuity tester, if you have one. If you don't, you'll just have to figure out whether it works by trial and error later.

Cross-over CAT-5 cable

Straight-through CAT-5 cable

The Wizzy project predates tuXlabs. It can also be configured to provide a similar range of application serving functions as the tuXlab classroom server provides. In this configuration, it uses the following packages:

The configuration settings for the DHCP server are contained in the /etc directory --- standard Linux location for configuration data --- in the file /etc/dhcpd.conf. XXX which settings in here should be explained?

When the tuXlab has a Wizzy server, there are a couple of other aspects to network configuration.

Access to directories, files and executable programs under Linux is managed in terms of users, groups and permissions. Every user belongs to a group, and every file belongs to a user and a group. The basic permissions are read, write and execute. For every file and directory, these permissions can be set for the user who owns the file, the group, and for all others (i.e. everyone but the owner or the group). For example, here are the permissions of a user's home directory:

jean@klippie jean $ ls -ld /home/jean
drwxr-xr-x  112 jean     users        6664 Des 26 17:31 /home/jean

The permissions are shown by the string drwxr-xr-x. The first character, d, indicates that this is a directory. You should read the following 9 characters in groups of three, that show the permissions for the owner jean ( rwx), the group users ( r-x), and all others ( r-x). In this case, the owner has read ( r), write ( w) and execute ( x) permissions, while the group and others only have read and execute permissions. In the case of a directory, execute permissions means that you are allowed to access the contents of the directory. This home directory may therefore be read by everyone, but only the user may change it.

Here are the permissions on the file that contains the system user database:

jean@klippie jean $ ls -l /etc/passwd
-rw-r--r--    1 root     root         2118 Des  1 05:32 /etc/passwd

These indicate firstly that this is a regular file, not a directory (the leading -), and that the owner root has read and write permissions ( rw-), and everyone else have only read permissions ( r--). In effect, this means that only the root user may add, modify or delete users.

You may further note that the group to which this file belongs is also root. This group only has one member (the root user), and is used for files that are under control of only this unique user.

XXX: what happens when a user is retired? Is the password just reset, or is the whole home directory and all email deleted?

If the Wikipedia has been installed, the Wizzy server will also serve a local mirror of it.

The Wikipedia is a one-of-a-kind collaborative effort to create an online encyclopedia. It is managed and operated by the non-profit Wikimedia Foundation. In addition to standard encyclopedic knowledge, the Wikipedia project has developed offshoots that include the kind of information associated with almanacs and gazetteers, as well as coverage of current events. With a little effort, it can be used offline in schools.

The Wikipedia is being written collaboratively as an open source project, using specialised wiki software called mediawiki. This means that anyone, including you, can make changes and add information. In fact, the openness of Wikipedia to local knowledge is one of its most important characteristics. For the first time, the world is being described not by an editorial committee but by a global community of volunteers, who are able to augment academic knowledge with local experience.

A wiki is a simple form of web-publishing that was thought up by a software design consultant called Ward Cunningham. His original wiki is still running at http://c2.com/cgi/wiki

In a wiki, every page is editable as plain text which is converted to HTML when served, following a number of simple conventions that convey the structure of the text. Specifically the convention for linking between pages is what gives wikis their identity. To create a link to another page, you simply write its title in a special format (e.g. AnotherPage), and if that page exists the title is turned into a hyperlink to it. If it doesn't exist, the title is turned into a link leading to a blank page where you may create AnotherPage instead. The mediawiki software also keeps a record of all versions of a page, so that the entire editorial history of a page may be examined.

For schools that don't have a permanent Internet connection, this entire resource, because of its Open Content licence, can be installed locally. Even for schools that are permanently online there are advantages to a local install, in preference to a wwwoffle mirror:

A local Wikipedia mirror does introduce some complexity though. In addition to apache, it requires PHP, Mediawiki and mysql. ^[18]

Project Gutenberg was started in 1971 by Michael Hart, with the goal to provide books electronically at no cost.

Their collection numbers more than 13,000 e-books, produced by hundreds of volunteers. Most of the Project Gutenberg e-books (but not all) are older literary works that are in the public domain in the United States. ^[19] All may be freely downloaded and read, and redistributed for non-commercial use (for complete details, see the license page).

The Connexions project of Rice University is an endeavour to create open source course material. On their homepage, they state: "Knowledge should be free, open, and shared. Connexions is a rapidly growing collection of free scholarly materials and a powerful set of free software tools to help authors publish and collaborate, instructors rapidly build and share custom courses, and learners to explore the links among concepts, courses, and disciplines.

They provide small "knowledge chunks", called modules, that connect into courses. Thanks to an open license, anyone can take these materials, adapt them to meet their needs, and contribute them back to the Commons.

Your tuXlab uses a star topology. This means that every thin client connects directly to the switch, giving it a fast connection to the tuXlab server. In other topologies, such as ring topologies, messages are passed on from computer to computer. Star topologies are the fastest, and are best suited for thin client computers.

In the diagram below, you will notice that all the thin clients, as well as the server, connect to the switch using CAT-5 cable. The server connects to a special high-speed port on the switch, called the "Gigabit" port. It has ten times the data throughput of the other ports, allowing computers to have fast access to the server. This is necessary because all the clients are constantly talking to the server, and not to each other.

If your lab has an Internet or e-mail setup, your server will also be connected to a gateway computer. This computer will dial up at night to collect your email and off-line content. The gateway computer will have a modem attached, that converts the sounds from your phone line to digital signals that your computer can understand, and vice-versa.

With troubleshooting, more than half the work is actually identifying the problem. Once you have a good overview of how things fit together, it is easier to locate the cause of the problem.

Thin clients rely on a network connection to work, so if all the computers fail to start up, you might want to check if the networking switch is turned on, or that the server is properly connected to a switch. If only one computer fails to start, it might be a problem with the cable connecting that computer to the switch. To make sure of this, plug this cable into a computer that starts successfully. If it stops working while using this cable and resumes working normally when the original cable is replaced, you know that the problem lies with the cable.

To fix the cable, you can try crimping the cable ends again. Examine both the switch end and the workstation end of the cable, making sure that all the copper wires in the CAT-5 cable are pushed up right to the end of the cable. If you notice something wrong, cut the cable a couple of centimeters beyond the RJ45 jack, and proceed as in the section called “Building the network”

XXX: diagram

Thin clients, being network computers, have limits on what they're capable of. It allows easy administration, and maintenance, but it has the following limitations:

Some of the software we install is very new, and may still be under development. In this section, we list the software that we know have issues.

Simply put, a terminal is a place where you can type instructions for your computer. Terminal access is often the easiest way to adjust a wide variety of settings in your tuXlab.

There are several ways to gain access to a terminal. In the following, we'll show a few of the ways.

#ssh server
The authenticity of host 'server (192.168.0.254)' can't be established.
RSA key fingerprint is 9e:8e:0e:9a:88:b9:a0:1e:0c:80:15:41:54:47:dd:fa.
Are you sure you want to continue connecting (yes/no)?

There are two types of users: those who have forgotten their password, and those that will forget their password. This is often the case for system administrators as well.

To reset your root password, you'll need:

Resetting your server in 4 easy steps:

The lts.conf file stores information about your thin client setup. Generally, thin client settings are detected automatically. However, there are times when you want to adjust certain settings manually. Remember to make comments when you change settings (it will make it easy for other people to troubleshoot the system). Comments are any lines in your lts.conf file that start with a #.

[default]

SERVER = 192.168.0.254
XSERVER = vesa
#used to be s3, changed to vesa on 10 December 2004 by Jonathan

X_MOUSE_PROTOCOL = microsoft
X_MOUSE_DEVICE = /dev/ttyS0
X_kb_Symboles = us(pc101)
X_kb_Layout = us

USE_XFS = N
LOCAL_APPS = N
SCREEN_01 = startx
SCREEN_02 = shell
USE_NFS_SWAP = Y
SWAPFILE_SIZE = 24m

RCFILE_01 = usb
RCFILE_02 = floppyd

SOUND = Y
SOUND_DAEMON = esd
# SOUND_DAEMON = nasd
VOLUME = 75
SMODULE_01 = sb io=0x220 irq=5 dma=1

#60 hz resolutions:
X_MODE_0 = 1024x768 65 1024 1048 1184 1344 768 771 777 806 -hsync -vsync

[00:08:A1:F1:EE:01]
    X_MODE_0 = 800x600
    LOCAL_APPS = N
    USE_NFS_SWAP = N

The tuXlab support process is fairly simple. The support process poster in your tuXlab explains the steps:

If you experience any hardware problems, it's generally a good idea to skip ahead to step 5 and phone the help desk, since other tuXlab schools might not always be able to help you there. Most tuXlab cluster leaders will have spare parts with them, contact your cluster leader to find out if they have any spares.

If you'd like to buy additional hardware for your tuXlab, or if you need to replace faulty equipment of which the guarantee has expired, you can source hardware from the following suppliers:

These are just pointers to sites on the World Wide Web where you can read more about some of the topics mentioned, and where you can search for further information.

Please supply some general information about your school.

Should you require any further assistance please contact: