Letters to the Editor
Just read your column about C++ [LJ, June 2003]. It is deliberately provocative, and as such, it will get you a large number of well-deserved replies. One point I wanted to make: C++ is getting old and still is not there. It is way away from being the main programming language, and I can see two main reasons for that.
The first is lack of standardization. C++ got ANSI less than ten years ago and still has no standardized ABI. Net result: installing C++-dependent software and libraries is a nightmare. If you ever tried to compile some KDE apps yourself you know what I mean. It does not stop there, however; the fact that you cannot link together two objects compiled with different compilers prevents vendors from easily distributing binary libraries. Not only a technical issue, it also becomes a commercial one.
The second reason is complexity.
C++ has accumulated so many features over the years that it has
become incredibly complex. I believe I can safely say that nobody
can master all of it. Result: put together a team of, say, ten people,
each of them mastering 90% of the language (that is, really good
C++ programmers). Chances are that the 10% they don't know will not
be the same for all programmers. You will end up with pieces of
code that can be understood only by the people who wrote them.
This is a disaster waiting to happen. Most project managers will
refuse to sign for a language that will bring more trouble than
it may solve. You just started a language war; you expected such things to
happen, didn't you?
In the April 2003 issue, David Bandel mentions
psh as an alternative shell to bash. Although psh
is the most feature-rich Perl shell I've seen,
it doesn't seem to be lighter as David claims.
I'm running psh 1.8 on my Gentoo box, with Perl 5.8.0.
top shows psh
resident in 3964k of RAM, while showing bash at only 1440k.
It would be great to see future optimization of
this shell, because Perl is already competing with
traditional shells as the de facto scripting
language on many systems.
Christopher J. Pilkington
I manage several research networks where I have
been using Linux (Red Hat mostly) for quite a few
years and have been very pleased with not only the
functionality but the great response from the Open
Source community. This week, I received a somewhat
unsettling call from a Red Hat sales rep when I
asked for info on their Red Hat Enterprise Linux AS
operating system. I was told that on December 31,
2003, Red Hat will discontinue support for their
OS, with the exception of their Enterprise line,
priced at $1,499–$2,499 per year, per server.
I asked what the Enterprise version offered that
I did not get with the versions I was currently
using, and was told I would get support and an
extended life on the kernel version (2.4.9). I am
a firm believer in trying to support development
in the Open Source community, and paying for a good
OS is just part of doing business, but $1,499–$2,499
per server actually seems more expensive than the
Microsoft offering, Sun Microsystems or Apple OS
X Server. How do the hardworking programmers who develop the
open-source code feel about someone selling it for
what appears to be a substantial profit?
MIS/MIT MIND Institute
I recently purchased a Sharp Zaurus 5600 and am very, very glad I
saved a copy of your January 2003 magazine containing a good article
about the Sharp Zaurus. I had a few questions about things I had read
and sent a message to
Guylhem Aznar, who promptly responded and quickly helped me. Keep up
the good work! Thank you for producing such a great magazine! Keep the
Zaurus articles coming!
Jonathan M. Rose
President, Farious Net Solutions
The Linux Journal October 2002 article, “Why the Public
Domain Isn't a License” (/article/6225) seems to disagree with prevailing wisdom as well as this rather
official-looking CMU page: www.cmu.edu/innovationtransfer/Home/documents/ipg6.html.
More specifically, they seem to disagree about whether something can be
placed in the public domain by a deliberate act.
Is there any way of clearing up this confusion?
Lawrence Rosen replies: I wrote the article to clear up confusion but apparently that hasn't helped. I don't recommend dedicating software to the public domain and am not convinced such a dedication is fully effective. Instead, use a license (like the BSD license) that accomplishes everything you want without disclaiming ownership.
I was gratified to see Richard Harlan's article
“Network Management with Nagios” in the July
2003 issue. We converted to Nagios last fall
after using another popular and widely available
management tool for several years. The old tool
was free as in “free beer”, but its license
severely restricted our use of it in some emerging
business opportunities, so we went looking for an
open-source replacement. Nagios fit the bill nicely. The flexibility
is awesome. Using the plugins from the APAN
Project (apan.sourceforge.net), we were able to use Nagios to accommodate
our Multi-Router Traffic Grapher
monitoring of traffic through network
devices. It was then easy to extend
Nagios to use Round Robin Database
to record and graph such diverse indicators as
ping times, disk utilization, CPU and memory
usage, RAS dial-up sessions, IPSec VPN sessions
and database license usage.
The visibility it gives us into our network has
proven its worth multiple times from identifying
software with a memory leak on one server to
finding a piece of spyware saturating a network
segment on another machine. This is a tool that
should be in every network admin's bag of tricks.
I've been reading Reuven Lerner's articles for several months now. Although they're very good articles, he never includes any graphic examples. One article mentioned how great and customizable the user interface was, with different color options. Again, no examples. Please Reuven, show us something.
PS: Marcel's Cooking With Linux is the best! Don't
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!
- Django Models and Migrations
- Hacking a Safe with Bash
- Secure Server Deployments in Hostile Territory, Part II
- Home Automation with Raspberry Pi
- The Controversy Behind Canonical's Intellectual Property Policy
- Huge Package Overhaul for Debian and Ubuntu
- Shashlik - a Tasty New Android Simulator
- Embed Linux in Monitoring and Control Systems
- KDE Reveals Plasma Mobile
- diff -u: What's New in Kernel Development