Computer Lab

From Artisan's Asylum

Revision as of 09:46, 29 October 2012 by Ifreecarve (Talk | contribs)
Jump to: navigation, search

We have a computer lab in the classroom, consisting of ten identical computers in roll-around desks. They are available for use by instructors and their students, and also by our members. This page documents how to use them, what software they've got, and how to request changes.

If you need to talk to us about particular CPUs, their names are the ten metallic elements from 24 to 33 in the periodic table: chromium, manganese, iron, cobalt, nickel, copper, zinc, gallium, germanium, and arsenic (Cr Mn Fe Co Ni Cu Zn Ga Ge As). Each CPU is labeled on the front with its name.


General rules

You must read and abide by these rules while you're using the computers. Pay particular attention to:

Your use of these computers means that you also agree to these policies at a minimum:

Also, note the sections below on:

Special notes for instructors

If you are an instructor teaching a new class, please see below about installing software---you can't install things yourself, and you must plan far enough ahead that we have time to schedule the installation in advance. Don't wait until the last minute.

If the students in your class might be using their own computers, please see below on how (and how not) to tell your students about our wireless network passphrase.

Finally, if we've installed software for you in the past, and you're repeating your class but it's been a while since it was last taught, please check with us to make sure that the software is still there and still works. We may occasionally upgrade operating systems---which could cause things to break---or remove software that hasn't been used in a long time to save space. It's wise to check as far in advance as possible to make sure your software is still there, still works, and isn't slated for deletion.

Setting up and putting away the computers

Each desk contains several cubbies:

  • A large cubby on the left, which holds a sewing machine. (If you're sewing, you're reading the wrong page.)
  • A large cubby on the right, which holds the CPU. Do not remove the CPU from the cubby.
  • A small horizontal cubby in the back, which holds the keyboard and mouse.
  • A larger cubby in the back, which holds the LCD monitor. The wifi transceiver is also attached to this.

Never disconnect any cables from any of the computers. You can set up and put away a computer while leaving everything connected.

Setting up

To set up a computer for use:

  • Go around to the back of the table.
  • First, pull out the keyboard and mouse and put them near the front edge of the desk.
  • Second, pull out the LCD and put it near the back edge of the desk.

Pulling the keybord and mouse out first is much easier than the other way around---the cables less likely to get tangled up while you're moving them.

The desks are designed to allow you to daisy-chain power from desk to desk by plugging each outlet strip into its neighbor. Don't daisy-chain all ten desks to each other, and don't plug the projector into a large string of desks. You will pop breakers on the outlet strips, probably about 20 minutes into whatever you're doing, when it's maximally annoying. For complete instructions on what to hook to what, read this carefully.

Abandoned machines

Please don't walk away and leave unsaved files and open applications. Saving your own files and closing applications before you walk away is your responsibility. If you don't do this, you leave later users in a quandry---can they shut down or reboot the computer, or not? Will you be back in five minutes or next week? And what should they do about unsaved files?

If you see a computer that looks abandoned and has unsaved files, don't save them. Why? Because you can't know whether the person who was editing them was making changes they really wanted, and you could overwrite a good version of, e.g., a CAD file with a version that isn't wanted. This is especially important because some random person could have poked at the file after the real user left and before you arrived, or character(s) could have been typed into it by accident, etc.

Putting away

When you're done with a computer, please shut it down and put it away.

It's important to shut it down for several reasons:

  • It guarantees you've thought about modified files, and haven't left it to the next person to make an arbitrary decision.
  • It saves power. (For several reasons, these machines are not set to sleep or hibernate.)
  • It reduces the chances that the machine will simply have the power yanked out from under it if someone unplugs (or blows a breaker on) an outlet strip it's daisy-chained to, perhaps several desks away.

It's important to put it away because the room is used for many other activities, and those activities might use the desks but not the computers.

You can shut the computer down via the operating system, or you can push the large power button on the front for about half a second only. (Don't just keep it held down---if you hold it for 4 seconds continuously, it will turn off the power immediately, without warning the operating system. Pushing it for half a second instead will ask the OS to shut down the machine gracefully. Note that, if there are still open applications, you may have to use the mouse to shut down instead---the OS will likely pop up a window complaining and asking what to do. This is another reason why everyone should exit all pplications before just walking away.]

Please leave the LCD power switch in the on position, even if you're turning everything else off. (It's okay to unplug the entire desk or desks if you want---just don't hit the off button on the LCD.) We do it this way because some of the LCDs have finicky buttons and it may be hard to get them turned back on, and because LCDs in standby consume very little power, assuming the desk is even plugged in at all.

Instructors may ask their students to put each computer away, or the instructor may put them all away, but you should not leave a classroom of computers all set up after your class unless someone has told you they'd like you to leave them set up.

To put a computer away, put the LCD in its cubby first. You may need to swing the screen down slightly to make it short enough to fit. Once the LCD is stowed, then stow the keyboard and mouse. You don't need to un-daisy-chain the power connections, because stowing and unstowing computers is more common than rolling all of the desks out of the way.

Hard drives and mechanical shock limits

Why are the computers all sitting on those squishy pads? Because they have spinning mechanical disks in them, and those disks have a shock limit of 4G even when they're turned off. The desks are also used for sewing machines, and some of those machines can produce quite a bit of vibration. The shockmounts are there to keep vibration from the sewing machines within the disks' 4G nonoperational limits.

The operational limits---how much shock a disk can take when it's actually on---are considerably lower. So if you see someone using a sewing machine---or doing anything else that could cause a lot of vibration---while the computer in that desk is turned on, please stop them and turn off the computer. For the same reason, it's a really bad idea to roll the desks around more than an inch or two if the disks are spinning---if you crash into another desk, or even run over a power cord you didn't see, the disk will not be happy. Having to recover a failed disk can be a lot of work, even with backups.

[If you'd like to volunteer to buy us 10 160GB+ SSDs to avoid this problem in the future, we would be more than happy to take you up on it.]

For more on how not to abuse the desks or the disks in them, see this discussion.

Do not disconnect cables

Do not ever disconnect any cabling from any of the computers in the classroom.

The sole exceptions are:

  • 120V power plugs from outlet strips, if you're moving desks around
  • Video from the one computer you're using to connect to the projector

We have found in the past that some people disconnect cabling from the classroom computers, such as network cables, leading to annoying and sometimes hard-to-debug problems for students and instructors taking classes. (For example, SolidWorks won't even start up without a working network, because it uses a network license.) Because this can interfere with classes, it is Asylum policy that no cables, with the exceptions above, should ever be unplugged from any classroom computers without prior permission from IT.

For more on why unplugging things is a bad idea, see immediately below.

In addition, if you have disconnected video from a computer in order to use the projector, you must reconnect it as soon as you are done with the projector. See above for why.

The computer lab is not for testing equipment

Do not test random equipment with our computer lab by unplugging bits of its hardware and then plugging in your own. If you have a computer you need to test with an LCD, or you have an LCD you need to test with a computer, don't do so in the computer lab. Find another, more expendable computer (ask us if necessary), or use your own. We say this for several reasons:

Inconvenience. It's been our experience that people who unplug any cables for any reason almost never remember to plug them back in, and when they do, they're often plugged into the wrong places (such as plugging not-quite-USB-3.0-compatible equipment into the USB 3.0 ports, leading to obscure and hard-to-debug flaky behavior). Many users think they'll remember, but experience demonstrates that they don't.

Damage. Unknown equipment under test could conceivably permanently damage one of the classroom computers. For example, failure modes that short 120V onto signal pins are not unknown. Hardware damage to one of the computers in the classroom is expensive to repair, not only in the money it takes to buy new parts, but in the personnel time required to buy the hardware, assemble it, and possibly reinstall entire disks full of operating systems, depending on what gets blown up.

Classes. These computers are constantly used for classes. They are critical resources. Having cables unplugged means that one or more students simply may not have a computer to use for that class, depending entirely on the skill of the students and instructor in debugging what went wrong. (For example, unplugging the network can lead to surprising failures; see above). Having one damaged by hardware experimentation means we can't run the class at full capacity until the damage is repaired. Either way, this leads to a very sticky situation, since people who have paid for a class would no longer be able to take it---possibly halfway through a set of several sessions.

For all these reasons, it is Asylum policy that the computers in the classroom are never to be used as test machines. The only exception to this policy is for well-behaved USB equipment (see below), and it is still a better idea to (a) go through a USB hub, and (b) use a more-expendable computer instead, unless this is part of an actual class.


Because the desks roll around, the computers can't be on a hardwired Ethernet. Instead, each of them has a wireless USB device, which looks like a flash drive, plugged into a USB extension cable. That cable is attached to the LCD; it will often be sticking out just behind the LCD, or perhaps pulled a few inches out and flopping around a bit.

We do it this way for two reasons:

  • It gets the wifi transceiver far away from the metal case of the computer, which would otherwise act like a groundplane and absorb the signal
  • It gets the wifi transceiver higher up, where it's more likely to be line of sight to the wireless access point without metal obstacles in the way

How (and how not) to tell your students about our wireless network passphrase

If your students are just using the classroom computers, you can skip this section, because all of the classroom computers already know the passphrase to our wireless network.

If you're using your own computer, or your students might be their own computers, then you need to read this section carefully.

We use a single passphrase for our wireless network. This is much easier than handing out individual credentials to every member. It's especially easier than having to generate new credentials for every new student, of which we have a large number. However, we don't want that passphrase getting out to the whole wide world, and there are many ways it can. If you're teaching a class or having some other gathering in the computer lab where there are new people and they'll need to get on our net, please abide by these rules at all times:

If you need to know the passphrase yourself, the front-desk staff has it. They often have little slips of paper you can take back with you if you want. Note that the little slips of paper don't say, by themselves, that what you're looking at is a passphrase at all. This is deliberate, in case slips wander off. (Note: If this is the first time you're teaching, and your class starts sometime outside of our normal staffed hours, please remember to swing by and get the passphrase before your class, or you may not be able to find anyone around who knows it. Even other members probably don't know it---they probably knew it just long enough to type it into a laptop or a phone exactly once, and don't remember it accurately any more.)

If you need to share the passphrase with your students, that's okay. You can write it down on the whiteboard, or hand it out on slips of paper, but do not write "our wireless passphrase" (or anything like it) on the whiteboard, or on the slip of paper. Why? Because that way a random visitor, or someone who finds your slip of paper floating around, will be none the wiser. (And if you write it on the whiteboard, please erase it as soon as your students have typed it into their devices. If you wait until after class, you'll likely forget, and it might stay there for days. There have been many, many instances of photographers publishing pictures taken in offices where crucial passwords were written on a visible whiteboard, and we'd rather not be one of them. We get a lot of reporters and photographers, a lot of students take pictures of things in class and post them to social media, and we also often stream live video from gatherings in the classroom.)

Never type our passphrase into any electronic document, ever. The only place you should be typing it is into a password prompt for something that requires it to get you on our network.

In particular:

  • Do not type it into a Google Doc---not even if you're projecting that doc for a class, not even if that doc is supposedly private. Use paper or the whiteboard.
  • Do not send it via email or text, ever, to anyone, for any reason.

In both cases, we say this because it's very easy to intercept such passwords, or for them to be copied somewhere else by mistake. All of these sorts of things have happened already with other passwords of ours. Those passwords were changed, but changing the wireless passphrase for our entire network is very painful and we'd like to minimize the number of times we need to do so. If our passphrase gets out, we will likely have to go to individual credentials for everyone, which is much more annoying for all users, and much more work to set up from the IT side as well.


If you're having issues with network on a computer lab machine, the first thing you should check is whether the wifi transceiver has a green LED that flashes occasionally. If it looks completely dead, it's probably unplugged. Check the connection right at the wifi first; that connection is frequently loose. (We've applied tape around the joint, but people sometimes disconnect the tape, believing that the wifi is instead a flash drive.) If that doesn't help, make sure the other end of the USB extension cable is plugged into the CPU. You can plug it into any of the USB ports except the blue ones, which are USB 3.0---the wifi drivers are unreliable using USB 3.0.

Never swap wifi transceivers between machines. They have unique MAC addresses. If you swap them, the machine will think it has new hardware, and it won't know that it can use the wifi passphrase that it already knows, which means it won't be able to get on the network. Even if you supply the passphrase for the new wifi transceiver, having the MACs swapped around will screw up remote administration of the machines. So don't do this.

(If you suspect that the wifi transceivers have gotten swapped, note that each one has the name of a chemical element writton on it in Sharpie. That should match the name on the front of the CPU.)


Each CPU consists of a quad-core 64-bit AMD 4100FX, in a Gigabyte GA-970A-UD3 motherboard, with 8GB DDR3 RAM, and an nVidia GT216GL (Quadro 400) graphics card. The motherboard will accomodate up to 32GB of RAM, if that turns out to be necessary. Each machine also has 160GB of disk, shared across various partitions and operating systems.

Each computer has USB ports on the front and back panels. Most are USB 2.0 (red connectors), but two on the back panel are USB 3.0 (blue connectors). USB 3.0 is much faster than USB 2.0 and can provide more peripheral power per port, and is a good choice for flash drives, DVD drives, and portable disks. However, USB 3.0 support is relatively new industrywide, and not every USB peripheral works correctly with USB 3.0 drivers, so if you're having puzzling or flaky results, try it with a USB 2.0 port and see if things work correctly then.

If you're using these computers for hardware development, please be careful. If you're rolling your own USB hardware and there's any chance of miswiring your USB connectors or having unusual voltages on them, use a USB hub between your device and the computers! Replacing a blown USB hub is much easier and cheaper than replacing a motherboard, especially since the short market lifetime of motherboards means we'll probably have to buy a different type and deal with odd-man-out sorts of issues from then on.

The only sort of hardware development we support on these machines involves well-behaved USB devices, and you should see here and here for other rules involving disconnecting cables, and non-USB hardware, respectively. Even better, please use a different computer instead; ask us if you need a more-expendable test target.

Note: Due to deficiencies of the motherboards, these computers cannot boot from USB flash drives unless they are very specially formatted, which yours almost certainly isn't. This means that you can't boot other operating systems from USB unless you have an external DVD drive and a disk.

Operating systems

With a few exceptions (documented below), all ten machines are kept in a nearly-identical configuration, with these operating systems installed:

  • Windows 7 Home Premium 64-bit
  • Ubuntu Linux 12.04 Precise Pangolin LTS 64-bit desktop


The machines autoboot to Windows. When the machine comes up, it will automatically log into the user named "user". The other accounts on the machine are for administrative purposes. If for some reason you log out, you can just click on "user" again and you'll be logged back in.

Please don't reconfigure the machines, since not everyone shares your tastes, and some of those configurations are there for a reason. This includes things like the appearance of folders and windows, where the trash is, etc.


If you want to run Linux, reboot, wait 10-15 seconds until you see a message saying "Loading Operating System", and then wait until you see the GRUB menu. Use the arrow keys to select the top menu item instead of the bottom, and hit return. (Once you type any character at the GRUB menu, the countdown will stop, and the machine will wait for you to decide what to do.)

Once the machine has booted, select "guest account". Note that your settings and any stored files will vanish when you log out. (We may in the future switch to permanent accounts instead.)

Booting your own

In general, please don't. If you must, ask us first

We say this because it's possible that booting an alternate OS can overwrite one or more of the existing partitions on the machine or the bootloader---even if you're not trying to install a new OS, some alternate OS's can be buggy. Such an overwrite could cost us an enormous amount of work.

But if you have permission to use an alternate that we trust, this is possible. Note that you likely can't do this from a USB flash drive, though. Under no circumstances are you allowed to write to any partition on the machine without prior arrangement---none of them are scratch or expendable.

Changing settings

Please don't. We don't want a war among various peoples' tastes, and some of those configurations are the way they are for a reason. See above.

If you absolutely must change some sort of configuration in order to make a particular piece of software run correctly, and the machine allows you to do so, send mail to explaining what you did and why. Your change will likely have to be replicated to all of our machines to keep them in sync. Also, it will likely be lost if we don't know if it was done and the machine is ever restored from a prior backup. It's a much better idea to get us involved from the start to avoid any problems.

Storing files

In general, do not assume anything you leave on the machine will survive.

We may reconfigure or reinstall any machine at any time without warning. Every time any maintenance is performed on the machines, or any time an automated backup happens, everything on the desktop will be thrown away, as well as the contents of download folders and similar directories as well. (This keeps the backups smaller. Also, if such items were not regularly thrown away, people would get in the habit of expecting them to survive. That's a bad habit to get into, because (a) someone else could throw them them away at any time, (b) no one else would ever know if they could throw something away, and (c) there is no guarantee that anything in the local filesystem won't be wiped out at any time if the machine is restored from backup. Finally, expecting one's files to be on some particular machine sets up a dynamic where people need to bump others off "their" machine to get to their files, which is annoying to the people getting bumped.)

If you need to store files, you have two choices:

  • Use your own local storage, such as a flash drive or USB external disk.
  • Use our public file share, which is available to all members over the network.

Installed software

This section documents the software currently installed on the machines. If you'd like something installed, please see below.


We have Windows 7 Home Premium 64-bit installed. The packages below are what we've installed on all machines that aren't there by default out of the box.

  • Audio/Video/DJing
    • Ableton Live
    • Mixxx 1.11.0-alpha2
    • PureData 0.42.5
    • ASIO4ALL 2.10 [low-latency audio driver]
  • CAD/CAM:
    • Electrical
      • PCB design & schematic capture
        • FreePCB
        • TinyCAD
      • Hardware programmers and IDEs
        • Arduino 1.0
        • Cypress PSOC (Creator, Designer, and Programmer)
        • Fritzing
    • Mechanical
      • AutoDesk 123D
      • Autodesk 123D Make
      • BigBlueSaw DXF exporter for Inkscape [gets units right]
      • Blender 2.63a
      • CamBam beta 0.8.2
      • CNCSimulator
      • DraftSight
      • Solidworks Premium 2012
  • General productivity
    • BullZip PDF Creator
    • Firefox
    • LibreOffice
  • Graphics
    • Inkscape
  • Other
    • Cygwin 1.7.16-1
    • Processing
    • Wacom tablet driver 6.3.2-3

In addition, the packages below are installed on a subset of the machines. Typically, this is done for very large installations that will only be used by one or two people at a time; doing this saves a lot of work and allows us to distribute packages so we don't run out of disk space in the Windows partition. The computers on which the packages are installed are in brackets.

  • XPlane 10 [Cr]


We have Ubuntu 12.04 LTS (Precise Pangolin) 64-bit desktop installed. The packages below are what we've installed on all machines that aren't there by default out of the box and are generally useful by end-users. [Several small utility packages, including pv, socat, smartmontools, gparted, ntp, ethtool, and many others, are installed, but the entire list isn't worth documenting here. Note also that many major packages that are optional add-ons for Windows are included out-of-the-box in Ubuntu, such as Firefox and LibreOffice.]

  • General productivity
    • Emacs
  • Graphics
    • Inkscape

Installing software

You can't install software on these machines without an administrative password. For a variety of reasons, we don't hand out these passwords.

If you'd like something installed, please talk to an admin or send mail to

Do not wait until the last minute to request an installation, especially if you need this software for a class. Installing software on ten machines can take considerable time, no one doing the work is doing this as a full-time job or even getting paid for any of it, and you can't make any assumptions about their schedules or availability. In addition, the most convenient times to install software are often also times that the desks or the computer themselves are already in use by something else, so installations have to work around those schedules. It's also considerably more efficient to batch up installations for several people or several classes and do them all at once, because it involves unstowing & restowing the machines only once and not once per package, and because often one package can be started on one machine while a different package is installing somewhere else.

Please allow at least a week, and the more warning, the better. If your class runs in a month, send mail about your installation needs now---preferably before the class is even advertised to the public---to minimize the chances of unexpected issues, and to maximize the amount of installation work that can be done in a batch. It's an excellent idea to send mail to before you're even done writing up the class description, so any potential problems can be spotted early.

Note that asking at the last minute risks your class not being able to run at all, which would be a disaster for you, your students, and the Asylum. (This goes double if you simply show up and expect an installation to happen in a few minutes at the start of your class--- chances are, no one will be available right then, and your class will have to do without. Plan ahead!)

If you want software installed that has a limited-time trial license, we can do that, but we discourage it---it means that all the effort of installing the software for your class is effectively wasted once the license runs out, and then we can't run the class again. In some cases, we can install the software on only a small number of machines if it's for a very small class---but that's also a hassle to keep track of, and doing so will slowly "burn out" all the machines for that software. Nonetheless, if you absolutely have to do this, be very clear about the timing of your class and the license terms---if you're teaching a one-month class on a one-month license, you'll have to be precise about when you want the software to be installed so it doesn't run out halfway through your class.

Do not ask us to install software for which we are not licensed. We just won't do it. That includes cracked versions, versions from sources we deem sketchy, requests to repeatedly uninstall and reinstall trial software (which only works for some packages anyway), and all similar requests. If you want to run sketchy software, do it on your own machine, not ours. If you need sketchy software to teach a class, reconsider how you're teaching the class.

If your software costs money, you're the one who has to buy it, not us. We're happy to install such software, but you can't assume that we'll pay for it. If this is for a class, please make sure that such software is factored into your budget for the class.

If you're using software that has to interact with hardware, such as Arduino programmers and the like, you need to make the precise hardware you're intending to use available at the same time the software installation will happen---especially for Windows installations. This is because, in many cases, the hardware will require Windows to locate and install device drivers, and that often requires administrative privileges. Note that even slightly different revisions of ostensibly the same board sometimes have, e.g., different USB/serial chips, and thus would trigger a device driver installation. (This is common for Arduinos.) So be careful about your hardware revisions, and check in advance.

If you want software installed under Linux, software that is already available in the package system for our existing OS release is a no-brainer. (Universe, Restricted, etc are all okay.) If it requires being built, that's a little more involved, and we'll want to make sure it doesn't also try to step on an existing package. (For example, Processing apparently requires Sun/Oracle's version of the JDK, which is inconsistent with the JDK distributed as an Ubuntu package.) Sorting out the conflicts and dependencies can be time-consuming, and making sure that OS upgrades or patches don't step on the installation can require extra attention. So if you can find it in the package system instead, please do. If installing one package automatically pulls in a bunch of dependencies, don't bother listing all those dependencies; apt-get will do the right thing anyway.

If you're asking for an installation, please include the following information:

  • Which operating system you'd like the software installed on (Windows, Linux, both?)
  • How to find the software. (A URL going to the precise version you'd like is best, though for Ubuntu package installs, just naming the package is fine.)
  • Whether the software will be talking to any hardware, and if so, what.
  • Your deadline. More warning is always better.
  • Whether this is limited-time trial software, and, if so:
    • Its timing constraints
    • Your class size (in case we only want to install it on one or two seats)

Also, if the software is likely to be particularly large (over a gig), please mention that if you know. It can help with planning.

By default, any installation will go to all ten machines, so their configurations stay similar. We may make exceptions for huge packages which few people will use, certain trial-licensed software, and so forth.

Some internal details

You don't need to know the stuff below to use the machines. It's here because every so often someone asks about it.


Don't store your files on these machines. Things left on the desktop may be deleted at any time, and the entire machine may be reinstalled at any time. See above for more details. In particular, desktop clutter is routinely deleted without warning anytime a round of software installation happens.

With that said, the Windows partitions are occasionally backed up, by taking a snapshot of the entire partition as a set of blocks and stashing it in an alternate partition on the same disk. Those snapshots are occasionally stored somewhere else, e.g., so losing a disk doesn't lose its backup. This is one reason why installations are batched---after a batch of installations is a good time to take a snapshot.

If a machine ever has some serious software-related problem, the entire partition image may be rolled back over the existing partition. This is one reason why you can't depend on your own files surviving at any given moment.

If for some reason you think a particular machine's configuration has gotten bashed, let us know, and we can probably restore the machine to a pre-bashed state.

Note that the Linux partitions are not currently backed up. Since they don't require individual licensing, it's far easier just to reinstall if anything goes seriously wrong, and the chances of that are lower than for Windows, anyway.

Individual installations

These machines are individually installed; they're not installed from a single master image. On the Windows side, we do this for several reasons:

  • Setting up the infrastructure for master-image installation is a fair amount of work.
  • It requires Pro and/or OEM licenses, which cost a lot more than the Home Premium licenses we have.
  • Pushing a new image over the wireless would take forever, especially to all ten machines.

Unfortunately, these constraints lead to several annoyances:

  • Running Home Premium means we can't use a centrally-administered user database, or use Active Directory at all.
  • Software must be installed on each machine individually, rather than once on a master image.

The issues above are some of (but not all of) the reasons why we have very tight restrictions on administrative access to these machines under Windows: It's just way too easy for a machine's configuration to either diverge from the rest, or get completely screwed up, and it's quite a lot of work to recover. Recovery in some cases could involve starting from scratch, with an installation of the OS and all applications, unless we're 100% positive exactly when the problem being recovered from first started, and thus can potentially use an existing image backup. This sort of from-scratch recovery is a tremendous amount of work to expect from a volunteer position for even one machine, much less ten. In addition, experience has shown it would very likely have been required several times in only the first few weeks we had the machines if users had been allowed to install software on their own. [In just those first few weeks, we had users and/or instructors who, because they didn't know better, wanted to install software with questionable or cracked licenses, from sites which were likely malware vectors, etc.] Finally, because we can't centrally administer passwords (Home Premium, hence no Active Directory), even handing out a temporary installation password is painful, because it requires turning on and setting up all ten machines to set the password, and the same amount of work to revoke it. (And we must revoke it---otherwise, experience demonstrates that any such password would be passed around almost immediately.)

In a more-traditional setup, with OEM-licensed software, hardwired Ethernet, and central password administration, it would be easier to allow administrative-like access, with the proviso that entire new images might be steamrollered over whatever users had done. In fact, many computer labs do this every time a user logs out. But that's a level of infrastructure that isn't warranted in our environment, would cost us quite a bit of money to set up, and isn't compatible with our reconfigurable physical setup.

The Linux side is somewhat easier to cope with, because a reinstall is much less work, and easier to automate. However, at the moment, the machines are still individually installed, with some simple homegrown tools for automating parallel deployment of patches and additional packages. At some point, we may use something more full-blown, but not yet, and again the issue of installation via wireless means that having to start from scratch frequently would be painful. However, if you have a good reason to need administrative access on one or more of the Linux sides, that can be arranged.

Personal tools
Wiki Maintenance