Netsurfing With Linux
Throughout the summer of 1994, the Linux box supported our beta effort, which eventually grew to over 1500 users getting copies of our e-zine twice per week. At the same time we obtained another PC to be used for development and production. This was outfitted with X-Windows as a user interface, Perl as the primary development language, and Seyon as the telecommunications program. Work proceeded on developing both our editorial process and on various support tools. So far, Linux was proving to be a very cost-effective choice and quite flexible as a beta test platform. However, our voyage was not entirely smooth sailing.
Early during the Beta test period, we had problems handling the continually-growing mailing lists. Our problems were caused by an interaction between our mailing software (smail at the time), the relatively slow machine, and a slow Internet connection (28.8K modem). In short order, we located another mailer (sendmail) at a Linux FTP site, wrote some Perl scripts, and had a working mail configuration. Linux's flexibility as a development environment was starting to pay dividends.
Of greater concern to us was stability. One of the things we noticed was that the machine was not as stable as we would have liked. It appeared that, for one reason or another, we had to reboot two or three times per month, on average. Frequently, this was due to random segmentation exceptions, or other obscure errors, which would hang-up our machine for no discernible reason. We could live with these occasional glitches during our beta test period, but clearly, this would not do for a production machine which had to reliably serve thousands of readers. However, since these glitches did not seriously impact our beta testing effort, we could put up with them for a while, given the economical nature of the software in particular. We were a happy and cheap startup.
By the fall of 1994, we were on the eve of a formal launch of Netsurfer Digest. Our mailing lists were growing larger and our Internet site was being accessed more and more often. As part of our effort to prepare for our public debut, one of the things we did was upgrade our copies of Linux to the then current version of 1.1.61. We noticed immediately that the new version appeared much more stable than the earlier 1.0.9. This has, in fact, proven to be true over the long term, with the latter version of Linux taking us smoothly through the early days of our commercial existence.
Steady as She Goes: Hauling the Cargo
Throughout the winter of '94-'95, Linux performed flawlessly as our Internet and production platform. Our subscription rates, and therefore our weekly mailings, were growing at a furious pace. We reached the point where it took over 24 hours to mail out one issue to our thousands of direct subscribers. The response time on our system did slow during a mailing, but Linux took the load and completed each run.
The accesses to our WWW server also started taking off. It seemed that every week we were adding another thousand hits to our daily access statistics. The real test came in early January, when we created a special Macintosh issue to coincide with Macworld Expo. Overnight, accesses to our poor 486DX33 PC topped 10 thousand per day as Macintosh aficionados overwhelmed us with accesses. Linux met the load with graceful performance degradation, doing just what a good operating system should do. There finally came a point where our faithful system could take no more and the machine hung. We had pushed our system to its limits.
By the end of January 1995, Linux was routinely handling over 16 thousand accesses to our Web site every day, with peak loads reaching almost 20 thousand hits per day. At the same time, we were handling mailing lists numbering over 15 thousand subscribers for two different e-zines. It was mind-boggling that this free system on a relatively puny machine could do all this. We definitely got value for our money.
We realized in late 1994 that there would come a time when we would have to upgrade our systems to handle the loads imposed by our dizzy growth rate. Simple math told us that, at some point, our weekly mailing would impose such a load on the system that people accessing our site would not be able to get through. Beyond a certain point, a 486 PC, or even a Pentium, would run out of horsepower. To handle tens of thousands of subscribers and tens of thousands of daily hits on our Net site, we would need to upgrade the speed of our feed, arrange for professional mirror sites, and get some serious hardware.
Fortunately, this does not mean that we will abandon Linux. All of our production and development still takes place on a Linux PC workstation. Our current machine, now a veteran of a long and eventful year, will remain hooked up to the Internet as a backup resource. Linux has proven itself in a very demanding environment. We have pushed it to its limits and occasionally beyond. We would not be where we are today without this wonderful operating system, and by extension, without all those who made it the great and powerful tool that it is today. We can only hope that by publishing our free e-zines, by making them entertaining and useful, we can return something to that vast Internet community without whom we could not have our dream jobs.
Arthur Bebak is a veteran of the Silicon Valley computer community, with a background in computer engineering and project management. As founder and publisher at Netsurfer Communications, Inc. he currently tries to stay out of the way of his talented staff as they create some of the best netsurfing e-zines currently available. Arthur can be reached at email@example.com. To see what Linux has helped create you can visit the Netsurfer Digest home page: www.netsurf.com/nsd/.
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
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- My +1 Sword of Productivity
- 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