Linux Does Comics
Last spring I attended a major comic book trade show for comic book store owners. One of the speakers sold software that could be used to maintain comic book subscriptions. I asked him if he could support customers making changes to their own subscription. He said, “No way”-he could not have some kid walking up to a DOS box, because the kid could type CTRL-ALT-DEL or something and destroy the database.
That cannot happen on my dumb terminal running from my Linux box.
Another thing I have wanted to do at the store was run an inventory system on the gaming stock. The gaming stock, unlike the comic stock, can be reordered from the distributors on demand. My partners do not understand how easy it would be to implement an inventory system, but I have all the tools waiting for them, should they some day want one.
I have learned how to print barcodes from scratch. I plan to print product numbers on the labels with my own program so that a barcode reader can be used at the checkout counter. Given:
a last night current inventory,
a model inventory (what we think we should stock) and,
a POS(point of sale)-terminal,
I can maintain a current inventory listing, and a “diff” (list of differences) of the current inventory with the model inventory as a reorder listing. This can be filtered with product listings from game distributors to make the actual reorder lists for each game distributor automatically.
I wanted to know if Linux and perl could keep up with the most important store application, the Point Of Sale Terminal, so I set up a test database using perl's ndbm arrays.
One day I plan to barcode with “code 3 of 9”, a popular barcode format, which would contain the product numbers. Then a light-pen or a laser scanner can read the barcode just like you see at the grocery store. With that item code, an item's price can be looked up and an itemized receipt can be produced. More importantly, it also lets me make a record of what was sold, so we can reorder it.
I have a DOS disk from one of the game distributors that contains their full listing of products - about one Megabyte of data: about 50 characters per record, with about 20,000 records. I set up an ndbm file that mapped product numbers into item description and pricing information.
I stored each key (product number) in an array and picked a random index and looked up that key. I then put that in a loop and ran a few time trials.
With my 386/33dx system, I could access over 300 stock items in my test database per second. If you are really good, you can scan in about 1-2 items per second, and most people are much slower than that. In other words, there is plenty of time to make few database references per item. From that, I can see that there is plenty of CPU power to run a few cash registers, as well as time to edit comic subscriptions and even do some reordering, all at the same time. Remember, this is on an old 386/33dx.
Every now and then I hear what a pain it is to do a reorder, but my partners are not yet ready to take the big step to automate. Some day the store will need an inventory system badly and Linux will be there, waiting for them. The store broke $1.5 million in gross sales this spring, after 3 years in business, so we may need to take this step soon.
If this interests you, here is our address and phone number:
(Games, Comics and Miniatures) 114 North Toll Gate Road Bel Air Maryland 21014 +1 410 638 2400
Sorry, we do not do mail order.
Free DevOps eBooks, Videos, and more!
Regardless of where you are in your DevOps process, Linux Journal can help!
We offer here the DEFINITIVE DevOps for Dummies, a mobile Application Development Primer, and advice & help from the expert sources like:
- Linux Journal
- New Products
- Users, Permissions and Multitenant Sites
- Flexible Access Control with Squid Proxy
- Security in Three Ds: Detect, Decide and Deny
- High-Availability Storage with HA-LVM
- DevOps: Everything You Need to Know
- Tighten Up SSH
- Non-Linux FOSS: MenuMeters
- Solving ODEs on Linux
- diff -u: What's New in Kernel Development