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
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.
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
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
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.
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
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.
ComCor I.T Solutions b.v.
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.
National Systems Evolution Planner