|
Letters to the Editor: Readers speak outThis month: Readers have their say on Tcl: is it really just a "toy language"? Also, amendments to Musciano's Web site checklist, technical Q&A with Adrian Cockcroft and Jim Mauro, and Cameron Laird and Kathryn Soraiz respond to a flurry of reader mail. |
Mail this article to a friend |
To the editors:
I regret the news that Microsoft is attempting to manipulate Java to exclusively support their current market dominance.
I have grown increasingly weary of Microsoft's blatant dominance of the PC industry. They've never appeared particularly innovative -- just lucky. And now they appear to be bent on a well-funded strategy of market-dominance-by-technicality (in this case, legal technicality).
Microsoft is the Ma Bell of the 90s: They recycle old ideas (and old bugs), and dictate to consumers what we need and how we'll use what we're given.
In example, I recently visited Microsoft's home page to access information on a problem I'm having with one of their programs, but I was denied access to the information because I declined to allow Microsoft to file a consumer tracking device on my hard drive.
Either I accept a loss of privacy over how I use my PC, or I'm left with no solution to my problem with their product. (To date I'm opting for the latter.)
Roz Waugh
Reader suggestions that will keep your site cruising
I have a few suggestions to add to your list:
Ken Selin
I read your article "Weeding your Web site -- part two," in the November issue, and I would like to add more tips to your checklist:
Amir Liran
Great articles on Web site weeding! More?
I enjoyed your column in the November issue of SunWorld.
At one point you state:
"The improved message queue kernel module has been backported and is available as a patch for Solaris 2.5 and 2.5.1."
What is the patch number?
I did a search on SunSolve and couldn't seem to find it.
For 2.5, patch 103732-01.
For 2.5.1, patch 103734-01.
Hi Adrian,
I've been trying to run virtual_adrian
on an Ultra1 with a
SSA112 containing 24 disks. The Ultra1 has a system disk and a CD. Whenever I try to run any se
scripts that monitor disk performance I get the message:
Fatal: subscript: 30 out of range for: disks: Near line 93
I understand from sysdepend.se
that MAX_DISK
is built in. What I don't understand is:
se
think this machine has 30 disks? Even if you count the
CD,it's only 26.
MAX_DISK
is 30, why does it fail on a machine that it thinks has 30 disks?
If I enter main() {printf("MAX_DISK = %d\n", MAX_DISK); }
The result is MAX_DISK = 30
VA works quite happily on an Ultra2 with 18 disks in an SSA112. Is it
possible to override the built-in value of MAX_DISK
?
Jim Cozens
Jim,
You have too many entries in
You can also try
Adrian
/dev/dsk
. Fix it by editing /opt/RICHPse/include/path_to_inst_class.se
to check that "count" is less than MAX_DISK
before it is incremented.
% se -DMAX_DISK=40 disks.se
.
I was monitoring a big ISP site. The main machines were two E4000s
running Solaris 2.5.1 with Netscape and Oracle. Everything seemed
right to me until I started seeing something I couldn't understand:
Running the vmstat
command, I could see 35
processes under label b. This happened even after I executed a reboot.
The machine was O.K., but I can't explain why I have that number of
processes. Any ideas?
Javier Alonso
Javier,
Processes blocked on disk I/O are filed under "b." Look at disk performance, see if you have an overloaded disk, or turn on NVRAM fast-writes in a storage array. (Time to troubleshoot.)
Adrian
I have searched high and low, but I am unable to find a number: What is the approximate overhead associated with running Disksuite?
I understand that RAID5 may have advantages over DiskSuite, but I am looking to justify going one way or the other.
Dave Zwieback
Dave,
The CPU overhead of DiskSuite is negligible. It's low enough that I've never
found it to be an issue.
The performance overhead of RAID5 without NVRAM to accelerate it is
very high. ODS RAID5 is extremely slow. Mirroring is very fast however,
so you should find out if the cost of extra disks amounts to less than the cost of a RAID controller plus NVRAM.
Adrian
The authors write back
SunWorld's recent report on SunScript's release of Jacl prompted a quick flurry of responses from readers. Authors Cameron Laird and Kathryn Soraiz have been answering most of these through private e-mail, and also updating http://starbase.neosoft.com/~claird/comp.lang.java/jacl.html with information of general interest. As they continue to work their way through the correspondence, they've encountered a few specific comments likely to interest SunWorld readers. We've compiled them, along with the author's commentary, below --editor.
Quite a few SunWorld readers responded negatively to our report on Jacl. As one reader put it, "Get real! Tcl is a toy language, unsuitable for serious applications."
We've heard this before. Frustration with this perception
of the language was, in fact, a recurring theme at this summer's
annual Tcl conference: http://www.sun.com/sunworldonline/swol-08-1997/swol-08-sunscript.html
As a result, we researched Tcl in depth, and you're welcome to check out our conclusions at: http://starbase.neosoft.com/~claird/comp.lang.tcl/commercial-tcl.html
The short of it is that many high-profile organizations, including Oracle, Sybase, USN submariners, the World Bank, IBM, Hewlett-Packard, National Semiconductor, Mentor Graphics, SCO, SGI, Beckman Instruments, Centerline, GTE, Mitel, BellCore, Cray, and many, many more rely on Tcl for mission critical performance. It's enough to convince us to take Tcl seriously.
One reader, however, wasn't even interested in taking Java seriously:
We're not out to convince people that Java is on its way to success; plenty of others are already in that business. See SunWorld's sister publication, JavaWorld,for solid reporting on the uses (and misuses) of Java.
Mr. Roy Anderson asked what Jacl has to offer end users. He
wondered, "how will it affect us using Netscape Navigator?"
and expressed interest in whether Jacl promotes or discourages
monopoly in the browser market. SunScript team leader Raymond
Johnson distanced himself from such strategic contentions in
remarks to us. He emphasized, "We are just trying to build
great technology that will develop a strong base of support."
Readers should remember that Jacl began as an academic project
motivated, from all the evidence, by engineering
considerations. Our own judgment is that Jacl's significance in the browser
wars is murky.
99% of Web CGIs are still written in Perl. I'll believe Java is on its way to success when a significant number of CGIs are instead written
in server-side Java.
The cover story for the October 1997 SunWorld on scripting languages inspired quite a few responses from readers. Authors Cameron Laird and Kathryn Soraiz are slowly working their way down the stack, answering most through private e-mail. A few patterns have emerged...
We're still updating http://starbase.neosoft.com/~claird/comp.lang.misc/portable_scripting.html almost daily with amplifications to the article. Thanks to everyone who
has written in, highlights and our responses below:
One of the most frequent requests was for "more
details on Python." Readers also want to know if these languages
are "really reliable enough for serious applications?" There was enough interest in these topics that we're planning in-depth follow-up articles. Write us (cameron.laird@sunworld.com) if you'd like notification when they appear.
A few readers protested that they wanted another language or two
(or six) profiled. We re-reviewed the couple of dozen
scripting languages we initially considered for the article
and found that we're more sure than ever that the "Big Three" best match
the needs and preferences of SunWorld readers as a whole.
On the other hand, we're open to suggestions on specialized
venues that might appropriately publish articles on other
"little languages" for those with particular interests and
needs.
We received appeals for more code, more examples and more
explanations. This was a surprise. We thought readers
looked to SunWorld for an executive summary. Our Resources
pointers detail (and often link to) books and other references that provide
technical details. The letters we received, though, show
our readers are hungry for technical content. In the future,
we'll shift our articles in that direction. For now,
we're publishing as much of our work as we can at http://starbase.neosoft.com/~claird/comp.lang.tcl/examples/,
http://starbase.neosoft.com/~claird/comp.lang.perl/examples/,
and so on.
A special thanks to the readers who asked, "What are the
disadvantages of each language?" It's an astute question,
and one we had in mind when we wrote the article. Perhaps our
touch was a bit too gentle for the liabilities to come through
clearly. Predictably, many of the disadvantages complement the
advantages:
The biggest disadvantage of these scripting languages is perhaps
that few commercial vendors include Tcl and Python with their
operating systems, and not even Perl makes it onto MacOS or Windows.
Many readers will have ten to fifty minutes (and probably many
more, in the case of Perl for Windows) of installation before they
can truly start with the languages.
A couple of readers mildly inquired whether we're serious in
characterizing Tcl as "easier" than the other languages. We
are. The challenge here is in how to explain this briefly.
There are a number of aspects to ease of use. The three that apply in this context are:
A. A script is a sequence of command lines, and
A few more rules have to do with grouping, continuation, and variable substitution. That's the whole thing. Perl and Python are more like C,
BASIC, Java, and so on, for they're based on substantial grammars.
There are situations in which the first two of these characteristics are disadvantages. They certainly are novel to many experienced programmers. However, we do believe that they make Tcl easier for beginners.
B. A command line is a command, followed by the command's arguments.
|
If you have technical problems with this magazine, contact webmaster@sunworld.com
URL: http://www.sunworld.com/swol-12-1997/swol-12-letters.html
Last modified: