Linux as POS in Pizza Bars

by Steve O'Connor

I am fortunate in that I started my career in the mid-80s as a UNIX applications programmer. Computers were fun then: Ataris and Amigas were breaking new ground each month, UNIX minis were fighting hard against the tide of IBM system 36s and 38s, and innovation ruled the day. Toward the end of the 80s, a new system, MS Windows, began gaining a tiny toehold in corporate computing. This new system offered three main advantages over minis :

  • Lower entry cost

  • Easy access to technical information

  • Ability to include exciting graphical interfaces

Many developers took to writing new applications in this new paradigm. Back then, I remembered that most corporations considered Windows something of a “renegade OS”, but the fact that a lot of new development was happening (and still happens) under Windows has helped to change that perception over time.

By 1994, I was a true believer. I lived and breathed MFC, VC++, OLE, VXD's and DLL's. Yet somewhere in the back of my mind lurked a deep yearning for the power of a UNIX command line. One day, when I got the money together, I would buy a Sun workstation and get a real computer for the home office. At that same time, one of my co-workers started telling me about Linux. I dismissed it at first—I simply assumed that a “free UNIX clone” would be some toy system that ran slowly, crashed often and lacked fundamental commands such as grep and find. To me, Windows was the key to the future, because in any objective comparison, the cost plus power of Windows would prove to be a better buy. I remember saying to him at the time: “The day that Linux is running the local pizza bar, I will start to change my mind.”

As 1995 came around, I was annoyed at having to upgrade all of my tools (again) in order to keep on the leading edge. Windows 95 was due out soon and the Win32 API was the thing to be using. I was faced with the prospect of possibly having to rewrite all of my core libraries (again) due to a company on the other side of the world which decided to change its APIs (again). I began to feel somewhat trapped.

August 24, 1995—Enter Linux

The day Win95 was released to the public, I walked down to the software shop at lunchtime, slipped past the queues of people holding Win95 boxes, and (purely out of curiosity) purchased a copy of Getting Started With Linux. For $35, this was half the cost of a book covering some of the new Win32 APIs. I was amazed to discover the book also included a CD for that price.

I installed Linux within a few hours and was literally stunned at what I found. I really did not expect to get a real system with X, compilers, source, etc. The whole experience changed the way I looked at a lot of things.

In the intervening period, I have used Linux at each place of work as a development platform for all manner of applications, web servers, database servers and more.

The Prophecy Fulfilled

In October 1997, a chance meeting with an old friend led me to a potential client who was looking to computerize a pizza bar/restaurant in Adelaide. While I normally work on large contract projects on enterprise level systems, I felt compelled for a number of reasons to take this job. While the irony of fulfilling my own comment from two years ago was indeed a factor, I also saw this as a good opportunity to prove that Linux can compete on traditional PC home ground.

A number of existing systems were available at the time for the restaurant owner to choose from; two other systems running under DOS, and one under Windows. All of the other systems were proven in existing restaurants and available at a low price. The decision on which system to purchase would come down to a number of factors:

  • Price

  • Ease of use/training

  • Reliability and support

  • Future expansion to handle multiple stores

Was it possible to produce something from scratch, in a limited time frame, and still beat the competition in all four categories? I assembled a team of three programmers, and we took the risk.

Figure 1. Main selection screen for the delivery orders shows the last orders that have been processed and allows the user to enter the customer phone number or name when they ring up for an order.

Figure 2. Shows the main order entry screen. The fields on the left scroll up and down to allow unlimited items to be added to an order, and the graphic panels on the right display a quick view of all of the various codes.

Linux helped us in the following ways:

  • Price: For a start, we had no operating system cost overhead. While this saved only about $100 initially, it would be a bigger factor when considering additional machines. Also, the wealth of freely available development tools gave us a big edge over the other systems. Finally, we could go with a more modest hardware configuration compared to the Windows solution, while still achieving the same level of performance.

  • Ease of use: Using Java, we produced nice GUIs that were as easy to use as any Delphi or VB application. For training, the X Window System allowed us to dial into the customer machine using PPP and redirect our screens onto the customer's monitor to discuss new features, while talking to them on the phone.

  • Reliability: These days it is easy to point to the proven track record of Linux as far as reliability goes. Selected articles from magazines such as Linux Journal continuously demonstrate this point.

  • Support: Linux allows us to take full control of the customer's machine from a remote location. This is especially important when a pizza bar, located 30 miles from your home, has problems at 3 o'clock in the morning.

  • Future Expansion: Linux's excellent ability to handle a distributed system comes from a long and proven track record of success as an Internet server. When you start talking about distributed databases linked via low cost dial-up lines, the opposition starts to look very shaky indeed. Most things in UNIX-based systems are a bit ugly to do, but a simple and elegant solution is always close at hand, no matter how complex the problem. The other systems, by comparison, tend to offer very friendly point-and-click solutions to simple problems, but also tend to get exponentially more difficult as the problem becomes more complex.

Figure 3. Displays the customer details, along with statistics and a history of orders.

Figure 4. Displays the contents of the docket exactly as it is printed. The generated dockets are also stored in the database, and can be viewed and reprinted at any time.

The Requirements

The requirements for this system were aimed at handling pick-up and delivery orders for pizzas and various other food items. This involves the usual items of a customer database, an items for sale database, an order entry screen, receipt printing and sales reports.

Some of the more esoteric requirements included :

  • Ability to specify pizzas as half one topping, half another

  • Combinations of various types of pasta and sauces

  • Drinks, desserts and miscellaneous items

  • Specials such as “any two large pizzas and a can of Coke for $10”, which may change on a regular basis

  • Minimum order prices depending on delivery location

  • Discount levels for certain customers, with certain items exempt from discount

  • Graphical displays of item codes alongside order entry screen

  • Ability to find previous (or most recent) orders for customers, and order the “same again”

  • Ability to mark customers as “bad” (refused to pay bill, etc.), so that if they call again, whoever takes the call is warned beforehand

The Development Process

We decided to go with Red Hat Linux 4.2 and use the JDK 1.0.2 as the development platform. In order to keep system quality under control, we used a simplified requirement traceability system (like we use on larger defense projects) and regression testing suite. These management tools were cobbled together out of shell scripts in just a few days.

We were all quite familiar with Java, so it took us only one week to produce a working prototype of the screen layouts to present to the client. When the time came to demonstrate our proposal, we brought in a laptop and demonstrated the layout of the system to the client in person. During this initial discussion, we learned of more requirements we had not previously considered. We were able to add these into our requirements-tracking database on the spot, and in some cases, make alterations to the screens to reflect how we might cover these additions in the future. It was pretty obvious to the client that, unlike the other contenders, we did not have a working system we could install tomorrow. However, the client was happy the interface was easy to use, and more importantly, they felt comfortable we would produce something unique and customized for their particular business. Whatever we said, it must have been the right thing, because we were awarded the order. Now we had to prove it could be done.

Development was to be performed at our own discretion, with collaboration via e-mail. This led to a very different development culture than we were used to in our “normal” working lives. When you are feeling very focused, you stay up and write code all night; otherwise, you go out, watch a movie, play Nintendo or just relax. I don't believe this development model had any adverse effect on the timing of the project, but I do believe it added greatly to the quality of the finished product. We all felt very motivated to prove that it was possible to deliver excellent customer service and excellent product quality in a short time frame. We did this with discipline, but also in a relaxed manner.

For a database, we looked at using PostgreSQL, but had some problems running this with Java 1.0.2, so we settled for creating our own simple database system. This database uses a flat file with all of the objects representing customers, orders, items and such. In order to maintain good performance with this arrangement, we set a flag that says “the data needs saving” and we have a separate thread to monitor system activity. When an idle period exceeds a threshold time (two minutes with no data changes), the data is saved and the flag is cleared. Despite the fact that we are using a non-JIT implementation of Java, the whole system responds very fast. I would like to say that even if we have achieved nothing else, we have proven that Java and Linux are a robust combination that you can bet your business on.

The System Comes to Life

Within the next three weeks, we got the system installation ready. After this, we set up the following equipment:

  • Pentium 120

  • 1MB SVGA (Cirrus Logic)

  • 32MB RAM

  • 2GB disk

  • Mouse

  • PCI Ethernet card

  • 33.6Kbps modem

  • Star SP 210 receipt printer

We installed the initial order processing system and set up a PPP dial-in daemon for remote maintenance. Since then, the software has undergone many changes and enhancements, but I am pleased to say the computer has been running 24x7 quite happily since that first install. Because the pizza bar hours are 10 AM to 3 AM, the machine is not turned off at the end of the day and the operating system has never once required rebooting.

It has taken an intensive period of three more months of development to bring the initial system up to the required standard. This has involved periods of time where I personally worked behind the bar and took orders, so that I could truly appreciate the business requirements and not just focus on the computer aspects. This has resulted in an excellent level of attention to detail. For example, no amount of pure computer analysis will alert you to the fact that when you hand the order docket to the cook (whose fingers are smeared in a sticky combination of flour and tomato sauce), the lower right-hand side of the order docket becomes unreadable. Adding a few line feeds to the printout gives the cook a nice spot where he can grab the docket without smearing sauce all over the printing.

We also set up an off-site backup arrangement so that at 4 AM each day, the client's machine dials into my machine and, using FTP, uploads the data files to act as an off-site backup. Should a disaster occur, I can load their data onto a spare machine and have them back in business within hours.

Now that the system has been enhanced to the client's satisfaction, another machine is being installed in the restaurant to handle the order processing and an additional machine and printer being installed to run a new point-of-sale system for the restaurant customers who dine in. (This is another product of ours written in Java 1.1 and PostgreSQL.)

Figure 5. Shows the main display on the point of sale screen to manage the tables in the restaurant. Empty tables are displayed in blue, and tables with customers are displayed in red/brown. A summary of each table's account balance and time of entry make it easy to see what is happening at a glance.

Figure 6. Shows the prices for red wines (from the point of sale system). Clicking on a button adds one item to the account.

Future Enhancements

The pizza bar is now expanding to three new locations. This is being done by locating existing pizza bars in other suburbs and selling them a franchise to join the chain. Part of the franchise arrangement involves the installation of at least one computer and running our Linux-based order processing system. This system adds value to the overall franchise.

To achieve the distributed database requirement, we are currently porting the existing application across to Java 1.1 so that we can use PostgreSQL for the database management. In order to synchronize the databases at the lowest possible cost, we have the main store dial up each branch store in turn to retrieve the last period's new data. The main system then consolidates all of the new data, dials each store again and disseminates the new (complete) database. Because this happens during a period when all stores are closed, there is no possibility of lost data. This approach should work well until we get to the point where the chain of pizza bars is spread across time zones. We will address this point if and when it becomes a requirement.

Another enhancement which PostgreSQL will make possible is the ability to pre-load the system with data commonly available on CD-ROM containing all names and phone numbers for an area. We have tested our Java and PostgreSQL implementation with 1,000,000 names and phone numbers on an AMD K6-233 server and response times are still excellent.

I would like to report soon that Linux + Java + PostgreSQL is also a combination that you can bet your business on.

Beyond Java

At the time of writing, we are currently experimenting with the GTK+ toolkit, with a view to porting the application over to pure C. This appears to be a long road to travel, with GTK+ currently lacking a lot of data-entry-type features. However, the performance improvements do look promising. We may be able to make a contribution to GTK/Gnome by adding some features in this area.

More Information

We all feel that we owe a debt to the Linux community, the GNU community and Sun (for Java) for giving us such a firm foundation on which to build a product. Therefore, we are releasing all of our software under the GPL for others to use. A very old release is currently on the Sunsite archives, but we will release the newer version there as soon as possible.

I sincerely hope that some readers will take the opportunity to download a copy of the software and sell it to pizza bars in their local areas. We do not ask for, or expect, any form of royalty in return; we just get a kick out of knowing that people are using Linux.

I thought it might be interesting to add a random “Powered by Linux” line at the end of the docket printout. I hear that in Redmond, Microsoft employees working late on the latest bug fix for NT often send out for pizzas. I wonder what their reaction would be to get a docket with this line.

Steve O'Connor ( is the Director of Eljay Pty. Ltd. in Adelaide, Australia. Steve has been working with UNIX systems since 1984 and advocates Linux wherever possible. Steve would eventually like to create a suite of business applications under the GPL for a variety of small businesses with unusual requirements. If you have any good ideas for the next opportunity, please e-mail him.

Load Disqus comments