Letters to the Editor
Any chance you could start putting the LJ code examples on the web site, so I don't have to type the stuff in? Especially hairy stuff like the PGP patch on page 6 of the February '97 issue. Sheesh. Really, I think this would be great. —Peter Watkins Washington, DC email@example.com
We think this is a good idea too, and starting with this issue, example code can be found at ftp://ftp.linuxjournal.com/lj/listings/issue##/. The files are tar, gzip files, one for each article, named article##.tar.gz. There will be a footnote to each article that has listings in it, giving you the article number.
My first question is, “What does CGI stand for?” The second question is, “Why did the editor/s never ensure that the abbreviation was defined at least once in the magazine?” This lack of definition of acronyms is very annoying to me since the computer world is so chock full of acronyms. Acronyms in this environment are also very context-sensitive—so much so that defining terms like this should be mandatory in every article published anywhere. —Mac Bowles Senior Software Engineer Lockheed Martin Astronautics firstname.lastname@example.org
First, CGI stands for Common Gateway Interface. Second, I agree that tossing acronyms around without defining them is annoying, and plan to be more careful in the future.
I have read the letter to Linux Journal from Mr. Jack McGregor, who is pushing usage of dumb terminals for schools (low cost). I am a Linux consultant. However, I am not pushing dumb terminals, but Linux-based X terminals using old 386 and 486 PCs. My experience with low end 486s demonstrates that indeed they are very fast and fun to use to operate major desktop packages (WordPerfect, Netscape, Applixware and StarOffice are a few I have tried). They can also run games (e.g., Doom).
I have customers who have turned to this solution not to save money but to gain raw speed. For example, one is using a dual Pentium Pro 200MHz with 192MB of RAM as a server for 10 users (C++ developers). Everything is in RAM all the time for all users. This beats any network when it comes to loading software or searching through directories and so on. In one case, the speedup they are getting by sharing the same server instead of the more standard Windows-to-server relation is close to a factor of 10.
While X is an old technology for some, Linux is making it into a revolution because of its low cost. —Jacques Gelinas email@example.com http://www.solucorp.qc.ca/linuxconf/
I have been using the Slackware distribution 3.0 (1.2.13 kernel) for over a year. I wanted to upgrade to the 2.0 kernel, and decided that a new CD-ROM distribution would be convenient. After reading about Red Hat 4.0 in the LJ Readers' Choice Awards and an InfoWorld review that selected Red Hat 4.0 as one of the two best operating system releases in 1996 (the other was NT workstation), I decided to order.
My installations (about a dozen trials) were plagued with random segmentation faults, stack-dumps and reboots. The Red Hat support team responded as advertised and suggested hardware (i.e., CPU, RAM, cache, motherboard) was producing my problems. The Red Hat technician pointed me toward RAM or cache because I just had a brand-new motherboard installed, and he presumed that the motherboard or the brand-new cache was not a problem. Finally, the Red Hat technician suggested that:
“Red Hat is sometimes not able to run (for unknown reasons) on some hardware that will run Slackware.” (E-mail from Red Hat support.)
I had my RAM diagnosed by a local computer repair shop that has a hardware technician who is a also Linux guru. No problems were reported with the RAM, but the technician could not duplicate my installation symptoms.
Finally, a bit dazed and still suspecting the RAM, I purchased some extra RAM. I tried the installation one last time, using only the new RAM—I still could not successfully install Red Hat 4.0. Alas, I am back to the Slackware 3.0 and out $60 for the Red Hat.
I am truly disappointed that I cannot get Red Hat 4.0 working. It seems Red Hat has so much to offer new Linux users in terms of configuration, installation, etc. But, as Microsoft can attest, it will be difficult for any commercial distribution to support every PC configuration. My PC is the evidence.
All is not lost, though. As the web master for our software manufacturing firm, I take care of the Intranet Web pages. We need a new internal web server, and I am adamant that it runs on a Linux box. Maybe the Red Hat distribution can foot this bill. For my PC though, I am sticking with Slackware. —Jeffery C. Cann Software Engineer firstname.lastname@example.org
Getting Started with DevOps - Including New Data on IT Performance from Puppet Labs 2015 State of DevOps Report
August 27, 2015
12:00 PM CDT
DevOps represents a profound change from the way most IT departments have traditionally worked: from siloed teams and high-anxiety releases to everyone collaborating on uneventful and more frequent releases of higher-quality code. It doesn't matter how large or small an organization is, or even whether it's historically slow moving or risk averse — there are ways to adopt DevOps sanely, and get measurable results in just weeks.
Free to Linux Journal readers.Register Now!
|Secure Server Deployments in Hostile Territory, Part II||Jul 29, 2015|
|Hacking a Safe with Bash||Jul 28, 2015|
|KDE Reveals Plasma Mobile||Jul 28, 2015|
|Huge Package Overhaul for Debian and Ubuntu||Jul 23, 2015|
|diff -u: What's New in Kernel Development||Jul 22, 2015|
|Shashlik - a Tasty New Android Simulator||Jul 21, 2015|
- Secure Server Deployments in Hostile Territory, Part II
- Hacking a Safe with Bash
- KDE Reveals Plasma Mobile
- Huge Package Overhaul for Debian and Ubuntu
- The Controversy Behind Canonical's Intellectual Property Policy
- Home Automation with Raspberry Pi
- Shashlik - a Tasty New Android Simulator
- Embed Linux in Monitoring and Control Systems
- diff -u: What's New in Kernel Development
- General Relativity in Python