Building a Linux Computer Lab for Schools?

joseamuniz asks: "After giving Linux classes to Secondary School Teachers, I got in touch with a non-profit organization called UNETE. This association has donated 1,523 computer labs to public schools in Mexico. I told them about Linux, and they are interested in equipping a beta computer lab with this Operating System, with Intel PIII, 256 MB RAM PCs. The more they like this lab, the higher chances to include Linux in the new labs donated by this institution." What hardware configurations and software packages would you install on such a machine to show off the real power of Linux in an educational environment?

Comments

Well, to start ....

[nanodude]

Firefox

First things first...

[DrEldarion]

Make absolutely sure that any software these schools really want to run either has a native Linux version, a practically-idential Linux version, or will run flawlessly under WINE. If the schools can't use the software they want to, it'll leave quite a bad taste in their mouths about Linux.

wont work that easy

[gargoleblaster]

Im afraid most of the educational software taught at the school level is built for windows and wont support other OS's very well. So the primary thing is find out which software is needed by them and get those working on Linux. Not many school children are going to start out running command line programs, or coding in perl and C++. Most likely, they will browse, use rich text editors/spreadsheets, chat apart form educational software. Unless of course, we are talking higer grades, even then, not all of them are going to be computer professionals. -imho

I would argue exactly the opposite

[mdarksbane]

Those who use only windows at home and at school learn just that, how to use windows.

Force them them to use something else, and they no longer just know how to use windows, but how to use a *computer*.

I've heard it said that the best way to learn how to learn language is to learn many of them. This is why we teach spanish, or why a good CS program should involve several different programming languages.

The concepts for using any OS are the same, and that's what should be taught in school, not exactly where to find what button in Word. You wouldn't say that kids should skip reading Shakespeare because every newspaper in the country is a 100% modern English shop, would you?

Re:I would argue exactly the opposite

[nine-times]

Force them them to use something else, and they no longer just know how to use windows, but how to use a *computer*.

I totally agree. If you're going to be teaching "computer literacy", it's better if you can incorporate multiple operating systems, not for the sake of being a politically-correct geek or pro-Linux advocacy, but because it will help them understand computers better.

For one thing, I don't consider a person "computer literate" because they can start MS Word and type a letter. If someone don't find it easy to sit down in front of any one of the more popular modern GUIs (Gnome, KDE, Windows, or OSX), find the word-processor, and type a letter, save it, and then find the saved file, they aren't computer literate. All of these DEs use common interface elements, and they should be figure-out-able even if you've never used them before so long as you *actually* understand how to use any of the other DEs.

In addition, seeing how the different DEs handle things would be helpful in understanding what's actually going on. I know lots of Windows users who don't really know what the start menu is. I mean, they use it all the time, but they don't know that it's a convention created to make your programs easier to find, they believe that it's as simple as "If I want to access Microsoft Word, it comes up when I click on start." Since they've only been exposed to Windows, they don't understand that a computer could exist without a start menu. It would be a useful training technique to stick these people in front of a Mac, for example, and point out that the Dock serves a similar purpose-- easy access to your apps along the side of your screen (default bottom). The applications aren't actually located there, but it's just a shortcut. Likewise, you can compare Windows Shortcuts and Macintosh Aliases, or the menu along the top of the screen vs. attached to each window. Understanding the differences and similarities should demonstrate that, though each of these conventions serve a purpose, they are conventions that can be understood rather than a memorized interaction.

Now before someone jumps down my throat saying, "We're talking about basic computer literacy, not trying to force people to be computer geeks," it's not as though I'm talking about making people build Linux from scratch. All I'm saying is that you give people an introduction to some of the major desktop environments so they can see what's different and what's the same. Comparing and contrasting two things is a great way to understand both things better. Many computer UI elements are conventional, some of them arbitrary, some of them even changing. The start menu from Windows 95 is not the same as the one from XP. Files are located in different places. Menus have become self-ajusting, and features have been added/removed/altered. But all of them have similarities: files, shortcuts/aliases, menus, heirarchical file systems of directories/folders, a program to browse the file system (nautilus, finder, explorer), etc.

I'm not asking that users understand how, exactly these things work, but I also think that even a Windows-only user should understand these things well enough to sit down in front of KDE or Gnome without too much confusion before we call them "computer literate". If you want users to be "literate" enough to deal with the differences between even different versions of Windows, they really need to have *some* idea about how things work, and why they are the way they are.

#1 is running smoothly

[lakeland]

Forget about distro arguments, forget about how cool kdeedu is, forget about how amazing (whatever, I don't use gnome, but I'm sure there is something).

Concentrate on the fact that you have slow machines running undocumented software that are being demonstrated by people who do not know the software. Every one of those issues needs to be resolved, and if you want the lab to be a real success then aim for the goal of making everything run smoothly every time.

The machines will feel slow, so you will have to work around this somehow or choose a light wm and cope with the added complexity it brings. The software is mimimally documented, and what documentation exists will need to be rewritten for your target level and language. Think howtos with step by step screenshots -- the reason cheesy computer courses use those is because they work... And the teachers need more than just a training course if you expect things to go well, they need a depth of experience.

So to start with the hardware. Linspire does not run well on a typical 500MHz machine because it needs more ram. Decide for each major choice (distro, window manager) how slow it is, and if it will feel better if you choose the fast but hard option or the slow but easy option. Generally, people who haven't used 3GHz computers cope with slowness more, so decide based on their experience rather than yours. If the machines have high ram I would go with KDE, low ram and I'd go with enlightenment or similar.

Next, concentrate on making sure every single thing these people want to do will work flawlessly first time. Make the documentation perfect. In many ways, the docs will be more important than the software.

Now you have the computer side working, concentrate on teaching the teachers to the point that they feel 100% comfortable. It is important at this point that no changes happen to the software. If the teachers just know how to do their lesson but don't feel comfortable then that discomfort will show strongly.

I hate to say it, but this sort of project is a lot of work even with awesome software running on blazingly fast machines. You're not targetting geeks who will overlook details such as user interface or docs because a program is cool. Of course, if you drop your standards and just deliver something that will appeal to geeks, well that's pretty easy with linux.

If you do manage to get the software, training materials and educators all working smoothly, then don't change a thing. Say openoffice 2.0 comes out and would fix a number of issues, ignore it! You can only retrain geeks fast, not people. You'd break your howto with items shifting menus or even just icons being tweaked. You'd upset your educators who don't have the depth of experience in software to cope.

Oh, and please publush everything at this point -- collaborative development doesn't just apply to software.

Good luck.