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