Reading Between The Lines

Feeling the need to comment, as so many others have, on the October 1999 article "Is Linux ready for the enterprise?" [p. 92], I wanted to say that I thought the article provided the first rational discussion of the Linux hype.

My understanding of the article was that it wasn't downplaying Linux, but trying to counteract the hype that Linux is going to do away with Windows. Since so many in the Linux religious fold preach the overthrow of the Windows operating system, the article tried to present what the typical user is faced with if they undertake this mission.

Windows works amazingly well considering all of the various drivers and components that it must somehow seamlessly recognize and make use of. From the consumer's point of view, this is necessary. The argument in my mind is not "Is it the best operating system?" but "Can my mother use it and load software that her friends use?"

The article simply points out that Linux is not there yet and may never be. I know there is word processing software and X Windows (windowsy)-looking shells, but that isn't the point. The point is this: Will 90% of the consumer public use it and, if they do, will they continue using it if they can't get it loaded easily and/or use the existing programs and gaming gear they may already own?

And if Linux bulks up to provide that kind of usefulness, hasn't it just become heavier and a Unix (Linux) version of Windows?

If [you haven't] noticed from the previous discussion, I am devoted to Microsoft technology. Much of this is due to the ease of interoperability between [Microsoft] and other OSes. Therefore, I enjoyed someone finally stating in a publication that there is a vibrant, existing Web application server approach that is not freshly out of beta and served at Starbucks.

There are many of us who use and have been using Visual Basic behind the Web server for many years. And we can use all of the tools that have been available to do things like asynchronously talk to CICS applications via APPC, connect a Unix file system with NFS, get RMS data on OpenVMS boxes like they were access databases, and so on.

Also, thanks for putting out an article ("Visual Basic stays strong in the e-commerce world," February 2000, p. 49) that shows what the classified ads in my paper say — that a good 60% or more of Web developer jobs are for Active Server Pages and Visual Basic server-side programming. I've been using Visual Basic for Web applications for about four years, starting with O'Reillys Web site. I've been using Visual Basic to produce XML solutions for customers for a good year and a half. It's there and it works.

Jim Huffer
[email protected]

Split Decision

This is about the front cover of the April issue — the one that's cut down the middle to open out to some ad inside. Please don't ever do that again! The magazine becomes so darn awkward and uncomfortable to hold that I just ended up ripping the whole front off and throwing it away. Thought you might like to know.

John Bonavia
Needham, MA

Editor's Note: Thank you for the input. We always like to receive readers' feedback on stories, items of future interest and the overall design of the magazine. Please send your comments to Editor-in-Chief Mike Bucken via E-mail at [email protected].

Every OS Can Shine

This letter is in regards to "Keep it Simple" [Letters, p. 6] in the February 2000 issue. Of course Mr. Van den Heuvel will be able to move the Linux drive easily from system to system on minimally configured systems. I routinely do the same with DOS, Windows 3.x/95/98/NT/2000. (And the systems I do it on are not nearly as minimal as the ones he described.) Anyone who carefully plans out their hardware in advance should have a smooth install, whether it is a minimal system or not.

In addition, if you do the standard installs, you do not get the most out of the system. Custom installs do not take much longer and, if done properly, will result in a much better system. Nor should the rest of the default settings be so easily accepted either. I was quite surprised to hear a Linux person speak of so plain a setup — the true power of Unix being its flexibility. If you want a straight system with few options, go to a Mac (though even those have options for those who know where to look).

Overall research is the key to a smooth install of hardware, software or an operating system. If this is done, the process generally goes very smoothly. Those who do not do this produce the nasty configurations that are such a mess for IT professionals. As to the performance he noted, any GUI OS is bound to be slower than a command-like one, and it is true that NT has a great deal of overhead. However, every OS can be configured so that it shines.

With all the potential in today's systems, it is a shame for a computer professional to preach such archaic configurations.

Joel Munt
Crosslake, MN
[email protected]

Utopian Promises

Ibegan to read the article "Components crucial for e-business development," in the March issue of ADT [p. 57] with interest. However, I'm sorry to say this interest quickly turned to disdain. The article is full of platitudes and, as far as I could tell, was the centerpiece of the March issue. I do not wish to offend the authors, but this is all far too good to be true — in fact the whole article is a litany of truisms!

Let's take a brief look at one or two of the points that were made in the article. To begin with, the biggest problem is the fictitious company (which has to be fictitious) that looked at three high-level alternatives: build from scratch, procure or develop using components.

Develop from components was chosen by the fictitious crew because the focus would be on business logic rather than on low-level technical detail, the design would be better and standard component interfaces could be utilized. I can appreciate the standards piece and the better design, but please let's not fool people into believing that a CBD project will be easier than any other approach the first time around or involve any less work. Lots of technical issues will need to be solved — granularity, state management, scalability and security to name but four.

Of course, the fictional characters were able to cut down on development by "evaluating the components that they would need to buy that would give them the core functionality to assemble their e-commerce applications." After a thorough analysis, we are told, they were able to acquire an initial set of components. Get real! This is where we would all like to be, but in the real world, this is where we find that the components aren't there and we either have to build them (option 1), or buy something that doesn't quite fit (option 3). You have to make compromises in the real world.

A final juicy piece for your delectation: "The developers used their existing Integrated Development Environment (IDE) to assemble the application."

CBD is worthwhile, don't get me wrong. It provides standard ways of doing what good developers always did: It promotes service-orientation instead of object-orientation. Put another way, it does a good job of encapsulating object-orientation. It is not, however, a panacea. And it is not easy (to get right). There are all sorts of hard issues to be tackled — how to get the granularity right, how to reduce dependencies on databases shared by components, how to manage load balancing, security, legacy integration, state management ... need I go on? After the fourth or fifth project — if management has the staying power to let you get that far — the rewards will become reapable. This article suggests that complex solutions can be solved with relative ease the first time around, which is simply not the case. This sort of utopian promise simply works against non-fictitious practitioners — but by that time the utopians will have moved on to herald the next miracle.

Tim Barrett
ComCor I.T Solutions b.v.
[email protected]

Stop Rewarding Techno-babble

I enjoyed reading David Chappell's article "Exploring the terminology jungle," in the April issue of Application Development Trends [p. 26].

My take on the confusing terminology is, perhaps, more gloomy than the author's own. While Mr. Chappell's article focused on Microsoft, my opinion is that there is a dominant culture in the information technology community that rewards vague and confusing terminology, meaningless acronyms and bad grammar. I refer to it as techno-babble.

Back in the "old days" (oops, I guess I'm irrelevant and outdated because I'm over the age of —), I remember that you were quickly brought up short if you used too many acronyms or technical terms. And if you did use a technical term, you had better understand it and use it properly!

Now it seems the more terms, and the vaguer they are, the better. It's even better if the word doesn't exist because it's a perversion of proper word formation. Functionality? Can't find it in the dictionary —perhaps "function" is the word? Or what about extensibility, and being "incented" to use the "extensibility" of something? If I hear that too much, I tend to get incensed. Was that what they wanted to accomplish when they used the phrase?

It sure would be nice to start seeing more articles that point out that, in order to communicate, the sender must send a comprehensible message that the receiver can understand. Techno-babble doesn't accomplish that.

Walt Calkins
National Systems Evolution Planner
[email protected]