Linux for Science Museums
An orderly development process is important here because of the educational goals and target audience. Some of the following actually may be quite informal, but it is important nonetheless. Your development cycle may not be exactly like this, of course.
The kickoff meeting: if you're building a standalone exhibit that is not part of a coordinated exhibition, this may not happen. Tech City, however, was to consist of around a dozen coordinated exhibits, with a central theme of engineering. Therefore, an all-day kick-off meeting was held to discuss project goals and to arrive at an initial focus. I've attended several meetings of this type, and all were well worth the time. In addition to getting a feel for the project, you'll pick up a few good ideas and meet people who may be helpful later on in the process.
Brainstorming: put your feet up and don't even worry about Linux until you come up with a few good ideas. On the other hand, if you know of a good existing application that could be modified and made useful, mention it and make note. While kicking around your cool ideas, keep handy a list of the project requirements. These can range from something quite simple, such as “demonstrate a type of engineering”, to something more difficult, like “demonstrate Heisenberg's Uncertainty Principle for elementary schoolchildren in a nonstructured, graphical manner using virtual manipulatives.” Always keep the requirements in mind, but I can guarantee that they'll change right up to the day you ship.
Prototype construction: this phase is the same as building prototypes anywhere else, but it can be even more fun because of the people you're working with. The museum people we've worked with over the years have been intelligent, creative and enthusiastic about their jobs. Don't be too shocked by the appearance of the kiosk prototype if your exhibit requires one. There's probably going to be a lot of duct tape and cardboard involved.
First review: this is where you show off your prototype for the first time, for critiquing. Don't worry if the adults involved in the process don't think your exhibit is as cool as you know it is. Remember, most adults don't think like kids. Show your prototype to a few kids in the target age range, informally.
Target test: this might be the most fun part of building your exhibit. It's the first, and possibly second and third, time that it's set up for museum visitors to try, so you and possibly other people can observe the results. Expect to go through this process several times. Important questions to consider include: Is the exhibit inviting to visitors? How long do visitors stay at the exhibit? Do several visitors use it together? Do visitors learn what you're trying to teach? Do visitors use the exhibit the way you intended? Can visitors figure out how to use the exhibit successfully? Does it appeal to the correct age bracket?
You may be able to interview visitors after they've tried your exhibit, or museum personnel may do so and report their results to you. This is probably the most valuable information you'll receive; kids can be brutally honest.
Professional evaluation: there are firms with expertise in evaluating educational programs such as museum exhibits. If your exhibit is being built as part of a National Science Foundation (NSF) grant, it likely will be evaluated by one of them. We've only had the opportunity to deal with one of these firms, Inverness Research Associates, but found their comments to be extremely helpful. If you have the chance, observe them at work—you'll learn a lot.
Revision, including code cleanup: like the prototype construction step, this is similar to what it would be like anywhere else. It's well worth taking the time to add extra comments and clean up any kludged code. Museum software tends to accumulate extra bits and pieces. If you need to modify your software sometime in the future, the extra time spent now may more than pay for itself later. At this stage, the nice versions of the non-computer parts of your exhibit are probably being built as well.
Deployment: again, this isn't much different from anywhere else, though you'll want to keep the turnkey and no-maintenance requirements of this sort of project in mind. If your software is shipping as part of a larger exhibition, remember that museum personnel will be extremely busy at this point, so make things as easy as possible for them. System deployment for Tech City ultimately consisted of setting up the systems—four targets, plus a spare—installing Linux on each and testing with the CD-ROMs we'd already prepared (see the Tips and Tricks section below).
Your software may have to run on an old PC that has been sitting around unused or on a latest-generation machine that has been donated specifically for the project. Or, if you're lucky—from the Linux driver perspective at least—you'll get a machine that is one generation old.
If you're able to specify the deliverable hardware, be conservative; try to look at this from the turnkey system viewpoint, as opposed to office desktop. Well-debugged hardware and drivers are probably going to be worth more to you than the latest-and-greatest devices, and saving a few degrees of cabinet temperature by using a somewhat slower processor and video board might prevent a failure six months from now in a faraway museum on a warm summer day. Don't be stingy with system cooling. If you can, specify good-quality fans, and make sure that whoever builds the exhibit kiosk, if there is one, provides for adequate airflow to and from the computer.
The Tech City software was deployed on donated Hewlett-Packard Vectra 400s, each with a 1GHz PIII processor, an i810 chipset with onboard video and a 20GB HD. We also added an Sound Blaster 16 PCI card to each machine, as Sound Studio requires either a full-duplex sound card or two cards without that capability. Each system was supplied with a 19" monitor, also donated by Hewlett-Packard.
Practical Task Scheduling Deployment
July 20, 2016 12:00 pm CDT
One of the best things about the UNIX environment (aside from being stable and efficient) is the vast array of software tools available to help you do your job. Traditionally, a UNIX tool does only one thing, but does that one thing very well. For example, grep is very easy to use and can search vast amounts of data quickly. The find tool can find a particular file or files based on all kinds of criteria. It's pretty easy to string these tools together to build even more powerful tools, such as a tool that finds all of the .log files in the /home directory and searches each one for a particular entry. This erector-set mentality allows UNIX system administrators to seem to always have the right tool for the job.
Cron traditionally has been considered another such a tool for job scheduling, but is it enough? This webinar considers that very question. The first part builds on a previous Geek Guide, Beyond Cron, and briefly describes how to know when it might be time to consider upgrading your job scheduling infrastructure. The second part presents an actual planning and implementation framework.
Join Linux Journal's Mike Diehl and Pat Cameron of Help Systems.
Free to Linux Journal readers.Register Now!
- SUSE LLC's SUSE Manager
- My +1 Sword of Productivity
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- Managing Linux Using Puppet
- Non-Linux FOSS: Caffeine!
- Doing for User Space What We Did for Kernel Space
- SuperTuxKart 0.9.2 Released
- Google's SwiftShader Released
- Parsing an RSS News Feed with a Bash Script
- Rogue Wave Software's Zend Server
With all the industry talk about the benefits of Linux on Power and all the performance advantages offered by its open architecture, you may be considering a move in that direction. If you are thinking about analytics, big data and cloud computing, you would be right to evaluate Power. The idea of using commodity x86 hardware and replacing it every three years is an outdated cost model. It doesn’t consider the total cost of ownership, and it doesn’t consider the advantage of real processing power, high-availability and multithreading like a demon.
This ebook takes a look at some of the practical applications of the Linux on Power platform and ways you might bring all the performance power of this open architecture to bear for your organization. There are no smoke and mirrors here—just hard, cold, empirical evidence provided by independent sources. I also consider some innovative ways Linux on Power will be used in the future.Get the Guide