Letters to the Editor

Letters to the Editor: Readers speak out

This 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.

December  1997
[Next story]
[Table of Contents]
Sun's Site

Mail this
article to
a friend
Send letters to sweditors@sunworld.com

"Microsoft countersues Sun on Java licensing" by Marc Ferranti

[Read Me]http://www.sunworld.com/sunworldonline/swol-10-1997/swol-10-countersuit.html

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

"Weeding your Web site, part one" by Webmaster columnist Chuck Musciano

[Read Me]http://www.sunworld.com/sunworldonline/swol-10-1997/swol-10-webmaster.html

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:

  1. Solid background: Some sites have a fancy background with bizarre colors and patterns, making them hard to read and annoying.

  2. Page size: Avoid creating pages with hundreds of lines of text; I become bored and leave these pages.

  3. Loading files:

  4. Huge Diagrams: Some sites contain huge diagrams, pictures, etc.. The result is very long loading time. Instead, prepare a minimized picture of each diagram you wish to include on your site. Place the minimized picture on the page and write near it the actual size of the original diagram. Now the loading of the page will be much faster, and the visitor can choose whether or not to load the original diagram.

  5. Unnecessary pages: Avoid the "welcome" page where the user has to press "continue" in order to move to the main page of the site.

  6. Dynamic text:

  7. Visitor privacy: Honor your visitor's privacy; avoid using cookies as much as possible.

  8. Search results: If your site is prepared to return dynamic search results, allow your visitors to define the total number of search results in a page.

  9. Add links to home pages: If an issue, company, or item is mentioned on the site, link it.

  10. Last update date: Maintain your list updates so that visitors will know, upon returning to a site, if anything new has been added.

  11. Under construction signs: If your page is not prepared yet, do not put up an "under construction" sign. Just don't put it up at all! To do otherwise can seem amateurish.

  12. Link colors: Use the unwritten standard which says that the default color for a link is blue, and red for a link that has been followed.

Amir Liran

Great articles on Web site weeding! More?

  1. Know your customer: Don't create pages that your customers don't want or need. Knowing what your customers are really looking for (and need) keeps them coming back and keeps you employed.

  2. Enforce standards: When you have a site built and maintained by multiple people, they tend to want to add their own twist to "their" pages, or the areas that they are responsible for. This creates havoc with your standards and sends unhappy customers elsewhere.

  3. Keep statistics: Monitor your logs to see what viewers are looking at and why. Real stats on bar graphs and pie charts look good to upper management, who are looking for trends and want to know where to spend budget money.
Dave Yeoman

"Demangling message queues" by Inside Solaris columnist Jim Mauro

[Read Me]http://www.sunworld.com/sunworldonline/swol-11-1997/swol-11-insidesolaris.html

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.

Performance Q&A with Adrian Cockcroft

[Read Me]http://www.sunworld.com/sunworldonline/swol-12-1997/swol-12-perf.html

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:

  1. Why does se think this machine has 30 disks? Even if you count the CD,it's only 26.

  2. If the value of 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


You have too many entries in /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.

You can also try % 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


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.)


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


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.


"Sun releases scripting technology for Java: Jacl promises more power for Java" by Cameron Laird and Kathryn Soraiz

[Read Me]http://www.sunworld.com/sunworldonline/swol-11-1997/swol-11-jacl.html

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:

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.

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.

"Choosing a scripting language" by Cameron Laird and Kathryn Soraiz

[Read Me]http://www.sunworld.com/sunworldonline/swol-10-1997/swol-10-scripting.html

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:

  1. Tcl is like FORTH and LISP in having a degenerate syntax. It goes like this:

    A. A script is a sequence of command lines, and
    B. A command line is a command, followed by the command's arguments.

    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.

  2. Tcl and Python arrive modally. What we mean by that is that it's natural in these two languages both to "batch" whole scripts, and also to interpret parts of them as small, a line at a time. Moreover, there's a comforting continuity between these modes. Although several debuggers exist for both Python and Tcl (generally written in Python and Tcl, of course), they're far less important than newcomers expect, because interactive development is so seamless.

  3. Tcl and Python both install easily on Windows and MacOS machines as well-behaved and ready-to-run Windows and MacOS programs. This encourages beginners enormously.

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.

What did you think of this article?
-Very worth reading
-Worth reading
-Not worth reading
-Too long
-Just right
-Too short
-Too technical
-Just right
-Not technical enough

[Table of Contents]
Sun's Site
[Next story]
Sun's Site

[(c) Copyright  Web Publishing Inc., and IDG Communication company]

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: