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.
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!
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- SUSE LLC's SUSE Manager
- My +1 Sword of Productivity
- Non-Linux FOSS: Caffeine!
- Managing Linux Using Puppet
- Tech Tip: Really Simple HTTP Server with Python
- SuperTuxKart 0.9.2 Released
- Parsing an RSS News Feed with a Bash Script
- Doing for User Space What We Did for Kernel Space
- Google's SwiftShader Released
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