Linux as an Internet Kiosk
If you are at all interested in consumer applications of the Internet, you have no doubt heard about cybercafés and so-called “Internet kiosks”. Both attempt to bring ubiquitous Internet accessibility to the general public. In cybercafés, the idea is to let you browse the Internet (or even do real work) while basking in the comfort of a familiar café. Internet kiosks are supposed to be quick and easy-to-use stations for checking e-mail or looking up a bit of information on the Web.
Café Liberty, a cybercafé in Cambridge, Massachusetts, was the first of its kind in the greater Boston area, founded in the fall of 1994. From the start, we have had several computers available for use by customers for a small hourly fee. Our own experiences, coupled with that of other café owners, eventually led us to the conclusion that there were a lot of us interested in giving their customers Internet access, but who had absolutely no idea how to go about it.
In March 1996, the NetPod project was born, to be funded and managed by Café Liberty. We set out to build a public access Internet terminal, a “NetPod”, that would allow anyone with a dollar to surf the Web, TELNET, check e-mail or do any common Internet function. The system had to be extremely easy to use, foolproof, fast, reliable and painless to install in the target site. Perhaps not surprisingly, we chose Linux for every machine in our network. The article, “Linux—The Internet Appliance?” by Phil Hughes, in the April 1997 Linux Journal struck a chord with us, since much of what he said is exactly what we are doing. While our system is not designed for the home, it does attempt to provide an interface that anyone can understand, it does it on cheap hardware, it is an Internet appliance and, of course, it runs Linux.
In order to understand our network architecture, it's necessary to understand what kind of services we wish to offer. When a user approaches the NetPod, he sees a heavily modified XDM (X Display Manager) which presents him with several options: Guest Login, Account Login, About and Create Account (see Figure 1). The machine costs six dollars an hour to use, paid in increments of one dollar for ten minutes. Users insert bills into a bill validator on the side of the NetPod (see Figure 2).
A guest login provides access only to Netscape Navigator and to TELNET, while an account (which costs three dollars a month) also provides e-mail (both sending and receiving) and access to Usenet newsgroups from a full news feed.
After login, the user is presented with a large Netscape window and a tool bar on the right hand side of the screen that lets them switch between the various parts of the system (see Figure 3). Their remaining time is also displayed on the tool bar. When an account holder logs out, their remaining money is kept for their next login session. When a guest logs out, any remaining money is lost.
As mentioned earlier, we used XDM for the login screen. This is because XDM is relatively easy to modify and takes care of all the details of logging a user in, like setting X access controls and creating an environment. The entire login program was simply linked to XDM through the Greet() function. Since we didn't want to deal with much of the bloat of Motif or the complexity of the X toolkit, we designed our own library of GUI tools for the NetPod. This let us tailor every last detail of our system's appearance. It also let us easily construct unique interface elements, like shaped graphic buttons, some of which can be seen in Figure 1.
The tool bar was considerably more difficult to write. We chose to use FVWM as a window manager because it is easily customizable and provides a module function that allows a separate program to probe FVWM's internal window information and structures. We configured FVWM to allow no window movement, no special menus and no key control; in short, it was locked up tight so the user couldn't do anything involving window management.
The tool bar continually receives information from FVWM about window updates so we can extract the window IDs of Netscape windows, TELNET sessions, etc. and move around the windows when the user clicks on the tool bar buttons.
This scheme would work fine, if Netscape were a relatively simple program, but Netscape opens many other windows during normal operation, such as mail and news windows, dialogs and others. Keeping track of all these windows is a bit of a chore, and it has only become more difficult with our recent incorporation of Netscape Communicator, which opens far more windows than Navigator.
Simple though it may be, many users have praised our straightforward interface for its ease of use and its speed. People used to sluggish Windows and Mac systems simply cannot believe machines like ours (Pentium 100 with 16MB RAM) can be as quick and responsive as they are—which is due in large part to our use of Linux and the X Window System.
|Speed Up Your Web Site with Varnish||Jun 19, 2013|
|Non-Linux FOSS: libnotify, OS X Style||Jun 18, 2013|
|Containers—Not Virtual Machines—Are the Future Cloud||Jun 17, 2013|
|Lock-Free Multi-Producer Multi-Consumer Queue on Ring Buffer||Jun 12, 2013|
|Weechat, Irssi's Little Brother||Jun 11, 2013|
|One Tail Just Isn't Enough||Jun 07, 2013|
- Speed Up Your Web Site with Varnish
- Containers—Not Virtual Machines—Are the Future Cloud
- Linux Systems Administrator
- Lock-Free Multi-Producer Multi-Consumer Queue on Ring Buffer
- RSS Feeds
- Senior Perl Developer
- Technical Support Rep
- Non-Linux FOSS: libnotify, OS X Style
- UX Designer
- Reply to comment | Linux Journal
18 min 25 sec ago
- Android has been dominating
22 min 57 sec ago
- It is quiet helping
3 hours 8 min ago
3 hours 25 min ago
- Reachli - Amplifying your
4 hours 42 min ago
5 hours 30 min ago
- good point!
5 hours 33 min ago
- Varnish works!
5 hours 42 min ago
- Reply to comment | Linux Journal
6 hours 12 min ago
- Reply to comment | Linux Journal
8 hours 38 min ago
Free Webinar: Hadoop
How to Build an Optimal Hadoop Cluster to Store and Maintain Unlimited Amounts of Data Using Microservers
Realizing the promise of Apache® Hadoop® requires the effective deployment of compute, memory, storage and networking to achieve optimal results. With its flexibility and multitude of options, it is easy to over or under provision the server infrastructure, resulting in poor performance and high TCO. Join us for an in depth, technical discussion with industry experts from leading Hadoop and server companies who will provide insights into the key considerations for designing and deploying an optimal Hadoop cluster.
Some of key questions to be discussed are:
- What is the “typical” Hadoop cluster and what should be installed on the different machine types?
- Why should you consider the typical workload patterns when making your hardware decisions?
- Are all microservers created equal for Hadoop deployments?
- How do I plan for expansion if I require more compute, memory, storage or networking?